From owner-ietf-calendar@mail.imc.org Fri Feb 1 08:56:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22105 for ; Fri, 1 Feb 2002 08:56:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11Dkkl02423 for ietf-calendar-bks; Fri, 1 Feb 2002 05:46:46 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Dki302419 for ; Fri, 1 Feb 2002 05:46:44 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id IAA12315 for ; Fri, 1 Feb 2002 08:46:40 -0500 Received: from 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 g11DkdQ06051 for ; Fri, 1 Feb 2002 08:46:39 -0500 (EST) Message-ID: <3C5A9E17.B0C6677A@steltor.com> Date: Fri, 01 Feb 2002 08:54:31 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Initial connection to CAP server? 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 Using the search command with the calstore as the target and the following query: SELECT RELCALID FROM VAGENDA WHERE OWNER = SELF() Should return the calendar(s) owned by the user. "Shannon J. Clark" wrote: > > A question occurred to me about initial connections to a Calendar Server: > > How does a user learn what their Calendar is? i.e. the first time a user > connects to a given CS and validates identity in some manner - how do they > learn what their Calendar Address is? > > Shannon > > Shannon J. Clark > President - JigZaw, Inc > 1.800.4.JIGZAW (454.4929) > shannon@jigzaw.com > www.jigzaw.com From owner-ietf-calendar@mail.imc.org Fri Feb 1 10:35:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26901 for ; Fri, 1 Feb 2002 10:35:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11FOxw07323 for ietf-calendar-bks; Fri, 1 Feb 2002 07:24:59 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11FOw307319 for ; Fri, 1 Feb 2002 07:24:58 -0800 (PST) To: ietf-calendar@imc.org Subject: RE: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 1 Feb 2002 10:32:12 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/01/2002 10:32:18 AM, Serialize complete at 02/01/2002 10:32:18 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Just a quick comment... how would you "know" which to use? All of them are equivalent; you pick the one that best matches the user's locale. I suppose, if you don't know the locale, you use the LOCATION instead of any of the ALT-LOCATIONs. /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===========================================================| |Sleep is for wimps--healthy, well-adjusted wimps, but wimps| |nonetheless. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 1 10:35:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26918 for ; Fri, 1 Feb 2002 10:35:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11FKrO07154 for ietf-calendar-bks; Fri, 1 Feb 2002 07:20:53 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11FKq307149 for ; Fri, 1 Feb 2002 07:20:52 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 1 Feb 2002 10:28:05 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/01/2002 10:28:12 AM, Serialize complete at 02/01/2002 10:28:12 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >We could invent something like ALT_LOCATION, ALT_SUMMARY, ... >to mean alternate: Yeah, this would be a good approach. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===============================================================| |Dave Barry for President! He'll Keep Dan Quayle. (OK, it's old)| \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 1 10:38:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26951 for ; Fri, 1 Feb 2002 10:38:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11FOFN07296 for ietf-calendar-bks; Fri, 1 Feb 2002 07:24:15 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11FOE307292 for ; Fri, 1 Feb 2002 07:24:14 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 1 Feb 2002 10:31:27 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/01/2002 10:31:34 AM, Serialize complete at 02/01/2002 10:31:34 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Not without breaking compatibility with 2445. > >It would break iTIP, but I don' think that there are >restriction tables in 2445. It's in the ABNF, though. /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===========================================================| |Sleep is for wimps--healthy, well-adjusted wimps, but wimps| |nonetheless. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 1 10:46:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27155 for ; Fri, 1 Feb 2002 10:46:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11FQsY07375 for ietf-calendar-bks; Fri, 1 Feb 2002 07:26:54 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11FQr307368 for ; Fri, 1 Feb 2002 07:26:53 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC-2445: Re: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 1 Feb 2002 10:34:06 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/01/2002 10:34:13 AM, Serialize complete at 02/01/2002 10:34:13 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >ALT-LOCATION (with a '-' and not a '_') sounds good to me. Of course, we should specify that ALT-foo can appear more than once. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===============================================================| |Campbell's has it wrong--it's "Never underestimate the power of| |*chocolate*". | \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 1 11:24:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02020 for ; Fri, 1 Feb 2002 11:24:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11GAjS08728 for ietf-calendar-bks; Fri, 1 Feb 2002 08:10:45 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11GAh308724 for ; Fri, 1 Feb 2002 08:10:43 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA16121 for ; Fri, 1 Feb 2002 11:10:39 -0500 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 g11GAcQ22194 for ; Fri, 1 Feb 2002 11:10:38 -0500 (EST) Message-ID: <3C5ABE66.B06F03E3@steltor.com> Date: Fri, 01 Feb 2002 11:12:22 -0500 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: CAP: WHAT MISSING TEXT ON VCAR??? (Was: Re: CAP: CAR-MIN vs CAR-FULL-1) References: <3C59703D.3EBBB6F3@steltor.com> <3C599C69.67357158@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: > > No - CAR-MIN (and its text needs to be added back into CAP), > ... > CAP (again text needs to be re-added). > ... > When the text goes (back) into CAP Doug, AFAIK, everything that was submitted to the list on VCAR is already in the latest interim version of the draft. See : http://www.calsch.org/ietf/drafts.html Can you please acknowledge that? Or else, send the missing text ASAP. Regards, 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 Feb 1 12:09:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04087 for ; Fri, 1 Feb 2002 12:09:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11GuJc10035 for ietf-calendar-bks; Fri, 1 Feb 2002 08:56:19 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11GuI310031 for ; Fri, 1 Feb 2002 08:56:18 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA17688 for ; Fri, 1 Feb 2002 11:56:14 -0500 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 g11GuDQ27761 for ; Fri, 1 Feb 2002 11:56:14 -0500 (EST) Message-ID: <3C5AC915.91A97E7A@steltor.com> Date: Fri, 01 Feb 2002 11:57:57 -0500 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: CAP: CAR-MIN vs CAR-FULL-1 References: <3C59703D.3EBBB6F3@steltor.com> <3C599C69.67357158@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 latest interim version of the draft still does > > not provide sufficient information about the level > > of CAR support CAR-MIN and CAR-FULL-1. > > > > I would like to propose some text that could be > > included in the draft, but I'm missing some key > > information. > > > > 1- What is the purpose of CAR-MIN? > > > > a) Make CS vendors' life easier (i.e., not forced > > to provide full CAR support)? > > > > It seems that to implement CAR-MIN a vendor will > > have to implement CAR-FULL-1 and then add a > > restriction on the value of CARID. Why would a > > vendor restrict his implementation to CAR-MIN? > > Unless I'm missing something it's not easier to > > support CAR-MIN than CAR-FULL-1. > > No. If a CS does not understand 'VCAR' but does hard code > the predefined CARID's then it is CAR-MIN. The example > used was a palm pilot. It in effect is a mini-CS, and may > never implement CAR-FULL-1. Same with an IP cell phone. But we don't need different level of CAR support for that purpose. The CS will need to deny all users the right to write and modify VCARs in a hard coded decreed VCAR anyway. The CS could return the capability CAR-FULL-1 and that wouldn't make any difference. I don't mean to bug you, but I still don't see the purpose of CAR-MIN. > > b) Make CUA vendors' life easier (i.e., can query > > specific predefined VCARs by CARID to figure out > > easily if they are granted the right to perform a > > command or not)? Wouldn't this ability be lost > > when the CS supports CAR-FULL-1? > > Lost - no. > > A CUA can just ask 'can I post a METHOD:REQUEST' to this CS. > And NEVER implement CARs in the CUA. Well it would still need to implement CAR to be able to parse the returned VCAR with CARID:REQUESTONLY. Simply looking at the GRANT property won't be enough as there might be some additional restrictions in the definition of the VCAR to consider as well. > No it is not lost because the other end of the connection > may be CAR-MIN only so a CS MUST always understand and > compute them. > > A CUA that supports CAR-FUL-1 can ask for REQUESTONLY and still > support CAR-FUL-1. Yes. > > 2- What are the limitations implied by CAR-MIN? > > > > a) VAGENDA can only contains VCARs with predefined > > CARIDs (e.g., CARID:REQUESTONLY)? > > In a CS - yes - if a CS only supports CAR-MIN, then > that is all it has and it will not process any VCARs sent it. Do you mean that CAR-MIN implies that I won't be able to modify my own VCAR (e.g., CARDID:REQUESTONLY)? Again, it seems that a decreed VCAR would do the job. > They could conceivably be decreed and not changeable in the CS. > (it SHOULD still store them) > > If in a CUA - that is all they will ever ask for and will ignore > any sent to it (it SHOULD still store them). > > For a CS that supports CAR-FUL-1, when asked for any > of the CAR-MIN CARID's, it MUST compute the answer and > provide the results to the CUA. What you are saying is that the CUA doesn't need to care whether the CS supports CAR-MIN or CAR-FULL-1? It can always query the predefined CARID regardless of the CAR support. > > b) VAGENDA can only contains VCAR with a CARID > > value listed in the property DEFAULT_VCARS > > of the CALSTORE. > > No - CAR-MIN (and its text needs to be added back into CAP), > means the pre-defined CAR-MIN VCARs as defined in CAP > and that *at least* those are in DEFAULT_VCARS. I'm pretty sure we're on the same page, but just to make sure: CS MUST implement the VCARs with the predefined CARIDs. CAP doesn't impose any restriction on the definition of these VCARs. It simply suggests definitions for them. The CARID are predefined. Not the content of these VCARs. Correct? > CAR-MIN in a CS is a MUST. It MAY support CAR-FULL-1 > and those extra VCARs MAY be in DEFAULT_VCARS. Yes. > > 3- With CAR-MIN, could a user have multiple VCARs > > with the same predefined CARID (e.g., 2 VCARs > > with CARID:DEFAULTOWNER)? > > Not in the same scope (calendar). Okay. > > 4- When a CU is searching for a predefined CARID > > (e.g., CARID:REQUESTONLY) is the CS supposed: > > > > a) to look at all the VCARs (including the decreed > > VCARs) regardless of their CARID and returned a > > coalesced VCARs that contains information pertinent > > to the definition of that CARID only? > > Yes - that is one of the primary reasons they were invented. > > > Does anybody > > looked at how this could be implemented? > > The same as COLESED=TRUE and a QUERY were done with those > restrictions on the query. I understand how the CUA will request coalesced VCARs. It's just not clear to me yet, what the CS will need to do to return coalesced VCARs. > > > b) to look at all the VCARs with the specified CARID > > and return a coalesced VCAR? > > No, when asking for a CAR-MIN VCAR, it means look at everything > and return the COLESED result that applies as specified in > CAP (again text needs to be re-added). > > > 5- Are there any restrictions on the rights that can > > be granted or denied in VCARs with predefined CARIDs? > > For instance, could I grant all users the right to > > read all my VEVENTs in the VCAR with CARID:REQUESTONLY? > > When the text goes (back) into CAP, it will be clear that REQUESTONLY > only applies to the desire to know if you can deposit a METHOD:REQUEST > into the TARGET calendar. > > > 6- Does CAR-MIN impose restrictions on decreed VCARs? > > No - they can be decreed, they might not be decreed. How will I know if they are decreed or not? Clearly, specifying "decreed" in the CARID is not an option here. Regards, 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 Feb 1 12:13:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04370 for ; Fri, 1 Feb 2002 12:13:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11Gnnm09917 for ietf-calendar-bks; Fri, 1 Feb 2002 08:49:49 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Gnm309913 for ; Fri, 1 Feb 2002 08:49:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA15522 for ; Fri, 1 Feb 2002 08:49:48 -0800 (PST) Message-ID: <3C5AC728.2A5ABC5F@Royer.com> Date: Fri, 01 Feb 2002 09:49:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: WHAT MISSING TEXT ON VCAR??? (Was: Re: CAP: CAR-MIN vs CAR-FULL-1) References: <3C59703D.3EBBB6F3@steltor.com> <3C599C69.67357158@Royer.com> <3C5ABE66.B06F03E3@steltor.com> Content-Type: multipart/mixed; boundary="------------004FEBCA990DF706C1E732E6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------004FEBCA990DF706C1E732E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Doug, AFAIK, everything that was submitted to the list on > VCAR is already in the latest interim version of the draft. > > See : http://www.calsch.org/ietf/drafts.html > > Can you please acknowledge that? Or else, send the missing > text ASAP. I was looking a verion 06 and not looking at version 06 :-) --------------004FEBCA990DF706C1E732E6 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 ; Fri, 1 Feb 2002 12:14:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11GjFb09800 for ietf-calendar-bks; Fri, 1 Feb 2002 08:45:15 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11GjE309795 for ; Fri, 1 Feb 2002 08:45:14 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA15501; Fri, 1 Feb 2002 08:45:15 -0800 (PST) Message-ID: <3C5AC617.58E395B1@Royer.com> Date: Fri, 01 Feb 2002 09:45:11 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Initial connection to CAP server? References: <3C5A9E17.B0C6677A@steltor.com> Content-Type: multipart/mixed; boundary="------------CC285D952F63A85170BE2A37" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CC285D952F63A85170BE2A37 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > Using the search command with the calstore as the target and > the following query: > > SELECT RELCALID FROM VAGENDA WHERE OWNER = SELF() There is no list of properties for a "VAGENDA". Do we need to rename "10.2 Calendar Properties " ? --------------CC285D952F63A85170BE2A37 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 ; Fri, 1 Feb 2002 12:17:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11GrMW09998 for ietf-calendar-bks; Fri, 1 Feb 2002 08:53:22 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11GrL309994 for ; Fri, 1 Feb 2002 08:53:21 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA17644 for ; Fri, 1 Feb 2002 11:53:18 -0500 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 g11GrGQ27324 for ; Fri, 1 Feb 2002 11:53:16 -0500 (EST) Message-ID: <3C5AC864.3F3492DC@steltor.com> Date: Fri, 01 Feb 2002 11:55:00 -0500 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: Editors notes in CAP References: <3C589558.7D2F64C9@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: > > No - It means that if you don't have DELETE on the old > location, and WRITE on the new location PLUS the MOVE > permission (that I was defining) - you can't move. That's different from your previous proposal : > The MOVE permission means you have WRITE permission > on the TARGET calendar and DELETE permission > on the OLD-TARGET calendar. And the permissions do > not need to be reciprocal. Regarding your last proposal: 1- On which location would you need the MOVE permission? 2- You would still need READ permission on the old location. 3- It doesn't buy us anything to have an MOVE permission. If the user as READ and DELETE granted for the old location and WRITE granted for the new location he'll still be able to do "search", "create" and "delete" to move the object the hard way. Can you agree that we don't need a MOVE permission? Regards, 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 Feb 1 13:34:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06960 for ; Fri, 1 Feb 2002 13:34:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11IGUu12355 for ietf-calendar-bks; Fri, 1 Feb 2002 10:16:30 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11IGS312351 for ; Fri, 1 Feb 2002 10:16:28 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA19719 for ; Fri, 1 Feb 2002 13:16:24 -0500 Received: from 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 g11IGOQ07016 for ; Fri, 1 Feb 2002 13:16:24 -0500 (EST) Message-ID: <3C5ADD4F.FA6AB408@steltor.com> Date: Fri, 01 Feb 2002 13:24:15 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Initial connection to CAP server? References: <3C5A9E17.B0C6677A@steltor.com> <3C5AC617.58E395B1@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: > > Patrice Lapierre wrote: > > > > Using the search command with the calstore as the target and > > the following query: > > > > SELECT RELCALID FROM VAGENDA WHERE OWNER = SELF() > > There is no list of properties for a "VAGENDA". > > Do we need to rename "10.2 Calendar Properties > " ? Yes I believe so, the descriptions of the properties PARENT and RELCALID suggest that the section refers to VAGENDA. Note: to be consistent with other components, it seems that the property TOMBSTONE should be replaced by METHOD:DELETE. From owner-ietf-calendar@mail.imc.org Fri Feb 1 13:57:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08006 for ; Fri, 1 Feb 2002 13:57:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11IXkk12783 for ietf-calendar-bks; Fri, 1 Feb 2002 10:33:46 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11IXj312777 for ; Fri, 1 Feb 2002 10:33:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA15727 for ; Fri, 1 Feb 2002 10:33:46 -0800 (PST) Message-ID: <3C5ADF85.7572C3A8@Royer.com> Date: Fri, 01 Feb 2002 11:33:41 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Editors notes in CAP References: <3C589558.7D2F64C9@Royer.com> <3C5AC864.3F3492DC@steltor.com> Content-Type: multipart/mixed; boundary="------------D35852D5B63C7AB1210039A8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D35852D5B63C7AB1210039A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > 3- It doesn't buy us anything to have an MOVE permission. > If the user as READ and DELETE granted for the old location > and WRITE granted for the new location he'll still be able > to do "search", "create" and "delete" to move the object > the hard way. Yes - you are right. But after thinking about it more, I think we are both off the mark. I think the the real definition is: You need to be able to add a new instance of the RELATED-TO property to the new location. You would do that with a MODIFY. It is a MODIFY because there may already be instances of RELATED-TO in the new location. So you have to MODIFY the new location to also contain the new RELATED-TO calid. You need MODIFY permission in order to remove an instance of RELATED-TO from the old location. You don't DELETE the RELATED-TO from the old location because there may be multiple instances that your are not removing. So you have to MODIFY the VAGENDA so it no longer contains that specific instance. So I don't think that READ or WRITE permission is what you need. --------------D35852D5B63C7AB1210039A8 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 ; Fri, 1 Feb 2002 14:08:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11IsXM13268 for ietf-calendar-bks; Fri, 1 Feb 2002 10:54:33 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11IsW313264 for ; Fri, 1 Feb 2002 10:54:32 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA21129 for ; Fri, 1 Feb 2002 13:54:29 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g11IsSQ12442 for ; Fri, 1 Feb 2002 13:54:28 -0500 (EST) Message-Id: <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Feb 2002 13:51:09 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: Last CallByMarchIETF: Need Volunteers!] In-Reply-To: <3C59842C.10943E84@Royer.com> References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable At 10:51 AM 1/31/2002 -0700, you wrote:
Mark Paterson wrote:
>
> At 02:57 PM 1/18/2002 -0700, Doug Royer wrote:
>
> ...
>
> > Use SEQUENCE. Only the ORGANIZER can update the SEQUENCE number.
>
> ....
>
> Sorry for taking so long to get back on this thread. My day job got in
> the way :-)
>
> I didn't quite get what you meant about older data appearing newer
> then newer data at first but I suppose some CS implementations where
> all messages ever sent are kept I suppose this is possible but all
> this means is that when we do a query for changes a sync CUA needs to
> be careful to filter out those objects whose SEQUENCE appears older
> then the SEQUENCE which the sync CUA last remembers. It=20 doesn't
> resolve my questions. A sync CUA is still not going to fetch each and
> every object it knows about to check the latest SEQUENCE to determine
> changes. This would be way too heavy on the CS.

I did not mean to imply that. I meant that LAST-MODIFIED only
tells you that it has been modified. It does not mean that
it is more-valid data simply because it has a newer time stamp.

Sorry. I misunderstood you. You made it sound as if SEQUENCE was the solution to all our problems.


> Let's try pulling back on reigns and refocus on my original questions.
> My claim was that in order for CAP to live up to the Sync requirements
> listed in the CAP Requirements a Sync CUA must be able to get the
> answers to the following 3 questions:
>
> 1) Within the given date range what entries are new?
> 2) Within the given date range what entries have changed?
> 3) Within the given date range what entries have been deleted?
>
> Having followed the CAP-QL thread its perhaps time I took a crack at
> building my own queries. I've made a few simplifying assumptions. I've
> just worried about events, I've used DTSTART to determine if something
> is in range and rather then figuring out what attributes to retrieve
> I've just put "*". So here we go:
>
> BEGIN:VQUERY
> EXPAND:TRUE
> QUERY:SELECT * FROM VEVENT WHERE
> DTSTART < upper_range
> AND DTSTART > lower range
> AND DTSTAMP > last_time_asked
> END:VQUERY

 (replace DTSTAMP with LAST-MODIFIED and I think it is right,
  I incorrectly used DTSTAMP when I should have said LAST-MODIFIED.
  DTSTAMP is the time the iCalendar object was created for transport
  and is ALWAYS updated [per iTIP?] just before transporting the
  object.)

Yes, LAST-MODIFIED. Sorry you mentioned DTSTAMP in an earlier replied and I switched over with out even really realizing I'd done so.


> If the Sync CUA then filters out any objects whose SEQUENCE seems to
> indicate that it is actually older then what the Sync CUA last knew
> about (as per Doug's suggestion) then the results that remain should
> be all the changes within the range.

Yes, and by also filtering out from the returned set any
with the same UID and older SEQUENCE numbers in the return set.
As in if there were 5 updates between your sync times, you may get:

   UID:1, and 5 objects, with SEQUENCE numbers 1 2 3 4 5

Where only '5' would be the newest and 1, 2, 3, 4 are discarded
using iTIP rules.

For the issue of sync I'll just say yes. If a CS is implemented in this fashion then yes this is what I meant. The Sync CUA should filter out everything out but the latest and greatest.

With respect to CAP-QL however perhaps a separate thread could be started since if I were a CUA developer I don't necessarily want to get every sequence and have to filter out the old stuff (seems like a lot of unnecessary byte count).

If am retrieving event data to populate say a week view then I think I'd go:

BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT WHERE
DTSTART < end of the week
DTSTART > beginning of the week
END:VQUERY

This should get me all the booked and unbooked events for the week. As a CUA I shouldn't have to filter through the SEQUENCE for each event I get back. If so how do I change the query to just get the latest. I checked in draft 06 and the VQUERY examples do not hint that this is the case (then again they don't hint that it isn't) and nothing within the current CAP-QL threads has addressed this as far as I know.

Anyhow this does not effect whether CAP is OK with respect to sync so for now let's say they get filtered.


> By enumerating through the
> results a Sync CUA can determine everything that is new by the objects
> whose UID it doesn't recognize, ...

Yes.

> ... everything that has changed by the
> objects whose UID it does recognize, ..

No - changes would have the same UID for the same objects
and has a newer SEQUENCE number.

That's what I said. Why are you disagreeing with me? I think we agree. The UIDs are the same so the sync CUA recognizes them and therefore knows they aren't new, hence they should be handled as objects which have had changes to them.


> .. and finally everything tha= t has
> been deleted from the objects within the changed list who now are
> marked with METHOD:DELETE (as long as CUAs are forced to use this
> method to delete objects).

iCalendar objects are marked for delete with METHOD:MODIFY.
They are deleted from the CS by <delete/>.

Yes I know. To quote you from later in this message "objects are marked for delete by using METHOD:MODIFY and changing the object in the store to METHOD:DELETE" which is all I meant.

Anyhow I think if it weren't for those annoying recurring entities we are both in agreement that my query (with LAST_MODIFIED) covers things for sync.

We need to agree on the issues with respect to recurring entries next.


>
> What about instances of a recurring object?
>
> The EXPAND:TRUE line in the query should ensure that all new and
> changed instances get returned. Correct?

Yes and all existing and unchanged instances.

This could be but I'm not sure this is actually specified anywhere within the CAP-QL text. Should I get the master event and its UID along with all its baby instances expanded out with their own RECURRENCE-ID or should I just get the instances falling within the range I've queried over?

Also, do I really need to put EXPAND:TRUE? I put it there since I thought it was needed to get anything back since if it weren't expanded then their would be no DTSTART values falling with the range but I suppose you could also say that with EXPAND:FALSE that you'd still get back recurring entries that have changed with recurrence sets that would cause an instance to fall within your query range with the difference being in the results you get back you just have the master event with its UID and recurrence set unexpanded (no babies hanging on :-) ).

Perhaps some text to make the answers to these questions clearer is needed. I'll let those of you contributing to the CAP-QL threads work it out :-).

As far as sync goes I think in the case of both questions either answer gives a Sync CUA a way to get new and changed instances of a recurring entry within a range.


> The problem is still deleted instances. I don't think EXPAND:TRUE will
> make sure that the Sync CUA gets returned instances marked with METHOD
> DELETE within the range. If it does then we're covered but I somehow
> don't think that's the way it is (comments from the CAP-QL gang?).

The instances of objects with a RECURRENCE-ID do not exists anyway.
They are an expansion of an existing object that is expanded and
for booked objects only. The ORGANIZER never sends a METHOD:REQUEST
object that contains a RECURRENCE-ID.

Of course not. I was speaking figuratively. That's why it's not covered.


And don't forget about METHOD:CANCEL sent by the ORGANIZER,
which can cancel entire objects or specific instances.

Quoting you from a past reply "And we need to add text about METHOD:DELETE and how that is the way to mark something as deleted." and I agree with you.


So, if the EXPAND:FALSE object is marked METHOD:DELETE, then ALL
of the instances are deleted and that object will NEVER have
a RECURRENCE-ID property (because EXPAND is FALSE).

When you say "the EXPAND:FALSE object" do just mean the VEVENT with its UID, recurence set, etc.. or do actually mean that it is considered marked as EXPAND:FALSE and then after someone does a VQUERY with EXPAND:TRUE it will get expanded, all the instances will get expanded out (with RECURRENCE-IDs being assigned) and then from then on it is a VEVENT marked EXPAND:TRUE?

I can see the logic to that but I never realized that this was the implication of querying with EXPAND:TRUE. Perhaps some explanatory text within the CAP-QL text is needed.

If this is what you mean then this should be OK for sync. If a VEVENT hasn't yet been expanded then it hasn't been sync'd to your PDA, Phone, whatever yet so the fact that it now doesn't exist is fine. The other end never new about them. I'll try that one more time. If a Sync CUA uses EXPAND:TRUE in its queries (like I've done above) then EXPAND:FALSE objects (to use your term) couldn't yet have been sent to the device (or whatever you are synching with) so the fact that they now won't be is fine.

The problem is still the instances that did result from EXPAND:TRUE that are now gone.


iTIP allows for updates to instances of objects. When that happens
there can be multiple objects created:

        'One' new object with an updated SEQUENCE

        'More than one' object each with the SAME UID and SEQUENCE.
        And each object specifying one or more instances.
        (see ADD in iTIP) - and all booked.

And if an object is METHOD:CANCEL, then its containing
DTSTART, DTEND/DURATION, RRULE, EXRULE, RDATE, and EXDATE=20 properties
specific instances that have been canceled, for the same
SEQUENCE number and UID objects. (see iTIP).

> Instead another query such as this is needed I think:
>
> BEGIN:VQUERY
> EXPAND:TRUE
> QUERY:SELECT * FROM VEVENT WHERE
> EXDATE < upper_range
> AND EXDATE > lower range
> AND DTSTAMP > last_time_asked
> END:VQUERY
>
> This would give a Sync CUA any newly changed recurring objects with
> exceptions within the range, I think?

No, an object can be modified and instances can be removed by
changing the RRULE and never adding a EXDATE. Or by adding
a RDATE, or by adding or altering a EXRULE, or by DTSTART,
or RECURRANCE-ID, ...

Yes I know. That's what my next paragraph says. That's my point. Once a recurring entry gets sync'd from then on if an instance is deleted using any method other then adding an EXDATE I can't think of a way to make query that ensures that the Sync CUA gets informed about the deleted instances which it previously sync'd.


> It will only work however if
> CUAs always add an EXDATE when an instance from a pre-existing
> recurrence set is deleted. If they just redo the recurrence=20 set
> completely then it becomes impossible.

Not impossible. Your first query (with LAST-MODIFIED) will
get all of the objects in that time range. Then the CUA
must compare using SEQUENCE and merging any multiple objects
with the same UID (originally created with ADD), then
it knows the state of the 'UID' object.

My first query doesn't get me all the objects in the time range, it get's me all the entries within the time range which have changed. There is a big difference. Anything the Sync CUA doesn't get, it assumes hasn't changed. There is no way of knowing that the reason it didn't get a recurring entry that used to have instances within this range is because it is gone. It just thinks it hasn't changed.

When I say that it is impossible I should perhaps say it is not possible in the way that the Sync CUA really needs.

A Sync CUA could take all the recurring entries it has sync'd in the past, figure out which ones aught to cause an instance to fall within the range being queried for and then do a query to get them from the CS individually to check but this would be a lot of extra calls to the CS and depending on your Sync model perhaps not even possible.

If you are building a Palm conduit or an Active Sync plug-in you can access the devices database so you could do this despite how ugly it seems but in the case of SyncML however I don't think you'd really be allowed to. In a SyncML scenario the SyncML client on the device authenticates against a Sync Server and reports its changes since the last time it initiated a sync. The Sync Server then asks the backend data store (the CAP CS in our world) for its changes since the last time a sync was done, it compares the two lists and sends each back instructions on what to change so that the two of them are good to go. The Sync Server does not have knowledge of the database on the device. In theory the SyncML protocol does have a search and get command so I guess the sync server could go back to the sync client and ask for the entries (but I've yet to see a SyncML client which implements these commands) but this flies in the face of the entire SyncML model. I'm sure the gang at the SyncML initiative would be horrified by my mere suggestion of this. The poor owner of the wireless device is paying by the second on a 2G network and by the packet on a 2.5G or 3G network so the extra trips back to the device will not be appreciated.


> If my logic holds true (and that remains to be seen. I need the
> expertise of the CAP-QL contributors) then text for the following
> should be added:
>
> 1. CUAs must use METHOD:DELETE to mark something as deleted.

Entire objects are marked for delete by using METHOD:MODIFY
and changing the object in the store to METHOD:DELETE.

It is NOT used when CANCELing instances of an object.

Hence the need for the text as suggested by you in a past response.


> 2. CUAs must use EXDATE to mark an instance within an existing
> Recurrence set as deleted rather than redefining the recurrence set.

No. That is not practical.

I admit it is rather restrictive but I can't think of any other way in which a Sync CUA could put together a set of queries and ensure that it gets told about deleted instances of recurring entries that it has previously sync'd.

I'd love it if someone else could suggest a query that'll do it. Anyone? It's the only sticking point keeping us from closing this issue as far as I can tell and I want it closed. This is far too much work. I have to go do the stuff I was supposed to do today now. I don't know how you guys do it :-).


> If we can do this and people agree that my logic makes sense then I
> think we can mark off the synchronization requirements for CAP as
> covered.

Not yet :-)

We're getting closer I think :-)

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@steltor.com
http://www.steltor.com



 From owner-ietf-calendar@mail.imc.org Fri Feb 1 14:17:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08833 for ; Fri, 1 Feb 2002 14:17:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11J8xk13586 for ietf-calendar-bks; Fri, 1 Feb 2002 11:08:59 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11J8w313581 for ; Fri, 1 Feb 2002 11:08:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA15805 for ; Fri, 1 Feb 2002 11:08:58 -0800 (PST) Message-ID: <3C5AE7C5.B0328C77@Royer.com> Date: Fri, 01 Feb 2002 12:08:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: CAR-MIN vs CAR-FULL-1 References: <3C59703D.3EBBB6F3@steltor.com> <3C599C69.67357158@Royer.com> <3C5AC915.91A97E7A@steltor.com> Content-Type: multipart/mixed; boundary="------------C1A95A93A32BB06417E91A98" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C1A95A93A32BB06417E91A98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > The latest interim version of the draft still does > > > not provide sufficient information about the level > > > of CAR support CAR-MIN and CAR-FULL-1. > > > > > > I would like to propose some text that could be > > > included in the draft, but I'm missing some key > > > information. > > > > > > 1- What is the purpose of CAR-MIN? > > > > > > a) Make CS vendors' life easier (i.e., not forced > > > to provide full CAR support)? > > > > > > It seems that to implement CAR-MIN a vendor will > > > have to implement CAR-FULL-1 and then add a > > > restriction on the value of CARID. Why would a > > > vendor restrict his implementation to CAR-MIN? > > > Unless I'm missing something it's not easier to > > > support CAR-MIN than CAR-FULL-1. > > > > No. If a CS does not understand 'VCAR' but does hard code > > the predefined CARID's then it is CAR-MIN. The example > > used was a palm pilot. It in effect is a mini-CS, and may > > never implement CAR-FULL-1. Same with an IP cell phone. > > But we don't need different level of CAR support for that > purpose. The CS will need to deny all users the right to > write and modify VCARs in a hard coded decreed VCAR anyway. > The CS could return the capability CAR-FULL-1 and that > wouldn't make any difference. So, the CUA would ask for one of the predefined VCARs and get a hard coded answer. The CS will NEVER need to understand any VCAR details. It can hard code the answer to the predefined VCARs in its ROM. A CS that has only the capability of CAR-MIN, is telling the CUA - I will ONLY reply to a VQUERY for the predefined VCARs. Any other VQUERY on a VCAR will result in an error. So do not put a QUERY in the VQUERY, other than by CARID. > I don't mean to bug you, but I still don't see the purpose > of CAR-MIN. So the CS can ONLY implement the predefined VCARs and NOT allow any other. The Palm Pilot "is" a mini-CS and it IS NOT going to implement CAR-FULL-1. > > > b) Make CUA vendors' life easier (i.e., can query > > > specific predefined VCARs by CARID to figure out > > > easily if they are granted the right to perform a > > > command or not)? Wouldn't this ability be lost > > > when the CS supports CAR-FULL-1? > > > > Lost - no. > > > > A CUA can just ask 'can I post a METHOD:REQUEST' to this CS. > > And NEVER implement CARs in the CUA. > > Well it would still need to implement CAR to be able to > parse the returned VCAR with CARID:REQUESTONLY. The CUA would, but not the CS. The CS can just return a hard coded (maybe decreed) value if it wants. If the CUA can not parse CAR-FULL-1, it is not going to ask for them. If the CUA can not parse ANY VCAR, it is not going to ask for any. But if the CUA DOES understand VCARs, it can ask a CAR-MIN CS for any VCAR defined in DEFAULT_VCARS, and get an answer. > Simply looking at the GRANT property won't be enough as there > might be some additional restrictions in the definition > of the VCAR to consider as well. The purpose of the predefined VCARs is spelled out in CAP. NO OTHER results should be returned. If the CUA can not parse the results - it should not ask for any results. CAR-MIN is the capability of the CS, not the CUA. The CUA will never ask for what it can not handle. But the CUA needs to know what the CS can handle. > > > 2- What are the limitations implied by CAR-MIN? > > > > > > a) VAGENDA can only contains VCARs with predefined > > > CARIDs (e.g., CARID:REQUESTONLY)? > > > > In a CS - yes - if a CS only supports CAR-MIN, then > > that is all it has and it will not process any VCARs sent it. > > Do you mean that CAR-MIN implies that I won't be able to > modify my own VCAR (e.g., CARDID:REQUESTONLY)? If a CS says it is CAR-MIN, then the ONLY VQUERY you can do on it is by CARID. BEGIN:VQUERY QUERY:SELECT from WHERE CARID = END:VQUERY And MUST be in DEFAULT_VCARS. We do not have a CAR-MIN VCAR that tells a CUA if it can modify any VCAR or not on a CAR-MIN CS. So there is no way to ask a CAR-MIN CS that question. > Again, it seems that a decreed VCAR would do the job. Decreed means 'hard coded and not changeable by the CUA'. It does not mean that it is predefined in CAP. So you could change any NON-decreed VCARs in a CAR-MIN CS. (Assuming one of the decreed or nondecreed VCARs allows it.) > > They could conceivably be decreed and not changeable in the CS. > > (it SHOULD still store them) > > > > If in a CUA - that is all they will ever ask for and will ignore > > any sent to it (it SHOULD still store them). > > > > For a CS that supports CAR-FUL-1, when asked for any > > of the CAR-MIN CARID's, it MUST compute the answer and > > provide the results to the CUA. > > What you are saying is that the CUA doesn't need to care > whether the CS supports CAR-MIN or CAR-FULL-1? Yes - If is all it wants to know is the DEFAULT-VCARS. Which the CS MUST include at least the predefined CARID VCARs. In this way ANY CUA that understands VCARs can do the minimum CARID queries. If a CUA wants to know more - it MUST talk to a CAR-FULL-1 CUA. If a CUA asks a CAR-MIN CS for more than what is provided in the DEFAULT-VCARS - the CAR-MIN CS will return an error because it can not process them. > It can always query the predefined CARID regardless of the CAR > support. Yes. > > > 4- When a CU is searching for a predefined CARID > > > (e.g., CARID:REQUESTONLY) is the CS supposed: > > > > > > a) to look at all the VCARs (including the decreed > > > VCARs) regardless of their CARID and returned a > > > coalesced VCARs that contains information pertinent > > > to the definition of that CARID only? > > > > Yes - that is one of the primary reasons they were invented. > > > > > Does anybody > > > looked at how this could be implemented? > > > > The same as COLESED=TRUE and a QUERY were done with those > > restrictions on the query. > > I understand how the CUA will request coalesced VCARs. > It's just not clear to me yet, what the CS will need > to do to return coalesced VCARs. I'll be happy to sell you a license for my code in a few months :-) >> >>> 6- Does CAR-MIN impose restrictions on decreed VCARs? >> >> No - they can be decreed, they might not be decreed. > > How will I know if they are decreed or not? Clearly, > specifying "decreed" in the CARID is not an option here. Why? If a CUA asks for UPDATEPARTSTATUS VCAR and gets back (assume we go with the decreed parameter): ... CARID;decreed=true:UPDATEPARTSTAUS GRANT... ... There is NO way to ask a CAR-MIN CS if you can update your VCARs anyway. --------------C1A95A93A32BB06417E91A98 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 ; Fri, 1 Feb 2002 14:24:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11JBiL13696 for ietf-calendar-bks; Fri, 1 Feb 2002 11:11:44 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11JBh313691 for ; Fri, 1 Feb 2002 11:11:43 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA15847 for ; Fri, 1 Feb 2002 11:11:44 -0800 (PST) Message-ID: <3C5AE86B.2F4D6C07@Royer.com> Date: Fri, 01 Feb 2002 12:11:39 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Initial connection to CAP server? References: <3C5A9E17.B0C6677A@steltor.com> <3C5AC617.58E395B1@Royer.com> <3C5ADD4F.FA6AB408@steltor.com> Content-Type: multipart/mixed; boundary="------------6980CAB0A1AE8866D2967052" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6980CAB0A1AE8866D2967052 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > Note: to be consistent with other components, it seems that the > property TOMBSTONE should be replaced by METHOD:DELETE. Do you mean change TOMBSTONE to METHOD, and that may have a A value of DELETE or CREATE ? --------------6980CAB0A1AE8866D2967052 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 ; Fri, 1 Feb 2002 14:25:30 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11J6Cc13504 for ietf-calendar-bks; Fri, 1 Feb 2002 11:06:12 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11J6B313500 for ; Fri, 1 Feb 2002 11:06:11 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA21391 for ; Fri, 1 Feb 2002 14:06:07 -0500 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 g11J67Q13585 for ; Fri, 1 Feb 2002 14:06:07 -0500 (EST) Message-ID: <3C5AE787.DE9AD268@steltor.com> Date: Fri, 01 Feb 2002 14:07:51 -0500 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: Editors notes in CAP References: <3C589558.7D2F64C9@Royer.com> <3C5AC864.3F3492DC@steltor.com> <3C5ADF85.7572C3A8@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: > > > 3- It doesn't buy us anything to have an MOVE permission. > > If the user as READ and DELETE granted for the old location > > and WRITE granted for the new location he'll still be able > > to do "search", "create" and "delete" to move the object > > the hard way. > > Yes - you are right. > > But after thinking about it more, I think we are both off the mark. > > I think the the real definition is: > > You need to be able to add a new instance of the RELATED-TO property > to the new location. You would do that with a MODIFY. It is a > MODIFY because there may already be instances of RELATED-TO in > the new location. So you have to MODIFY the new location to also > contain the new RELATED-TO calid. > > You need MODIFY permission in order to remove an instance of > RELATED-TO from the old location. You don't DELETE the RELATED-TO > from the old location because there may be multiple instances > that your are not removing. So you have to MODIFY the VAGENDA so > it no longer contains that specific instance. This is not an issue. This WG has agreed to drop hierarchial calendars and fanout is out of scope. Since all VAGENDA MUST be stored under CALSTORE where would you want to move them? > > So I don't think that READ or WRITE permission is what you need. For components that can be moved across targets (i.e., VAGENDA and CALSTORE) I need READ and DELETE for the old location and WRITE for the new location. We don't need a MOVE permission, and we don't need the MODIFY permission to be granted on either the old or the new location to be allowed to move components across targets (i.e., VAGENDA and CALSTORE). Agreed? Regards, 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 Feb 1 14:32:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09534 for ; Fri, 1 Feb 2002 14:32:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11JJWi13962 for ietf-calendar-bks; Fri, 1 Feb 2002 11:19:32 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11JJV313958 for ; Fri, 1 Feb 2002 11:19:31 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP & BEEP: Initial connection MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 1 Feb 2002 14:19:28 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/01/2002 02:19:35 PM, Serialize complete at 02/01/2002 02:19:35 PM Content-Type: multipart/alternative; boundary="=_alternative 0069EA1385256B53_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069EA1385256B53_= Content-Type: text/plain; charset="US-ASCII" Dogu replied: >[I MOVED THIS TO THE WG LIST] So I see. I was just trying to get an understanding of the comments made on the CAP Editors call but they eventually come to the list so... >If you read BEEP you will know :-) But Im reading CAP since thats the protocol we are defining. If one must read BEEP to grok this normal CAP function then you had better _clearly_ state that WAY up front! I dont mind having to read other docs but my cited text clearly does not reflect or even imply this! >Yes I too think it needs to explicitly say how. Great however thats not what it sounded like on the editors call, hence my question. I hope the CAP editors can provide at least starter text in the next update (or two)... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0069EA1385256B53_= Content-Type: text/html; charset="US-ASCII"
Dogu replied:
>[I MOVED THIS TO THE WG LIST]
So I see.  I was just trying to get an understanding of the comments made on the CAP Editors call but they eventually come to the list so...

>If you read BEEP you will know :-)
But Im reading CAP since thats the protocol we are defining.  If one must read BEEP to grok this normal CAP function then you had better _clearly_ state that WAY up front!  I dont mind having to read other docs but my cited text clearly does not reflect or even imply this!  

>Yes I too think it needs to explicitly say how.
Great however thats not what it sounded like on the editors call, hence my question.  I hope the CAP editors can provide at least starter text in the next update (or two)...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0069EA1385256B53_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 1 14:53:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10158 for ; Fri, 1 Feb 2002 14:53:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11Ji6f14852 for ietf-calendar-bks; Fri, 1 Feb 2002 11:44:06 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Ji4314847 for ; Fri, 1 Feb 2002 11:44:05 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA23013 for ; Fri, 1 Feb 2002 14:44:01 -0500 Received: from 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 g11Ji1Q20164 for ; Fri, 1 Feb 2002 14:44:01 -0500 (EST) Message-ID: <3C5AF1D8.6F2950DD@steltor.com> Date: Fri, 01 Feb 2002 14:51:52 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Initial connection to CAP server? References: <3C5A9E17.B0C6677A@steltor.com> <3C5AC617.58E395B1@Royer.com> <3C5ADD4F.FA6AB408@steltor.com> <3C5AE86B.2F4D6C07@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: > > Patrice Lapierre wrote: > > > > Note: to be consistent with other components, it seems that the > > property TOMBSTONE should be replaced by METHOD:DELETE. > > Do you mean change TOMBSTONE to METHOD, and that may have a > A value of DELETE or CREATE ? Initially I was not thinking of the value METHOD:CREATE (or BOOKED which ever is chosen). But yes it seems logical, VAGENDAs can be searched, created, deleted and modified with the same commands as other components. I don't see why the concept of marked as deleted should be expressed differently. The same principle probably applies to stored VQUERYs. From owner-ietf-calendar@mail.imc.org Fri Feb 1 15:06:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10666 for ; Fri, 1 Feb 2002 15:06:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11JuWw15081 for ietf-calendar-bks; Fri, 1 Feb 2002 11:56:32 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11JuV315077 for ; Fri, 1 Feb 2002 11:56:31 -0800 (PST) To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: RFC-2445: Re: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 1 Feb 2002 14:56:30 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/01/2002 02:56:34 PM, Serialize complete at 02/01/2002 02:56:34 PM Content-Type: multipart/alternative; boundary="=_alternative 006D4DD785256B53_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D4DD785256B53_= Content-Type: text/plain; charset="US-ASCII" John posited: >Of course, we should specify that ALT-foo can appear more than once. We are already covered by the existing ABNF: ; the following is optional, ; and MAY occur more than once (";" xparam) (Ok, technically we need to have a " (";" ianaparam) " clause but thats a known oversight thats to be corrected w/o any real impact on good engines. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D4DD785256B53_= Content-Type: text/html; charset="US-ASCII"
John posited:

>Of course, we should specify that ALT-foo can appear more than once.
We are already covered by the existing ABNF:

                ; the following is optional,
               ; and MAY occur more than once

               (";" xparam)

(Ok, technically we need to have a " (";" ianaparam) " clause but thats a known oversight thats to be corrected w/o any real impact on good engines.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006D4DD785256B53_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 1 15:11:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10813 for ; Fri, 1 Feb 2002 15:11:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11K2Bw15315 for ietf-calendar-bks; Fri, 1 Feb 2002 12:02:11 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11K29315309 for ; Fri, 1 Feb 2002 12:02:09 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC-2445: Re: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 1 Feb 2002 15:09:20 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/01/2002 03:09:31 PM, Serialize complete at 02/01/2002 03:09:31 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>Of course, we should specify that ALT-foo can appear more than once. > >We are already covered by the existing ABNF: Syntactically, maybe, but we need to make sure to cover multiples when we specify the semantics. Otherwise, an implementor might think that ALT-LOCATION can show up only once, like LOCATION. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |"All gateways lose information. Some do it more efficiently than| |others." -- Einar Stefferud | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 1 15:44:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11538 for ; Fri, 1 Feb 2002 15:44:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11KZAJ16236 for ietf-calendar-bks; Fri, 1 Feb 2002 12:35:10 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11KZ9316232 for ; Fri, 1 Feb 2002 12:35:09 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA24476 for ; Fri, 1 Feb 2002 15:35:07 -0500 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 g11KZ6Q26220 for ; Fri, 1 Feb 2002 15:35:06 -0500 (EST) Message-ID: <3C5AFC62.99D19512@steltor.com> Date: Fri, 01 Feb 2002 15:36:50 -0500 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: CAP: What is the purpose of CAR-MIN? 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 In my quest to find the purpose of CAR-MIN, I've been able to identify the following requirements. None of which requires that a CS should report a different level of CAP support. As it stands, CAP doesn't need two different values for the capability. 1- CS MUST implement VCARs for the following predefined CARIDs: READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER; Rational: At one point in time people in this WG believed it would make CUA's life easier. Comment : CAP doesn't impose any restriction on the definition of these VCARs. It simply suggests definitions for them. 2- It MUST be possible for a CS to deny all users the right to write, modify and delete any VCARs. Rational: A CS might want to hard code all its VCAR. Comment : Can easily be done with a decreed VCAR, potentially hard coded. 3- It MUST be possible for a CS to deny all users the right to write, modify and delete VCARs other than VCARs with the predefined CARID. Comment : Can easily be done with a decreed VCAR, potentially hard coded. 4- It MUST be possible for a CUA to search for VCAR based on their CARID (predefined or not). Comment : As is the case for all search operation, an empty response will be returned when no VCAR matches the VQUERY. 5- The VCAR with the predefined CARIDs MAY be decreed. Comment : Need to agree on way to differenciate decreed VCARs from non-decreed VCARs. See Doug's proposal (i.e., "decreed" parameter for the CARID property). 6- VCAR MUST have a CARID unique within the scope of the VAGENDA (or CALSTORE) in which they are stored. Rational: Identifiers are useful to manage objects. Open Issue: 1- Can a CS deny the right to READ the VCARs with the predefined CARIDs? Why not? Regards, 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 Feb 1 16:52:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12770 for ; Fri, 1 Feb 2002 16:52:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11LdK618100 for ietf-calendar-bks; Fri, 1 Feb 2002 13:39:20 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11LdI318096 for ; Fri, 1 Feb 2002 13:39:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA16129 for ; Fri, 1 Feb 2002 13:39:19 -0800 (PST) Message-ID: <3C5B0B01.5741298E@Royer.com> Date: Fri, 01 Feb 2002 14:39:13 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: LastCallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------97C3BEBA30B54E1F3E3D0E02" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------97C3BEBA30B54E1F3E3D0E02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > With respect to CAP-QL however perhaps a separate thread could be > started since if I were a CUA developer I don't necessarily want to > get every sequence and have to filter out the old stuff (seems like a > lot of unnecessary byte count). > > If am retrieving event data to populate say a week view then I think > I'd go: > > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT * FROM VEVENT WHERE > DTSTART < end of the week > DTSTART > beginning of the week > END:VQUERY > > This should get me all the booked and unbooked events for the week. As > a CUA I shouldn't have to filter through the SEQUENCE for each event I > get back. If so how do I change the query to just get the latest. I > checked in draft 06 and the VQUERY examples do not hint that this is > the case (then again they don't hint that it isn't) and nothing within > the current CAP-QL threads has addressed this as far as I know. > > Anyhow this does not effect whether CAP is OK with respect to sync so > for now let's say they get filtered. No - it gets everything you ask for in the VQUERY. If YOUR same CUA put the data there and did not do the filtering before depositing it in the CS, then you get it back. [PLUS I am going to reply to this in a separate post to explain more] If ANOTHER CUA (or CUA-bot) put it there, then your CUA needs to decide what to do with data - not the CS. A CS should not do anything more that store and get iCalendar objects. (You could have a CUA compiled into your CS that did smart things for you, but *that* or *those* features are still in a CUA). > > > By enumerating through the > > > results a Sync CUA can determine everything that is new by the > > objects > > > whose UID it doesn't recognize, ... > > > > Yes. > > > > > ... everything that has changed by the > > > objects whose UID it does recognize, .. > > > > No - changes would have the same UID for the same objects > > and has a newer SEQUENCE number. > > That's what I said. Why are you disagreeing with me? Okay - I must have misunderstood you. > I think we agree. > The UIDs are the same so the sync CUA recognizes them and therefore > knows they aren't new, hence they should be handled as objects which > have had changes to them. Yes. > We need to agree on the issues with respect to recurring entries next. > > > > > > > What about instances of a recurring object? > > > > > > The EXPAND:TRUE line in the query should ensure that all new and > > > changed instances get returned. Correct? > > > > Yes and all existing and unchanged instances. > > This could be but I'm not sure this is actually specified anywhere > within the CAP-QL text. Should I get the master event and its UID > along with all its baby instances expanded out with their own > RECURRENCE-ID or should I just get the instances falling within the > range I've queried over? You will get multiple objects. Each with the same UID, each with a RECURRENCE-ID. The 'master' object will not be returned as it is what was expanded. If EXPAND=TRUE, then you will get only the ones that have RECURRENCE-ID in the specified range - I think it is part of the (#3) proposal I sent out. If not, I'll add it to (#4) I am sending and checking in tonight. > Also, do I really need to put EXPAND:TRUE? I put it there since I > thought it was needed to get anything back since if it weren't > expanded then their would be no DTSTART values falling with the range > but I suppose you could also say that with EXPAND:FALSE that you'd > still get back recurring entries that have changed with recurrence > sets that would cause an instance to fall within your query range with > the difference being in the results you get back you just have the > master event with its UID and recurrence set unexpanded (no babies > hanging on :-) ). If EXPAND:FALSE then the 'master' object(s) are returned and they are not expanded into multiple 'baby' instances. If EXPAND:TRUE, then you do not get the 'master' object. You get multiple instances, each with the same UID and a unique RECURRANCE-ID (and other properties may be different between instances). > > > The problem is still deleted instances. I don't think EXPAND:TRUE > > So, if the EXPAND:FALSE object is marked METHOD:DELETE, then ALL > > of the instances are deleted and that object will NEVER have > > a RECURRENCE-ID property (because EXPAND is FALSE). > > When you say "the EXPAND:FALSE object" do just mean the VEVENT with > its UID, recurence set, etc.. or do actually mean that it is > considered marked as EXPAND:FALSE and then after someone does a VQUERY > with EXPAND:TRUE it will get expanded, all the instances will get > expanded out (with RECURRENCE-IDs being assigned) and then from then > on it is a VEVENT marked EXPAND:TRUE? I meant that the VQUERY was done with EXPAND:FALSE, and you get back an object marked METHOD:DELETE, then all of its instances are also METHOD:DELETE. If you were to VQUERY that same object with EXPAND=TRUE, you will get X number of objects, each with METHOD:DELETE and their RECURRANCE-ID. > I can see the logic to that but I never realized that this was the > implication of querying with EXPAND:TRUE. Perhaps some explanatory > text within the CAP-QL text is needed. yes. > If this is what you mean then this should be OK for sync. If a VEVENT > hasn't yet been expanded then it hasn't been sync'd to your PDA, > Phone, whatever yet so the fact that it now doesn't exist is fine. The > other end never new about them. I'll try that one more time. If a Sync > CUA uses EXPAND:TRUE in its queries (like I've done above) then > EXPAND:FALSE objects (to use your term) couldn't yet have been sent to > the device (or whatever you are synching with) so the fact that they > now won't be is fine. The 'EXPAND' parameter is not stored in the CS. EXPAND is simply the way for the CUA to tell the CS that it wants the CS to expand the 'master' object into instances, or that it wants THE 'master' object(s). > > No, an object can be modified and instances can be removed by > > changing the RRULE and never adding a EXDATE. Or by adding > > a RDATE, or by adding or altering a EXRULE, or by DTSTART, > > or RECURRANCE-ID, ... > > Yes I know. That's what my next paragraph says. That's my point. Once > a recurring entry gets sync'd from then on if an instance is deleted > using any method other then adding an EXDATE I can't think of a way to > make query that ensures that the Sync CUA gets informed about the > deleted instances which it previously sync'd. The LAST-MODIFIED in the object will be updated. Or there will be new objects with the same UID that have a newer LAST-MODIFIED than your sync time. So the a VQUERY where LAST-MODIFED will return them if they fall in the time range specified in the VQUERY. > > > It will only work however if > > > CUAs always add an EXDATE when an instance from a pre-existing > > > recurrence set is deleted. If they just redo the recurrence set > > > completely then it becomes impossible. > > > > Not impossible. Your first query (with LAST-MODIFIED) will > > get all of the objects in that time range. Then the CUA > > must compare using SEQUENCE and merging any multiple objects > > with the same UID (originally created with ADD), then > > it knows the state of the 'UID' object. > > My first query doesn't get me all the objects in the time range, it > get's me all the entries within the time range which have changed. Yes. All the objects in the time range you specified with the given restrictions. (a) If you replace DTSTART with RECURRANCE-ID and set EXPAND:TRUE you will get all instances that fall in the time range (modified or not). (b) If you replace DTSART with LAST-MODIFIED, and EXPAND:TRUE, you will get ALL instances of any expanded 'master' object where the 'master' object has been modified within your time range. This *is* what you want because if the 'master' object is changed, it may effect all of its instances. (c) If you make the QUERY: EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE LAST-MODIFIED > ...last-sync You will get ALL instances that have been modified since your last sync time. > There is a big difference. Anything the Sync CUA doesn't get, it > assumes hasn't changed. There is no way of knowing that the reason it > didn't get a recurring entry that used to have instances within this > range is because it is gone. It just thinks it hasn't changed. The CUA has the object, it gets the new objects with the updated LAST-MODIFIED time, the difference between the two is the difference. > When I say that it is impossible I should perhaps say it is not > possible in the way that the Sync CUA really needs. You have the old objects, you have the updated objects. What else do you need? > A Sync CUA could take all the recurring entries it has sync'd in the > past, figure out which ones aught to cause an instance to fall within > the range being queried for and then do a query to get them from the > CS individually to check but this would be a lot of extra calls to the > CS and depending on your Sync model perhaps not even possible. Or as they will all have the SAME UID's as the original object, just do one VQUERY for that (or those) UID's and set EXPAND=TRUE. The result will be the new object instances. If you perform a VQUERY looking for LAST-MODIFIED after a specified time, from the result set: - Delete from the CUA any that you have that did not come back. - Add any that the CUA does not have. - Update any where the data in the instance has changed. > If you are building a Palm conduit or an Active Sync plug-in you can > access the devices database so you could do this despite how ugly it > seems but in the case of SyncML however I don't think you'd really be > allowed to. In a SyncML scenario the SyncML client on the device > authenticates against a Sync Server and reports its changes since the > last time it initiated a sync. The Sync Server then asks the backend > data store (the CAP CS in our world) for its changes since the last > time a sync was done, it compares the two lists and sends each back > instructions on what to change so that the two of them are good to go. Sounds like a good proposal for an add on later draft to CAP. It could be a predefined VQUERY, GET-WHAT-CHANGED with a parameter containing a date-time. > The Sync Server does not have knowledge of the database on the device. > In theory the SyncML protocol does have a search and get command so I > guess the sync server could go back to the sync client and ask for the > entries (but I've yet to see a SyncML client which implements these > commands) but this flies in the face of the entire SyncML model. I'm > sure the gang at the SyncML initiative would be horrified by my mere > suggestion of this. The poor owner of the wireless device is paying by > the second on a 2G network and by the packet on a 2.5G or 3G network > so the extra trips back to the device will not be appreciated. I think it can be done in one single VQUERY. EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE LAST-MODIFIED > ...last-sync-time... OR if the CUA knows how to expand the objects - just VQUERY with EXPAND:FALSE and get the fewer objects - and expand the instances in the CUA code. > > > 2. CUAs must use EXDATE to mark an instance within an existing > > > Recurrence set as deleted rather than redefining the recurrence > > set. > > > > No. That is not practical. > > I admit it is rather restrictive but I can't think of any other way in > which a Sync CUA could put together a set of queries and ensure that > it gets told about deleted instances of recurring entries that it has > previously sync'd. I think I covered that above in this reply - do you agree? > I'd love it if someone else could suggest a query that'll do it. > Anyone? It's the only sticking point keeping us from closing this > issue as far as I can tell and I want it closed. This is far too much > work. I have to go do the stuff I was supposed to do today now. I > don't know how you guys do it :-). The LAST-MODIFIED in the 'master' object would have been updated, so when your VQUERY is performed (with or without EXPAND=TRUE) the result set will include those objects or instances that have changed after the time specified. This will include METHOD:DELETE objects. It would include any: instances that have changed (updated LAST-MODIFIED) new objects (new/unknown UID, new LAST-MODIFED) object marked for delete (METHOD:DELETE, updated LAST-MODIFIED) For iTIP objects, the same VQUERY will have returned in the result set: new instances (METHOD:ADD, new LAST-MODIFED) canceled objects (METHOD:CANCEL - new LAST-MODIFIED) canceled instances (METHOD:CANCEL with a RECURRANCE-ID property and a new LAST-MODIFIED) updated objects (METHOD:REQUEST with new SEQUENCE, updated LAST-MODIFIED) declined counter proposals (METHOD:DECLINE-COUNTER, new LAST-MODIFIED) And if your are the ORGANIZER it would also return any: counter proposals (METHOD:COUNTER, new LAST-MODIFIED) Is anything missing? --------------97C3BEBA30B54E1F3E3D0E02 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 ; Fri, 1 Feb 2002 17:08:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11Lvou18632 for ietf-calendar-bks; Fri, 1 Feb 2002 13:57:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Lvm318627 for ; Fri, 1 Feb 2002 13:57:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA16154 for ; Fri, 1 Feb 2002 13:57:49 -0800 (PST) Message-ID: <3C5B0F57.FDCD42CA@Royer.com> Date: Fri, 01 Feb 2002 14:57:43 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Why CS can not filter OLD SEQUENCES. References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------D2A707644A34626A9ED52308" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D2A707644A34626A9ED52308 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > > Where only '5' would be the newest and 1, 2, 3, 4 are discarded > > using iTIP rules. > > For the issue of sync I'll just say yes. If a CS is implemented in > this fashion then yes this is what I meant. The Sync CUA should filter > out everything out but the latest and greatest. [broken out from separate and related thread] Think of this from the iTIP perspective. For an object where you are the ORGANIZER. You could send and get in this order: send REQUEST , SEQUENCE 0 you sync get REPLY, SEQUENCE 0, ATTENDEE A1 get REPLY, SEQUENCE 0, ATTENDEE A2 you sync. get COUNTER, SEQUENCE 0, ATTENDEE A3 get REPLY, SEQUENCE 0, ATTENDEE A4 you sync and accept the COUNTER send REQUEST, SEQUENCE 1 get COUNTER SEQUENCE 0, ATTENDEE A5 get REPLY, SEQUENCE 1, ATTENDEE A1 get REPLY, SEQUENCE 1, ATTENDEE A3 you sync. As you can see, you have to keep the old SEQUENCE number objects until the CUA has determined that all of the ATTENDEES have performed a REPLY or COUNTER. If the CS were to delete all SEQUENCE 0 objects, your CUA would not know which ATTENDEE is participating as their PARTSTAT is only in their REPLY and what SEQUENCE item they think they said YES or NO to. And you would not know to send a DECLINE-COUNTER (or a new REQUEST and updated SEQUENCE) in responce to ATTENDEE A5's COUNTER object. I am sure there are other reasons to keep old SEQUENCE items until processed by a CUA. These are NOT CAP issues, they are iTIP issues. And we should not add this and other scenarios like this to CAP. --------------D2A707644A34626A9ED52308 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 ; Fri, 1 Feb 2002 17:09:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11M0ar18737 for ietf-calendar-bks; Fri, 1 Feb 2002 14:00:36 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11M0Z318733 for ; Fri, 1 Feb 2002 14:00:35 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA16172 for ; Fri, 1 Feb 2002 14:00:36 -0800 (PST) Message-ID: <3C5B0FFE.63531E8E@Royer.com> Date: Fri, 01 Feb 2002 15:00:30 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Editors notes in CAP References: <3C589558.7D2F64C9@Royer.com> <3C5AC864.3F3492DC@steltor.com> <3C5ADF85.7572C3A8@Royer.com> <3C5AE787.DE9AD268@steltor.com> Content-Type: multipart/mixed; boundary="------------01F4D4988E8B5BC3B8EA5FE4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------01F4D4988E8B5BC3B8EA5FE4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > 3- It doesn't buy us anything to have an MOVE permission. > > > If the user as READ and DELETE granted for the old location > > > and WRITE granted for the new location he'll still be able > > > to do "search", "create" and "delete" to move the object > > > the hard way. > > > > Yes - you are right. > > > > But after thinking about it more, I think we are both off the mark. > > > > I think the the real definition is: > > > > You need to be able to add a new instance of the RELATED-TO property > > to the new location. You would do that with a MODIFY. It is a > > MODIFY because there may already be instances of RELATED-TO in > > the new location. So you have to MODIFY the new location to also > > contain the new RELATED-TO calid. > > > > You need MODIFY permission in order to remove an instance of > > RELATED-TO from the old location. You don't DELETE the RELATED-TO > > from the old location because there may be multiple instances > > that your are not removing. So you have to MODIFY the VAGENDA so > > it no longer contains that specific instance. > > This is not an issue. > > This WG has agreed to drop hierarchial calendars and > fanout is out of scope. This has NOTHING to do with fanout. And I thought you wanted to MOVE calendars by altering their RELATED-TO properties? > Since all VAGENDA MUST be stored under CALSTORE where > would you want to move them? Are you proposing we delete MOVE of calendars? I thought that was your entire argument, what is a MOVE? > > > > So I don't think that READ or WRITE permission is what you need. > > For components that can be moved across targets (i.e., > VAGENDA and CALSTORE) I need READ and DELETE for the > old location and WRITE for the new location. > > We don't need a MOVE permission, and we don't need the > MODIFY permission to be granted on either the old or the > new location to be allowed to move components across > targets (i.e., VAGENDA and CALSTORE). If you still want to MOVE a calendar, you MUST modify the properties in the CS - true? --------------01F4D4988E8B5BC3B8EA5FE4 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 ; Fri, 1 Feb 2002 17:16:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11M7g019101 for ietf-calendar-bks; Fri, 1 Feb 2002 14:07:42 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11M7e319097 for ; Fri, 1 Feb 2002 14:07:40 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA16182 for ; Fri, 1 Feb 2002 14:07:42 -0800 (PST) Message-ID: <3C5B11A7.E763B1C6@Royer.com> Date: Fri, 01 Feb 2002 15:07:35 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RFC-2445: Re: CAP: LANGUAGE parameter References: Content-Type: multipart/mixed; boundary="------------BE3FA8EC4560E5481AA6C27B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BE3FA8EC4560E5481AA6C27B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > John posited: > > >Of course, we should specify that ALT-foo can appear more than once. > > We are already covered by the existing ABNF: > > ; the following is optional, > ; and MAY occur more than once > > (";" xparam) > > (Ok, technically we need to have a " (";" ianaparam) " clause but > thats a known oversight thats to be corrected w/o any real impact on > good engines. No - the debate was over adding new PROPERTIES, your quote adds parameters. New properties: LOCATION;LANGUAGE=EN_US:IBM in Bruce's office. ALT-LOCATION;LANGUAGE=FR_CA: <...in French Canadian...> I could make it a mess to do that using a parameter with more than two languages. I don't think we want 2 or more parameters on the same property with the same parameter name. --------------BE3FA8EC4560E5481AA6C27B 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 ; Fri, 1 Feb 2002 17:46:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11MT0B20145 for ietf-calendar-bks; Fri, 1 Feb 2002 14:29:00 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11MSx320141 for ; Fri, 1 Feb 2002 14:28:59 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA27432 for ; Fri, 1 Feb 2002 17:28:57 -0500 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 g11MSrQ09012 for ; Fri, 1 Feb 2002 17:28:53 -0500 (EST) Message-ID: <3C5B170D.CE06AD8@steltor.com> Date: Fri, 01 Feb 2002 17:30:37 -0500 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: Editors notes in CAP References: <3C589558.7D2F64C9@Royer.com> <3C5AC864.3F3492DC@steltor.com> <3C5ADF85.7572C3A8@Royer.com> <3C5AE787.DE9AD268@steltor.com> <3C5B0FFE.63531E8E@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: > > > > This WG has agreed to drop hierarchial calendars and > > fanout is out of scope. > > This has NOTHING to do with fanout. And I thought you wanted > to MOVE calendars by altering their RELATED-TO properties? Not at all. > > Since all VAGENDA MUST be stored under CALSTORE where > > would you want to move them? > > Are you proposing we delete MOVE of calendars? I don't have to. You already agreed that removing hierarchical calendars would break MOVE of VAGENDAs. In http://www.imc.org/ietf-calendar/mail-archive/msg02812.html : Doug Royer wrote: > > Patrice Lapierre wrote: > > > > 1) "move" of VAGENDA no longer make sense. > > I agree - it would break that. > I thought that was your entire argument, what is a MOVE? Not at all. > If you still want to MOVE a calendar, you MUST modify > the properties in the CS - true? If you want to modify the RELATED-TO property of a VAGENDA you must have the permission "MODIFY" and you must use the "modify" command. Regards, 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 Feb 1 18:05:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13845 for ; Fri, 1 Feb 2002 18:05:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11MpRI20935 for ietf-calendar-bks; Fri, 1 Feb 2002 14:51:27 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11MpQ320931 for ; Fri, 1 Feb 2002 14:51:26 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA16299 for ; Fri, 1 Feb 2002 14:51:28 -0800 (PST) Message-ID: <3C5B1BE9.9F387946@Royer.com> Date: Fri, 01 Feb 2002 15:51:21 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> Content-Type: multipart/mixed; boundary="------------8FFB06F5A96098DE48D96598" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8FFB06F5A96098DE48D96598 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > In my quest to find the purpose of CAR-MIN, I've been > able to identify the following requirements. None of > which requires that a CS should report a different level > of CAP support. > > As it stands, CAP doesn't need two different values for > the capability. > > 1- CS MUST implement VCARs for the following predefined > CARIDs: READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, > and DEFAULTOWNER; > > Rational: At one point in time people in this WG believed > it would make CUA's life easier. No. It makes small CS's possible. > > 1- Can a CS deny the right to READ the VCARs with the > predefined CARIDs? It could, but that would defeat the point of having predefined VCARs. Are you proposing a third level: CAR-NONE ? --------------8FFB06F5A96098DE48D96598 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 ; Fri, 1 Feb 2002 18:17:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11MwJL21206 for ietf-calendar-bks; Fri, 1 Feb 2002 14:58:19 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11MwI321201 for ; Fri, 1 Feb 2002 14:58:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA16317 for ; Fri, 1 Feb 2002 14:58:20 -0800 (PST) Message-ID: <3C5B1D85.C71CE063@Royer.com> Date: Fri, 01 Feb 2002 15:58:13 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> Content-Type: multipart/mixed; boundary="------------79288F91AACE2CEEA1A9C947" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------79288F91AACE2CEEA1A9C947 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > In my quest to find the purpose of CAR-MIN, I've been > able to identify the following requirements. None of > which requires that a CS should report a different level > of CAP support. > > As it stands, CAP doesn't need two different values for > the capability. Explain how a CUA can know if a CS can only handle the CAP predefined VCARs? --------------79288F91AACE2CEEA1A9C947 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 ; Fri, 1 Feb 2002 18:18:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g11Mxrl21308 for ietf-calendar-bks; Fri, 1 Feb 2002 14:59:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Mxq321303 for ; Fri, 1 Feb 2002 14:59:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA16321 for ; Fri, 1 Feb 2002 14:59:54 -0800 (PST) Message-ID: <3C5B1DE3.559E1972@Royer.com> Date: Fri, 01 Feb 2002 15:59:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Editors notes in CAP References: <3C589558.7D2F64C9@Royer.com> <3C5AC864.3F3492DC@steltor.com> <3C5ADF85.7572C3A8@Royer.com> <3C5AE787.DE9AD268@steltor.com> <3C5B0FFE.63531E8E@Royer.com> <3C5B170D.CE06AD8@steltor.com> Content-Type: multipart/mixed; boundary="------------BC91FE6EEDE8E5B30F40D6ED" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BC91FE6EEDE8E5B30F40D6ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > This WG has agreed to drop hierarchial calendars and > > > fanout is out of scope. > > > > This has NOTHING to do with fanout. And I thought you wanted > > to MOVE calendars by altering their RELATED-TO properties? > > Not at all. > > > > Since all VAGENDA MUST be stored under CALSTORE where > > > would you want to move them? > > > > Are you proposing we delete MOVE of calendars? > > I don't have to. You already agreed that removing > hierarchical calendars would break MOVE of VAGENDAs. I think we then agree. I'll re-read your email as I thought it applied to moving caledars. --------------BC91FE6EEDE8E5B30F40D6ED 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 ; Sun, 3 Feb 2002 13:22:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g13I8p320889 for ietf-calendar-bks; Sun, 3 Feb 2002 10:08:51 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g13I8j320882 for ; Sun, 3 Feb 2002 10:08:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA18354 for ; Sun, 3 Feb 2002 10:08:35 -0800 (PST) Message-ID: <3C5D7C9F.E88BA296@Royer.com> Date: Sun, 03 Feb 2002 11:08:31 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------03FB6E79C8035A8E44CF983C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------03FB6E79C8035A8E44CF983C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > > > capselect = "SELECT" SP cap-cols SP > > Must also support: > > SELECT VEVENT.VALARM > SELECT VEVENT.* > > > "FROM" SP comp-name SP > > comp-name won't accept VEVENT.VALARM. True but it does not have to do that. The 'FROM' value is the component that you are selecting from If you want to get from VALARM, there is no need for VEVENT.VALARM . SELECT * FROM VALARM ... If you just want the VALARMs for VEVENTs: SELECT VALARM[.xxx][,...] FROM VEVENT .... --------------03FB6E79C8035A8E44CF983C 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 ; Sun, 3 Feb 2002 13:50:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g13IgJF21569 for ietf-calendar-bks; Sun, 3 Feb 2002 10:42:19 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g13IgI321564 for ; Sun, 3 Feb 2002 10:42:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA18370 for ; Sun, 3 Feb 2002 10:42:18 -0800 (PST) Message-ID: <3C5D8486.B091254A@Royer.com> Date: Sun, 03 Feb 2002 11:42:14 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: LANGUAGE in CALSTORE Content-Type: multipart/mixed; boundary="------------6ACCEF4C7D6F8128F750F48C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6ACCEF4C7D6F8128F750F48C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NEW PROPOSAL. (1) mandate BEEP "localize" attribute be sent in CS greeting. (2) Add optional LANGUAGE property to VQUERY in order to specify locale sort order when CS supports more than one locale. (Too late as it is in 2445, but LANGUAGE should be LOCALE) Each calendar has a LANGUAGE property, however the CALSTORE does not and that can be covered in the beep greeting. We need to include text that specifies that a CS MUST include the "localize" attribute as specified as optional in section 2.3.1.1 of BEEP (rfc3080). This list is the list (one or more) of locales that the CS understands. And if multiple are supplied, then the first is the default locale sort order for any VAGANDA that does not have the LANGUAGE property value set. This is needed as VQUERY can do sorts, so if the CUA wishes a different locale sort order, then it can specify a LANGUAGE property in the VQUERY. And this LANGUAGE property is only supplied in a VQUERY when: It is not the VAGAENDAs default locale (LANGUAGE). When it is not the CS's default local (first in list), when if the VAGANDAs LANGUAGE is not set. And the LANGUAGE property specified in the VQUERY was listed in the initial CS BEEP greeting "localize" attribute (as proof that the CS supports that locale). The CUA wishes to specify the locale sort. If not supplied, the sort order is in the order sepcified by the locale (LANGUAGE) of the VAGENDA or if not set, the first (or only) locale listed in the "localize" CS greeting attribute. --------------6ACCEF4C7D6F8128F750F48C 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 ; Mon, 4 Feb 2002 08:27:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14DDNo20200 for ietf-calendar-bks; Mon, 4 Feb 2002 05:13:23 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14DDM320195 for ; Mon, 4 Feb 2002 05:13:22 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id IAA09807 for ; Mon, 4 Feb 2002 08:13:17 -0500 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 g14DDHQ19155 for ; Mon, 4 Feb 2002 08:13:17 -0500 (EST) Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C5D7C9F.E88BA296@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <3C5D7C9F.E88BA296@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Feb 2002 08:21:02 -0500 Message-Id: <1012828862.29604.9.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 Sun, 2002-02-03 at 13:08, Doug Royer wrote: > Patrice Lapierre wrote: > > > > > > > > capselect = "SELECT" SP cap-cols SP > > > > Must also support: > > > > SELECT VEVENT.VALARM > > SELECT VEVENT.* > > > > > "FROM" SP comp-name SP > > > > comp-name won't accept VEVENT.VALARM. > > True but it does not have to do that. > > The 'FROM' value is the component that you are selecting from > If you want to get from VALARM, there is no need for VEVENT.VALARM . > > SELECT * FROM VALARM ... > > If you just want the VALARMs for VEVENTs: > > SELECT VALARM[.xxx][,...] FROM VEVENT .... Then the example 6b from the proposition must be changed. Doug Royer wrote: > ... > (6) A contained component without a '.' it is the same as > .* with the result being a properly formatted > (s) in the data stream, and correctly formatted > in the contained component(s) in iCalendar (RFC2445) format. > > VALID: > > (a) SELECT VEVENT. FROM VEVENT > > (b) SELECT VEVENT.VALARM FROM VEVENT > From owner-ietf-calendar@mail.imc.org Mon Feb 4 10:54:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26525 for ; Mon, 4 Feb 2002 10:54:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g14FcEF28143 for ietf-calendar-bks; Mon, 4 Feb 2002 07:38:14 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14FcD328138 for ; Mon, 4 Feb 2002 07:38:13 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA13442 for ; Mon, 4 Feb 2002 10:38:09 -0500 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 g14Fc8Q05902 for ; Mon, 4 Feb 2002 10:38:08 -0500 (EST) Message-ID: <3C5EAB4B.9978C5F4@steltor.com> Date: Mon, 04 Feb 2002 10:39:55 -0500 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: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@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: > > > > In my quest to find the purpose of CAR-MIN, I've been > > able to identify the following requirements. None of > > which requires that a CS should report a different level > > of CAP support. > > > > As it stands, CAP doesn't need two different values for > > the capability. > > Explain how a CUA can know if a CS can only handle > the CAP predefined VCARs? So, that would be THE purpose of CAR-MIN? Now can you explain how a CUA can know if it can modify the CAP predefined VCARs of a CAR-MIN CS? Regards, 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 Feb 4 11:17:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27352 for ; Mon, 4 Feb 2002 11:17:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14FuiI28830 for ietf-calendar-bks; Mon, 4 Feb 2002 07:56:44 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Fug328822 for ; Mon, 4 Feb 2002 07:56:42 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA14098 for ; Mon, 4 Feb 2002 10:56:38 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g14FubQ08423 for ; Mon, 4 Feb 2002 10:56:37 -0500 (EST) Message-Id: <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 10:53:18 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: LastCallByMarchIETF: Need Volunteers!] In-Reply-To: <3C5B0B01.5741298E@Royer.com> References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:39 PM 2/1/2002 -0700, you wrote:

I think it can be done in one single VQUERY.

        EXPAND:TRUE
        QUERY:SELECT * FROM VEVENT
         WHERE LAST-MODIFIED >  ...last-sync-time...

OR if the CUA knows how to expand the objects - just VQUERY
with EXPAND:FALSE and get the fewer objects - and expand
the instances in the CUA code.

Yes this would do it but the difference between your query and mine is that mine had a time range. Your query will give back everything that has changed on the CS within the users agenda and not just those within a specific time range. The Sync CUA may not care about new meetings that have been booked 3 years out. The requirement for CAP reads as follows...

"CAP MUST allow synchronization, meaning at a minimum that the CUA is able to find and retrieve new, modified or deleted entries for a given time period. The CUA MUST be able to find out which entries have been added, modified or deleted since it last synchronized, in order to operate in disconnected mode. This requirement may be satisfied using the query requirements already defined."

The five words of importance "for a given time period".

How does a Sync CUA find out about deleted instances of a recurring entry that used to fall within a given time period but which have been deleted since the last time a sync was performed without getting ALL the changes on the CS and then doing its own time range filtering?

Perhaps something like this (once again I am simplifying things by just using DTSTART and just worrying about VEVENTS)...

QUERY:SELECT * FROM VEVENT
WHERE LAST-MODIFIED >  ...last-sync-time
AND DTSTART > bottom of time range
AND DTSTART < top of time range
AND RRULE="" (I'm trying to say not recurring. What's the proper way of doing this is?)

followed by...

EXPAND:TRUE (or FALSE if the Sync CUA wants. It's not really CAP's concern)
QUERY:SELECT * FROM VEVENT
WHERE LAST-MODIFIED >  ...last-sync-time
AND RRULE=* (I'm trying to say recurring. What's the proper way of doing this is?)

These two queries will give the Sync CUA all new, changed and deleted non-recurring entries within a users calendar within a given time period and will give the Sync CUA ALL new, changed, and deleted recurring entries within a users calendar. This means that the Sync CUA may get back more recurring entries then it actually needs but this would seem to be a reasonable compromise. Statistically users would tend to have less recurring entries in their calendar I think and they tend to change less often then non-recurring entries so hopefully the extra overhead of the Sync CUA getting recurring entries not actually within the given time period would be kept to a minimum.

I suspect Sync solution implementors should be OK with this compromise as well. Sync'ing recurring entries is difficult and a lot of solutions just don't do it properly. Those that do just deal with them as one object with their recurrence set and don't worry about expansion or if they do sync them all every time since keeping track of what instances have been sync'd in a range is just too confusing. So I don't think the compromise I am proposing should really harm their implementations (lurkers on the list thinking about implementing a sync solution against a CAP compliant CS in the future may want to speak up now if you disagree).

If we can agree that this is sufficient then the following 2 things needs to be done to put this issue to rest.

1) We still need some text within the CAP spec explaining that CAP CUAs should delete things use METHOD MODIFY (as suggested by Doug in a previous reply and seconded by me).

2) Either the CAP sync requirements should be updated  to reflect what we can actually support or perhaps a section within the CAP Spec could be added to explain how well it lives up to the requirments. As the CAP Requirements document is an official document going back and changing it would probably be a pain so my vote is for a small informational section within the CAP spec.

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@steltor.com
http://www.steltor.com



 From owner-ietf-calendar@mail.imc.org Mon Feb 4 12:29:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00323 for ; Mon, 4 Feb 2002 12:29:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14HEwl04777 for ietf-calendar-bks; Mon, 4 Feb 2002 09:14:58 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14HEv304773 for ; Mon, 4 Feb 2002 09:14:57 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA19813; Mon, 4 Feb 2002 09:14:56 -0800 (PST) Message-ID: <3C5EC18C.956D9361@Royer.com> Date: Mon, 04 Feb 2002 10:14:52 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Desruisseaux CC: ietf-calendar@imc.org Subject: Re: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> Content-Type: multipart/mixed; boundary="------------B261A67A5E7FB385B1AFEEC4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B261A67A5E7FB385B1AFEEC4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > In my quest to find the purpose of CAR-MIN, I've been > > > able to identify the following requirements. None of > > > which requires that a CS should report a different level > > > of CAP support. > > > > > > As it stands, CAP doesn't need two different values for > > > the capability. > > > > Explain how a CUA can know if a CS can only handle > > the CAP predefined VCARs? > > So, that would be THE purpose of CAR-MIN? > > Now can you explain how a CUA can know if it can > modify the CAP predefined VCARs of a CAR-MIN CS? It can't. --------------B261A67A5E7FB385B1AFEEC4 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 ; Mon, 4 Feb 2002 12:29:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g14HFdn04819 for ietf-calendar-bks; Mon, 4 Feb 2002 09:15:39 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14HFc304806 for ; Mon, 4 Feb 2002 09:15:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA19818 for ; Mon, 4 Feb 2002 09:15:38 -0800 (PST) Message-ID: <3C5EC1B7.3FD68AF6@Royer.com> Date: Mon, 04 Feb 2002 10:15:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> Content-Type: multipart/mixed; boundary="------------72A5A6467B6498F9BBA70879" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------72A5A6467B6498F9BBA70879 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > In my quest to find the purpose of CAR-MIN, I've been > > > able to identify the following requirements. None of > > > which requires that a CS should report a different level > > > of CAP support. > > > > > > As it stands, CAP doesn't need two different values for > > > the capability. > > > > Explain how a CUA can know if a CS can only handle > > the CAP predefined VCARs? > > So, that would be THE purpose of CAR-MIN? > > Now can you explain how a CUA can know if it can > modify the CAP predefined VCARs of a CAR-MIN CS? It can't. --------------72A5A6467B6498F9BBA70879 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 ; Mon, 4 Feb 2002 13:45:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14ISAW06902 for ietf-calendar-bks; Mon, 4 Feb 2002 10:28:10 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14IS9306898 for ; Mon, 4 Feb 2002 10:28:09 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA19884 for ; Mon, 4 Feb 2002 10:28:09 -0800 (PST) Message-ID: <3C5ED2B4.762B4A7E@Royer.com> Date: Mon, 04 Feb 2002 11:28:04 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP:LastCallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------29E2B159BA54A3E26FA5527B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------29E2B159BA54A3E26FA5527B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > > At 02:39 PM 2/1/2002 -0700, you wrote: > > > I think it can be done in one single VQUERY. > > > > EXPAND:TRUE > > QUERY:SELECT * FROM VEVENT > > WHERE LAST-MODIFIED > ...last-sync-time... > > > > OR if the CUA knows how to expand the objects - just VQUERY > > with EXPAND:FALSE and get the fewer objects - and expand > > the instances in the CUA code. > > > > Yes this would do it but the difference between your query and mine is > that mine had a time range. Your query will give back everything that > has changed on the CS within the users agenda and not just those > within a specific time range. The Sync CUA may not care about new > meetings that have been booked 3 years out. The requirement for CAP > reads as follows... > > "CAP MUST allow synchronization, meaning at a minimum that the CUA is > able to find and retrieve new, modified or deleted entries for a given > time period. The CUA MUST be able to find out which entries have been > added, modified or deleted since it last synchronized, in order to > operate in disconnected mode. This requirement may be satisfied using > the query requirements already defined." It was my belief that text meant that it needed to know about changes since a time. What good is it to 1/2 sync? That is if you only get 'changes' from yesterday and ignore changes from two days ago? Here is why you don't want that: Jan. 1 you sync and everything is up to date. Jan. 10 your CS gets METHOD:CANCEL for objects in Feb. Feb. 1 you sync with a time range of Feb. 1- Feb. 28. You now missed the METHOD:CANCEL for the VEVENTS in Feb. and the results you get back are exactly what you asked for and bogus. > The five words of importance "for a given time period". > > How does a Sync CUA find out about deleted instances of a recurring > entry that used to fall within a given time period but which have been > deleted since the last time a sync was performed without getting ALL > the changes on the CS and then doing its own time range filtering? You don't mean 'deleted' you mean METHOD:CANCEL, and those would show up with the above query I provided. You can't 'delete' an instance, you can only METHOD:CANCEL an instance. You can only delete an object, not instances that only exist when the CS expands an object. > Perhaps something like this (once again I am simplifying things by > just using DTSTART and just worrying about VEVENTS)... > > QUERY:SELECT * FROM VEVENT > WHERE LAST-MODIFIED > ...last-sync-time > AND DTSTART > bottom of time range > AND DTSTART < top of time range > AND RRULE="" (I'm trying to say not recurring. What's the proper way > of doing this is?) "AND RRULE IS NULL" I think is what you are saying. But I don't think that is what you want - see below. > followed by... > > EXPAND:TRUE (or FALSE if the Sync CUA wants. It's not really CAP's > concern) > QUERY:SELECT * FROM VEVENT > WHERE LAST-MODIFIED > ...last-sync-time > AND RRULE=* (I'm trying to say recurring. What's the proper way of > doing this is?) "RRULE IS NOT NULL" - Not what you really want. Your above query would return instances of VEVENTs with an RRULE (but not a RDATE, EXDATE, or EXRULE), within the given time range that have changed since last-sync-time. Only instances in that time range would be returned - and only if they changed after last-sync-time. This below would get all instances (with or without RRULE's) that have changed since your last sync within a time range: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE LAST-MODIFIED > ..last-sync-time AND METHOD != 'CREATE' QUERY:SELECT * FROM VEVENT WHERE DTSART > bottom of time range AND DTSTART < top of time range AND METHOD = 'CREATE' END:VQUERY Above, the CS would EXPAND 'original' VEVENTs into instances, and only return the ones that fall within the provided time range. AND it would return any modified objects that might effect the results. So you would now see the METHOD:CANCEL done in January that effected the February objects. ONLY a CUA combines objects, the CS does not, so the CS could not 'know' that the January 10th object effected the February objects in order to return them in the query. A problem with your examples, is that they ignored RDATE, EXDATE, and EXRULE. The CUA would have then had to calculate those exceptions and additions from the result set. > These two queries will give the Sync CUA all new, changed and deleted > non-recurring entries within a users calendar within a given time > period and will give the Sync CUA ALL new, changed, and deleted > recurring entries within a users calendar. This means that the Sync > CUA may get back more recurring entries then it actually needs but > this would seem to be a reasonable compromise. Statistically users > would tend to have less recurring entries in their calendar I think > and they tend to change less often then non-recurring entries so > hopefully the extra overhead of the Sync CUA getting recurring entries > not actually within the given time period would be kept to a minimum. Your query would have missed instances with a RDATE, and had excessive instances that did not exists because of ignored EXDATE and EXRULE. And because you specified a time range in the same query based on DTSTART, you would missed any CANCEL for objects or instances of those objects. > I suspect Sync solution implementors should be OK with this compromise > as well. Sync'ing recurring entries is difficult and a lot of > solutions just don't do it properly. Those that do just deal with them > as one object with their recurrence set and don't worry about > expansion or if they do sync them all every time since keeping track > of what instances have been sync'd in a range is just too confusing. > So I don't think the compromise I am proposing should really harm > their implementations (lurkers on the list thinking about implementing > a sync solution against a CAP compliant CS in the future may want to > speak up now if you disagree). > > If we can agree that this is sufficient then the following 2 things > needs to be done to put this issue to rest. > > 1) We still need some text within the CAP spec explaining that CAP > CUAs should delete things use METHOD MODIFY (as suggested by Doug in a > previous reply and seconded by me). (1) Mark them for delete with (2) Delete them with (3) Cancel entire object with METHOD:CANCEL and RECURRANCE-ID IS NULL (4) Cancel instances of object with METHOD:CANCEL and RECURRANCE-ID IS NOT NULL. With (3) and (4) currently being defiend by iTIP. > 2) Either the CAP sync requirements should be updated to reflect what > we can actually support or perhaps a section within the CAP Spec could > be added to explain how well it lives up to the requirments. As the > CAP Requirements document is an official document going back and > changing it would probably be a pain so my vote is for a small > informational section within the CAP spec. I agree we need more text in CAP. As part of the editors conference call last week - I (I think it was me) agreed to write a proposal. FYI - anyone is also allowed to propose text. --------------29E2B159BA54A3E26FA5527B 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 ; Mon, 4 Feb 2002 13:46:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g14IOeZ06818 for ietf-calendar-bks; Mon, 4 Feb 2002 10:24:40 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14IOd306814 for ; Mon, 4 Feb 2002 10:24:39 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA18529 for ; Mon, 4 Feb 2002 13:24:36 -0500 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 g14IOEQ25934 for ; Mon, 4 Feb 2002 13:24:14 -0500 (EST) Message-ID: <3C5ED239.7DA0803E@steltor.com> Date: Mon, 04 Feb 2002 13:26:01 -0500 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: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@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: > > > > Doug Royer wrote: > > > > > > Explain how a CUA can know if a CS can only handle > > > the CAP predefined VCARs? > > > > So, that would be THE purpose of CAR-MIN? > > > > Now can you explain how a CUA can know if it can > > modify the CAP predefined VCARs of a CAR-MIN CS? > > It can't. Then, to "hard code the answer to the predefined VCARs in its ROM", a CS will need to be CAR-FULL-1. Right? It seems as all we really need is yet another predefined CARID to specify VCAR's access right, and not different levels of CAR support. Such a VCAR could be defined to specify that only VCAR with predefined CARID can be read and/or modified. As all other predefined VCARs, this VCAR could be decreed or not. Regards, 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 Feb 4 16:05:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05975 for ; Mon, 4 Feb 2002 16:05:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14Kqht11958 for ietf-calendar-bks; Mon, 4 Feb 2002 12:52:43 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Kqg311954 for ; Mon, 4 Feb 2002 12:52:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA19996 for ; Mon, 4 Feb 2002 12:52:43 -0800 (PST) Message-ID: <3C5EF495.743FB1DF@Royer.com> Date: Mon, 04 Feb 2002 13:52:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> Content-Type: multipart/mixed; boundary="------------11AAC556727A53BFD0CCCF01" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------11AAC556727A53BFD0CCCF01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Doug Royer wrote: > > > > > > > > Explain how a CUA can know if a CS can only handle > > > > the CAP predefined VCARs? > > > > > > So, that would be THE purpose of CAR-MIN? > > > > > > Now can you explain how a CUA can know if it can > > > modify the CAP predefined VCARs of a CAR-MIN CS? > > > > It can't. > > Then, to "hard code the answer to the predefined VCARs > in its ROM", a CS will need to be CAR-FULL-1. Right? No. It can just copy the predefined (decreed) data to the CUA. A CAR-MIN CS implementation would never need to understand how to parse a VCAR. And a CAR-MIN CS would never have the ability to serve out any non-predefined (non-DEFAULT-VCARS) VCAR. If a CS implementation needs to allow the CUA to create any non-pre-defined VCARs, it is NOT a CAR-MIN CS. > It seems as all we really need is yet another predefined > CARID to specify VCAR's access right, Why not include it as part of the predefined VCAR? I think I found a bug in the new VCAR proposal as last proposed. You used to be able to specify multiple GRANT/DENY in a VCAR, now they seem to be limited to one set per VCAR. We used to be able to do this (may be we still can as I am still learning the new proposal): BEGIN:VCAR CARID:REQUESTONLY GRANT:NONOWNER PERMISSION:WRITE RESTRICTION:METHOD = 'REQUEST' GRANT:OWNER PERMISSION:MODIFY SCOPE:SELECT * FROM VCAR WHERE CARID = 'REQUESTONLY' RESTRICTION:CARID = 'REQUESTONLY' END:VCAR How do I do the above two (or more) things in one VCAR using the new VCAR proposal? > and not different > levels of CAR support. Restricting a predefined vcar has nothing to do with if a CS MUST fully understand all VCARs. > Such a VCAR could be defined to > specify that only VCAR with predefined CARID can be read > and/or modified. As all other predefined VCARs, this VCAR > could be decreed or not. Or we need to remove the restriction from the current VCAR proposal that limits the predefined VCAR itself from specifying if it can be modified. A spur of the moment proposal is a change to Bernards VCAR proposal, allow something like: BEGIN:VCAR CARID:REQUESTONLY GRANT:UPN=NONOWNER();PERMISSION="WRITE" ;RESTRICTION="METHOD=REQUEST" GRANT:UPN=OWNER();PERMISSION=MODIFY ;SCOPE="SELECT * FROM VCAR WHERE CARID = 'REQUESTONLY'" ;RESTRICTION="METHOD=MODIFY" END:VCAR That would again allow multiple rules per VCAR and use the CAP-QL as the selection language. --------------11AAC556727A53BFD0CCCF01 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 ; Mon, 4 Feb 2002 17:50:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g14MbUM14756 for ietf-calendar-bks; Mon, 4 Feb 2002 14:37:30 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14MbT314752 for ; Mon, 4 Feb 2002 14:37:29 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA25764 for ; Mon, 4 Feb 2002 17:37:26 -0500 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 g14MbNQ26128 for ; Mon, 4 Feb 2002 17:37:23 -0500 (EST) Message-ID: <3C5F0D8E.27D0FB08@steltor.com> Date: Mon, 04 Feb 2002 17:39:10 -0500 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: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> <3C5EF495.743FB1DF@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: > > > > Doug Royer wrote: > > > > > > Bernard Desruisseaux wrote: > > > > > > > > Doug Royer wrote: > > > > > > > > > > Explain how a CUA can know if a CS can only handle > > > > > the CAP predefined VCARs? > > > > > > > > So, that would be THE purpose of CAR-MIN? > > > > > > > > Now can you explain how a CUA can know if it can > > > > modify the CAP predefined VCARs of a CAR-MIN CS? > > > > > > It can't. > > > > Then, to "hard code the answer to the predefined VCARs > > in its ROM", a CS will need to be CAR-FULL-1. Right? > > No. It can just copy the predefined (decreed) data to the CUA. > A CAR-MIN CS implementation would never need to understand how to > parse a VCAR. And a CAR-MIN CS would never have the ability to > serve out any non-predefined (non-DEFAULT-VCARS) VCAR. > > If a CS implementation needs to allow the CUA to create > any non-pre-defined VCARs, it is NOT a CAR-MIN CS. That's not the issue. If a CS hard codes its predefined VCARs it needs to deny all users the right to WRITE, MODIFY and DELETE them. Currently, there is no predefined VCARs meant to allow the CS to specify that information. So, as of now, a CAR-MIN CS cannot hard code its predefined VCAR. > > It seems as all we really need is yet another predefined > > CARID to specify VCAR's access right, > > Why not include it as part of the predefined VCAR? I wouldn't have any problem adding a predefined VCAR with CARID:DEFAULTVCAR (I'm open to suggestion for a better name). Now, given that this predefined VCAR could specify which VCAR you are allowed to READ, WRITE, MODIFY and DELETE, we no longer need CAR-MIN. This predefined VCAR is all we need to fulfil the purpose for which CAR-MIN existed. Regards, 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 Feb 4 17:51:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07597 for ; Mon, 4 Feb 2002 17:51:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14Mb2C14716 for ietf-calendar-bks; Mon, 4 Feb 2002 14:37:02 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Mb1314711 for ; Mon, 4 Feb 2002 14:37:01 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA25760 for ; Mon, 4 Feb 2002 17:36:58 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g14MavQ26120 for ; Mon, 4 Feb 2002 17:36:58 -0500 (EST) Message-Id: <5.1.0.14.0.20020204134506.00b11398@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 17:33:37 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP:LastCallByMarchIETF: Need Volunteers!] In-Reply-To: <3C5ED2B4.762B4A7E@Royer.com> References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:28 AM 2/4/2002 -0700, you wrote:

Mark Paterson wrote:
>
> At 02:39 PM 2/1/2002 -0700, you wrote:
>
> > I think it can be done in one single VQUERY.
> >
> >         EXPAND:TRUE
> >         QUERY:SELECT * FROM VEVENT
> >          WHERE LAST-MODIFIED >  ...last-sync-time...
> >
> > OR if the CUA knows how to expand the objects - just VQUERY
> > with EXPAND:FALSE and get the fewer objects - and expand
> > the instances in the CUA code.
> >
>
> Yes this would do it but the difference between your query and mine is
> that mine had a time range. Your query will give back everything that
> has changed on the CS within the users agenda and not just those
> within a specific time range. The Sync CUA may not care about new
> meetings that have been booked 3 years out. The requirement for CAP
> reads as follows...
>
> "CAP MUST allow synchronization, meaning at a minimum that the CUA is
> able to find and retrieve new, modified or deleted entries for a given
> time period. The CUA MUST be able to find out which entries have been
> added, modified or deleted since it last synchronized, in order to
> operate in disconnected mode. This requirement may be satisfied using
> the query requirements already defined."

It was my belief that text meant that it needed to know about
changes since a time. What good is it to 1/2 sync? That is if
you only get 'changes' from yesterday and ignore changes
from two days ago? Here is why you don't want that:

        Jan. 1  you sync and everything is up to date.
        Jan. 10  your CS gets METHOD:CANCEL for objects in Feb.
        Feb. 1   you sync with a time range of Feb. 1- Feb. 28.

     You now missed the METHOD:CANCEL for the VEVENTS in Feb.
     and the results you get back are exactly what you asked for
     and bogus.

Why have I missed it? If I ask for everything that has changed since Jan 1st which falls between Feb 1 and Feb 28th the objects within February that have been deleted will get returned because their LAST-MODIFIED attribute with be Jan 10th (greater than Jan 1) and their DTSTARTs fall within the range. Are the meetings in February part of a recurring entry in your example? If so, then yes they'd be missed which has been my point all along that a query against LAST-MODIFIED with a time range catches everything but instances of recurring entries that no longer exist. This why in my last response I compromised and only used a time range when querying for non-recurring entries and did not when querying for recurring entries since I'll always have the chance of missing these if I do.

Please note that above I mean the English word "deleted" and not the CAP command so please don't correct me by telling me that I mean the modify command updating the METHOD to CANCEL)  Note that in a previous response you claimed the following...

"Entire objects are marked for delete by using METHOD:MODIFY
and changing the object in the store to METHOD:DELETE"

Here you say CANCEL. Which is it? Its the "delete" command which zaps the whole object which we don't want CUAs to do and the "modify" command with METHOD:DELETE (or CANCEL).


> The five words of importance "for a given time period".
>
> How does a Sync CUA find out about deleted instances of a recurring
> entry that used to fall within a given time period but which have been
> deleted since the last time a sync was performed without getting ALL
> the changes on the CS and then doing its own time range filtering?

You don't mean 'deleted' you mean METHOD:CANCEL, and those
would show up with the above query I provided.

Yes I do mean deleted. I mean the English word deleted as in the instance is no more and not the CAP command AND yes it would show up in your query along with ever other change within the user's calendar but we were trying to find a way to just get those changes within a given time period. In my compromise I used your approach (with no time range) only for recurring entries to cut down on the amount of unnecessary changes being reported to the Sync CUA.


You can't 'delete' an instance, you can only METHOD:CANCEL
an instance. You can only delete an object, not instances
that only exist when the CS expands an object.

I know that !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From the Sync CUAs perspective their is an instance that it no more and that is all I am saying. The CUA which did the deletion should do so as you describe, yes, we agreed to this several replies back.


> Perhaps something like this (once again I am simplifying things by
> just using DTSTART and just worrying about VEVENTS)...
>
> QUERY:SELECT * FROM VEVENT
> WHERE LAST-MODIFIED >  ...last-sync-time
> AND DTSTART > bottom of time range
> AND DTSTART < top of time range
> AND RRULE="" (I'm trying to say not recurring. What's the proper way
> of doing this is?)

"AND RRULE IS NULL" I think is what you are saying. But I don't
think that is what you want - see below.

What I am saying is "I'm trying to say not recurring. What's the proper way
of doing this is?". Exactly what's written in the parentheses. I'm trying to express a query that gets all changes within a given time period for all non recurring entries but I wasn't sure how to do so, so I asked for your help.


> followed by...
>
> EXPAND:TRUE (or FALSE if the Sync CUA wants. It's not really CAP's
> concern)
> QUERY:SELECT * FROM VEVENT
> WHERE LAST-MODIFIED >  ...last-sync-time
> AND RRULE=* (I'm trying to say recurring. What's the proper way of
> doing this is?)

"RRULE IS NOT NULL" - Not what you really want.

Your above query would return instances of VEVENTs with an RRULE
(but not a RDATE, EXDATE, or EXRULE),

I know that. That's why in parentheses I state quite clearly "I'm trying to say recurring. What's the proper way of doing this is?"  In other words, Please help me with this query.

within the given time range

I have no time range in this query. It follows your approach of no time range since there seems to be no way of ensuring that the Sync CUA catches instances that have been deleted (the English word deleted :-)) if you do. The only way to do it with a time range is if you could query on something like an EXDATE but we've both agreed that forcing a CUA to use an EXDATE to get rid of an instance is simply too restrictive.

that have changed since last-sync-time. Only instances in that
time range would be returned - and only if they changed after
last-sync-time.

As stated above my 2nd query does not have a time range.


This below would get all instances (with or without RRULE's) that
have changed since your last sync within a time range:

  BEGIN:VQUERY

  EXPAND:TRUE

  QUERY:SELECT * FROM VEVENT
   WHERE LAST-MODIFIED > ..last-sync-time AND METHOD != 'CREATE'

  QUERY:SELECT * FROM VEVENT
   WHERE DTSART > bottom of time range
   AND DTSTART < top of time range
   AND METHOD = 'CREATE'

  END:VQUERY

Above, the CS would EXPAND 'original' VEVENTs into instances,
and only return the ones that fall within the provided time range.
AND it would return any modified objects that might effect
the results. So you would now see the METHOD:CANCEL done
in January that effected the February objects.

ONLY a CUA combines objects, the CS does not, so the CS could
not 'know' that the January 10th object effected the February
objects in order to return them in the query.

Here's where we disagree and I think why we seem to think differently and have trouble understanding each other's proposal. I'm going to reply to this separately next (this reply is already too long).


A problem with your examples, is that they ignored RDATE,
EXDATE, and EXRULE. The CUA would have then had to calculate
those exceptions and additions from the result set.

They did not ignore them. I simply didn't know how to express a query which only returned recurring entries and was hoping that you make a suggestion as to how it could be done.


> These two queries will give the Sync CUA all new, changed and deleted
> non-recurring entries within a users calendar within a given time
> period and will give the Sync CUA ALL new, changed, and deleted
> recurring entries within a users calendar. This means that the Sync
> CUA may get back more recurring entries then it actually needs but
> this would seem to be a reasonable compromise. Statistically users
> would tend to have less recurring entries in their calendar I think
> and they tend to change less often then non-recurring entries so
> hopefully the extra overhead of the Sync CUA getting recurring entries
> not actually within the given time period would be kept to a minimum.

Your query would have missed instances with a RDATE, and had
excessive instances that did not exists because of ignored
EXDATE and EXRULE. And because you specified a time range
in the same query based on DTSTART, you would missed any CANCEL
for objects or instances of those objects.

I think we've covered this. I didn't ignore EXDATE and EXRULE and my second query had no time range.


> I suspect Sync solution implementors should be OK with this compromise
> as well. Sync'ing recurring entries is difficult and a lot of
> solutions just don't do it properly. Those that do just deal with them
> as one object with their recurrence set and don't worry about
> expansion or if they do sync them all every time since keeping track
> of what instances have been sync'd in a range is just too confusing.
> So I don't think the compromise I am proposing should really harm
> their implementations (lurkers on the list thinking about implementing
> a sync solution against a CAP compliant CS in the future may want to
> speak up now if you disagree).
>
> If we can agree that this is sufficient then the following 2 things
> needs to be done to put this issue to rest.
>
> 1) We still need some text within the CAP spec explaining that CAP
> CUAs should delete things use METHOD MODIFY (as suggested by Doug in a
> previous reply and seconded by me).

        (1) Mark them for delete with <modify>

        (2) Delete them with <delete>

        (3) Cancel entire object with METHOD:CANCEL
            and RECURRANCE-ID IS NULL

        (4) Cancel instances of object with METHOD:CANCEL
            and RECURRANCE-ID IS NOT NULL.

With (3) and (4) currently being defiend by iTIP.

I'm not sure what this text is for? Is this what you want to put in CAP? We don't want them to zap things with the delete command. You've lost me.


> 2) Either the CAP sync requirements should be updated  to reflect what
> we can actually support or perhaps a section within the CAP Spec could
> be added to explain how well it lives up to the requirments. As the
> CAP Requirements document is an official document going back and
> changing it would probably be a pain so my vote is for a small
> informational section within the CAP spec.

I agree we need more text in CAP. As part of the editors conference
call last week - I (I think it was me) agreed to write a proposal.

FYI - anyone is also allowed to propose text.

I would be willing to work with you on this but we first need to get on the same page. Wait for my next reply before commenting. I'm pretty sure I know why we don't really seem to understand each other's ideas.

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@steltor.com
http://www.steltor.com



 From owner-ietf-calendar@mail.imc.org Mon Feb 4 17:51:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07609 for ; Mon, 4 Feb 2002 17:51:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g14MchU14801 for ietf-calendar-bks; Mon, 4 Feb 2002 14:38:43 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Mcg314797 for ; Mon, 4 Feb 2002 14:38:43 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA25805 for ; Mon, 4 Feb 2002 17:38:40 -0500 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 g14MceQ26237 for ; Mon, 4 Feb 2002 17:38:40 -0500 (EST) Message-ID: <3C5F0DDB.77708BF7@steltor.com> Date: Mon, 04 Feb 2002 17:40:27 -0500 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: CAP: Comments on VCAR proposal (Was: Re: CAP: What is the purpose of CAR-MIN?) References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> <3C5EF495.743FB1DF@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: > > I think I found a bug in the new VCAR proposal as last > proposed. You used to be able to specify multiple GRANT/DENY > in a VCAR, now they seem to be limited to one set per VCAR. > We used to be able to do this (may be we still can as I am > still learning the new proposal): That's not a bug. This limitation was highlighted in the introduction of my proposal: Bernard Desruisseaux wrote: > > - A VCAR component, as defined in this proposal, can only > define a single access right. If there is a need to group > multiple access rights in a single VCAR (e.g., to share > the same CARID and/or NAME properties) we could always > group the properties GRANT, DENY, PERMISSION, SCOPE, and > RESTRICTION in a component (e.g., VRIGHT). BTW, following our discussions (no two VCARs can have the same CARID within the same scope), I've already modified my proposal to allow multiple access rights to be defined in a single VCAR. I'm planning to post an updated version of my proposal tomorrow. > > > and not different > > levels of CAR support. > > Restricting a predefined vcar has nothing to do with if a CS > MUST fully understand all VCARs. All I said is that the CUA MUST have a way to know if it can modify, create, delete predefined VCARs. There is no such way with a CAR-MIN CS. That's a problem. > > Such a VCAR could be defined to > > specify that only VCAR with predefined CARID can be read > > and/or modified. As all other predefined VCARs, this VCAR > > could be decreed or not. > > Or we need to remove the restriction from the current VCAR > proposal that limits the predefined VCAR itself from specifying > if it can be modified. There is no such restriction. I think we just need to add one more predefined VCAR to solve the problem. Regards, 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 Feb 4 19:03:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08695 for ; Mon, 4 Feb 2002 19:03:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14Ngg816405 for ietf-calendar-bks; Mon, 4 Feb 2002 15:42:42 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Ngf316401 for ; Mon, 4 Feb 2002 15:42:41 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA20241 for ; Mon, 4 Feb 2002 15:42:43 -0800 (PST) Message-ID: <3C5F1C6C.D59962C4@Royer.com> Date: Mon, 04 Feb 2002 16:42:36 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Comments on VCAR proposal (Was: Re: CAP: What is the purpose of CAR-MIN?) References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> <3C5EF495.743FB1DF@Royer.com> <3C5F0DDB.77708BF7@steltor.com> Content-Type: multipart/mixed; boundary="------------84F8DABCF29D2F65B1F1A7CE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------84F8DABCF29D2F65B1F1A7CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > I think I found a bug in the new VCAR proposal as last > > proposed. You used to be able to specify multiple GRANT/DENY > > in a VCAR, now they seem to be limited to one set per VCAR. > > We used to be able to do this (may be we still can as I am > > still learning the new proposal): > > That's not a bug. This limitation was highlighted in > the introduction of my proposal: That is a matter of opinion. We need to get it back so that it can be done. > Bernard Desruisseaux wrote: > > > > - A VCAR component, as defined in this proposal, can only > > define a single access right. If there is a need to group > > multiple access rights in a single VCAR (e.g., to share > > the same CARID and/or NAME properties) we could always > > group the properties GRANT, DENY, PERMISSION, SCOPE, and > > RESTRICTION in a component (e.g., VRIGHT). > > BTW, following our discussions (no two VCARs can have > the same CARID within the same scope), I've already > modified my proposal to allow multiple access rights > to be defined in a single VCAR. I'm planning to post > an updated version of my proposal tomorrow. :-) > > > > > and not different > > > levels of CAR support. > > > > Restricting a predefined vcar has nothing to do with if a CS > > MUST fully understand all VCARs. > > All I said is that the CUA MUST have a way to know if it can > modify, create, delete predefined VCARs. There is no such way > with a CAR-MIN CS. That's a problem. No, there is a way - define it in the same VCAR. > > > Such a VCAR could be defined to > > > specify that only VCAR with predefined CARID can be read > > > and/or modified. As all other predefined VCARs, this VCAR > > > could be decreed or not. > > > > Or we need to remove the restriction from the current VCAR > > proposal that limits the predefined VCAR itself from specifying > > if it can be modified. > > There is no such restriction. I think we just need to > add one more predefined VCAR to solve the problem. No - the problem (bug) exists in ALL VCARs. You in the proposal removed the ability for a VCAR to be complex. We need to fix that. --------------84F8DABCF29D2F65B1F1A7CE 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 ; Mon, 4 Feb 2002 19:04:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14NbAP16241 for ietf-calendar-bks; Mon, 4 Feb 2002 15:37:10 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Nb8316236 for ; Mon, 4 Feb 2002 15:37:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA20226 for ; Mon, 4 Feb 2002 15:37:09 -0800 (PST) Message-ID: <3C5F1B1E.D9A71673@Royer.com> Date: Mon, 04 Feb 2002 16:37:02 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re:CAP:LastCallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> <5.1.0.14.0.20020204134506.00b11398@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------52D852A17FC91D23DA0D661D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------52D852A17FC91D23DA0D661D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > > It was my belief that text meant that it needed to know about > > changes since a time. What good is it to 1/2 sync? That is if > > you only get 'changes' from yesterday and ignore changes > > from two days ago? Here is why you don't want that: > > > > Jan. 1 you sync and everything is up to date. > > Jan. 10 your CS gets METHOD:CANCEL for objects in Feb. > > Feb. 1 you sync with a time range of Feb. 1- Feb. 28. > > > > You now missed the METHOD:CANCEL for the VEVENTS in Feb. > > and the results you get back are exactly what you asked for > > and bogus. > > Why have I missed it? If I ask for everything that has changed since > Jan 1st which falls between Feb 1 and Feb 28th the objects within > February that have been deleted will get returned because their > LAST-MODIFIED attribute with be Jan 10th (greater than Jan 1) and > their DTSTARTs fall within the range. No, the LAST-MODIFIED date for the METHOD:CREATE is Jan. 10. And the CS 'does NOT know' how to merge iTIP objects - that is the job of the CUA. Your original QUERY was (edited): > QUERY:SELECT * FROM VEVENT > WHERE LAST-MODIFIED > ...last-sync-time > AND DTSTART > bottom of time range > AND DTSTART < top of time range > AND RRULE IS NULL So as you used the 'AND' logical operator, any object would have to match ALL three expressions, and the Jan-10 object would not match all three. > Are the meetings in February > part of a recurring entry in your example? If so, then yes they'd be > missed which has been my point all along that a query against > LAST-MODIFIED with a time range catches everything but instances of > recurring entries that no longer exist. Only - CUA processed objects - the Jan-10 object has a LAST-MODIFIED of Jan-10 and has not yet been processed/merged into modify object(s) with METHOD:CREATE by the CUA. It does not match your query. > This why in my last response I > compromised and only used a time range when querying for non-recurring > entries and did not when querying for recurring entries since I'll > always have the chance of missing these if I do. > > Please note that above I mean the English word "deleted" and not the > CAP command so please don't correct me by telling me that I mean the > modify command updating the METHOD to CANCEL) Note that in a previous > response you claimed the following... There is NO SUCH THING as a 'deleted instance'. I have no idea what you mean. > "Entire objects are marked for delete by using METHOD:MODIFY > and changing the object in the store to METHOD:DELETE" > > Here you say CANCEL. Which is it? Its the "delete" command which zaps > the whole object which we don't want CUAs to do and the "modify" > command with METHOD:DELETE (or CANCEL). I was trying to find out if you meant: (a) An instance is CANCELED or (b) An entire object was marked for delete (METHOD:DELETE). > > > The five words of importance "for a given time period". > > > > > > How does a Sync CUA find out about deleted instances of a > > recurring > > > entry that used to fall within a given time period but which have > > been > > > deleted since the last time a sync was performed without getting > > ALL > > > the changes on the CS and then doing its own time range filtering? > > > > You don't mean 'deleted' you mean METHOD:CANCEL, and those > > would show up with the above query I provided. > > Yes I do mean deleted. I mean the English word deleted as in the > instance is no more and not the CAP command AND yes it would show up > in your query along with ever other change within the user's calendar > but we were trying to find a way to just get those changes within a > given time period. In my compromise I used your approach (with no time > range) only for recurring entries to cut down on the amount of > unnecessary changes being reported to the Sync CUA. There is NO such thing in CAP as a DELETED instance. Which do you mean - CANCELed instance or METHOD:DELETE of the entire object and it instances? > > You can't 'delete' an instance, you can only METHOD:CANCEL > > an instance. You can only delete an object, not instances > > that only exist when the CS expands an object. > > I know that !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From the Sync CUAs > perspective their is an instance that it no more and that is all I am > saying. The CUA which did the deletion should do so as you describe, > yes, we agreed to this several replies back. But you did say: "How does a Sync CUA find out about deleted instances of a recurring ..." I was just trying to figure out which of the two you meant. > entry > > > Perhaps something like this (once again I am simplifying things by > > > just using DTSTART and just worrying about VEVENTS)... > > > > > > QUERY:SELECT * FROM VEVENT > > > WHERE LAST-MODIFIED > ...last-sync-time > > > AND DTSTART > bottom of time range > > > AND DTSTART < top of time range > > > AND RRULE="" (I'm trying to say not recurring. What's the proper > > way > > > of doing this is?) > > > > "AND RRULE IS NULL" I think is what you are saying. But I don't > > think that is what you want - see below. > > What I am saying is "I'm trying to say not recurring. What's the > proper way > of doing this is?". Exactly what's written in the parentheses. I'm > trying to express a query that gets all changes within a given time > period for all non recurring entries but I wasn't sure how to do so, > so I asked for your help. There is NO way to do that in the CS. Because of 'METHOD:ADD' objects. This is VALID in the CS: BEGIN:VEVENT METHOD:CREATE UID: ... LOCATION:#1 DTSTART: in-your-time-range-#1 ... END:VEVENT -AND ALSO IN THE SAME VAGENDA- BEGIN:VEVENT METHOD:CREATE UID: ... LOCATION:#2 DTSTART: in-your-time-range-#2 ... END:VEVENT The second object with THE SAME UID was created by METHOD:ADD. As METHOD:ADD adds instances to an object. Nether contains RRULE, RDATE, EXRULE, or EXDATE. Yet the VEVENT has recurring instances. They CAN not be combined because the LOCATION property is not the same. There is no way to as the CS if there are multiple instances of object without: (a) Asking the CS for all object EXPAND:FALSE and the CUA figuring it out. or (b) Asking the CS for all objects EXPAND:TRUE and counting the objects per unique UID. > I know that. That's why in parentheses I state quite clearly "I'm > trying to say recurring. What's the proper way of doing this is?" In > other words, Please help me with this query. It was not clear to me, that is why this IETF process is so fun :-) > > within the given time range > > I have no time range in this query. Yes you did (bottom of time range AND top of time range): > QUERY:SELECT * FROM VEVENT > WHERE LAST-MODIFIED > ...last-sync-time > AND DTSTART > bottom of time range > AND DTSTART < top of time range > AND RRULE IS NULL > It follows your approach of no > time range since there seems to be no way of ensuring that the Sync > CUA catches instances that have been deleted (the English word deleted > :-)) if you do. So to you mean instance CANCELed or object DELETEed ? You can't delete an instance. Which ever you mean is not true. --------------52D852A17FC91D23DA0D661D 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 ; Mon, 4 Feb 2002 19:05:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14NdcO16302 for ietf-calendar-bks; Mon, 4 Feb 2002 15:39:38 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Ndb316298 for ; Mon, 4 Feb 2002 15:39:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA20233 for ; Mon, 4 Feb 2002 15:39:39 -0800 (PST) Message-ID: <3C5F1BB3.D898343B@Royer.com> Date: Mon, 04 Feb 2002 16:39:31 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> <3C5EF495.743FB1DF@Royer.com> <3C5F0D8E.27D0FB08@steltor.com> Content-Type: multipart/mixed; boundary="------------AC5241916BEFB59FB3642B87" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AC5241916BEFB59FB3642B87 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Doug Royer wrote: > > > > > > > > Bernard Desruisseaux wrote: > > > > > > > > > > Doug Royer wrote: > > > > > > > > > > > > Explain how a CUA can know if a CS can only handle > > > > > > the CAP predefined VCARs? > > > > > > > > > > So, that would be THE purpose of CAR-MIN? > > > > > > > > > > Now can you explain how a CUA can know if it can > > > > > modify the CAP predefined VCARs of a CAR-MIN CS? > > > > > > > > It can't. > > > > > > Then, to "hard code the answer to the predefined VCARs > > > in its ROM", a CS will need to be CAR-FULL-1. Right? > > > > No. It can just copy the predefined (decreed) data to the CUA. > > A CAR-MIN CS implementation would never need to understand how to > > parse a VCAR. And a CAR-MIN CS would never have the ability to > > serve out any non-predefined (non-DEFAULT-VCARS) VCAR. > > > > If a CS implementation needs to allow the CUA to create > > any non-pre-defined VCARs, it is NOT a CAR-MIN CS. > > That's not the issue. > > If a CS hard codes its predefined VCARs it needs to > deny all users the right to WRITE, MODIFY and DELETE > them. No - it only needs to deny all users the right to WRITE, MODIFY, and DELETE 'decreed' VCARs. > Currently, there is no predefined VCARs meant > to allow the CS to specify that information. So, as > of now, a CAR-MIN CS cannot hard code its predefined > VCAR. > > > > It seems as all we really need is yet another predefined > > > CARID to specify VCAR's access right, > > > > Why not include it as part of the predefined VCAR? > > I wouldn't have any problem adding a predefined VCAR > with CARID:DEFAULTVCAR (I'm open to suggestion for a > better name). > > Now, given that this predefined VCAR could specify which > VCAR you are allowed to READ, WRITE, MODIFY and DELETE, > we no longer need CAR-MIN. This predefined VCAR is all > we need to fulfil the purpose for which CAR-MIN existed. No. You still (above) seem to think that predefined means decreed - they are not the same thing. --------------AC5241916BEFB59FB3642B87 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 ; Tue, 5 Feb 2002 08:33:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15DGgT16961 for ietf-calendar-bks; Tue, 5 Feb 2002 05:16:42 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15DGe316956 for ; Tue, 5 Feb 2002 05:16:41 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id IAA32161 for ; Tue, 5 Feb 2002 08:16:36 -0500 Received: from c-1401.steltor.com ([192.168.2.3]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g15DGYQ05747 for ; Tue, 5 Feb 2002 08:16:34 -0500 (EST) Message-Id: <5.1.0.14.0.20020204180406.00a705d8@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Feb 2002 21:22:20 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP:LastCallByMarchIETF: Need Volunteers!] In-Reply-To: <3C5ED2B4.762B4A7E@Royer.com> References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe:
2nd reply.

While putting together my first reply to this message it started to become clear why Doug and I seem to be so far apart.  I thought of scrapping the first reply all together and starting over but I still wanted to point out where I felt what I had written was misinterpreted such that my original reply could be reconsidered properly.

What I wrote should be coupled with what is in this reply as well to fully understand things.

Let's look at Doug's example again...

Here is why you don't want that:

        Jan. 1  you sync and everything is up to date.
        Jan. 10  your CS gets METHOD:CANCEL for objects in Feb.
        Feb. 1   you sync with a time range of Feb. 1- Feb. 28.

     You now missed the METHOD:CANCEL for the VEVENTS in Feb.
     and the results you get back are exactly what you asked for
     and bogus.

To start I think the example should read METHOD:DELETE and not METHOD:CANCEL but either way how come I think for sure that I'll get back the deleted object and Doug doesn't?

The problem lies in how we see objects within the CS and how we expect VQUERY to react I suspect.

In my view of the world there is an up-to-date copy of the object in February so when it gets deleted on Jan 10th its last modified time gets updated to Jan 10, its METHOD becomes CANCEL, the DTSTART is still there, and I suppose the SEQUENCE has been incremented. So if you apply the following query to that vision of the world you'll be told about the meeting in February which has been deleted.

QUERY:SELECT * FROM VEVENT
WHERE LAST-MODIFIED > last-sync-time
AND DTSART > bottom of time range
AND DTSTART < top of time range

Now let's look at it differently. Instead of there being an up-to-date object there is an object with a DTSTART in February and a METHOD:CREATE with a LAST_MODIFIED from perhaps December when the meeting was booked, and a sequence of say 4. On top of this there is also an object (with the same UID) with METHOD;DELETE and a LAST_MODIFIED time of Jan 10th and a sequence of 5. In this vision of the world the query above will not tell the Sync CUA about the deleted meeting in February.

Now let's take these two visions of the world and apply them to the larger query which Doug suggested.


This below would get all instances (with or without RRULE's) that
have changed since your last sync within a time range:

  BEGIN:VQUERY

  EXPAND:TRUE

  QUERY:SELECT * FROM VEVENT
   WHERE LAST-MODIFIED > ..last-sync-time AND METHOD != 'CREATE'

  QUERY:SELECT * FROM VEVENT
   WHERE DTSART > bottom of time range
   AND DTSTART < top of time range
   AND METHOD = 'CREATE'

  END:VQUERY

Above, the CS would EXPAND 'original' VEVENTs into instances,
and only return the ones that fall within the provided time range.
AND it would return any modified objects that might effect
the results. So you would now see the METHOD:CANCEL done
in January that effected the February objects.

With my vision of the world this query just makes no sense whatsoever. Why am I asking for this extra stuff?

But if you use the other vision you need to get all the booked entries within your range along with all the changes. Then your Sync CUA needs to go through all the changes and match them up with all the booked entries within the range to see which ones need to be adjusted accordingly.

If we consider a CAP CS as implemented in this fashion then I agree with Doug that this is how a Sync CUA would have to figure out changes for a specific time range.

Essentially the Sync CUA will have to do all the work as is indicated below.


ONLY a CUA combines objects, the CS does not, so the CS could
not 'know' that the January 10th object effected the February
objects in order to return them in the query.

The problem with this is that it doesn't seem to live up to the CAP Sync requirements as they are written.  A Sync CUA in the end has to download all booked entries within a range along with all changes and combine the objects (as described above) and figure out what's changed.

If this is the case then I think Doug's suggestion from an earlier response that their be a query such as this...

"a predefined VQUERY, GET-WHAT-CHANGED with a
parameter containing a date-time"

Doug suggested that it be an enhancement for a CAP update but if the only current way for a Sync CUA to figure out changes is with the bigger query above where it downloads everything and figures it out on its own then I'd say it is needed now or NO, CAP does not live up to the Sync requirements.

This however all hinges on how we expect a CS to react. In the first example at the top of this email should my query return the deleted meeting in February? Yes or No?

If the answer is YES (as I thought it would) then something close to the queries I've been suggesting should take care of things for sync and satisfy the CAP Sync requirements. If the answer is NO then my argument above applies.

So which is it?

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@steltor.com
http://www.steltor.com



 From owner-ietf-calendar@mail.imc.org Tue Feb 5 09:09:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00168 for ; Tue, 5 Feb 2002 09:09:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15Dgx017561 for ietf-calendar-bks; Tue, 5 Feb 2002 05:42:59 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Dgw317554 for ; Tue, 5 Feb 2002 05:42:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id IAA32530 for ; Tue, 5 Feb 2002 08:42:53 -0500 Received: from c-1401.steltor.com ([192.168.2.3]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g15DgpQ08188 for ; Tue, 5 Feb 2002 08:42:51 -0500 (EST) Message-Id: <5.1.0.14.0.20020205082921.00a76cd8@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Feb 2002 08:39:30 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: Fwd: Re: Synchronization [Was: Re:CAP:LastCallByMarchIETF: Need Volunteers!] In-Reply-To: <3C5F1B1E.D9A71673@Royer.com> References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> <5.1.0.14.0.20020204134506.00b11398@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I asked for you to wait for my 2nd reply. I sent it earlier this morning when I logged in. I think you'll be less frustrated reading it. I know what you mean now. I don't necessarily agree but based on how you see objects laid out within the CS (where only CUAs can combine them) I understand what you are saying and agree your query would work the way you are thinking.

I still can't figure out why you can't understand that when I write an English sentence with the word "delete" that I just mean that a user is sitting in front of his computer and he has his calendar up and he has chosen to delete something. The user doesn't care how the CUA actually goes about making the meeting go away. I just find it easier when describing something at a conceptual level to just keep it in simple English but I will try be more careful in the future and try to spell out exactly what is happening in CAPese :-)

At 04:37 PM 2/4/2002 -0700, you wrote:

Mark Paterson wrote:

> > It was my belief that text meant that it needed to know about
> > changes since a time. What good is it to 1/2 sync? That is if
> > you only get 'changes' from yesterday and ignore changes
> > from two days ago? Here is why you don't want that:
> >
> >         Jan. 1  you sync and everything is up to date.
> >         Jan. 10  your CS gets METHOD:CANCEL for objects in Feb.
> >         Feb. 1   you sync with a time range of Feb. 1- Feb. 28.
> >
> >      You now missed the METHOD:CANCEL for the VEVENTS in Feb.
> >      and the results you get back are exactly what you asked for
> >      and bogus.
>
> Why have I missed it? If I ask for everything that has changed since
> Jan 1st which falls between Feb 1 and Feb 28th the objects within
> February that have been deleted will get returned because their
> LAST-MODIFIED attribute with be Jan 10th (greater than Jan 1) and
> their DTSTARTs fall within the range.

No, the LAST-MODIFIED date for the METHOD:CREATE is Jan. 10.
And the CS 'does NOT know' how to merge iTIP objects - that
is the job of the CUA. Your original QUERY was (edited):

>   QUERY:SELECT * FROM VEVENT
>   WHERE LAST-MODIFIED >  ...last-sync-time
>   AND DTSTART > bottom of time range
>   AND DTSTART < top of time range
>   AND RRULE IS NULL

So as you used the 'AND' logical operator, any object would have
to match ALL three expressions, and the Jan-10 object would not
match all three.

> Are the meetings in February
> part of a recurring entry in your example? If so, then yes they'd be
> missed which has been my point all along that a query against
> LAST-MODIFIED with a time range catches everything but instances of
> recurring entries that no longer exist.

Only - CUA processed objects - the Jan-10 object has a LAST-MODIFIED
of Jan-10 and has not yet been processed/merged into modify object(s)
with METHOD:CREATE by the CUA. It does not match your query.

> This why in my last response I
> compromised and only used a time range when querying for non-recurring
> entries and did not when querying for recurring entries since I'll
> always have the chance of missing these if I do.
>
> Please note that above I mean the English word "deleted" and not the
> CAP command so please don't correct me by telling me that I mean the
> modify command updating the METHOD to CANCEL)  Note that in a previous
> response you claimed the following...

There is NO SUCH THING as a 'deleted instance'. I have no idea
what you mean.

> "Entire objects are marked for delete by using METHOD:MODIFY
> and changing the object in the store to METHOD:DELETE"
>
> Here you say CANCEL. Which is it? Its the "delete" command which zaps
> the whole object which we don't want CUAs to do and the "modify"
> command with METHOD:DELETE (or CANCEL).

I was trying to find out if you meant:

        (a) An instance is CANCELED
or
        (b) An entire object was marked for delete (METHOD:DELETE).


> > > The five words of importance "for a given time period".
> > >
> > > How does a Sync CUA find out about deleted instances of a
> > recurring
> > > entry that used to fall within a given time period but which have
> > been
> > > deleted since the last time a sync was performed without getting
> > ALL
> > > the changes on the CS and then doing its own time range filtering?
> >
> > You don't mean 'deleted' you mean METHOD:CANCEL, and those
> > would show up with the above query I provided.
>
> Yes I do mean deleted. I mean the English word deleted as in the
> instance is no more and not the CAP command AND yes it would show up
> in your query along with ever other change within the user's calendar
> but we were trying to find a way to just get those changes within a
> given time period. In my compromise I used your approach (with no time
> range) only for recurring entries to cut down on the amount of
> unnecessary changes being reported to the Sync CUA.

There is NO such thing in CAP as a DELETED instance.

Which do you mean - CANCELed instance or METHOD:DELETE of
the entire object  and it instances?

> > You can't 'delete' an instance, you can only METHOD:CANCEL
> > an instance. You can only delete an object, not instances
> > that only exist when the CS expands an object.
>
> I know that !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From the Sync CUAs
> perspective their is an instance that it no more and that is all I am
> saying. The CUA which did the deletion should do so as you describe,
> yes, we agreed to this several replies back.

But you did say: "How does a Sync CUA find out about deleted instances
                  of a recurring ..."

I was just trying to figure out which of the two you meant.

> entry
> > > Perhaps something like this (once again I am simplifying things by
> > > just using DTSTART and just worrying about VEVENTS)...
> > >
> > > QUERY:SELECT * FROM VEVENT
> > > WHERE LAST-MODIFIED >  ...last-sync-time
> > > AND DTSTART > bottom of time range
> > > AND DTSTART < top of time range
> > > AND RRULE="" (I'm trying to say not recurring. What's the proper
> > way
> > > of doing this is?)
> >
> > "AND RRULE IS NULL" I think is what you are saying. But I don't
> > think that is what you want - see below.
>
> What I am saying is "I'm trying to say not recurring. What's the
> proper way
> of doing this is?". Exactly what's written in the parentheses. I'm
> trying to express a query that gets all changes within a given time
> period for all non recurring entries but I wasn't sure how to do so,
> so I asked for your help.

There is NO way to do that in the CS. Because of 'METHOD:ADD' objects.
This is VALID in the CS:

        BEGIN:VEVENT
        METHOD:CREATE
        UID:<uid-1>
        ...
        LOCATION:#1
        DTSTART: in-your-time-range-#1
        ...
        END:VEVENT

-AND ALSO IN THE SAME VAGENDA-

        BEGIN:VEVENT
        METHOD:CREATE
        UID:<uid-1>
        ...
        LOCATION:#2
        DTSTART: in-your-time-range-#2
        ...
        END:VEVENT

The second object with THE SAME UID was created by METHOD:ADD.
As METHOD:ADD adds instances to an object. Nether contains RRULE,
RDATE, EXRULE, or EXDATE. Yet the VEVENT has recurring instances.
They CAN not be combined because the LOCATION property is not
the same.

There is no way to as the CS if there are multiple instances
of object without:

        (a) Asking the CS for all object EXPAND:FALSE and the
            CUA figuring it out.
or
        (b) Asking the CS for all objects EXPAND:TRUE and
            counting the objects per unique UID.

> I know that. That's why in parentheses I state quite clearly "I'm
> trying to say recurring. What's the proper way of doing this is?"  In
> other words, Please help me with this query.

It was not clear to me, that is why this IETF process is so fun :-)

> > within the given time range
>
> I have no time range in this query.

Yes you did (bottom of time range AND top of time range):

>   QUERY:SELECT * FROM VEVENT
>   WHERE LAST-MODIFIED >  ...last-sync-time
>   AND DTSTART > bottom of time range
>   AND DTSTART < top of time range
>   AND RRULE IS NULL

> It follows your approach of no
> time range since there seems to be no way of ensuring that the Sync
> CUA catches instances that have been deleted (the English word deleted
> :-)) if you do.

So to you mean instance CANCELed or object DELETEed ?
You can't delete an instance.

Which ever you mean is not true.

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@steltor.com
http://www.steltor.com



 From owner-ietf-calendar@mail.imc.org Tue Feb 5 09:49:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01570 for ; Tue, 5 Feb 2002 09:49:40 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15EZLB21032 for ietf-calendar-bks; Tue, 5 Feb 2002 06:35:21 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15EZK321027 for ; Tue, 5 Feb 2002 06:35:20 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA01607 for ; Tue, 5 Feb 2002 09:35:20 -0500 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 g15EZKQ15554 for ; Tue, 5 Feb 2002 09:35:20 -0500 (EST) Message-ID: <3C5FEE14.C23F6D80@steltor.com> Date: Tue, 05 Feb 2002 09:37:08 -0500 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: CAP: Definition of CAR-MIN 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 I would like to propose the following definition for the CAR capability "CAR-MIN". The CAR capability "CAR-MIN" indicates that the CS only supports VCARs with the following predefined CARIDs: READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and DEFAULTOWNER. Regards, 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 Feb 5 09:51:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01935 for ; Tue, 5 Feb 2002 09:51:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15EWx620929 for ietf-calendar-bks; Tue, 5 Feb 2002 06:32:59 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15EWw320924 for ; Tue, 5 Feb 2002 06:32:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA01401 for ; Tue, 5 Feb 2002 09:32:50 -0500 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 g15EWnQ14611 for ; Tue, 5 Feb 2002 09:32:49 -0500 (EST) Message-ID: <3C5FED7D.CBEB21AD@steltor.com> Date: Tue, 05 Feb 2002 09:34:37 -0500 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: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> <3C5EF495.743FB1DF@Royer.com> <3C5F0D8E.27D0FB08@steltor.com> <3C5F1BB3.D898343B@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: > > > > If a CS hard codes its predefined VCARs it needs to > > deny all users the right to WRITE, MODIFY and DELETE > > them. > > No - it only needs to deny all users the right to > WRITE, MODIFY, and DELETE 'decreed' VCARs. Defining a VCAR as "decreed" is all that is needed to deny all those rights. Correct? > > Currently, there is no predefined VCARs meant > > to allow the CS to specify that information. So, as > > of now, a CAR-MIN CS cannot hard code its predefined > > VCAR. > > > > > > It seems as all we really need is yet another predefined > > > > CARID to specify VCAR's access right, > > > > > > Why not include it as part of the predefined VCAR? > > > > I wouldn't have any problem adding a predefined VCAR > > with CARID:DEFAULTVCAR (I'm open to suggestion for a > > better name). > > > > Now, given that this predefined VCAR could specify which > > VCAR you are allowed to READ, WRITE, MODIFY and DELETE, > > we no longer need CAR-MIN. This predefined VCAR is al > > we need to fulfil the purpose for which CAR-MIN existed. > > No. You still (above) seem to think that predefined means > decreed - they are not the same thing. It is clear to me that they are not the same. Regards, 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 Feb 5 10:01:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02367 for ; Tue, 5 Feb 2002 10:01:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15EaGL21076 for ietf-calendar-bks; Tue, 5 Feb 2002 06:36:16 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15EaF321071 for ; Tue, 5 Feb 2002 06:36:15 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA01624 for ; Tue, 5 Feb 2002 09:36:11 -0500 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 g15EaBQ15605 for ; Tue, 5 Feb 2002 09:36:11 -0500 (EST) Message-ID: <3C5FEE47.62046C9E@steltor.com> Date: Tue, 05 Feb 2002 09:37:59 -0500 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: CAP: Hardcoded VCARs with predefined CARIDs / New DECREED property in VCAR 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 CS limited to the CAR-MIN CAR capability willing to hard code the VCARs with predefined CARIDs should define these VCARs as "decreed" in order to deny all users the right to write, modify, and delete these VCARs. I propose the addition of a new DECREED property of value type BOOLEAN in VCAR components. Example: BEGIN:VCAR CARID:READBUSYTIMEINFO DECREED:TRUE GRANT:* PERMISSION:READ SCOPE:SELECT * FROM VFREEBUSY END:VCAR Regards, 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 Feb 5 10:30:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03840 for ; Tue, 5 Feb 2002 10:30:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15FBdB24012 for ietf-calendar-bks; Tue, 5 Feb 2002 07:11:39 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15FBb324006 for ; Tue, 5 Feb 2002 07:11:37 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA02830; Tue, 5 Feb 2002 10:11:30 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g15FAxQ20074; Tue, 5 Feb 2002 10:10:59 -0500 (EST) Message-ID: <3C5FF602.46D11A6E@steltor.com> Date: Tue, 05 Feb 2002 10:10:58 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Summmary Of January 31st 2002 CAP Editors Conference Call 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 The summary of what was discussed during last Thursday's CAP Editors conference call: - We need to make sure that CAP supports internationalization. We believe it does. However, we need to prove it to the area directors. We may need to add "Internationalization" section to CAP. - We need to resolve the issues with synchronization. We may need to add a "synchronization" section to explain how a CUA can do it. - George will move the "Editors Notes" from CAP into the CAL issues and to do list. - It seems that there is consensus on the CURRENT_DATETIME issue. Will we close it and adjust the draft. - Need to try to close all the issues that we seem to have a consensus on. Other than for minor typos, anything that changes the ABNF or text that describes the ABNF will be posted to the list. Otherwise, we will post a summary of the changes done after reaching consensus. We need to keep a list of what we changed, and notify the WG that 'xxx' changed. - Are there any examples missing from CAP? We need to be careful not to add too many examples since the document is already quite large and we want people to implement the protocol and not the examples. - We need to resolve the issue of how to handle local changes to components. Doug will post something to the list. - Need to make sure that the capabilities command returns the capabilities of the protocol and not the properties of the CS. Furthermore, the properties of the CS should not include capabilities of the protocol. From owner-ietf-calendar@mail.imc.org Tue Feb 5 10:35:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04237 for ; Tue, 5 Feb 2002 10:35:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15FE8B24139 for ietf-calendar-bks; Tue, 5 Feb 2002 07:14:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15FE6324132 for ; Tue, 5 Feb 2002 07:14:07 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA03321 for ; Tue, 5 Feb 2002 10:14:01 -0500 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 g15FE1Q21807 for ; Tue, 5 Feb 2002 10:14:01 -0500 (EST) Message-ID: <3C5FF725.C07691A7@steltor.com> Date: Tue, 05 Feb 2002 10:15:49 -0500 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: CAP: Comments on VCAR proposal (Was: Re: CAP: What is the purpose of CAR-MIN?) References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> <3C5EF495.743FB1DF@Royer.com> <3C5F0DDB.77708BF7@steltor.com> <3C5F1C6C.D59962C4@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: > > > > All I said is that the CUA MUST have a way to know if it can > > modify, create, delete predefined VCARs. There is no such way > > with a CAR-MIN CS. That's a problem. > > No, there is a way - define it in the same VCAR. The VCAR with CARID:REQUESTONLY should only specify whether users are granted or not the right to WRITE iCalendar objects that contain METHOD:REQUEST. If that's not the case, then let's drop all VCARs with predefined CARID as they won't be any easier to parse/interpret than any other VCAR. > > > > Such a VCAR could be defined to > > > > specify that only VCAR with predefined CARID can be read > > > > and/or modified. As all other predefined VCARs, this VCAR > > > > could be decreed or not. > > > > > > Or we need to remove the restriction from the current VCAR > > > proposal that limits the predefined VCAR itself from specifying > > > if it can be modified. I understand what you meant now, and I can say that I'm against removing this restriction. I will state this restriction clearly in my proposal as I don't think it was written anywhere. > > There is no such restriction. I think we just need to > > add one more predefined VCAR to solve the problem. > > No - the problem (bug) exists in ALL VCARs. You in the > proposal removed the ability for a VCAR to be complex. > We need to fix that. I've already added back this ability in my proposal, but it should not be used for the purpose you mentioned. Regards, 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 Feb 5 12:07:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08671 for ; Tue, 5 Feb 2002 12:07:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15GltK29151 for ietf-calendar-bks; Tue, 5 Feb 2002 08:47:55 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Gls329145 for ; Tue, 5 Feb 2002 08:47:54 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA21303 for ; Tue, 5 Feb 2002 08:47:54 -0800 (PST) Message-ID: <3C600CB7.32AADB47@Royer.com> Date: Tue, 05 Feb 2002 09:47:51 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Definition of CAR-MIN References: <3C5FEE14.C23F6D80@steltor.com> Content-Type: multipart/mixed; boundary="------------E02246EBF33C07A364489FDD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E02246EBF33C07A364489FDD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > I would like to propose the following definition for the > CAR capability "CAR-MIN". > > The CAR capability "CAR-MIN" indicates that the CS only > supports VCARs with the following predefined CARIDs: > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and > DEFAULTOWNER. And and: or any IANA or X-NAME. Okay? --------------E02246EBF33C07A364489FDD 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 ; Tue, 5 Feb 2002 12:07:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15GgKv28889 for ietf-calendar-bks; Tue, 5 Feb 2002 08:42:20 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15GgI328884 for ; Tue, 5 Feb 2002 08:42:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA21287 for ; Tue, 5 Feb 2002 08:42:18 -0800 (PST) Message-ID: <3C600B66.BCC2169F@Royer.com> Date: Tue, 05 Feb 2002 09:42:14 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re:CAP:LastCallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> <5.1.0.14.0.20020204180406.00a705d8@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------8F6326F268406C1490C4F176" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8F6326F268406C1490C4F176 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > In my view of the world there is an up-to-date copy of the object in > February so when it gets deleted on Jan 10th its last modified time > gets updated to Jan 10, its METHOD becomes CANCEL, the DTSTART is > still there, and I suppose the SEQUENCE has been incremented. So if > you apply the following query to that vision of the world you'll be > told about the meeting in February which has been deleted. More text that disappeared in 06. This was in 05 and it has NOTHING todo with CAP tranaport and I can find any discussion that should have caused it to be removed, I'll assume it was an errror to remove it. It clearly describes the iTIP CANCEL and how to use the new METHOD:DELETE. Again this is accidently deleted text from 05 that we need to put back into CAP (+ BEEP wrappers for it): 7.2.2.1 Reading Scheduling Components A CU might be invited to a meeting. If the CU had been invited by CAP, the entry in the CU calendar will be scheduled, but not booked. So a CUA will need to look for scheduled entries in the calendar and present them to the CU or automaticly decide if the invitation is to be accepted or processed. Example: The little league coach places the teams entire schedule into your calendar. Lets say that every game and practice is on a Friday night and your calendar now has this iTIP scheduling data: BEGIN:VCAP VERSION:2.0 METHOD:PUBLISH BEGIN:VEVENT DTSTAMP;TZID=US/Pacific:20000229T180000 DTSTART;TZID=US/Pacific:20000303T180000 ORGANIZER:coach@little.league.com SUMMARY: Schedule of games and practice UID:1-coach@little.league.com SEQUENCE:0 DESCRIPTION:Please have your child at the field and ready to play by 6pm. RRULE:FREQ=WEEKLY;COUNT=10 END:VEVENT END:VCAP At this point the above VEVENT is not booked in your calendar, It is simply scheduled. A CUA would fetch this and all other scheduled VEVENTs from your calendar with: C: SENDDATA C: Content-type:text/calendar; Method=READ; Component=VQUERY C: C: BEGIN:VCAP C: VERSION:2.1 C: BEGIN:VCOMMAND C: METHOD:READ C: CMDID:xyz12345 C: TARGET:relcal2 C: BEGIN:VQUERY C: QUERY:SELECT * WHERE FROM VEVENT METHOD != 'CREATE' C: END:VQUERY C: END:VCOMMAND C: END:VCAP C: . The the CUA and CU could determine which scheduling items were to remain on the calendar. Each scheduling component could be deleted or updated with METHOD:MODIFY to change the METHOD from PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINE-COUNTER to what the CU and CUA had decided. In some cases the CUA could automaticly do the work and inform the CU. An example of this is CANCEL. If configured to process METHOD:CANCEL it could METHOD:DELETE the component an inform the CU that the booked component had been canceled. The CUA MUST process the scheduled components in the order sent. Some optimization could be done by the CUA. One example is if a PUBLISH and later a CANCEL for the same component with the same SEQUENCE number were scheduled, but not booked. The CUA might never inform the CU and treat it as if the PUBLISH had never been received by doing a METHOD:DELETE on both entries. It is important to note that scheduled components do not show up in busy time as BUSY. Only when they are booked does the TRANSP:OPAQUE property take effect. A CS implementation MAY mark the time as TENTATIVE. This is an implementation and administrative choice. --------------8F6326F268406C1490C4F176 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 ; Tue, 5 Feb 2002 12:08:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15GklI29100 for ietf-calendar-bks; Tue, 5 Feb 2002 08:46:47 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Gkk329096 for ; Tue, 5 Feb 2002 08:46:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA21293 for ; Tue, 5 Feb 2002 08:46:46 -0800 (PST) Message-ID: <3C600C73.676C0857@Royer.com> Date: Tue, 05 Feb 2002 09:46:43 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> <3C5EF495.743FB1DF@Royer.com> <3C5F0D8E.27D0FB08@steltor.com> <3C5F1BB3.D898343B@Royer.com> <3C5FED7D.CBEB21AD@steltor.com> Content-Type: multipart/mixed; boundary="------------A35D51B9F46BF124339C313B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A35D51B9F46BF124339C313B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > If a CS hard codes its predefined VCARs it needs to > > > deny all users the right to WRITE, MODIFY and DELETE > > > them. > > > > No - it only needs to deny all users the right to > > WRITE, MODIFY, and DELETE 'decreed' VCARs. > > Defining a VCAR as "decreed" is all that is needed > to deny all those rights. Correct? Defining a VCAR as decreed only means it is NOT changeable by the CUA. I would think that a CS implementation SHOULD tag that decreed VCAR as read-only - and we still need a way to have multiple GRANT/DENY per VCAR so that one single VCAR can specify complex GRANT/DENY permissions such as this. I think that your had said that you are going to send a proposal that will allow multiple GRANT/DENY in one VCAR. True? --------------A35D51B9F46BF124339C313B 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 ; Tue, 5 Feb 2002 12:27:25 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15HAfa00433 for ietf-calendar-bks; Tue, 5 Feb 2002 09:10:41 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15HAd300428 for ; Tue, 5 Feb 2002 09:10:39 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA07535 for ; Tue, 5 Feb 2002 12:10:35 -0500 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 g15HAYQ07489 for ; Tue, 5 Feb 2002 12:10:34 -0500 (EST) Message-ID: <3C601276.3D3AD195@steltor.com> Date: Tue, 05 Feb 2002 12:12:22 -0500 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: CAP: What is the purpose of CAR-MIN? References: <3C5AFC62.99D19512@steltor.com> <3C5B1D85.C71CE063@Royer.com> <3C5EAB4B.9978C5F4@steltor.com> <3C5EC1B7.3FD68AF6@Royer.com> <3C5ED239.7DA0803E@steltor.com> <3C5EF495.743FB1DF@Royer.com> <3C5F0D8E.27D0FB08@steltor.com> <3C5F1BB3.D898343B@Royer.com> <3C5FED7D.CBEB21AD@steltor.com> <3C600C73.676C0857@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: > > > > Doug Royer wrote: > > > > > > Bernard Desruisseaux wrote: > > > > > > > > If a CS hard codes its predefined VCARs it needs to > > > > deny all users the right to WRITE, MODIFY and DELETE > > > > them. > > > > > > No - it only needs to deny all users the right to > > > WRITE, MODIFY, and DELETE 'decreed' VCARs. > > > > Defining a VCAR as "decreed" is all that is needed > > to deny all those rights. Correct? > > Defining a VCAR as decreed only means it is NOT changeable > by the CUA. I would think that a CS implementation SHOULD > tag that decreed VCAR as read-only - and we still need > a way to have multiple GRANT/DENY per VCAR so that > one single VCAR can specify complex GRANT/DENY permissions > such as this. What do you mean exactly? 1- We simply have to add "DECREED:TRUE" in the VCAR component to specify that it is "decreed", that is, that it is NOT changeable (which imply that you can't WRITE, MODIFY, and DELETE it); 2- All users should explicitly be denied the right to WRITE, MODIFY and DELETE decreed VCAR by means of a VCAR (potentially the same VCAR); 3- In addition to "DECREED:TRUE", all users should explicitly be denied the right to WRITE, MODIFY and DELETE decreed VCAR by means of a VCAR (potentially the same VCAR). > I think that your had said that you are going to send > a proposal that will allow multiple GRANT/DENY in one > VCAR. True? True. Regards, 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 Feb 5 12:36:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10094 for ; Tue, 5 Feb 2002 12:36:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15HJ2B00895 for ietf-calendar-bks; Tue, 5 Feb 2002 09:19:02 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15HJ1300891 for ; Tue, 5 Feb 2002 09:19:01 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA07798 for ; Tue, 5 Feb 2002 12:18:56 -0500 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 g15HIuQ08307 for ; Tue, 5 Feb 2002 12:18:56 -0500 (EST) Message-ID: <3C60146C.996E45A9@steltor.com> Date: Tue, 05 Feb 2002 12:20:44 -0500 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: CAP: Definition of CAR-MIN References: <3C5FEE14.C23F6D80@steltor.com> <3C600CB7.32AADB47@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: > > > > I would like to propose the following definition for the > > CAR capability "CAR-MIN". > > > > The CAR capability "CAR-MIN" indicates that the CS only > > supports VCARs with the following predefined CARIDs: > > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and > > DEFAULTOWNER. > > And and: > > or any IANA or X-NAME. > > Okay? Why would you want/need that? If the CS wants/needs to support more than the four (4) VCARs with predefined CARIDs it simply has to advertize itself as a CAR-FULL-1 CS. Regards, 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 Feb 5 13:16:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11832 for ; Tue, 5 Feb 2002 13:16:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15I2lB03010 for ietf-calendar-bks; Tue, 5 Feb 2002 10:02:47 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15I2i303006 for ; Tue, 5 Feb 2002 10:02:45 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA09432 for ; Tue, 5 Feb 2002 13:02:40 -0500 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 g15I2dQ14810 for ; Tue, 5 Feb 2002 13:02:39 -0500 (EST) Message-ID: <3C601EAC.6576FE66@steltor.com> Date: Tue, 05 Feb 2002 13:04:28 -0500 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: Fwd: Re: Synchronization [Was: Re:CAP:LastCallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> <5.1.0.14.0.20020204180406.00a705d8@imap1.in.steltor.com> <3C600B66.BCC2169F@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: > > More text that disappeared in 06. This was in 05 and it > has NOTHING todo with CAP tranaport and I can find any discussion > that should have caused it to be removed, I'll assume it was > an errror to remove it. It clearly describes the iTIP CANCEL > and how to use the new METHOD:DELETE. Again this is accidently > deleted text from 05 that we need to put back into CAP (+ BEEP > wrappers for it): > > 7.2.2.1 Reading Scheduling Components Doug, This text is present in ALL versions of draft 06. Official Draft 06 available from IETF: http://search.ietf.org/internet-drafts/draft-ietf-calsch-cap-06.txt Latest interim version available at calsch.org: http://calsch.org/ietf/cap.txt > 6.3.2 Processing Scheduling Components > > A CU might be invited to a meeting. If the CU had been invited by > CAP, the entry in the CU calendar will be scheduled, but not booked. > So a CUA will need to look for scheduled entries in the calendar and > present them to the CU or automatically decide if the invitation is > to be accepted or processed. Perhaps you've deleted this text accidentally in your own copy of draft 06? :-) Regards, 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 Feb 5 13:29:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12476 for ; Tue, 5 Feb 2002 13:29:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15I81A03284 for ietf-calendar-bks; Tue, 5 Feb 2002 10:08:01 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15I80303280 for ; Tue, 5 Feb 2002 10:08:00 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA21488; Tue, 5 Feb 2002 10:08:00 -0800 (PST) Message-ID: <3C601F7D.6AACF644@Royer.com> Date: Tue, 05 Feb 2002 11:07:57 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Definition of CAR-MIN References: <3C5FEE14.C23F6D80@steltor.com> <3C600CB7.32AADB47@Royer.com> <3C60146C.996E45A9@steltor.com> Content-Type: multipart/mixed; boundary="------------EB9B02BB3E79EB8D53805274" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EB9B02BB3E79EB8D53805274 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > I would like to propose the following definition for the > > > CAR capability "CAR-MIN". > > > > > > The CAR capability "CAR-MIN" indicates that the CS only > > > supports VCARs with the following predefined CARIDs: > > > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and > > > DEFAULTOWNER. > > > > And and: > > > > or any IANA or X-NAME. > > > > Okay? > > Why would you want/need that? So that they can be extended. So vendors can have extensions. > If the CS wants/needs to support more than the four (4) > VCARs with predefined CARIDs it simply has to advertize > itself as a CAR-FULL-1 CS. No. Not if the CS can't parse VCARS. --------------EB9B02BB3E79EB8D53805274 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 ; Tue, 5 Feb 2002 13:38:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15I9e203387 for ietf-calendar-bks; Tue, 5 Feb 2002 10:09:40 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15I9d303381 for ; Tue, 5 Feb 2002 10:09:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA21498 for ; Tue, 5 Feb 2002 10:09:40 -0800 (PST) Message-ID: <3C601FE0.8AF71935@Royer.com> Date: Tue, 05 Feb 2002 11:09:36 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Definition of CAR-MIN References: <3C5FEE14.C23F6D80@steltor.com> <3C600CB7.32AADB47@Royer.com> <3C60146C.996E45A9@steltor.com> Content-Type: multipart/mixed; boundary="------------070B6DA64F7FC024C2AF614F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------070B6DA64F7FC024C2AF614F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > I would like to propose the following definition for the > > > CAR capability "CAR-MIN". > > > > > > The CAR capability "CAR-MIN" indicates that the CS only > > > supports VCARs with the following predefined CARIDs: > > > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and > > > DEFAULTOWNER. > > > > And and: > > > > or any IANA or X-NAME. > > > > Okay? > > Why would you want/need that? So that they can be extended. So vendors can have extensions. > If the CS wants/needs to support more than the four (4) > VCARs with predefined CARIDs it simply has to advertize > itself as a CAR-FULL-1 CS. No. Not if the CS can't parse VCARS. --------------070B6DA64F7FC024C2AF614F 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 ; Tue, 5 Feb 2002 14:12:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15IlKu04486 for ietf-calendar-bks; Tue, 5 Feb 2002 10:47:20 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15IlH304482 for ; Tue, 5 Feb 2002 10:47:18 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA10752 for ; Tue, 5 Feb 2002 13:47:13 -0500 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 g15IlCQ19900 for ; Tue, 5 Feb 2002 13:47:12 -0500 (EST) Message-ID: <3C60291D.1E9E70C@steltor.com> Date: Tue, 05 Feb 2002 13:49:01 -0500 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: CAP: Definition of CAR-MIN References: <3C5FEE14.C23F6D80@steltor.com> <3C600CB7.32AADB47@Royer.com> <3C60146C.996E45A9@steltor.com> <3C601F7D.6AACF644@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: > > > > Doug Royer wrote: > > > > > > Bernard Desruisseaux wrote: > > > > > > > > I would like to propose the following definition for the > > > > CAR capability "CAR-MIN". > > > > > > > > The CAR capability "CAR-MIN" indicates that the CS only > > > > supports VCARs with the following predefined CARIDs: > > > > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and > > > > DEFAULTOWNER. > > > > > > And and: > > > > > > or any IANA or X-NAME. > > > > > > Okay? > > > > Why would you want/need that? > > So that they can be extended. > So vendors can have extensions. Then, it's my turn to ask: Explain how a CUA can know if a CS can only handle the CAP predefined VCARs? > > If the CS wants/needs to support more than the four (4) > > VCARs with predefined CARIDs it simply has to advertize > > itself as a CAR-FULL-1 CS. > > No. Not if the CS can't parse VCARS. Irrelevant. A CAR-FULL-1 CS could hard code all its VCARs and tag them as "decreed", as long as one of the VCAR denies all users to write, modify and delete VCARs. Regards, 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 Feb 5 14:15:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14530 for ; Tue, 5 Feb 2002 14:15:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15IrLx04627 for ietf-calendar-bks; Tue, 5 Feb 2002 10:53:21 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15IrI304623 for ; Tue, 5 Feb 2002 10:53:19 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA10992 for ; Tue, 5 Feb 2002 13:53:14 -0500 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 g15IrDQ20723 for ; Tue, 5 Feb 2002 13:53:13 -0500 (EST) Message-ID: <3C602A86.2CA515DE@steltor.com> Date: Tue, 05 Feb 2002 13:55:02 -0500 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: CAP: is not a capability of CAP (Was: Re: Summmary Of January 31st 2002 CAP Editors Conference Call) References: <3C5FF602.46D11A6E@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 George Babics wrote: > > - Need to make sure that the capabilities command returns the capabilities of > the protocol and not the properties of the CS. Furthermore, the properties > of the CS should not include capabilities of the protocol. As far as I know, the capability doesn't return capabilities of the protocol. So it should be removed. Besides, I am not convinced that we need a CAR property in addition to DEFAULT-VCARS in the CALSTORE. Regards, 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 Feb 5 15:02:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16926 for ; Tue, 5 Feb 2002 15:02:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15JjJC05738 for ietf-calendar-bks; Tue, 5 Feb 2002 11:45:19 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15JjI305734 for ; Tue, 5 Feb 2002 11:45:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA21657 for ; Tue, 5 Feb 2002 11:45:19 -0800 (PST) Message-ID: <3C60364A.503EF7F0@Royer.com> Date: Tue, 05 Feb 2002 12:45:14 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re:CAP:LastCallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> <5.1.0.14.0.20020204180406.00a705d8@imap1.in.steltor.com> <3C600B66.BCC2169F@Royer.com> <3C601EAC.6576FE66@steltor.com> Content-Type: multipart/mixed; boundary="------------B96C3C4CDD1B9E914079FDD9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B96C3C4CDD1B9E914079FDD9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > More text that disappeared in 06. This was in 05 and it > > has NOTHING todo with CAP tranaport and I can find any discussion > > that should have caused it to be removed, I'll assume it was > > an errror to remove it. It clearly describes the iTIP CANCEL > > and how to use the new METHOD:DELETE. Again this is accidently > > deleted text from 05 that we need to put back into CAP (+ BEEP > > wrappers for it): > > > > 7.2.2.1 Reading Scheduling Components > > Doug, > > This text is present in ALL versions of draft 06. Look closer - the text was changed and it changed not only the transport data - but what was done. The old text specified that the data is deleted from the CS and that the entire object may be METHOD:DELETE (not CANCAL as you have said). > > Perhaps you've deleted this text accidentally > in your own copy of draft 06? :-) No - the meaning of what was done was also changed. --------------B96C3C4CDD1B9E914079FDD9 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 ; Tue, 5 Feb 2002 15:07:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15Jprm05879 for ietf-calendar-bks; Tue, 5 Feb 2002 11:51:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Jpq305874 for ; Tue, 5 Feb 2002 11:51:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA21666 for ; Tue, 5 Feb 2002 11:51:53 -0800 (PST) Message-ID: <3C6037D4.A8B6DB3F@Royer.com> Date: Tue, 05 Feb 2002 12:51:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Definition of CAR-MIN References: <3C5FEE14.C23F6D80@steltor.com> <3C600CB7.32AADB47@Royer.com> <3C60146C.996E45A9@steltor.com> <3C601F7D.6AACF644@Royer.com> <3C60291D.1E9E70C@steltor.com> Content-Type: multipart/mixed; boundary="------------53FC1A6987B0FE6FEE210C50" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------53FC1A6987B0FE6FEE210C50 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Doug Royer wrote: > > > > > > > > Bernard Desruisseaux wrote: > > > > > > > > > > I would like to propose the following definition for the > > > > > CAR capability "CAR-MIN". > > > > > > > > > > The CAR capability "CAR-MIN" indicates that the CS only > > > > > supports VCARs with the following predefined CARIDs: > > > > > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and > > > > > DEFAULTOWNER. > > > > > > > > And and: > > > > > > > > or any IANA or X-NAME. > > > > > > > > Okay? > > > > > > Why would you want/need that? > > > > So that they can be extended. > > So vendors can have extensions. > > Then, it's my turn to ask: > > Explain how a CUA can know if a CS can only handle > the CAP predefined VCARs? (1) The CS advertises CAR-MIN which tells the CUA that the CS can not parse VCARs. (2) The CUA looks at 'DEFAULT-VCARS' to determine what VCARs the CS knows, which is going to be at least the predefined CAP VCARs. (3) The predefined VCARs can only be queried by CARID. > > > If the CS wants/needs to support more than the four (4) > > > VCARs with predefined CARIDs it simply has to advertize > > > itself as a CAR-FULL-1 CS. > > > > No. Not if the CS can't parse VCARS. > > Irrelevant. A CAR-FULL-1 CS could hard code all > its VCARs and tag them as "decreed", as long as > one of the VCAR denies all users to write, modify > and delete VCARs. Any CS that can not PARSE VCARs better advertise CAR-MIN. And it better place the VCARs that it knows in DEFAULT-VCARS. And it better reply to the predefined VCARs by CARID when queried. If a CS can PARSE VCARs it can advertise CAR-FULL-1, and it is still free to mark them read only (decreed). --------------53FC1A6987B0FE6FEE210C50 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 ; Tue, 5 Feb 2002 15:16:26 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15K10q06076 for ietf-calendar-bks; Tue, 5 Feb 2002 12:01:00 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15K0x306071 for ; Tue, 5 Feb 2002 12:00:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA21684 for ; Tue, 5 Feb 2002 12:01:00 -0800 (PST) Message-ID: <3C6039F7.8660A53E@Royer.com> Date: Tue, 05 Feb 2002 13:00:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: is not a capability of CAP (Was: Re: Summmary Of January 31st 2002 CAP Editors Conference Call) References: <3C5FF602.46D11A6E@steltor.com> <3C602A86.2CA515DE@steltor.com> Content-Type: multipart/mixed; boundary="------------96866F7AF12B33A53750E13E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------96866F7AF12B33A53750E13E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > George Babics wrote: > > > > - Need to make sure that the capabilities command returns the > > > capabilities of the protocol and not the properties of the CS. > > Furthermore, the properties of the CS should not include > > capabilities of the protocol. > > As far as I know, the capability doesn't return > capabilities of the protocol. So it should be removed. Yes it does, it returns supported protocol level of the CS with respect to VCARs. If a CS returns CAR-MIN, then the CUA MUST NOT require the CS to be able to parse VCARs. > Besides, I am not convinced that we need a CAR property > in addition to DEFAULT-VCARS in the CALSTORE. I did not propose that CAR be a property. Did you mean the reply to ? --------------96866F7AF12B33A53750E13E 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 ; Tue, 5 Feb 2002 16:06:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15Kqbh07347 for ietf-calendar-bks; Tue, 5 Feb 2002 12:52:37 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15KqZ307341 for ; Tue, 5 Feb 2002 12:52:36 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Feb 2002 15:50:56 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/05/2002 03:52:39 PM, Serialize complete at 02/05/2002 03:52:39 PM Content-Type: multipart/alternative; boundary="=_alternative 00728E7A85256B57_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00728E7A85256B57_= Content-Type: text/plain; charset="US-ASCII" Doug replied with: > > It should be allowable that a Delegator can send non-process info like > > a COMMENT (or other IANA properties/parameters) in the Delegation > > notice. > > As COMMENT is already defined, the delegatee would have no way > of knowing if the COMMENT was from the ORGANIZER or the Delegate. > I think we would need a new property. I think you are adding some extra semantics/usages to the COMMENT property. We added COMMENT with the definition of: Purpose: This property specifies non-processing information intended to provide a comment to the calendar user. but implicit in this was that it was intended to be a 'single shot usage' between the sender and the recipient. It was not something that was to be preserved and passed along. Otherwise you start to have problems with stuff like "When do I purge off COMMENTs?", "Who said what?" (with any degree of assuredness), etc. You could make your CUA encapsulate the COMMENT in a new COMMENT if you like but do NOT want to try and 'preserve' someone elses supposed COMMENTs (or perhaps you do). In any case, you wont be able to do that in iTIP since many restriction tables contain: COMMENT 0 or 1 which is a further indication that COMMENT is not intended to be preserved indefinitely. After all, why would I send back the Organizers COMMENT to then when I really want to send my own back instead??? > Instead; How about we modify the last sentence of the above 2445 text > to say: > > The "ORGANIZER" MUST send out a new REQUEST with > an updated SEQUENCE number. > > That I think solves the problem. Sorry, it doesnt. It makes the entire workflow process 'thrash' if you do that. Just because I delegate a meeting request to Steve, the Organizer now has to invalidate all responses from all other Invitees (the net effect of blindly reving SEQUENCE)?? You go and try to sell that to folks and Ill offer them a better solution! ;^b Its clear from the 2446 that we need to revise the restriction tables so that we can include delegation information otherwise it wont really matter what the prose says since it will be wrong. If we are going to fix it, we should fix it so that it works the way CUs will expect it to work. The normal set of steps are described in the cited text; just the last line is wrong because it precludes the previously described actions. Perhaps you think the other actions are whats wrong?? The solution is to allow the Delegator to make minor changes to the Organizers 'original' REQUEST (ie: Adding the Delegatees info, supplying back a COMMENT of their own to the Organzier saying why the Delegatee is coming [or why the Delegator cannot or both], etc). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00728E7A85256B57_= Content-Type: text/html; charset="US-ASCII"
Doug replied with:
> > It should be allowable that a Delegator can send non-process info like
> > a COMMENT (or other IANA properties/parameters) in the Delegation
> > notice.
>
> As COMMENT is already defined, the delegatee would have no way
> of knowing if the COMMENT was from the ORGANIZER or the Delegate.
> I think we would need a new property.

I think you are adding some extra semantics/usages to the COMMENT property.  We added COMMENT with the definition of:

   Purpose: This property specifies non-processing information intended
  to provide a comment to the calendar user.

but implicit in this was that it was intended to be a 'single shot usage' between the sender and the recipient.  It was not something that was to be preserved and passed along.  Otherwise you start to have problems with stuff like "When do I purge off COMMENTs?", "Who said what?" (with any degree of assuredness), etc.

You could make your CUA encapsulate the COMMENT in a new COMMENT if you like but do NOT want to try and 'preserve' someone elses supposed COMMENTs (or perhaps you do).  In any case, you wont be able to do that in iTIP since many restriction tables contain:

     COMMENT        0 or 1

which is a further indication that COMMENT is not intended to be preserved indefinitely.  After all, why would I send back the Organizers COMMENT to then when I really want to send my own back instead???

> Instead; How about we modify the last sentence of the above 2445 text
> to say:
>
>    The "ORGANIZER" MUST send out a new REQUEST with
>    an updated SEQUENCE number.
>
> That I think solves the problem.

Sorry, it doesnt.  It makes the entire workflow process 'thrash' if you do that.  Just because I delegate a meeting request to Steve, the Organizer now has to invalidate all responses from all other Invitees (the net effect of blindly reving SEQUENCE)??  You go and try to sell that to folks and Ill offer them a better solution! ;^b

Its clear from the 2446 that we need to revise the restriction tables so that we can include delegation information otherwise it wont really matter what the prose says since it will be wrong.

If we are going to fix it, we should fix it so that it works the way CUs will expect it to work.  The normal set of steps are described in the cited text; just the last line is wrong because it precludes the previously described actions.  Perhaps you think the other actions are whats wrong??

The solution is to allow the Delegator to make minor changes to the Organizers 'original' REQUEST (ie: Adding the Delegatees info, supplying back a COMMENT of their own to the Organzier saying why the Delegatee is coming [or why the Delegator cannot or both], etc).  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00728E7A85256B57_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 5 16:21:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19708 for ; Tue, 5 Feb 2002 16:20:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15LAh508381 for ietf-calendar-bks; Tue, 5 Feb 2002 13:10:43 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15LAf308377 for ; Tue, 5 Feb 2002 13:10:42 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: RFC-2445: Re: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Feb 2002 16:09:02 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/05/2002 04:10:45 PM, Serialize complete at 02/05/2002 04:10:45 PM Content-Type: multipart/alternative; boundary="=_alternative 007436E485256B57_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007436E485256B57_= Content-Type: text/plain; charset="US-ASCII" Doug shot back: > No - the debate was over adding new PROPERTIES, your > quote adds parameters. The thread started on parameters and digressed to properties as you note but the ABNF still covers it. In case you haven't seen it lately its: ; the following are optional, ; and MAY occur more than once [Snip] resources / rdate / rrule / x-prop ) on VEVENTs and similar on others... So, we are still covered! If you decided to make a NEW property that digresses from the standard ABNF model of "optional and more than once" then go ahead and shot your self in the head, its your bad not mine. > I could make it a mess to do that using a parameter with more > than two languages. The mess comes in how you try to link ALT-xxx to a property of a similar name as being the alternate rendering. Thats an implicit assumption Id hate to deal with for sure... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007436E485256B57_= Content-Type: text/html; charset="US-ASCII"
Doug shot back:

> No - the debate was over adding new PROPERTIES, your
> quote adds parameters.

The thread started on parameters and digressed to properties as you note but the ABNF still covers it.  In case you haven't seen it lately its:

                ; the following are optional,
               ; and MAY occur more than once

[Snip]
                resources / rdate / rrule / x-prop

               )

on VEVENTs and similar on others...    So, we are still covered!  If you decided to make a NEW property that digresses from the standard ABNF model of "optional and more than once" then go ahead and shot your self in the head, its your bad not mine.

> I could make it a mess to do that using a parameter with more
> than two languages.

The mess comes in how you try to link ALT-xxx to a property of a similar name as being the alternate rendering.  Thats an implicit assumption Id hate to deal with for sure...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007436E485256B57_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 5 16:34:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20239 for ; Tue, 5 Feb 2002 16:34:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15LI8M08761 for ietf-calendar-bks; Tue, 5 Feb 2002 13:18:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15LI7308757 for ; Tue, 5 Feb 2002 13:18:07 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA14749 for ; Tue, 5 Feb 2002 16:18:04 -0500 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 g15LI3Q07490 for ; Tue, 5 Feb 2002 16:18:03 -0500 (EST) Message-ID: <3C604C78.7CB6292D@steltor.com> Date: Tue, 05 Feb 2002 16:19:52 -0500 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: CAP: is not a capability of CAP (Was: Re: Summmary Of January 31st 2002 CAP Editors Conference Call) References: <3C5FF602.46D11A6E@steltor.com> <3C602A86.2CA515DE@steltor.com> <3C6039F7.8660A53E@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: > > > > As far as I know, the capability doesn't return > > capabilities of the protocol. So it should be removed. > > Yes it does, it returns supported protocol level of the > CS with respect to VCARs. What are you talking about? CAR-MIN does NOT change the CAP protocol. > If a CS returns CAR-MIN, > then the CUA MUST NOT require the CS to be able to parse > VCARs. This is NOT specified anywhere, and on all the occasions that I've asked this list for the purpose of CAR-MIN, this was NEVER mentioned. Furthermore, this doesn't make sense. If CU are granted the right to modify the VCARs with predefined CARIDs, the CS obviously will need to parse and interpret the VCARs. Finally, the fact that the CS can parse VCAR or not is not relevant to the protocol or the CUA for that matter. > > Besides, I am not convinced that we need a CAR property > > in addition to DEFAULT-VCARS in the CALSTORE. > > I did not propose that CAR be a property. True. > Did you mean the reply to ? No. I meant to say that I was not convinced that we should add a CAR property to CALSTORE, given that we should remove the capability. Regards, 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 Feb 5 16:36:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20316 for ; Tue, 5 Feb 2002 16:36:40 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15LNRQ09087 for ietf-calendar-bks; Tue, 5 Feb 2002 13:23:27 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15LNQ309080 for ; Tue, 5 Feb 2002 13:23:26 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA14903 for ; Tue, 5 Feb 2002 16:23:23 -0500 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 g15LNMQ08132 for ; Tue, 5 Feb 2002 16:23:22 -0500 (EST) Message-ID: <3C604DB7.DA91CC59@steltor.com> Date: Tue, 05 Feb 2002 16:25:11 -0500 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: Fwd: Re: Synchronization [Was: Re:CAP:LastCallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> <5.1.0.14.0.20020204180406.00a705d8@imap1.in.steltor.com> <3C600B66.BCC2169F@Royer.com> <3C601EAC.6576FE66@steltor.com> <3C60364A.503EF7F0@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: > > > > Doug Royer wrote: > > > > > > More text that disappeared in 06. > > > > Doug, > > > > This text is present in ALL versions of draft 06. > > Look closer - the text was changed and it changed not > only the transport data - but what was done. Perhaps, and thank you for bringing this to the attention of the list. On the other hand, you shouldn't claim that some text has disappeared when it has only changed. Regards, 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 Feb 5 16:38:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20371 for ; Tue, 5 Feb 2002 16:38:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15LRG109296 for ietf-calendar-bks; Tue, 5 Feb 2002 13:27:16 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15LRE309292 for ; Tue, 5 Feb 2002 13:27:14 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 5 Feb 2002 16:34:33 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/05/2002 04:34:51 PM, Serialize complete at 02/05/2002 04:34:51 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Just because I delegate a meeting request to Steve, the Organizer now has to invalidate all responses from all other Invitees[...]?? That might be the Right Thing, though. Maybe some other invitee accepted only because you were invited, and isn't interested if Steve is coming instead. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |All I ask is a chance to prove that money can't make me happy.| \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 5 16:57:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20939 for ; Tue, 5 Feb 2002 16:57:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15Lhs010265 for ietf-calendar-bks; Tue, 5 Feb 2002 13:43:54 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Lhq310260 for ; Tue, 5 Feb 2002 13:43:53 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: RFC-2445: Re: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 5 Feb 2002 16:51:12 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/05/2002 04:51:29 PM, Serialize complete at 02/05/2002 04:51:29 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >The mess comes in how you try to link ALT-xxx to a property of a >similar name as being the alternate rendering. Thats an implicit >assumption Id hate to deal with for sure... Not at all. It's an explicit part of the definition of ALT-foo. The only implementations that don't understand that link will be the ones that don't understand ALT-foo; and those will simply ignore it and default to foo. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |I'm not imaginary. I'm ontologically challenged. | \========================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 5 17:05:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21161 for ; Tue, 5 Feb 2002 17:05:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15Ln0q10551 for ietf-calendar-bks; Tue, 5 Feb 2002 13:49:00 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Lmx310547 for ; Tue, 5 Feb 2002 13:48:59 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA15368 for ; Tue, 5 Feb 2002 16:48:57 -0500 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 g15LmuQ10625 for ; Tue, 5 Feb 2002 16:48:56 -0500 (EST) Message-ID: <3C6053B5.17FE33D7@steltor.com> Date: Tue, 05 Feb 2002 16:50:45 -0500 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: CAP: Definition of CAR-MIN References: <3C5FEE14.C23F6D80@steltor.com> <3C600CB7.32AADB47@Royer.com> <3C60146C.996E45A9@steltor.com> <3C601F7D.6AACF644@Royer.com> <3C60291D.1E9E70C@steltor.com> <3C6037D4.A8B6DB3F@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: > > > > Then, it's my turn to ask: > > > > Explain how a CUA can know if a CS can only handle > > the CAP predefined VCARs? > > (1) The CS advertises CAR-MIN which tells the CUA that > the CS can not parse VCARs. This is not true. Else, why would CU waste their valuable time modifying the VCARs with predefined CARID? > (2) The CUA looks at 'DEFAULT-VCARS' to determine what > VCARs the CS knows, which is going to be at least > the predefined CAP VCARs. DEFAULT-VCARS is not meant to advertize the VCARs the CS knows, but the VCAR that MUST be copied in newly created VAGENDA. That's different. > (3) The predefined VCARs can only be queried by CARID. a) Again, this was never mentioned on the list. b) This is of no help. The question was: "how a CUA can know if a CS can only handle the CAP predefined VCARs?" c) Why shouldn't I be able to query the predefined VCARs by other properties? There is no such restriction for other components, and there are no reasons to handle VCAR differently. > > > > If the CS wants/needs to support more than the four (4) > > > > VCARs with predefined CARIDs it simply has to advertize > > > > itself as a CAR-FULL-1 CS. > > > > > > No. Not if the CS can't parse VCARS. > > > > Irrelevant. A CAR-FULL-1 CS could hard code all > > its VCARs and tag them as "decreed", as long as > > one of the VCAR denies all users to write, modify > > and delete VCARs. > > Any CS that can not PARSE VCARs better advertise CAR-MIN. Why? > And it better place the VCARs that it knows in DEFAULT-VCARS. Not necessarily (see above). > And it better reply to the predefined VCARs by CARID when queried. Yes. But not only "by CARID". > > If a CS can PARSE VCARs it can advertise CAR-FULL-1, and > it is still free to mark them read only (decreed). Yes, it CAN (i.e., this is not a MUST). Regards, 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 Feb 5 17:24:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21672 for ; Tue, 5 Feb 2002 17:24:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15M97A11646 for ietf-calendar-bks; Tue, 5 Feb 2002 14:09:07 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15M96311638 for ; Tue, 5 Feb 2002 14:09:06 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA15806; Tue, 5 Feb 2002 17:09:03 -0500 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 g15M92Q12710; Tue, 5 Feb 2002 17:09:03 -0500 (EST) Message-ID: <3C60586B.662B38D3@steltor.com> Date: Tue, 05 Feb 2002 17:10:51 -0500 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: Bruce_Kahn@notesdev.ibm.com CC: "ietf-calendar@imc.org" Subject: CAP: CAR-MIN and predefined CARIDs (Was: Re: CAP: DEFAULT_VCARS) References: <3BF9485D.69E8DF89@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: > > In: > > 10.1 Calendar Store Properties > > Is: > > DEFAULT_VCARS N TEXT A multivalued property > containing the default VCARs > for newly created top level > calendars. Each entry is a > CARID. It MUST include at a > minimum > READBUSYTIMEINFO,REQUESTONLY, > UPDATEPARTSTATUS, and > DEFAULTOWNER. > > As part of the debate that separated SQL into SQL-MIN and SQL-92, > there was an agreement (Insisted upon by I think Frank and perhaps > Bruce), for some pre-defined VCARS. They were agreed to be: > > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER. Bruce, Would you remember why the VCARs with predefined CARIDs were introduced in CAP, and how they relate to the CAR capability "CAR-MIN"? Regards, 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 Feb 5 17:39:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22037 for ; Tue, 5 Feb 2002 17:39:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15MSKh12855 for ietf-calendar-bks; Tue, 5 Feb 2002 14:28:20 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15MSJ312851 for ; Tue, 5 Feb 2002 14:28:19 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21896 for ; Tue, 5 Feb 2002 14:28:21 -0800 (PST) Message-ID: <3C605C76.D5267FD5@Royer.com> Date: Tue, 05 Feb 2002 15:28:06 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC-2445: Re: CAP: LANGUAGE parameter References: Content-Type: multipart/mixed; boundary="------------F83D1003B97AE587FB24E10A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F83D1003B97AE587FB24E10A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug shot back: > > > No - the debate was over adding new PROPERTIES, your > > quote adds parameters. > > The thread started on parameters and digressed to properties as you > note but the ABNF still covers it. In case you haven't seen it lately > its: Welcome to follow the IETF thread :-) Much like musical chairs, but painfully long. --------------F83D1003B97AE587FB24E10A 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 ; Tue, 5 Feb 2002 17:41:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15MUpW13080 for ietf-calendar-bks; Tue, 5 Feb 2002 14:30:51 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15MUn313076 for ; Tue, 5 Feb 2002 14:30:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21902 for ; Tue, 5 Feb 2002 14:30:51 -0800 (PST) Message-ID: <3C605D06.346E62DE@Royer.com> Date: Tue, 05 Feb 2002 15:30:30 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC 2446: Delegation text needs some changes References: Content-Type: multipart/mixed; boundary="------------BD249C7924CF354CAC11BD5E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BD249C7924CF354CAC11BD5E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied with: > > > It should be allowable that a Delegator can send non-process info > like > > > a COMMENT (or other IANA properties/parameters) in the Delegation > > > notice. > > > > As COMMENT is already defined, the delegatee would have no way > > of knowing if the COMMENT was from the ORGANIZER or the Delegate. > > I think we would need a new property. > > I think you are adding some extra semantics/usages to the COMMENT > property. We added COMMENT with the definition of: > > Purpose: This property specifies non-processing information > intended > to provide a comment to the calendar user. > > but implicit in this was that it was intended to be a 'single shot > usage' between the sender and the recipient. It was not something > that was to be preserved and passed along. Otherwise you start to > have problems with stuff like "When do I purge off COMMENTs?", "Who > said what?" (with any degree of assuredness), etc. Yes. I can live with that. However if it is a 'one-shot' comment, then we need to add that text somewhere? Or if we are 'planning' to use it that way - we need some CAP text. --------------BD249C7924CF354CAC11BD5E 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 ; Tue, 5 Feb 2002 17:41:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15MR7b12781 for ietf-calendar-bks; Tue, 5 Feb 2002 14:27:07 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15MR5312776 for ; Tue, 5 Feb 2002 14:27:05 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21890 for ; Tue, 5 Feb 2002 14:27:06 -0800 (PST) Message-ID: <3C605C2E.8FB495AE@Royer.com> Date: Tue, 05 Feb 2002 15:26:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: is not a capability of CAP (Was: Re: Summmary Of January 31st 2002 CAP Editors Conference Call) References: <3C5FF602.46D11A6E@steltor.com> <3C602A86.2CA515DE@steltor.com> <3C6039F7.8660A53E@Royer.com> <3C604C78.7CB6292D@steltor.com> Content-Type: multipart/mixed; boundary="------------1CC3A80CAC3544CD6EA15A54" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1CC3A80CAC3544CD6EA15A54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > As far as I know, the capability doesn't return > > > capabilities of the protocol. So it should be removed. > > > > Yes it does, it returns supported protocol level of the > > CS with respect to VCARs. > > What are you talking about? CAR-MIN does NOT change the > CAP protocol. Yes - I meant: It returns the protocol level of VCARs supported by the CS. So it changes what protocol commands and data the CUA sends to the CS. Which does not change the CAP protocol, but it changes that connections valid protocol > > If a CS returns CAR-MIN, > > then the CUA MUST NOT require the CS to be able to parse > > VCARs. > > This is NOT specified anywhere, and on all the occasions > that I've asked this list for the purpose of CAR-MIN, this > was NEVER mentioned. The only VCAR that a CS knows about are the CAR-MIN predefined VCARs and any additional in DEFAULT-VCARS, so I guess you could send the same ones back down from the CUA. But I don't see the point. So that implies that you CAN NOT delete ANY DEFAULT-VARS from the CUA. (without deleting them from DEFAULT-VCARS first). And CAR-MIN implies that you can not send down NEW VCARs, because the only ones that exist are already (somehow) in DEFAULT-VCARS. So it does not change CAP, but it changes that connections valid commands (the protocol for that session) and data to that CS. > Furthermore, this doesn't make sense. If CU are granted > the right to modify the VCARs with predefined CARIDs, the > CS obviously will need to parse and interpret the VCARs. Yes - I overstated my point. A CAR-MIN CS MAY not be able to parse VCARs - if they are all decreed. And a CAR-MIN CS MUST NOT accept any new VCARs that are not in DEFAULT-VCARS. And as they MUST exist in the CS if they are in DEFAULT-VCARS, then that means you can not create new ANY VCARs on a CAR-MIN CS - using a CUA. It means that they are defined but the CS is very limited with respect to VCARs. > Finally, the fact that the CS can parse VCAR or not is not > relevant to the protocol or the CUA for that matter. It limits the VCAR related commands that can be sent from the CUA to MODIFY and QUERY. (subject to even more VCAR restriction). And if we add the DECREED property (or parameter), then for a CS that only has DECREED VCARs - it will NEVER need to parse a VCAR - that is what I badly meant to say. At the very least - A CA may not fully need to understand VCARs - if they are not the ones in DEFAULT-VCARS. > > > Besides, I am not convinced that we need a CAR property > > > in addition to DEFAULT-VCARS in the CALSTORE. > > > > I did not propose that CAR be a property. > n> True. > > > Did you mean the reply to ? > > No. I meant to say that I was not convinced that we > should add a CAR property to CALSTORE, given that we > should remove the capability. I also do not want to add a CAR property to the CALSTORE. And we should not remove the capability. --------------1CC3A80CAC3544CD6EA15A54 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 ; Tue, 5 Feb 2002 17:50:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15Mes613618 for ietf-calendar-bks; Tue, 5 Feb 2002 14:40:54 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Mer313612 for ; Tue, 5 Feb 2002 14:40:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21923 for ; Tue, 5 Feb 2002 14:40:55 -0800 (PST) Message-ID: <3C605F4A.6650938@Royer.com> Date: Tue, 05 Feb 2002 15:40:10 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re:CAP:LastCallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> <5.1.0.14.0.20020201103752.00a70680@imap1.in.steltor.com> <5.1.0.14.0.20020204094201.00a8dfb0@imap1.in.steltor.com> <5.1.0.14.0.20020204180406.00a705d8@imap1.in.steltor.com> <3C600B66.BCC2169F@Royer.com> <3C601EAC.6576FE66@steltor.com> <3C60364A.503EF7F0@Royer.com> <3C604DB7.DA91CC59@steltor.com> Content-Type: multipart/mixed; boundary="------------FBF58F3C8EFE9049ABEE2391" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FBF58F3C8EFE9049ABEE2391 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > This text is present in ALL versions of draft 06. > > > > Look closer - the text was changed and it changed not > > only the transport data - but what was done. > > Perhaps, and thank you for bringing this to the > attention of the list. > > On the other hand, you shouldn't claim that some > text has disappeared when it has only changed. I was trying to be polite. Is what I really should have said is that someone got too happy with the text editor :-) --------------FBF58F3C8EFE9049ABEE2391 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 ; Tue, 5 Feb 2002 17:50:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15MdHj13481 for ietf-calendar-bks; Tue, 5 Feb 2002 14:39:17 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15MdG313477 for ; Tue, 5 Feb 2002 14:39:16 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21919 for ; Tue, 5 Feb 2002 14:39:17 -0800 (PST) Message-ID: <3C605EEC.A8DDE562@Royer.com> Date: Tue, 05 Feb 2002 15:38:36 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC 2446: Delegation text needs some changes References: Content-Type: multipart/mixed; boundary="------------E32714D59B6D515555837F96" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E32714D59B6D515555837F96 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > Instead; How about we modify the last sentence of the above 2445 > text > > to say: > > > > The "ORGANIZER" MUST send out a new REQUEST with > > an updated SEQUENCE number. > > > > That I think solves the problem. > > Sorry, it doesnt. It makes the entire workflow process 'thrash' if > you do that. Just because I delegate a meeting request to Steve, the > Organizer now has to invalidate all responses from all other Invitees > (the net effect of blindly reving SEQUENCE)?? You go and try to sell > that to folks and Ill offer them a better solution! ;^b As I recall, the ORGANIZER has two valid choices: (1) Send everyone the same VEVENT (or whatever). And that one VEVENT contains ALL of the ATTENDEEs. or (2) Send a uique VEVENT to everyone where only the destination ATTENDEE was in the VEVENT. If (1), then the ORGANIZER MUST update everyone when it changes. If (2), then the ORGANIZER ONLY has to update the changed ATTENDEE (and the delegatee?). So, if (2), no, if (1) I see your point. > Its clear from the 2446 that we need to revise the restriction tables > so that we can include delegation information otherwise it wont really > matter what the prose says since it will be wrong. Yes. > If we are going to fix it, we should fix it so that it works the way > CUs will expect it to work. The normal set of steps are described in > the cited text; just the last line is wrong because it precludes the > previously described actions. Perhaps you think the other actions are > whats wrong?? No - I just forgot about (1) above. > The solution is to allow the Delegator to make minor changes to the > Organizers 'original' REQUEST (ie: Adding the Delegatees info, > supplying back a COMMENT of their own to the Organzier saying why the > Delegatee is coming [or why the Delegator cannot or both], etc). I think I agree, then the ORGANIZER can decide if they need to update everyone (1) or in the case of (2) - nothing as the ORGANIZER and ATTENDEE are in sync for that ATTENDEE. --------------E32714D59B6D515555837F96 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 ; Tue, 5 Feb 2002 17:53:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g15Mhff13840 for ietf-calendar-bks; Tue, 5 Feb 2002 14:43:41 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Mhd313834 for ; Tue, 5 Feb 2002 14:43:40 -0800 (PST) To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Feb 2002 17:41:41 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/05/2002 05:43:44 PM, Serialize complete at 02/05/2002 05:43:44 PM Content-Type: multipart/alternative; boundary="=_alternative 007CB20985256B57_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007CB20985256B57_= Content-Type: text/plain; charset="US-ASCII" John suggested on 02/05/2002 04:34:33 PM: > That might be the Right Thing, though. Maybe some other invitee accepted > only because you were invited, and isn't interested if Steve is coming > instead. You really dislike your customers that much to make them reschedule for ANY change like that?? You are also making the incorrect assumption that ALL ATTENDEEs see the entire ATTENDEE list and thats not correct. As such your youthful optimism is misserving. I realize you are tongue in cheek but... Still, if you want to build it that way fine but it still a self conflicting design that needs resolution. So far I havent heard of any reason not to propose a fix so Ill work on some change text for later this week. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007CB20985256B57_= Content-Type: text/html; charset="US-ASCII"
John suggested on 02/05/2002 04:34:33 PM:
> That might be the Right Thing, though.  Maybe some other invitee accepted
> only because you were invited, and isn't interested if Steve is coming
> instead.
You really dislike your customers that much to make them reschedule for ANY change like that??  

You are also making the incorrect assumption that ALL ATTENDEEs see the entire ATTENDEE list and thats not correct.  As such your youthful optimism is misserving.  I realize you are tongue in cheek but...

Still, if you want to build it that way fine but it still a self conflicting design that needs resolution.  So far I havent heard of any reason not to propose a fix so Ill work on some change text for later this week.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007CB20985256B57_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 5 18:04:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22701 for ; Tue, 5 Feb 2002 18:04:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15Mghb13777 for ietf-calendar-bks; Tue, 5 Feb 2002 14:42:43 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Mgg313773 for ; Tue, 5 Feb 2002 14:42:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21939 for ; Tue, 5 Feb 2002 14:42:38 -0800 (PST) Message-ID: <3C605FAC.1C9C1A55@Royer.com> Date: Tue, 05 Feb 2002 15:41:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC 2446: Delegation text needs some changes References: Content-Type: multipart/mixed; boundary="------------C1D81BA1F77D578DBC1FA16D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C1D81BA1F77D578DBC1FA16D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >Just because I delegate a meeting request to Steve, the Organizer now has > to invalidate all responses from all other Invitees[...]?? > > That might be the Right Thing, though. Maybe some other invitee accepted > only because you were invited, and isn't interested if Steve is coming > instead. This is *exactly* the debate that caused the (1) and (2) ways of inviting people that I described in my (recent) reply to Bruces comments. --------------C1D81BA1F77D578DBC1FA16D 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 ; Tue, 5 Feb 2002 18:09:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15Mpnt14330 for ietf-calendar-bks; Tue, 5 Feb 2002 14:51:49 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Mpm314325 for ; Tue, 5 Feb 2002 14:51:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA21962 for ; Tue, 5 Feb 2002 14:51:50 -0800 (PST) Message-ID: <3C6061BE.F6499594@Royer.com> Date: Tue, 05 Feb 2002 15:50:38 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Definition of CAR-MIN References: <3C5FEE14.C23F6D80@steltor.com> <3C600CB7.32AADB47@Royer.com> <3C60146C.996E45A9@steltor.com> <3C601F7D.6AACF644@Royer.com> <3C60291D.1E9E70C@steltor.com> <3C6037D4.A8B6DB3F@Royer.com> <3C6053B5.17FE33D7@steltor.com> Content-Type: multipart/mixed; boundary="------------EE19C7562DE71AB6178B5B22" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EE19C7562DE71AB6178B5B22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Then, it's my turn to ask: > > > > > > Explain how a CUA can know if a CS can only handle > > > the CAP predefined VCARs? > > > > (1) The CS advertises CAR-MIN which tells the CUA that > > the CS can not parse VCARs. > > This is not true. Else, why would CU waste their valuable > time modifying the VCARs with predefined CARID? > > > (2) The CUA looks at 'DEFAULT-VCARS' to determine what > > VCARs the CS knows, which is going to be at least > > the predefined CAP VCARs. > > DEFAULT-VCARS is not meant to advertize the VCARs the > CS knows, but the VCAR that MUST be copied in newly > created VAGENDA. That's different. You missed some of the thread. For CAR-MIN CS's, it is the FULL list of VCARs the CS understands. Why? Because the (long ago) debate was something like this: If I have a CAR-MIN CS, only the 'predefined VCARs' exist? YES. Do we know the full set that may be needed? NO. Then if we extend them (define more), how will a CUA know which ones are defined witout having to create more capability replies? Lets put them in the DEFAULT_VCARS, as a CAR-MIN CS would only have the 'predefined' VCARs in the DEFAULT-VCARS property - because when a CAR-MIN CS advertises that it is a CAR-MIN CS, it is telling the world that the predefined VCARS are the the only VCARs it supports. So for a CAR-MIN CS, no other VCARs can exists? TRUE. Then for a CAR-MIN CS - DEFAULT-VCARS is the full list of predefined (or x-) VCARS that exist for this CS. As the CS CAN NOT use any other than the predefined VCARs, there can't be any more or less for any calendar. -Doug --------------EE19C7562DE71AB6178B5B22 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 ; Tue, 5 Feb 2002 18:14:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15N4Aq15099 for ietf-calendar-bks; Tue, 5 Feb 2002 15:04:10 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15N49315092 for ; Tue, 5 Feb 2002 15:04:09 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 5 Feb 2002 17:59:58 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/05/2002 06:04:13 PM, Serialize complete at 02/05/2002 06:04:13 PM Content-Type: multipart/alternative; boundary="=_alternative 007E5EBD85256B57_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007E5EBD85256B57_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 02/05/2002 05:38:36 PM: > As I recall, the ORGANIZER has two valid choices: > > (1) Send everyone the same VEVENT (or whatever). > And that one VEVENT contains ALL of the ATTENDEEs. > or > (2) Send a uique VEVENT to everyone where only the > destination ATTENDEE was in the VEVENT. > > If (1), then the ORGANIZER MUST update everyone when it changes. We never mandated it as you described because there are more than just 2 ways that current CUAs deal with it (and do to so would mandate some architectural changes vendors cannot just "toss in" so easily). The Organizer (or thier CUA) can chose how the invitations or reschedules get created and sent out. We never mandated that _each_ ATTENDEE gets the exact same copy of the invitation or that the ATTENDEE list would be identical for everyone. As such I can build a copy per ATTENDEE that has the same info but NO other ATTENDEE info. Or I can chose to make 'onesies' for Delegatees and none for Delegators. Or... In any case, the text regarding how delegation happens (and what is permitted or excluded) needs to be fixed. > > Its clear from the 2446 that we need to revise the restriction tables > > so that we can include delegation information otherwise it wont really > > matter what the prose says since it will be wrong. > > Yes. Glad we do agree on some parts... ;^) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007E5EBD85256B57_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 02/05/2002 05:38:36 PM:

> As I recall, the ORGANIZER has two valid choices:
>
>    (1) Send everyone the same VEVENT (or whatever).
>             And that one VEVENT contains ALL of the ATTENDEEs.
> or
>    (2) Send a uique VEVENT to everyone where only the
>             destination ATTENDEE was in the VEVENT.
>
> If (1), then the ORGANIZER MUST update everyone when it changes.

We never mandated it as you described because there are more than just 2 ways that current CUAs deal with it (and do to so would mandate some architectural changes vendors cannot just "toss in" so easily).  

The Organizer (or thier CUA) can chose how the invitations or reschedules get created and sent out.  We never mandated that _each_ ATTENDEE gets the exact same copy of the invitation or that the ATTENDEE list would be identical for everyone.  As such I can build a copy per ATTENDEE that has the same info but NO other ATTENDEE info.  Or I can chose to make 'onesies' for Delegatees and none for Delegators. Or...

In any case, the text regarding how delegation happens (and what is permitted or excluded) needs to be fixed.

> > Its clear from the 2446 that we need to revise the restriction tables
> > so that we can include delegation information otherwise it wont really
> > matter what the prose says since it will be wrong.
>
> Yes.
Glad we do agree on some parts... ;^)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007E5EBD85256B57_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 5 18:41:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24152 for ; Tue, 5 Feb 2002 18:41:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15NPVu16557 for ietf-calendar-bks; Tue, 5 Feb 2002 15:25:31 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15NPT316551 for ; Tue, 5 Feb 2002 15:25:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA22055 for ; Tue, 5 Feb 2002 15:25:31 -0800 (PST) Message-ID: <3C606979.C681C000@Royer.com> Date: Tue, 05 Feb 2002 16:23:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC 2446: Delegation text needs some changes References: Content-Type: multipart/mixed; boundary="------------CB33B5386CB8B6BD63DC9B31" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CB33B5386CB8B6BD63DC9B31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 02/05/2002 05:38:36 PM: > > > As I recall, the ORGANIZER has two valid choices: > > > > (1) Send everyone the same VEVENT (or whatever). > > And that one VEVENT contains ALL of the ATTENDEEs. > > or > > (2) Send a uique VEVENT to everyone where only the > > destination ATTENDEE was in the VEVENT. > > > > If (1), then the ORGANIZER MUST update everyone when it changes. > > We never mandated it as you described because there are more than just > 2 ways that current CUAs deal with it (and do to so would mandate some > architectural changes vendors cannot just "toss in" so easily). > > The Organizer (or thier CUA) can chose how the invitations or > reschedules get created and sent out. We never mandated that _each_ > ATTENDEE gets the exact same copy of the invitation or that the > ATTENDEE list would be identical for everyone. Not that it was mandated - but that it was allowed. > As such I can build a > copy per ATTENDEE that has the same info but NO other ATTENDEE info. > Or I can chose to make 'onesies' for Delegatees and none for > Delegators. Or... Yes. I did not mean that was all you could do - your right. > In any case, the text regarding how delegation happens (and what is > permitted or excluded) needs to be fixed. Yes. > Glad we do agree on some parts... ;^) We always agree - we just don't always know we agree until after a debate :-) --------------CB33B5386CB8B6BD63DC9B31 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 ; Tue, 5 Feb 2002 18:47:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15NawW17189 for ietf-calendar-bks; Tue, 5 Feb 2002 15:36:58 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Nav317184 for ; Tue, 5 Feb 2002 15:36:57 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA17395 for ; Tue, 5 Feb 2002 18:36:54 -0500 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 g15NasQ21742 for ; Tue, 5 Feb 2002 18:36:54 -0500 (EST) Message-ID: <3C606D02.70689642@steltor.com> Date: Tue, 05 Feb 2002 18:38:42 -0500 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: CAP: VCAR Proposal (#2) 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 As promised, here's an updated version of my proposal on VCAR. Highlight of changes: - Re-ordered sections as in RFC 2445. - CARID property is now mandatory. - NAME property can now occur more than once, given some restrictions specified in the restriction tables. - Added new component VRIGHT to group multiple access rights in a single VCAR component. - Added new value type UPN-FILTER. - Changed properties GRANT and DENY to be UPN-FILTERs. - Changed syntax of the RESTRICTION property to be 'cap-select' to allow restrictions on the type of components as well. - Simplified some examples (using "SCOPE:SELECT * FROM VAGENDA" instead of multipled SCOPE instances for each type of component. - I assumed that OWNER(), in addition to SELF(), was defined in CAP-QL. I hereby officially propose that OWNER(), NONOWNER() and SELF() be added to the CAP-QL ABNF. --------------------------------------------------------------------- x.x.1 Property Value Data Types x.x.1.1 UPN Filter Value Name: UPN-FILTER Purpose: This value type is used to identify values that contain a user principal name filter. Formal Definition: The value type is defined by the following notation: upn-filter = "OWNER" / "NONOWNER" / "*" / ( "*" / *upn-char ) "@" ( "*" / 1*upn-char ) upn-char = Description: The value is used to match user principal names (UPNs). Example: The following are examples of this value type: [ Editor's Note: Not sure this is the right place for this information. ] OWNER Matches the UPN equal to the OWNER property of the VAGENDA in which the encapsulating VCAR is stored. NONOWNER Matches all UPNs different from the OWNER property of the VAGENDA in which the encapsulating VCAR is stored. * Matches all UPNs. @ Matches the UPN of anonymous CUs belonging to the unnamed realm @* Matches the UPN of anonymous CUs belonging to any named realm @realm Matches the UPN of anonymous CUs belonging to the specified realm *@* Matches the UPN of non-anonymous CUs belonging to any named realm *@realm Matches the UPN of non-anonymous CUs belonging to the specified realm user@realm Matches the UPN of the specified CU belonging to the specified realm user@* Matches the UPN of the specified CU belonging to any named realm x.x.2 Calendar Components x.x.2.1 Calendar Access Right Component Component Name: "VCAR" Purpose: Provide a grouping of calendar access rights. Format Definition: A "VCAR" calendar component is defined by the following notation: carc = "BEGIN" ":" "VCAR" CRLF carprop 1*rightc "END" ":" "VCAR" CRLF carprop = 1*( ; 'carid' is REQUIRED, ; but MUST NOT occur more than once carid / ; the following are OPTIONAL, ; and MAY occur more than once name / x-prop / iana-prop ) Description: A "VCAR" calendar component is a grouping of component properties, and "VRIGHT" calendar components, that represents access rights granted or denied to calendar users. The "CARID" property specifies the local identifier for the "VCAR" calendar component. The "NAME" property specifies a localizable display name. Example: In the following example, the UPN "foo@host.com" is given read access to the "DTSTART" and "DTEND" VEVENT properties. No other access is specified: BEGIN:VCAR CARID:abcd12345 NAME:"View Start and End Times" BEGIN:VRIGHT GRANT:foo@host.com PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VRIGHT END:VCAR In this example, all UPNs are given read access to "DTSTART" and "DTEND" properties of VEVENT components. "All CUs and UGs" are specified by the UPN value "*". Note that this enumerated UPN value is not in quotes: BEGIN:VCAR CARID:abcd12345 NAME:"View Start and End Times 2" BEGIN:VRIGHT GRANT:* PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VRIGHT END:VCAR In this example, rights are specified for all UPNs to read VEVENT components classified as PUBLIC: BEGIN:VCAR CARID:abcd12345 NAME:"View PUBLIC Start and End Times" BEGIN:VRIGHT GRANT:* PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' END:VRIGHT END:VCAR In this example, rights are specified for all UPNs to read or modify existing VEVENT components classified as PUBLIC: BEGIN:VCAR CARID:abcd12345 NAME:"Read and Modify PUBLIC Calendar Entries" BEGIN:VRIGHT GRANT:* PERMISSION:READ PERMISSION:MODIFY SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC' END:VRIGHT END:VCAR In these examples, full calendar access rights are given to the OWNER, and a hypothetical administrator is given access rights to specify calendar access rights. If no other rights are specified, only these two UPNs can specify calendar access rights: BEGIN:VCAR CARID:abcd12345 NAME:"Only OWNER or ADMIN Settable CARs" BEGIN:VRIGHT GRANT:OWNER PERMISSION:* SCOPE:SELECT * FROM VAGENDA END:VRIGHT BEGIN:VRIGHT GRANT:cal-admin@host.com PERMISSION:* SCOPE:SELECT * FROM VCAR RESTRICTION:SELECT * FROM VCAR END:VRIGHT END:VCAR In this example, rights to write, read, modify or delete calendar access rights are denied to all UPNs. This example would disable providing different access rights to the calendar store or calendar. This calendar access rights should not be specified, as they remove the ability to change calendar access; even for the owner or administrator: BEGIN:VCAR CARID:abcd12345 NAME:"No CAR At All" BEGIN:VRIGHT DENY:* PERMISSION:* SCOPE:SELECT * FROM VCAR END:VRIGHT END:VCAR x.x.2.2 VRIGHT Calendar Component Component Name: "VRIGHT" Purpose: Provide a grouping of component properties that describe an access right. Format Definition: A "VRIGHT" calendar component is defined by the following notation: rightc = "BEGIN" ":" "VRIGHT" CRLF rightprop "END" ":" "VRIGHT" CRLF rightprop = 2*( ; either 'grant' or 'deny' MUST ; occur at least once ; and MAY occur more than once grant / deny / ; 'permission' MUST occur at least once ; and MAY occur more than once permission / ; the following are optional, ; and MAY occur more than once scope / restriction / x-prop / iana-prop ) Description: A "VRIGHT" calendar component is a grouping of calendar access right component properties. The "GRANT" property specifies the CU or UG to whom a calendar access right is granted. The "DENY" property specifies the CU or UG to whom a calendar access right is denied. The "PERMISSION" property specifies the actual permission being set. The "SCOPE" property identifies the calendar store properties, calendar properties, calendar components, component properties to which the access right applies. The "RESTRICTION" property specifies restriction on the value that may take calendar store properties, calendar properties, calendar components, and component properties after a WRITE or MODIFY operation. Values MUST match all the instances of the RESTRICTION property to be valid. x.x.3 Component Properties The following properties can appear within calendar components, as specified by each component property definition. x.x.3.1 Descriptive Component Properties The following properties specify descriptive information about calendar components. x.x.3.1.1 Name Component Property Property Name: NAME Purpose: This property provides a localizable display name for a calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VAGENDA" and "VCAR" calendar components. Description: This property is used in the "VAGENDA" and in the "VCAR" calendar components to specify a localizable display name. Format Definition: The property is defined by the following notation: name = "NAME" nameparam ":" text CRLF nameparam = *( ; the following is optional, ; but MUST NOT occur more than once ( ";" languageparam ) / ; the following is optional, ; and MAY occur more than once ( ";" xparam ) ) Example: The following is an example of this property: NAME:"Restrict Guests From Creating ALARMs On Events" x.x.3.2 Calendar Access Right Component Properties x.x.3.2.1 Identifier Component Property Property Name: CARID Purpose: This property specifies the identifier for an access right calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified once in a "VCAR" calendar component. Description: This property is used in the "VCAR" calendar component to specify an identifier. Format Definition: The property is defined by the following notation: carid = "CARID" caridparam ":" text CRLF caridparam = *( ";" xparam ) Example: The following is an example of this property: CARID:abcd12345 x.x.3.3 Right Component Properties x.x.3.3.1 Grant Component Property Property Name: GRANT Purpose: This property identifies the CU or UG being granted access in the VRIGHT component. Value Type: UPN-FILTER Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components. Description: This property is used in the "VRIGHT" calendar component to specify the CU or UG being granted access. Format Definition: The property is defined by the following notation: grant = "GRANT" grantparam ":" upn-filter CRLF grantparam = *( ";" xparam ) Example: The following are examples of this property: GRANT:* GRANT:bob@example.com x.x.3.3.2 Deny Component Property Property Name: DENY Purpose: This property identifies the CU or UG being denied access in the VRIGHT component. Value Type: UPN-FILTER Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components. Description: This property is used in the "VRIGHT" calendar component to define the CU or UG being denied access. Format Definition: The property is defined by the following notation: deny = "DENY" denyparam ":" upn-filter CRLF denyparam = *( ";" xparam ) Example: The following are examples of this property: DENY:* DENY:bob@example.com x.x.3.3.3 Permission Component Property Property Name: PERMISSION Purpose: This property defines a permission that is granted or denied in a VRIGHT component. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components. Description: This property is used in the "VRIGHT" calendar component to define a permission that is granted or denied. Format Definition: The property is defined by the following notation: perm = "PERMISSION" permparam ":" permvalue CRLF permparam = *( ";" xparam ) permvalue = ( "READ" / "WRITE" / "DELETE" / "MODIFY" / all ) all = "*" Example: The following is an example of this property: PERMISSION:READ x.x.3.3.4 Scope Component Property Property Name: SCOPE Purpose: This property identifies the objects in the CS to which the access rights applies. Value Type: capselect Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components. Description: This property is used in the "VRIGHT" calendar component to define the set of objects subject to the access right being defined. Format Definition: The property is defined by the following notation: scope = "SCOPE" scopeparam ":" capselect CRLF scopeparam = *( ";" xparam ) Example: The following is an example of this property: SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' x.x.3.3.5 Restriction Component Property Property Name: RESTRICTION Purpose: This property defines restrictions on the value that may take new or existent calendar components. Value Type: capselect Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components, but only when the PERMISSION property is set to "WRITE", "MODIFY", or "*". Description: This property is used in the "VRIGHT" calendar component to define restrictions on the calendar components that can be written (i.e., by using the "create" or "move" commands) as well as on the values that may take existent calendar store properties, calendar properties, calendar components, and component properties (i.e., by using the "modify" command). Accepted values MUST match the specified RESTRICTION. Format Definition: The property is defined by the following notation: restrict = "RESTRICTION" restrictparam ":" capselect CRLF restrictparam = *( ";" xparam ) Example: The following are examples of this property: RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' RESTRICTION:SELECT * FROM VEVENT WHERE ORGANIZER = SELF() RESTRICTION:SELECT * FROM VEVENT WHERE CONTAINS(CATEGORIES,'BUSINESS') ------------------------------------------------------------------------ [Editor's Note: The purpose of predefined CARID needs to be specified. ] Predefined calendar access CARIDs that MUST be implemented are: CS MUST implement the following CARID:READBUSYTIMEINFO - grants all authenticated users the right to read VFREEBUSY components. BEGIN:VCAR CARID:READBUSYTIMEINFO BEGIN:VRIGHT GRANT:* PERMISSION:READ SCOPE:SELECT * FROM VFREEBUSY END:VRIGHT END:VCAR CARID:REQUESTONLY - grants to users other than the owner of the calendar the right to write new events with the property METHOD set to REQUEST. BEGIN:VCAR CARID:REQUESTONLY BEGIN:VRIGHT GRANT:NONOWNER PERMISSION:WRITE RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' END:VRIGHT END:VCAR CARID:UPDATEPARTSTATUS - grants all authenticated users the right to modify the instances of the ATTENDEE property set to one of their calendar adresses in the VEVENT and VTODO components for which the ORGANIZER property is set to the address of the VAGENDA in which the VEVENT or VTODO is stored, given that the submitted value of the ATTENDEE property is one of their calendar adresses. BEGIN:VCAR CARID:UPDATEPARTSTATUS BEGIN:VRIGHT GRANT:* PERMISSION:MODIFY SCOPE:SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() AND ORGANIZER = OWNER() RESTRICTION:SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() END:VRIGHT BEGIN:VRIGHT GRANT:* PERMISSION:MODIFY SCOPE:SELECT att FROM VTODO USING_PROPERTIES ATTENDEE att WHERE att = SELF() AND ORGANIZER = OWNER() RESTRICTION:SELECT att FROM VTODO USING_PROPERTIES ATTENDEE att WHERE att = SELF() END:VRIGHT END:VCAR CARID:DEFAULTOWNER - grants to the owner all permissions on all the objects in the calendar. BEGIN:VCAR CARID:DEFAULTOWNER BEGIN:VRIGHT GRANT:OWNER PERMISSION:* SCOPE:SELECT * FROM VAGENDA END:VRIGHT END:VCAR ------------------------------------------------------------------------ Restriction table for both "create" and "modify". Component/Property Presence Comment ------------------- -------- ----------------------------- . . VCAR 0+ . . . CARID 1 . . . NAME 0+ Note, there MUST NOT be more than one NAME with no LANGUAGE parameter, and there MUST NOT be more than one NAME with the same LANGUAGE value. . . . X-PROPERTY 0+ . . . [IANA-PROP] 0+ any IANA registered property . . . VRIGHT 1+ . . . . PERMISSION 1+ . . . . DENY 0+ Note, there must be at least one GRANT or DENY within the VRIGHT. . . . . GRANT 0+ Note, there must be at least one GRANT or DENY within the VRIGHT. . . . . SCOPE 0+ Note, there must be at least one SCOPE if PERMISSION is set to "READ", "MODIFY", "DELETE", or "*". . . . . RESTRICTION 0 or 0+ Note, allowed only if PERMISSION is set to "WRITE", "MODIFY", or "*". . . . . X-PROPERTY 0+ . . . . [IANA-PROP] 0+ any IANA registered property ------------------------------------------------------------------------ Regards, 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 Feb 5 20:58:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27591 for ; Tue, 5 Feb 2002 20:58:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g161d8o22587 for ietf-calendar-bks; Tue, 5 Feb 2002 17:39:08 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g161d6322583 for ; Tue, 5 Feb 2002 17:39:06 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA22172 for ; Tue, 5 Feb 2002 17:39:07 -0800 (PST) Message-ID: <3C60880A.17B840FC@Royer.com> Date: Tue, 05 Feb 2002 18:34:02 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) References: <3C606D02.70689642@steltor.com> Content-Type: multipart/mixed; boundary="------------0B1734E7FF34A8E6AB660443" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0B1734E7FF34A8E6AB660443 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: Great - but I am sure you know I have suggestions :-) > > - I assumed that OWNER(), in addition to SELF(), was defined in > CAP-QL. I hereby officially propose that OWNER(), NONOWNER() > and SELF() be added to the CAP-QL ABNF. They are not in the text I checked in today - but I agree that they are needed. Any objections? Where OWNER() == any one of the UPN's listed in the VAGENDA OWNER properties. > OWNER Matches the UPN equal to the OWNER > property of the VAGENDA in which the > encapsulating VCAR is stored. ...equal to any OWNER - correct? (as opposed to 'the' OWNER). > NONOWNER Matches all UPNs different from the > OWNER property of the VAGENDA in which > the encapsulating VCAR is stored. Same here - ...different from any OWNER... ? > * Matches all UPNs. > @ Matches the UPN of anonymous CUs > belonging to the unnamed realm You need to define 'unnamed realm'. I know it is the the WG mailing list - I don't remember what it is and it is not currently defined in CAP (or this proposal). > @* Matches the UPN of anonymous CUs > belonging to any named realm Same here - define a 'named realm'. > @realm Matches the UPN of anonymous CUs > belonging to the specified realm In a previous email you said that the CS is not required to do a reverse DNS lookup to find the 'belonging' to realm. Do you mean the realm the UPN supplied as part of it authentication? If not - what is it? > Description: A "VCAR" calendar component is a grouping of component > properties, and "VRIGHT" calendar components, that represents access > rights granted or denied to calendar users. Add - "and the default is DENY". Agree? We have to have some default, and the security guys in the past said the default should be to deny anything not specifically granted. > In this example, rights are specified for all UPNs to read VEVENT > components classified as PUBLIC: nnn> > BEGIN:VCAR > CARID:abcd12345 > NAME:"View PUBLIC Start and End Times" > BEGIN:VRIGHT > GRANT:* > PERMISSION:READ > SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' > END:VRIGHT > END:VCAR Questions / comments: You use quotes (") in the text value of the NAME property, that is optional - just like it is optional in any TEXT value property? Correct? They all have the SAME CARID in your examples. I think we need to add text that says that a CARID MUST BE unique within its scope. > In this example, rights are specified for all UPNs to read or modify > existing VEVENT components classified as PUBLIC: > > BEGIN:VCAR > CARID:abcd12345 > NAME:"Read and Modify PUBLIC Calendar Entries" > BEGIN:VRIGHT > GRANT:* > PERMISSION:READ > PERMISSION:MODIFY > SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC' > END:VRIGHT > END:VCAR You define PERMISSION in x.x.3.3.3 below as a TEXT value type. A TEXT value type can have multiple values, separated by commas. So this is also valid? If not, there needs to be restrictions specified in the proposal. PERMISSION:READ,MODIFY > In this example, rights to write, read, modify or delete calendar > access rights are denied to all UPNs. This example would disable > providing different access rights to the calendar store or calendar. > This calendar access rights should not be specified, as they remove > the ability to change calendar access; even for the owner or > administrator: Or it is the perfect data to add to a CAR-MIN CS that only has decreed VCARs and does not wish to give READ access to those VCARs. So I think the the "...should not be specified..." sentence needs to be: This calendar access rights should not be specified unless all of the VCARs are decreed and the CS wishes to not allow any UPN to query for any of those decreed VCARs. > BEGIN:VCAR > CARID:abcd12345 > NAME:"No CAR At All" > BEGIN:VRIGHT > DENY:* > PERMISSION:* > SCOPE:SELECT * FROM VCAR > END:VRIGHT > END:VCAR > x.x.2.2 VRIGHT Calendar Component > > .... > > As CAP-QL, RESTRICTION, and SCOPE have the same value type, we need to define a CAPSELECT value type. Much like 2445 defines TEXT, BINARY, ... value types, then modify CAP-QL/QUERY and VCAR/SCOPE to say that they have a value type of CAPSELECT. And I think we need to add a note that the CAPSELECT value-type is a valid "iana-token" value as defined in 2445 "4.2.20 Value Data Types". This is a complex and formatted data type. I think it needs is own standalone 'IANA registration' section. Agree? And below you call the value for GRANT and DENY a 'upn-filter' value type. I know what you mean, but there is no such thing as a 'upn-filter' value type. They need to be: (1) TEXT value type, with specific restrictions to its content. or (2) We need to define UPN-FILTER as a valid VALUE type like I think we need to do with CAPSELECT. (which is what you call them below - value types). I would opt for (1). > x.x.3.1.1 Name Component Property > > NAME:"Restrict Guests From Creating ALARMs On Events" Again, the (")'s are optional - right? > x.x.3.2.1 Identifier Component Property I think the above section title needs renamed, perhaps "VCAR Identifier". It only identifies VCARs and not 'any' component - correct? > Format Definition: The property is defined by the following notation: > > carid = "CARID" caridparam ":" text CRLF And BOOLEAN parameter 'DECREED' ? Or was that going to be a property? Or were we going to force the CUA to figure it out after reading the VCARs? > x.x.3.3 Right Component Properties > > x.x.3.3.1 Grant Component Property > > Property Name: GRANT > > Purpose: This property identifies the CU or UG being granted access > in the VRIGHT component. Specifies the UPN subject to the upn-filters, not the CU or UG - correct? The 'CU' is an entity that may have multiple UPNs. Same with UG, it is the CS's responsibility to expand any UPN *if* it happens to be a UG, but we are only restricting or granting based on UPN - correct? > Value Type: UPN-FILTER > > Property Parameters: Only non-standard property parameters can be > specified on this property. > > Conformance: This property can be specified in "VRIGHT" calendar > components. > > Description: This property is used in the "VRIGHT" calendar component > to specify the CU or UG being granted access. > x.x.3.3.2 Deny Component Property Same issues with DENY as GRANT above. > x.x.3.3.4 Scope Component Property > > Property Name: SCOPE > > Purpose: This property identifies the objects in the CS to which > the access rights applies. > > Value Type: capselect And as I said above, lets make 'capselect' and official value type. > Predefined calendar access CARIDs that MUST be implemented are: > > CS MUST implement the following > > CARID:READBUSYTIMEINFO - grants all authenticated users the > right to read VFREEBUSY components. We are NOT defining them as MUST have 'this' content, add: A suggested content for the READBUSYTIMEINFO is: > BEGIN:VCAR > CARID:READBUSYTIMEINFO > BEGIN:VRIGHT > GRANT:* > PERMISSION:READ > SCOPE:SELECT * FROM VFREEBUSY > END:VRIGHT > END:VCAR Add: In order to make this a decreed VCAR, an implementation would have to add something like the following to the above suggested VCAR. BEGIN:VRIGHT DENY:* PERMISSION:WRITE,MODIFY SCOPE:SELECT * FROM VCAR WHERE CARID = 'READBUSYTIMEINFO' END:VRIGHT Add: (similar notes to the other predefined VCAR CARIDs, or one general statement that covers them all). > CARID:UPDATEPARTSTATUS - grants all authenticated users the right > to modify the instances of the ATTENDEE property set to one of > their calendar adresses in the VEVENT and VTODO components for > which the ORGANIZER property is set to the address of the VAGENDA > in which the VEVENT or VTODO is stored, given that the submitted > value of the ATTENDEE property is one of their calendar adresses. Technical wording issue: Where the value matched their authenticated UPN. The CS would not know their 'calendar addresses' (two places). > > ------------------------------------------------------------------------ > > Restriction table for both "create" and "modify". What about delete? (Not that I can't guess - but what about the new reader?) > --------------0B1734E7FF34A8E6AB660443 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 ; Wed, 6 Feb 2002 10:05:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16EjHr05329 for ietf-calendar-bks; Wed, 6 Feb 2002 06:45:17 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16EjF305320 for ; Wed, 6 Feb 2002 06:45:16 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 6 Feb 2002 09:52:41 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/06/2002 09:52:53 AM, Serialize complete at 02/06/2002 09:52:53 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> That might be the Right Thing, though. Maybe some other invitee accepted >> only because you were invited, and isn't interested if Steve is coming >> instead. > >This is *exactly* the debate that caused the (1) and (2) ways >of inviting people that I described in my (recent) reply to Bruces >comments. Right, OK, I remember now. And, yes, I agree that (2) solves the spurious-update problem. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |The good are innocent and create justice. The bad are guilty, and| |invent mercy. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 6 10:05:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22086 for ; Wed, 6 Feb 2002 10:05:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16EkDS05413 for ietf-calendar-bks; Wed, 6 Feb 2002 06:46:13 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16EkC305409 for ; Wed, 6 Feb 2002 06:46:12 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 6 Feb 2002 09:53:37 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/06/2002 09:53:49 AM, Serialize complete at 02/06/2002 09:53:49 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >We always agree No, we don't. :-) /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |Seen in computer peripheral ad: "User-friendly dip switches!"| \=============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 6 17:00:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03844 for ; Wed, 6 Feb 2002 17:00:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16Lgah28597 for ietf-calendar-bks; Wed, 6 Feb 2002 13:42:36 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16LgY328591 for ; Wed, 6 Feb 2002 13:42:35 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA23386 for ; Wed, 6 Feb 2002 13:42:36 -0800 (PST) Message-ID: <3C61A010.E3942645@Royer.com> Date: Wed, 06 Feb 2002 14:28:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Alternate to COALESCE Content-Type: multipart/mixed; boundary="------------FB26BE3C667C9134888D1B3C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FB26BE3C667C9134888D1B3C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After seeing the latest VCAR proposal, it occurred to me that we don't need COALESCE. Instead of COALESCE, how about : When you VQUERY where GRANT = SELF() and EXPAND:TRUE you get single a logical VCAR reply where all of the VCARs contents are merged for the current UPN. If EXPAND is FALSE, your get multiple VCARS as stored. An implementation MAY return EXPAND:TRUE results as if EXPAND:FALSE was supplied. CS implementations may wish to restrict what CUAs can see based on the authenticated UPN. Example: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VCAR WHERE GRANT = SELF() END:VQUERY You don't need DENY = SELF(), because that is the default for what you don't have access to anyway. And when not selected by CARID: BEGIN:VQUERY EXPAND:FALSE QUERY:SELECT * FROM VCAR WHERE GRANT = SELF() END:VQUERY The CS MAY return only the any existing VCARs that apply to SELF() for which SELF() has GRANT access, and READ access to the VCAR, but restricted to only what applies to the UPN. The difference between these two is the the first produces one VCAR. The second returns multiple VCARs, where each one is tagged with CARID and may or might not be the original VCAR - but is guaranteed to apply to SELF(). --------------FB26BE3C667C9134888D1B3C 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 ; Wed, 6 Feb 2002 17:10:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16Lw0s28966 for ietf-calendar-bks; Wed, 6 Feb 2002 13:58:00 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16Lvw328962 for ; Wed, 6 Feb 2002 13:57:59 -0800 (PST) To: Bernard Desruisseaux Cc: ietf-calendar@imc.org Subject: Re: CAP: CAR-MIN and predefined CARIDs (Was: Re: CAP: DEFAULT_VCARS) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Feb 2002 16:57:57 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/06/2002 05:00:23 PM, Serialize complete at 02/06/2002 05:00:23 PM Content-Type: multipart/alternative; boundary="=_alternative 00789F0E85256B58_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00789F0E85256B58_= Content-Type: text/plain; charset="US-ASCII" Bernard wrote on 02/05/2002 05:10:51 PM: > Would you remember why the VCARs with predefined CARIDs > were introduced in CAP, and how they relate to the CAR > capability "CAR-MIN"? Ill try to clarify this a bit. Im sure if Im too far off base Ill hear about it from Frank or some other ol' timer. We created named CARIDs to define some commonly used sets of VCARs that we could use instead of expecting every implementor to derive the same exact set. That is, instead of 3 vendors deriving 3 different sets of, say, "Calendar Owner" VCARs, we wanted to keep things a bit more uniform (and simple). If we predefined some sets then we can use them consistantly across all CUAs and we would have an understood set of VCARs that are easily represented in some form to the CU. It also makes interoperability easier too for like reasons. Now given predetermined sets of VCARs you need some way to determine what sets a particular implementation supports and which it does not. Thats where grouping predefined CARIDs came into the different CAP capabilities... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00789F0E85256B58_= Content-Type: text/html; charset="US-ASCII"
Bernard wrote on 02/05/2002 05:10:51 PM:
> Would you remember why the VCARs with predefined CARIDs
> were introduced in CAP, and how they relate to the CAR
> capability "CAR-MIN"?
Ill try to clarify this a bit.  Im sure if Im too far off base Ill hear about it from Frank or some other ol' timer.

We created named CARIDs to define some commonly used sets of VCARs that we could use instead of expecting every implementor to derive the same exact set.  That is, instead of 3 vendors deriving 3 different sets of, say,  "Calendar Owner" VCARs, we wanted to keep things a bit more uniform (and simple).  If we predefined some sets then we can use them consistantly across all CUAs and we would have an understood set of VCARs that are easily represented in some form to the CU.  It also makes interoperability easier too for like reasons.

Now given predetermined sets of VCARs you need some way to determine what sets a particular implementation supports and which it does not.  Thats where grouping predefined CARIDs came into the different CAP capabilities...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00789F0E85256B58_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 6 17:21:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04203 for ; Wed, 6 Feb 2002 17:21:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16M8Yl29238 for ietf-calendar-bks; Wed, 6 Feb 2002 14:08:34 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16M8X329234 for ; Wed, 6 Feb 2002 14:08:33 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Feb 2002 17:05:13 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/06/2002 05:10:57 PM, Serialize complete at 02/06/2002 05:10:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0079497085256B58_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079497085256B58_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 02/05/2002 05:30:30 PM: > > but implicit in this was that it was intended to be a 'single shot > > usage' between the sender and the recipient. It was not something [Snip] > Yes. I can live with that. However if it is a 'one-shot' comment, > then we need to add that text somewhere? That was part of one of my earlier postings (go find that thread... ;^] ). It is currently _implicitly_ a 'single shot' deal (based on our original intent AND the restriction tables of sorts in iTIP). I will try to propose some formal text to make this clearer. (To Do Maintainer: chalk this one up to me please in case it gets lost...) > Or if we are 'planning' > to use it that way - we need some CAP text. I seriously hope you are NOT planning on making COMMENT persistantly preserved or part of the workflow processing process. It sounded like you expected stuff like COMMENT from an Organizer to be preserved when I delegate to someone and thats how this came about. If you did not expect it to be preserved and that the COMMENT sent would be mine (to the Delegatee) then I think you are agreeing w/my basic premise that the RFC is self conflicting in this area and needs to be resolved. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0079497085256B58_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 02/05/2002 05:30:30 PM:
> > but implicit in this was that it was intended to be a 'single shot
> > usage' between the sender and the recipient.  It was not something
[Snip]
> Yes. I can live with that. However if it is a 'one-shot' comment,
> then we need to add that text somewhere?

That was part of one of my earlier postings (go find that thread... ;^] ).  It is currently _implicitly_ a 'single shot' deal (based on our original intent AND the restriction tables of sorts in iTIP).  I will try to propose some formal text to make this clearer.  (To Do Maintainer: chalk this one up to me please in case it gets lost...)

>                                           Or if we are 'planning'
> to use it that way - we need some CAP text.

I seriously hope you are NOT planning on making COMMENT persistantly preserved or part of the workflow processing process.  It sounded like you expected stuff like COMMENT from an Organizer to be preserved when I delegate to someone and thats how this came about.  If you did not expect it to be preserved and that the COMMENT sent would be mine (to the Delegatee) then I think you are agreeing w/my basic premise that the RFC is self conflicting in this area and needs to be resolved.

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

--=_alternative 0079497085256B58_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 6 18:10:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04202 for ; Wed, 6 Feb 2002 17:21:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g16MBbN29403 for ietf-calendar-bks; Wed, 6 Feb 2002 14:11:37 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16MBW329398 for ; Wed, 6 Feb 2002 14:11:33 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 6 Feb 2002 17:11:31 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/06/2002 05:13:57 PM, Serialize complete at 02/06/2002 05:13:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0079DD0585256B58_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079DD0585256B58_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 02/05/2002 06:23:37 PM: > Not that it was mandated - but that it was allowed. Lots of stuff was allowed given the diversity of C&S currently out there. However there seems to be a difference of opinion and self contradictory text in the RFCs about how delegation can or should work. I just want to get the vagueness and conflicts removed so we can all work together (or at least so the CalConnect matrixes gets more "Yes" than "No"...) > We always agree - we just don't always know we agree > until after a debate :-) Sounds like you are counting in "We agree to disagree" in this tally... ;^b Actually once I get some Real Work (TM) done for this week Ill get out some proposed text to fix it up and we can then agree on that... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0079DD0585256B58_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 02/05/2002 06:23:37 PM:
> Not that it was mandated - but that it was allowed.
Lots of stuff was allowed given the diversity of C&S currently out there.  However there seems to be a difference of opinion and self contradictory text in the RFCs about how delegation can or should work.  I just want to get the vagueness and conflicts removed so we can all work together (or at least so the CalConnect matrixes gets more "Yes" than "No"...)

> We always agree - we just don't always know we agree
> until after a debate :-)

Sounds like you are counting in "We agree to disagree" in this tally... ;^b  Actually once I get some Real Work (TM) done for this week Ill get out some proposed text to fix it up and we can then agree on that...

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

--=_alternative 0079DD0585256B58_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 6 20:25:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06258 for ; Wed, 6 Feb 2002 20:25:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g171E7j09215 for ietf-calendar-bks; Wed, 6 Feb 2002 17:14:07 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g171E4309211 for ; Wed, 6 Feb 2002 17:14:05 -0800 (PST) To: ietf-calendar@imc.org Subject: Interop information on Calsch.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 6 Feb 2002 20:14:02 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 02/06/2002 08:14:09 PM, Serialize complete at 02/06/2002 08:14:09 PM Content-Type: multipart/alternative; boundary="=_alternative 0006C73A85256B59_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0006C73A85256B59_= Content-Type: text/plain; charset="us-ascii" I have created a page on www.calsch.org that has the following information. 1. Details on CalConnect3 - March 28-29, 2002 2. Results of CalConnect2 3. Results of CalConnect1 This is a quick link to the interop page (which you can also reach by going to www.calsch.org: http://www.calsch.org/CalConnect3/interop.html --=_alternative 0006C73A85256B59_= Content-Type: text/html; charset="us-ascii"
I have created a page on www.calsch.org that has the following information.

1. Details on CalConnect3 - March 28-29, 2002
2. Results of CalConnect2
3. Results of CalConnect1

This is a quick link to the interop page (which you can also reach by going to www.calsch.org:

http://www.calsch.org/CalConnect3/interop.html
 --=_alternative 0006C73A85256B59_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 7 13:05:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03924 for ; Thu, 7 Feb 2002 13:05:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17Hp8j26360 for ietf-calendar-bks; Thu, 7 Feb 2002 09:51:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Hp7326356 for ; Thu, 7 Feb 2002 09:51:07 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA19139 for ; Thu, 7 Feb 2002 12:51:04 -0500 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 g17Hp3Q18978 for ; Thu, 7 Feb 2002 12:51:03 -0500 (EST) Message-ID: <3C62BEF6.5CB5C89D@steltor.com> Date: Thu, 07 Feb 2002 12:52:54 -0500 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: CAP: Multiple OWNER in VAGENDA? (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@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: > > > OWNER Matches the UPN equal to the OWNER > > property of the VAGENDA in which the > > encapsulating VCAR is stored. > > ...equal to any OWNER - correct? > > (as opposed to 'the' OWNER). > > > NONOWNER Matches all UPNs different from the > > OWNER property of the VAGENDA in which > > the encapsulating VCAR is stored. > > Same here - ...different from any OWNER... ? You are correct. OWNER is currently 1+ in the draft. Did this WG thought through the issues involved with allowing multiple owners? Since we invite calendars and not users, only one owner can (need to) reply to an invitation? Are there any issue with multiple instances of RELATED-TO? Regards, 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 Thu Feb 7 13:08:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04046 for ; Thu, 7 Feb 2002 13:08:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17Him326170 for ietf-calendar-bks; Thu, 7 Feb 2002 09:44:48 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Hil326165 for ; Thu, 7 Feb 2002 09:44:47 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA18996 for ; Thu, 7 Feb 2002 12:44:43 -0500 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 g17HihQ18350 for ; Thu, 7 Feb 2002 12:44:43 -0500 (EST) Message-ID: <3C62BD79.5F37EF52@steltor.com> Date: Thu, 07 Feb 2002 12:46:33 -0500 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: CAP: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@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: > > > > > - I assumed that OWNER(), in addition to SELF(), was defined in > > CAP-QL. I hereby officially propose that OWNER(), NONOWNER() > > and SELF() be added to the CAP-QL ABNF. > > They are not in the text I checked in today - but I agree > that they are needed. Any objections? > > Where OWNER() == any one of the UPN's listed in the > VAGENDA OWNER properties. I realize that we can't use OWNER(), NONOWNER() and SELF() as I did in my proposal. For instance, the following "cap-select" statement suffers from 2 type mismatches: SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() AND ORGANIZER = OWNER() That is, 1- att = SELF() att is an ATTENDEE which is a calendar address (CAL-ADDRESS) and SELF() returns a user principal name (UPN). Bug! :-) 2- ORGANIZER = OWNER() where ORGANIZER is a calendar address (CAL-ADDRESS) and OWNER() returns a list of user principal names (UPN). Bug! :-) To iron out these bugs, I propose the following additions to CAP-QL: Function: CAL-OWNERS( CAL-ADDRESS ) Returns a SET containing the UPNs of all the OWNERs of the specified calendar address. UG UPN are expanded to CU UPN in the returned set. Function: CURRENT-CAL-ADDRESS() Returns the calendar address of the queried source (i.e., VAGENDA or CALSTORE). To get the OWNERs of the queried source we could do: CAL-OWNERS( CURRENT-CAL-ADDRESS() ) Operator: IN (e.g., "elem IN set") Returns TRUE if "elem" is in "set", else it returns FALSE. Thus, the "cap-select" statement could be written as follows: SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE SELF() IN CAL-OWNERS(att) AND ORGANIZER = CURRENT-CAL-ADDRESS() Comments? Regards, 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 Thu Feb 7 13:12:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04317 for ; Thu, 7 Feb 2002 13:12:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17HxXA26551 for ietf-calendar-bks; Thu, 7 Feb 2002 09:59:33 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17HxW326547 for ; Thu, 7 Feb 2002 09:59:32 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA19341 for ; Thu, 7 Feb 2002 12:59:29 -0500 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 g17HxSQ20031 for ; Thu, 7 Feb 2002 12:59:28 -0500 (EST) Message-ID: <3C62C0EF.AF1657E8@steltor.com> Date: Thu, 07 Feb 2002 13:01:19 -0500 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: CAP: VCAR Proposal (#2) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@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: > > > > > * Matches all UPNs. > > > @ Matches the UPN of anonymous CUs > > belonging to the unnamed realm > > You need to define 'unnamed realm'. I know it is the > the WG mailing list - I don't remember what it is and > it is not currently defined in CAP (or this proposal). I'll simply use "null" as in section 2.4.4 "CAP Session Identity". The UPN-FILTER value type is based on the UPN value type which is not yet formally defined with an ABNF. I'll rely on the fact that the definition of UPN will need to provide the definition of "null". > > @* Matches the UPN of anonymous CUs > > belonging to any named realm > > Same here - define a 'named realm'. I'll use "non-null" as in section 2.4.4. > > @realm Matches the UPN of anonymous CUs > > belonging to the specified realm > > In a previous email you said that the CS is not required > to do a reverse DNS lookup to find the 'belonging' to realm. DNS provides information on Internet domains NOT realms. DNS is of no use to find the realm to whom you belong. > Do you mean the realm the UPN supplied as part of it authentication? > If not - what is it? It is the UPN that identifies the authenticated user, that is, after sufficient credentials were provided to an authentication mechanism. Whether the UPN itself is provided as part of the credentials or not is irrelevant. I could provide an X.500 distinguished name and a clear text password as my credentials and still be identified as "bernard@steltor.com" (my UPN) in the CS. > > Description: A "VCAR" calendar component is a grouping of component > > properties, and "VRIGHT" calendar components, that represents access > > rights granted or denied to calendar users. > > Add - "and the default is DENY". > Agree? We have to have some default, and the security guys > in the past said the default should be to deny anything not > specifically granted. That's already covered in section 2.4.2 "Access Rights - Summary". My proposal does not intend to replace this text. On the other hand, we will need to make sure nothing is missing from this section as well. > > In this example, rights are specified for all UPNs to read VEVENT > > components classified as PUBLIC: > nnn> > > BEGIN:VCAR > > CARID:abcd12345 > > NAME:"View PUBLIC Start and End Times" > > BEGIN:VRIGHT > > GRANT:* > > PERMISSION:READ > > SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' > > END:VRIGHT > > END:VCAR > > Questions / comments: > > You use quotes (") in the text value of the NAME > property, that is optional - just like it is optional in > any TEXT value property? Correct? Correct. These values used to be specified in the CARID property with double quote (") and I did not bothered removing them. I will remove them to avoid confusion. > They all have the SAME CARID in your examples. > I think we need to add text that says that a CARID > MUST BE unique within its scope. Yes. How shall we express "scope" in: The CARID itself MUST be a unique identifier within ??? > > In this example, rights are specified for all UPNs to read or modify > > existing VEVENT components classified as PUBLIC: > > > > BEGIN:VCAR > > CARID:abcd12345 > > NAME:"Read and Modify PUBLIC Calendar Entries" > > BEGIN:VRIGHT > > GRANT:* > > PERMISSION:READ > > PERMISSION:MODIFY > > SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC' > > END:VRIGHT > > END:VCAR > > You define PERMISSION in x.x.3.3.3 below as a TEXT value type. > A TEXT value type can have multiple values, separated > by commas. > > So this is also valid? If not, there needs to be > restrictions specified in the proposal. > > PERMISSION:READ,MODIFY The ABNF for PERMISSION does not allow this. I don't think I need to change anything. Have a look at the TRANSP property in RFC 2445. What you are saying is true for CATEGORIES, but not for PERMISSION and TRANSP. > > In this example, rights to write, read, modify or delete calendar > > access rights are denied to all UPNs. This example would disable > > providing different access rights to the calendar store or calendar. > > This calendar access rights should not be specified, as they remove > > the ability to change calendar access; even for the owner or > > administrator: > > Or it is the perfect data to add to a CAR-MIN CS that > only has decreed VCARs and does not wish to give READ access > to those VCARs. > > So I think the the "...should not be specified..." sentence > needs to be: > > This calendar access rights should not be specified unless > all of the VCARs are decreed and the CS wishes to not > allow any UPN to query for any of those decreed VCARs. I will simply change "should not be specified" to "should be specified with great care". > > BEGIN:VCAR > > CARID:abcd12345 > > NAME:"No CAR At All" > > BEGIN:VRIGHT > > DENY:* > > PERMISSION:* > > SCOPE:SELECT * FROM VCAR > > END:VRIGHT > > END:VCAR > > > x.x.2.2 VRIGHT Calendar Component > > > > .... > > > > > > As CAP-QL, RESTRICTION, and SCOPE have the same value type, we > need to define a CAPSELECT value type. Much like 2445 defines > TEXT, BINARY, ... value types, then modify CAP-QL/QUERY and > VCAR/SCOPE to say that they have a value type of CAPSELECT. That's right. > > And I think we need to add a note that the CAPSELECT value-type > is a valid "iana-token" value as defined > in 2445 "4.2.20 Value Data Types". > > This is a complex and formatted data type. I think it > needs is own standalone 'IANA registration' section. > > Agree? How would that be different from the format that I've used to define "Value Type", "Calendar Component" and "Component Properties" in my proposal? Isn't it implicit that all new "Value Type", "Calendar Component" and "Component Properties" are indeed valid iana-token? Let me know if I haven't used the right format. > And below you call the value for GRANT and DENY > a 'upn-filter' value type. I know what you mean, but > there is no such thing as a 'upn-filter' value type. > > They need to be: > > (1) TEXT value type, with specific restrictions to > its content. > or > (2) We need to define UPN-FILTER as a valid VALUE type > like I think we need to do with CAPSELECT. > (which is what you call them below - value types). > > I would opt for (1). I already did (2). See very first section of the proposal. > x.x.1 Property Value Data Types > > x.x.1.1 UPN Filter > > Value Name: UPN-FILTER > > > x.x.3.1.1 Name Component Property > > > > NAME:"Restrict Guests From Creating ALARMs On Events" > > Again, the (")'s are optional - right? Correct. > > > x.x.3.2.1 Identifier Component Property > > I think the above section title needs renamed, > perhaps "VCAR Identifier". Okay. > > It only identifies VCARs and not 'any' component - correct? > > > Format Definition: The property is defined by the following notation: > > > > carid = "CARID" caridparam ":" text CRLF > > And BOOLEAN parameter 'DECREED' ? > > Or was that going to be a property? > > Or were we going to force the CUA to figure it out after > reading the VCARs? I'll add the DECREED property and I'll modify the restriction tables as follow: . . . . DECREED 0 This property is outside the scope of the protocol. Agree? > > x.x.3.3 Right Component Properties > > > > x.x.3.3.1 Grant Component Property > > > > Property Name: GRANT > > > > Purpose: This property identifies the CU or UG being granted access > > in the VRIGHT component. > > Specifies the UPN subject to the upn-filters, > not the CU or UG - correct? The 'CU' is an entity that > may have multiple UPNs. Correct. > Same with UG, it is the CS's responsibility > to expand any UPN *if* it happens to be a UG, but we are only > restricting or granting based on UPN - correct? Correct. > > > Value Type: UPN-FILTER > > > > Property Parameters: Only non-standard property parameters can be > > specified on this property. > > > > Conformance: This property can be specified in "VRIGHT" calendar > > components. > > > > Description: This property is used in the "VRIGHT" calendar component > > to specify the CU or UG being granted access. > > > x.x.3.3.2 Deny Component Property > > Same issues with DENY as GRANT above. Yes. > > > x.x.3.3.4 Scope Component Property > > > > Property Name: SCOPE > > > > Purpose: This property identifies the objects in the CS to which > > the access rights applies. > > > > Value Type: capselect > > And as I said above, lets make 'capselect' and official value type. I propose the name "CAL-QUERY" as the name of this new value type. I don't think value type should bear the name of any protocol making use of them (e.g., "CAP"). Agree? > > Predefined calendar access CARIDs that MUST be implemented are: > > > > CS MUST implement the following > > > > CARID:READBUSYTIMEINFO - grants all authenticated users the > > right to read VFREEBUSY components. > > We are NOT defining them as MUST have 'this' content, > add: > > A suggested content for the READBUSYTIMEINFO is: I agree. > > > BEGIN:VCAR > > CARID:READBUSYTIMEINFO > > BEGIN:VRIGHT > > GRANT:* > > PERMISSION:READ > > SCOPE:SELECT * FROM VFREEBUSY > > END:VRIGHT > > END:VCAR > > Add: > > In order to make this a decreed VCAR, an implementation would > have to add something like the following to the above suggested VCAR. > > BEGIN:VRIGHT > DENY:* > PERMISSION:WRITE,MODIFY > SCOPE:SELECT * FROM VCAR WHERE CARID = 'READBUSYTIMEINFO' > END:VRIGHT > > Add: (similar notes to the other predefined VCAR CARIDs, > or one general statement that covers them all). Decreed also mean "persistent and immutable" so this is not sufficient. Can you agree that in order to make a VCAR decreed you ONLY have to specify DECREED:TRUE in the VCAR component? > > CARID:UPDATEPARTSTATUS - grants all authenticated users the right > > to modify the instances of the ATTENDEE property set to one of > > their calendar adresses in the VEVENT and VTODO components for > > which the ORGANIZER property is set to the address of the VAGENDA > > in which the VEVENT or VTODO is stored, given that the submitted > > value of the ATTENDEE property is one of their calendar adresses. > > Technical wording issue: > > Where the value matched their authenticated UPN. The > CS would not know their 'calendar addresses' (two places). > > > > ------------------------------------------------------------------------ > > > > Restriction table for both "create" and "modify". > > What about delete? (Not that I can't guess - but what about > the new reader?) An oversight from my part. This information will need to appear in many places in the draft. Regards, 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 Thu Feb 7 14:04:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05979 for ; Thu, 7 Feb 2002 14:04:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17IpW128199 for ietf-calendar-bks; Thu, 7 Feb 2002 10:51:32 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17IpU328195 for ; Thu, 7 Feb 2002 10:51:30 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA24824 for ; Thu, 7 Feb 2002 10:51:31 -0800 (PST) Message-ID: <3C62CCAE.5B73E250@Royer.com> Date: Thu, 07 Feb 2002 11:51:26 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BD79.5F37EF52@steltor.com> Content-Type: multipart/mixed; boundary="------------64AF3E3AE3F8AF6D03B60BE6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------64AF3E3AE3F8AF6D03B60BE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > > - I assumed that OWNER(), in addition to SELF(), was defined in > > > CAP-QL. I hereby officially propose that OWNER(), NONOWNER() > > > and SELF() be added to the CAP-QL ABNF. > > > > They are not in the text I checked in today - but I agree > > that they are needed. Any objections? > > > > Where OWNER() == any one of the UPN's listed in the > > VAGENDA OWNER properties. > > I realize that we can't use OWNER(), NONOWNER() and SELF() > as I did in my proposal. For instance, the following > "cap-select" statement suffers from 2 type mismatches: > > SELECT att FROM VEVENT > USING_PROPERTIES ATTENDEE att > WHERE att = SELF() AND ORGANIZER = OWNER() > > That is, > > 1- att = SELF() > > att is an ATTENDEE which is a calendar > address (CAL-ADDRESS) and SELF() returns > a user principal name (UPN). Bug! :-) > > 2- ORGANIZER = OWNER() > > where ORGANIZER is a calendar address > (CAL-ADDRESS) and OWNER() returns a list > of user principal names (UPN). Bug! :-) > > To iron out these bugs, I propose the following > additions to CAP-QL: > > Function: CAL-OWNERS( CAL-ADDRESS ) > > Returns a SET containing the UPNs of all the OWNERs > of the specified calendar address. UG UPN are > expanded to CU UPN in the returned set. I assume returned in comma separated format like any other multi-value property value? Which would include quoting if needed and backslash escaping if needed? > Function: CURRENT-CAL-ADDRESS() > > Returns the calendar address of the queried > source (i.e., VAGENDA or CALSTORE). To get > the OWNERs of the queried source we could do: > CAL-OWNERS( CURRENT-CAL-ADDRESS() ) Returns the CALID, not the RELCALID - correct? > Operator: IN (e.g., "elem IN set") > > Returns TRUE if "elem" is in "set", else it > returns FALSE. > Thus, the "cap-select" statement could be written > as follows: > > SELECT att FROM VEVENT > USING_PROPERTIES ATTENDEE att > WHERE SELF() IN CAL-OWNERS(att) AND > ORGANIZER = CURRENT-CAL-ADDRESS() > > Comments? Yes - and it is the same as the SQL 'IN' and seem to do the same thing. Also "NOT IN". --------------64AF3E3AE3F8AF6D03B60BE6 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 ; Thu, 7 Feb 2002 14:18:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17J2iT28685 for ietf-calendar-bks; Thu, 7 Feb 2002 11:02:44 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17J2h328680 for ; Thu, 7 Feb 2002 11:02:43 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA24857 for ; Thu, 7 Feb 2002 11:02:44 -0800 (PST) Message-ID: <3C62CF4F.3D1A8B62@Royer.com> Date: Thu, 07 Feb 2002 12:02:39 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: CAP: Multiple OWNER in VAGENDA? (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BEF6.5CB5C89D@steltor.com> Content-Type: multipart/mixed; boundary="------------92A87F21ED12D13E99B69451" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------92A87F21ED12D13E99B69451 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > OWNER Matches the UPN equal to the OWNER > > > property of the VAGENDA in which the > > > encapsulating VCAR is stored. > > > > ...equal to any OWNER - correct? > > > > (as opposed to 'the' OWNER). > > > > > NONOWNER Matches all UPNs different from the > > > OWNER property of the VAGENDA in which > > > the encapsulating VCAR is stored. > > > > Same here - ...different from any OWNER... ? > > You are correct. OWNER is currently 1+ in the draft. > > Did this WG thought through the issues involved with > allowing multiple owners? Yes, it was changed to a multi-instances, single value in 05 or earlier. (this text from 06) OWNER N URI A multi-instanced property indicating the calendar owner. Each entry returned will be a UPN. There must be at least one owner. > Since we invite calendars and not users, only one owner > can (need to) reply to an invitation? Also [iTIP] 2.1.3 Acting on Behalf of other Calendar Users ...Second, a "sent-by" parameter may be specified in either the "Organizer" or "Attendee" properties. When specified, the "sent-by" parameter indicates that the responding CU acted on behalf of the specified "Attendee" or "Organizer". So you can have your assistant be able to connect to your calendar and REPLY for you - and they do not need to be an OWNER of your calendar. > Are there any issue with multiple instances of RELATED-TO? According to Bruce, the RELATED-TO property needs to be multi instance single value. I have no problem with that. --------------92A87F21ED12D13E99B69451 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 ; Thu, 7 Feb 2002 14:18:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17IxYp28548 for ietf-calendar-bks; Thu, 7 Feb 2002 10:59:34 -0800 (PST) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17IxX328544 for ; Thu, 7 Feb 2002 10:59:33 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail1.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g17IxYd13510 for ; Thu, 7 Feb 2002 10:59:34 -0800 (PST) Received: from oracle.com (pc.idc.oracle.com [152.69.171.253] (may be forged)) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g17IxUc14895; Thu, 7 Feb 2002 11:59:31 -0700 (MST) Message-ID: <3C62D271.144F2EE5@oracle.com> Date: Fri, 08 Feb 2002 00:46:01 +0530 From: Lata Kannan Reply-To: lata.kannan@oracle.com X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: lata.kannan@oracle.com, prashantkumar.shetty@oracle.com Subject: Event owner in ICAL schema 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 Hi, We already have an existing Calendar application using our proprietory database schema, proprietory APIs and a Web client interface. We are now in the process of creating a new ICAL compliant calendar schema. In our existing calendar, we have every appointment owned by a person, namely an event_owner, every todo owned by a todo_owner and every journal owned by a journal owner. This is a mandatory field for every appointment, todo and journal. As far as we have understood the RFC 2445, we are not able to find an equivalent attribute wherein we coudl store this information. The RFC does not seem to mandate any field and nothing wherein we could store this existing attribute of the calendar. As of now we are planning to add this attribute to the VEVENT table which we create in our ICAL schema. Is there anything that we are missing out here? Any inputs on this would really help. Thanks in advance Lata From owner-ietf-calendar@mail.imc.org Thu Feb 7 14:51:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07589 for ; Thu, 7 Feb 2002 14:51:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17JbCa29935 for ietf-calendar-bks; Thu, 7 Feb 2002 11:37:12 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17JbB329931 for ; Thu, 7 Feb 2002 11:37:11 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA21752; Thu, 7 Feb 2002 14:37:06 -0500 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g17Jb6Q00757; Thu, 7 Feb 2002 14:37:06 -0500 (EST) Message-Id: <5.1.0.14.0.20020207141548.02c7d008@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Feb 2002 14:40:29 -0500 To: lata.kannan@oracle.com, "ietf-calendar@imc.org" From: Alan Davies Subject: Re: Event owner in ICAL schema Cc: prashantkumar.shetty@oracle.com In-Reply-To: <3C62D271.144F2EE5@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: iCalendar has the concept of an ORGANIZER, but it's not mandatory in RFC 2445. Is this the same information that you wanted to represent? RFC2446 (iTIP) defines an interoperability protocol for exchange of iCalendar objects, and specifies that ORGANIZER must be present for all methods (except 'REFRESH'). I notice that you refer to a "VEVENT table" - did you follow the recent thread about creating a virtual iCalendar relational schema for CAP that would allow queries to be made using SQL-92? If you didn't, the main problems were: - Components can contain other components. - Properties can appear multiple times in a component. - Properties can have several named parameters, as well as a value. - Some property values are comma-separated lists. (One of several threads that made up this discussion: http://www.imc.org/ietf-calendar/mail-archive/msg02877.html ) --Alan At 12:46 AM 08/02/2002 +0530, Lata Kannan wrote: >Hi, > >We already have an existing Calendar application using our proprietory >database schema, proprietory APIs and a Web client interface. We are now >in the process of creating a new ICAL compliant calendar schema. In our >existing calendar, we have every appointment owned by a person, namely >an event_owner, every todo owned by a todo_owner and every journal owned >by a journal owner. This is a mandatory field for every appointment, >todo and journal. As far as we have understood the RFC 2445, we are >not able to find an equivalent attribute wherein we coudl store this >information. The RFC does not seem to mandate any field and nothing >wherein we could store this existing attribute of the calendar. As of >now we are planning to add this attribute to the VEVENT table which we >create in our ICAL schema. > >Is there anything that we are missing out here? Any inputs on this >would really help. > >Thanks in advance >Lata From owner-ietf-calendar@mail.imc.org Thu Feb 7 14:53:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07683 for ; Thu, 7 Feb 2002 14:53:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17JZuC29906 for ietf-calendar-bks; Thu, 7 Feb 2002 11:35:56 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17JZt329901 for ; Thu, 7 Feb 2002 11:35:55 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: Event owner in ICAL schema MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 7 Feb 2002 14:43:19 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/07/2002 02:43:38 PM, Serialize complete at 02/07/2002 02:43:38 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >We are now >in the process of creating a new ICAL compliant calendar schema. That's "iCalendar". >In our >existing calendar, we have every appointment owned by a person, [...] >As far as we have understood the RFC 2445, we are >not able to find an equivalent attribute wherein we coudl store this >information. What about ORGANIZER? /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Among animals, it's eat or be eaten. Among people, it's define or| |be defined. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Feb 7 14:55:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07735 for ; Thu, 7 Feb 2002 14:55:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17Je4t00129 for ietf-calendar-bks; Thu, 7 Feb 2002 11:40:04 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Je3300124 for ; Thu, 7 Feb 2002 11:40:03 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA21850 for ; Thu, 7 Feb 2002 14:40:00 -0500 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 g17JdxQ01264 for ; Thu, 7 Feb 2002 14:40:00 -0500 (EST) Message-ID: <3C62D87E.5A53AA72@steltor.com> Date: Thu, 07 Feb 2002 14:41:50 -0500 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: CAP: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BD79.5F37EF52@steltor.com> <3C62CCAE.5B73E250@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: > > > > Function: CAL-OWNERS( CAL-ADDRESS ) > > > > Returns a SET containing the UPNs of all the OWNERs > > of the specified calendar address. UG UPN are > > expanded to CU UPN in the returned set. > > I assume returned in comma separated format like > any other multi-value property value? > > Which would include quoting if needed and backslash escaping > if needed? Do you mean? CAL-OWNERS(ATTENDEE) = 'user1@abc.com', 'user2@abc.com' If so, that's fine with me. > > > Function: CURRENT-CAL-ADDRESS() > > > > Returns the calendar address of the queried > > source (i.e., VAGENDA or CALSTORE). To get > > the OWNERs of the queried source we could do: > > CAL-OWNERS( CURRENT-CAL-ADDRESS() ) > > Returns the CALID, not the RELCALID - correct? Yes. We should even rename the function to 'CURRENT-CALID()'. Correct? > > > Operator: IN (e.g., "elem IN set") > > > > Returns TRUE if "elem" is in "set", else it > > returns FALSE. > > > Thus, the "cap-select" statement could be written > > as follows: > > > > SELECT att FROM VEVENT > > USING_PROPERTIES ATTENDEE att > > WHERE SELF() IN CAL-OWNERS(att) AND > > ORGANIZER = CURRENT-CAL-ADDRESS() > > > > Comments? > > Yes - and it is the same as the SQL 'IN' and seem to > do the same thing. > > Also "NOT IN". Great! Regards, 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 Thu Feb 7 15:27:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08769 for ; Thu, 7 Feb 2002 15:27:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17K6MD00872 for ietf-calendar-bks; Thu, 7 Feb 2002 12:06:22 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17K6K300868 for ; Thu, 7 Feb 2002 12:06:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA24982 for ; Thu, 7 Feb 2002 12:06:21 -0800 (PST) Message-ID: <3C62DE37.6712BE28@Royer.com> Date: Thu, 07 Feb 2002 13:06:15 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> Content-Type: multipart/mixed; boundary="------------66E6CAAEACB3447CF06FE8DF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------66E6CAAEACB3447CF06FE8DF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: I removed the UPN discussion from this reply. I'll need to see the new text to understand. I don't yet. > > Add - "and the default is DENY". > > Agree? We have to have some default, and the security guys > > in the past said the default should be to deny anything not > > specifically granted. > > That's already covered in section 2.4.2 "Access Rights - Summary". Yep - I missed that. > > > They all have the SAME CARID in your examples. > > I think we need to add text that says that a CARID > > MUST BE unique within its scope. > > Yes. > > How shall we express "scope" in: > > The CARID itself MUST be a unique identifier within ??? How about? Any CALSTORE VCARS must be unique in the CALSTORE. Any VCARs in the CALSTORE override any in all contained VAGENDAs where the CARID are the same. Any VAGENDA VCARs must be unique in the VAGENDA. Any VAGENDA VCARs override any in all contained components where the CARID is the same in the VAGENDA. Any VCARs contained in any component must have unique CARIDs with respect to any other VCAR in that component. This keeps the calendar owner from overriding any administrative VCARs. And it keeps someone from depositing a REQUEST that allows them to override the owners VCARs. And it also allows the administrator or implementation to allow the calendar OWNERs to define the VCARs for their calendars by not defining them at the CALSTORE level. > > You define PERMISSION in x.x.3.3.3 below as a TEXT value type. > > A TEXT value type can have multiple values, separated > > by commas. > > > > So this is also valid? If not, there needs to be > > restrictions specified in the proposal. > > > > PERMISSION:READ,MODIFY > > The ABNF for PERMISSION does not allow this. > I don't think I need to change anything. Have > a look at the TRANSP property in RFC 2445. > > What you are saying is true for CATEGORIES, > but not for PERMISSION and TRANSP. The TANSP property is defined as single instance in 2445 grammar and the 2446 restriction tables as there is only one state the value can be for any given component. The PERMISSION property is defined as multiple instance in your proposal and each one is NOT declared in the proposal as MUST BE be unique per component. Which is why I was asking - it is not clear to me if it is allowed. And if it is not allowed - why not as it can be one of several combination of values? It is not fixed to one state per component. So why is it single value multiple instance, and not single instance multiple value? Or multiple instance, multiple value like CATEGORIES? Is there are reason? > > Or it is the perfect data to add to a CAR-MIN CS that > > only has decreed VCARs and does not wish to give READ access > > to those VCARs. > > > > So I think the the "...should not be specified..." sentence > > needs to be: > > > > This calendar access rights should not be specified unless > > all of the VCARs are decreed and the CS wishes to not > > allow any UPN to query for any of those decreed VCARs. > > I will simply change "should not be specified" to > "should be specified with great care". I agree. > > And I think we need to add a note that the CAPSELECT value-type > > is a valid "iana-token" value as defined > > in 2445 "4.2.20 Value Data Types". > > > > This is a complex and formatted data type. I think it > > needs is own standalone 'IANA registration' section. > > > > Agree? > > How would that be different from the format that I've > used to define "Value Type", "Calendar Component" and > "Component Properties" in my proposal? It allows them to be valid as the right hand side of the 'VALUE=" parameter. The 2445 registration procedure for new properties specifies that they must be declared. I will 'declare' CAL-QUERY value type (as you pointed out you did for UPN-FILTER). I'll rip it out or modify the CAP-QL proposal and make it a stand alone section that explicitly declares it to be a new value type. > Isn't it implicit that all new "Value Type", "Calendar > Component" and "Component Properties" are indeed valid > iana-token? We have to 'register' it somewhere so that it is explicitly visible. We used it as if it is a value type, but we have to declare that it is. > > It only identifies VCARs and not 'any' component - correct? > > > > > Format Definition: The property is defined by the following notation: > > > > > > carid = "CARID" caridparam ":" text CRLF > > > > And BOOLEAN parameter 'DECREED' ? > > > > Or was that going to be a property? > > > > Or were we going to force the CUA to figure it out after > > reading the VCARs? > > I'll add the DECREED property and I'll modify the > restriction tables as follow: > > . . . . DECREED 0 This property is outside > the scope of the protocol. > > Agree? I don't follow. I don't think so. You and others at Steltor have asked several times "how do you know that it is DECREED". Are you now saying that you don't want to define how to tell if it is decreed? If you are saying "you do not care", then no, we need to be able to define the VCAR it in the VCAR itself that it is read-only. That must be by adding another VRIGHTs component, or by a 'DECREED' property - that is defined. > > > x.x.3.3 Right Component Properties > > > > > > x.x.3.3.1 Grant Component Property > > > > > > Property Name: GRANT > > > > > > Purpose: This property identifies the CU or UG being granted access > > > in the VRIGHT component. > > > > Specifies the UPN subject to the upn-filters, > > not the CU or UG - correct? The 'CU' is an entity that > > may have multiple UPNs. > > Correct. So, I assume this means your going to update the text? :-) > > Can you agree that in order to make a VCAR decreed you > ONLY have to specify DECREED:TRUE in the VCAR component? Yes - you need to add a new property definition with a boolean value DECREED. > --------------66E6CAAEACB3447CF06FE8DF 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 ; Thu, 7 Feb 2002 15:33:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17KHDf01249 for ietf-calendar-bks; Thu, 7 Feb 2002 12:17:13 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17KHC301245 for ; Thu, 7 Feb 2002 12:17:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA25010; Thu, 7 Feb 2002 12:17:11 -0800 (PST) Message-ID: <3C62E0C1.9E74366E@Royer.com> Date: Thu, 07 Feb 2002 13:17:05 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: lata.kannan@oracle.com, "ietf-calendar@imc.org" CC: "ietf-calendar@imc.org" , prashantkumar.shetty@oracle.com Subject: Re: Event owner in ICAL schema References: <3C62D271.144F2EE5@oracle.com> Content-Type: multipart/mixed; boundary="------------CB893E7451EB5B31B5307A40" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CB893E7451EB5B31B5307A40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lata Kannan wrote: > > Hi, > > We already have an existing Calendar application using our proprietory > database schema, proprietory APIs and a Web client interface. We are now > in the process of creating a new ICAL compliant calendar schema. In our > existing calendar, we have every appointment owned by a person, namely > an event_owner, every todo owned by a todo_owner and every journal owned > by a journal owner. This is a mandatory field for every appointment, > todo and journal. As far as we have understood the RFC 2445, we are > not able to find an equivalent attribute wherein we coudl store this > information. The RFC does not seem to mandate any field and nothing > wherein we could store this existing attribute of the calendar. As of > now we are planning to add this attribute to the VEVENT table which we > create in our ICAL schema. > > Is there anything that we are missing out here? Any inputs on this > would really help. Have your read the Calendar Access Protocol draft (CAP) available at www.calsch.org. RFC 2445 specifies how to describe an object. RFC 2446 specifies how to do scheduling. RFC 2447 specifies how to email RFC 2446 objects. And CAP specifies (among other things), how objects are stored into a calendar owned by an entity. We did not put the owner in each object. Instead we define a logical object called a VAGENDA, which contains RFC 2445 objects that are all owned by a named set of owners. In addition CAP specifies how to put (CREATE), fetch (QUERY), and update (MODIFY) those objects. --------------CB893E7451EB5B31B5307A40 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 ; Thu, 7 Feb 2002 15:49:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17Kax901910 for ietf-calendar-bks; Thu, 7 Feb 2002 12:36:59 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Kaw301906 for ; Thu, 7 Feb 2002 12:36:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA25025; Thu, 7 Feb 2002 12:36:59 -0800 (PST) Message-ID: <3C62E562.8C010A5@Royer.com> Date: Thu, 07 Feb 2002 13:36:50 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BD79.5F37EF52@steltor.com> <3C62CCAE.5B73E250@Royer.com> <3C62D87E.5A53AA72@steltor.com> Content-Type: multipart/mixed; boundary="------------E5EEC4A37BE5CA1E0E386A59" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E5EEC4A37BE5CA1E0E386A59 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Function: CAL-OWNERS( CAL-ADDRESS ) > > > > > > Returns a SET containing the UPNs of all the OWNERs > > > of the specified calendar address. UG UPN are > > > expanded to CU UPN in the returned set. > > > > I assume returned in comma separated format like > > any other multi-value property value? > > > > Which would include quoting if needed and backslash escaping > > if needed? > > Do you mean? > > CAL-OWNERS(ATTENDEE) = 'user1@abc.com', 'user2@abc.com' > > If so, that's fine with me. Yes. > > > > > Function: CURRENT-CAL-ADDRESS() > > > > > > Returns the calendar address of the queried > > > source (i.e., VAGENDA or CALSTORE). To get > > > the OWNERs of the queried source we could do: > > > CAL-OWNERS( CURRENT-CAL-ADDRESS() ) > > > > Returns the CALID, not the RELCALID - correct? > > Yes. We should even rename the function > to 'CURRENT-CALID()'. Correct? Yes. > > > > > Operator: IN (e.g., "elem IN set") > > > > > > Returns TRUE if "elem" is in "set", else it > > > returns FALSE. > > > > > Thus, the "cap-select" statement could be written > > > as follows: > > > > > > SELECT att FROM VEVENT > > > USING_PROPERTIES ATTENDEE att > > > WHERE SELF() IN CAL-OWNERS(att) AND > > > ORGANIZER = CURRENT-CAL-ADDRESS() > > > > > > Comments? > > > > Yes - and it is the same as the SQL 'IN' and seem to > > do the same thing. > > > > Also "NOT IN". > > Great! After thinking about it, by mofifying the definition of 'CONTAINS' to mean the left hand side is the value of the named property or function: SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE CONTAINS(CAL-OWNERS(att), SELF()) AND ORGANIZER = CURRENT-CAL-ADDRESS() Correct? So do we need 'IN' ? Or should we replace CONTAINS with 'IN' (this option sounds better to me) ? SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE SELF() IN CAL-OWNERS(att) AND ORGANIZER = CURRENT-CAL-ADDRESS() And 'IN' also works with: WHERE "value1" in CATEGORIES If we write the text correcty. --------------E5EEC4A37BE5CA1E0E386A59 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 ; Thu, 7 Feb 2002 15:57:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17KcTL02014 for ietf-calendar-bks; Thu, 7 Feb 2002 12:38:29 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17KcS302010 for ; Thu, 7 Feb 2002 12:38:28 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA24255 for ; Thu, 7 Feb 2002 15:38:25 -0500 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 g17KcOQ10033 for ; Thu, 7 Feb 2002 15:38:24 -0500 (EST) Message-ID: <3C62E62F.24A46FF@steltor.com> Date: Thu, 07 Feb 2002 15:40:15 -0500 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: Alternate to COALESCE References: <3C61A010.E3942645@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 I agree that there must be a way to specify that we only want the VCARs that pertain to the authenticated user to be returned. But I don't see why you think it will be easier to the CUA to handle the following coalesced VCAR: BEGIN:VCAR BEGIN:VRIGHT GRANT:foo@host.com PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VRIGHT BEGIN:VRIGHT GRANT:foo@host.com PERMISSION:READ PERMISSION:MODIFY SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC' END:VRIGHT END:VCAR than these two separate VCARs? BEGIN:VCAR CARID:abcd12345-1 BEGIN:VRIGHT GRANT:foo@host.com PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VRIGHT END:VCAR BEGIN:VCAR CARID:abcd12345 BEGIN:VRIGHT GRANT:foo@host.com PERMISSION:READ PERMISSION:MODIFY SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC' END:VRIGHT END:VCAR I'll reply to your message once I understand this. Regards, 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 Thu Feb 7 16:19:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10158 for ; Thu, 7 Feb 2002 16:19:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17L47U03549 for ietf-calendar-bks; Thu, 7 Feb 2002 13:04:07 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17L45303545 for ; Thu, 7 Feb 2002 13:04:05 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA24998 for ; Thu, 7 Feb 2002 16:04:02 -0500 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 g17L3qQ13135 for ; Thu, 7 Feb 2002 16:03:53 -0500 (EST) Message-ID: <3C62EC27.A65AA059@steltor.com> Date: Thu, 07 Feb 2002 16:05:43 -0500 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: CAP: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BD79.5F37EF52@steltor.com> <3C62CCAE.5B73E250@Royer.com> <3C62D87E.5A53AA72@steltor.com> <3C62E562.8C010A5@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: > > Or should we replace CONTAINS with 'IN' (this option > sounds better to me) ? I agree. Let's replace CONTAINS with 'IN'. Regards, 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 Thu Feb 7 17:09:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11259 for ; Thu, 7 Feb 2002 17:09:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17LuGB05476 for ietf-calendar-bks; Thu, 7 Feb 2002 13:56:16 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17LuF305471 for ; Thu, 7 Feb 2002 13:56:15 -0800 (PST) To: lata.kannan@oracle.com Cc: ietf-calendar@imc.org, prashantkumar.shetty@oracle.com Subject: Re: Event owner in ICAL schema MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 7 Feb 2002 17:03:08 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/07/2002 04:56:19 PM, Serialize complete at 02/07/2002 04:56:19 PM Content-Type: multipart/alternative; boundary="=_alternative 007870F885256B59_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007870F885256B59_= Content-Type: text/plain; charset="US-ASCII" Lata asked: > In our > existing calendar, we have every appointment owned by a person, namely > an event_owner, every todo owned by a todo_owner and every journal owned > by a journal owner. [Snip, snip] > As far as we have understood the RFC 2445, we are > not able to find an equivalent attribute wherein we coudl store this > information. As several of my quick fingered collegues replied, you probably looked at the ORGANIZER property to do what you wanted. However I think several folks have forgotten the text that describes the ORGANIZER property. What they seemingly correclty suggested is actually NOT allowed. From RFC 2445, Section 4.8.4.3 Organizer (p. 106): Conformance: This property MUST be specified in an iCalendar object that specifies a group scheduled calendar entity. This property MUST be specified in an iCalendar object that specifies the publication of a calendar user's busy time. This property MUST NOT be specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but are entities only on a single user's calendar. (emphasis mine). So, as such for calendar entries that do not involve others there is no 'concept' of an Owner or Organizer as we call them in iCalendar. Unfortunately at this time I do not recally why we chose to include this particular restriction (at least the latter half of it). Perhaps we can nudge Frank Dawson or someone else whose equally long in the CalSched tooth to recall why. (Im sure once mentioned Ill probably slap my forehad and say "Oh, of course!" but in the mean time Ill just scratch my head a bit...) > Is there anything that we are missing out here? Any inputs on this > would really help. You can define your own custom vendor extension (ie: X-ORCL-OWNER) and include it on all non-workflow entries. For any workflow entities, ORGANIZER is what you want... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007870F885256B59_= Content-Type: text/html; charset="US-ASCII"
Lata asked:

>                                                                  In our
> existing calendar, we have every appointment owned by a person, namely
> an event_owner, every todo owned by a todo_owner and every journal owned
> by a journal owner.
[Snip, snip]
>                       As far as we have understood the RFC 2445, we are
> not able to find an equivalent attribute wherein we coudl store this
> information.  

  As several of my quick fingered collegues replied, you probably looked at the ORGANIZER property to do what you wanted.  However I think several folks have forgotten the text that describes the ORGANIZER property.  What they seemingly correclty suggested is actually NOT allowed.  

  From RFC 2445, Section 4.8.4.3 Organizer (p. 106):

   Conformance: This property MUST be specified in an iCalendar object
  that specifies a group scheduled calendar entity. This property MUST
  be specified in an iCalendar object that specifies the publication of
  a calendar user's busy time. This property MUST NOT be specified in
  an iCalendar object that specifies only a time zone definition or
  that defines calendar entities that are not group scheduled entities,
  but are entities only on a single user's calendar.

(emphasis mine).  So, as such for calendar entries that do not involve others there is no 'concept' of an Owner or Organizer as we call them in iCalendar.  Unfortunately at this time I do not recally why we chose to include this particular restriction (at least the latter half of it).  Perhaps we can nudge Frank Dawson or someone else whose equally long in the CalSched tooth to recall why.  (Im sure once mentioned Ill probably slap my forehad and say "Oh, of course!" but in the mean time Ill just scratch my head a bit...)

> Is there anything that we are missing out here?  Any inputs on this
> would really help.
You can define your own custom vendor extension (ie: X-ORCL-OWNER) and include it on all non-workflow entries.  For any workflow entities, ORGANIZER is what you want...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007870F885256B59_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 7 17:09:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11274 for ; Thu, 7 Feb 2002 17:09:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17LvkS05512 for ietf-calendar-bks; Thu, 7 Feb 2002 13:57:46 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Lvj305505 for ; Thu, 7 Feb 2002 13:57:45 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA26469 for ; Thu, 7 Feb 2002 16:57:42 -0500 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 g17LvfQ19118 for ; Thu, 7 Feb 2002 16:57:42 -0500 (EST) Message-ID: <3C62F8C4.C47A4D83@steltor.com> Date: Thu, 07 Feb 2002 16:59:32 -0500 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: CAP: VCAR Proposal (#2) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@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: > > > How shall we express "scope" in: > > > > The CARID itself MUST be a unique identifier within ??? > > How about? > > Any CALSTORE VCARS must be unique in the CALSTORE. > Any VCARs in the CALSTORE override any in all contained > VAGENDAs where the CARID are the same. > > Any VAGENDA VCARs must be unique in the VAGENDA. > Any VAGENDA VCARs override any in all contained components > where the CARID is the same in the VAGENDA. > > Any VCARs contained in any component must have unique CARIDs > with respect to any other VCAR in that component. > > This keeps the calendar owner from overriding any administrative > VCARs. And it keeps someone from depositing a REQUEST that > allows them to override the owners VCARs. > > And it also allows the administrator or implementation > to allow the calendar OWNERs to define the VCARs for their calendars > by not defining them at the CALSTORE level. As you said recently, we all need to keep each other from inventing new things at this point in time. :-) I would like to keep it simple and just say: The CARID MUST uniquely identify VCAR components within the components they are stored (i.e., VAGENDA or CALSTORE). Correct? > > > > You define PERMISSION in x.x.3.3.3 below as a TEXT value type. > > > A TEXT value type can have multiple values, separated > > > by commas. > > > > > > So this is also valid? If not, there needs to be > > > restrictions specified in the proposal. > > > > > > PERMISSION:READ,MODIFY > > > > The ABNF for PERMISSION does not allow this. > > I don't think I need to change anything. Have > > a look at the TRANSP property in RFC 2445. > > > > What you are saying is true for CATEGORIES, > > but not for PERMISSION and TRANSP. > > The TANSP property is defined as single instance in 2445 grammar > and the 2446 restriction tables as there is only one state > the value can be for any given component. > > The PERMISSION property is defined as multiple instance > in your proposal and each one is NOT declared in the > proposal as MUST BE be unique per component. > > Which is why I was asking - it is not clear to me if it is allowed. > And if it is not allowed - why not as it can be one of several > combination of values? It is not fixed to one state per component. > So why is it single value multiple instance, and not single instance > multiple value? Or multiple instance, multiple value like CATEGORIES? > > Is there are reason? It is clear that the current ABNF doesn't allow it. perm = "PERMISSION" permparam ":" permvalue CRLF permparam = *( ";" xparam ) permvalue = ( "READ" / "WRITE" / "DELETE" / "MODIFY" / all ) all = "*" The allow it the perm rule-part would need to be written as follow: perm = "PERMISSION" permparam ":" permvalue *( "," permvalue ) CRLF Do you have a problem with PERMISSION being single value multiple instance? > > How would that be different from the format that I've > > used to define "Value Type", "Calendar Component" and > > "Component Properties" in my proposal? > > It allows them to be valid as the right hand side > of the 'VALUE=" parameter. > > The 2445 registration procedure for new properties > specifies that they must be declared. I will 'declare' > CAL-QUERY value type (as you pointed out you did for UPN-FILTER). > > I'll rip it out or modify the CAP-QL proposal and make it a stand > alone section that explicitly declares it to be a new > value type. Good. I'll change my proposal to obey to RFC 2445 as well. I neglected to specify the following: To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property XXX > > > It only identifies VCARs and not 'any' component - correct? > > > > > > > Format Definition: The property is defined by the following notation: > > > > > > > > carid = "CARID" caridparam ":" text CRLF > > > > > > And BOOLEAN parameter 'DECREED' ? > > > > > > Or was that going to be a property? > > > > > > Or were we going to force the CUA to figure it out after > > > reading the VCARs? > > > > I'll add the DECREED property and I'll modify the > > restriction tables as follow: > > > > . . . . DECREED 0 This property is outside > > the scope of the protocol. > > > > Agree? > > I don't follow. I don't think so. > > You and others at Steltor have asked several times "how do > you know that it is DECREED". Are you now saying that > you don't want to define how to tell if it is decreed? :-) Here's the reason: > 2.4.2.2 Decreed VCARs > > ... > > The CAP protocol does not define the semantics used to initially > create a decreed VCAR. This administrative task is outside the scope > of the CAP protocol. Agree? > > If you are saying "you do not care", then no, we need to be > able to define the VCAR it in the VCAR itself that it is > read-only. That must be by adding another VRIGHTs component, > or by a 'DECREED' property - that is defined. > > > > > x.x.3.3 Right Component Properties > > > > > > > > x.x.3.3.1 Grant Component Property > > > > > > > > Property Name: GRANT > > > > > > > > Purpose: This property identifies the CU or UG being granted access > > > > in the VRIGHT component. > > > > > > Specifies the UPN subject to the upn-filters, > > > not the CU or UG - correct? The 'CU' is an entity that > > > may have multiple UPNs. > > > > Correct. > > So, I assume this means your going to update the text? :-) Of course! :-) "Purpose: This property identifies the UPN(s) being granted access in the VRIGHT component." UPN with "(s)" since "*@steltor.com" will identify many UPNs. > > > > > Can you agree that in order to make a VCAR decreed you > > ONLY have to specify DECREED:TRUE in the VCAR component? > > Yes - you need to add a new property definition with > a boolean value DECREED. I will. Regards, 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 Thu Feb 7 17:37:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11712 for ; Thu, 7 Feb 2002 17:37:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17MRrJ06365 for ietf-calendar-bks; Thu, 7 Feb 2002 14:27:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17MRq306360 for ; Thu, 7 Feb 2002 14:27:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA30120; Thu, 7 Feb 2002 17:27:48 -0500 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g17MRmQ23346; Thu, 7 Feb 2002 17:27:48 -0500 (EST) Message-Id: <5.1.0.14.0.20020207171104.02acbdd0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Feb 2002 17:31:11 -0500 To: Bruce_Kahn@notesdev.ibm.com, lata.kannan@oracle.com From: Alan Davies Subject: Re: Event owner in ICAL schema Cc: ietf-calendar@imc.org, prashantkumar.shetty@oracle.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:03 PM 07/02/2002 -0500, Bruce_Kahn@notesdev.ibm.com wrote: > However I think several folks have forgotten the text that describes the > ORGANIZER property. What they seemingly correclty suggested is actually > NOT allowed. > Conformance: This property MUST be specified in an iCalendar object > that specifies a group scheduled calendar entity. This property MUST > be specified in an iCalendar object that specifies the publication of > a calendar user's busy time. This property MUST NOT be specified in > an iCalendar object that specifies only a time zone definition or > that defines calendar entities that are not group scheduled entities, > but are entities only on a single user's calendar. > >(emphasis mine). So, as such for calendar entries that do not involve >others there is no 'concept' of an Owner or Organizer as we call them in >iCalendar. Unfortunately at this time I do not recally why we chose to >include this particular restriction (at least the latter half of >it). Perhaps we can nudge Frank Dawson or someone else whose equally long >in the CalSched tooth to recall why. (Im sure once mentioned Ill probably >slap my forehad and say "Oh, of course!" but in the mean time Ill just >scratch my head a bit...) That text is a very strange (it seems to contradict iTIP 3.2.1, which specifies that a PUBLISH must have an ORGANIZER, but must not have ATTENDEEs), but I don't see why our answers were so wrong unless Lata's original schema does not allow for group scheduling. When you say 'calendar entries that do not involve others' would the case of an entity where the ORGANIZER is the sole ATTENDEE count as involving others, which would therefore allow the ORGANIZER property to be present? Doug's reply about CAP and VAGENDAs seemed a more correct way to represent the concept of 'owner' in a schema, although the original question was about iCalendar alone. --Alan From owner-ietf-calendar@mail.imc.org Thu Feb 7 18:08:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12355 for ; Thu, 7 Feb 2002 18:08:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17Ms5706905 for ietf-calendar-bks; Thu, 7 Feb 2002 14:54:05 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Ms4306901 for ; Thu, 7 Feb 2002 14:54:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA25243 for ; Thu, 7 Feb 2002 14:54:05 -0800 (PST) Message-ID: <3C630586.122EEE4F@Royer.com> Date: Thu, 07 Feb 2002 15:53:58 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> Content-Type: multipart/mixed; boundary="------------642A306523BF6C85A60D8424" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------642A306523BF6C85A60D8424 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > I agree that there must be a way to specify that we > only want the VCARs that pertain to the authenticated > user to be returned. > > But I don't see why you think it will be easier to the > CUA to handle the following coalesced VCAR: > ... Fist I like the VRIGHTs vs the old VCAR model. It looks much more clean. My reply: As the order of VCARs is unspecified and the order they have been deposited into the CS in interminable: (1) Because for the predefined VCARs in a CAR-MIN CS, the second is not be defined in CAR-MIN, so the CUA would have NO way to ask for the second one so it MUST HAVE been specified in at least one of the predefined VCARS. Therefore a CUA must be able to query for this and it would have to come back in combined format in at the very least the predefined VCAR it came from. (2) Given these two VCARs that effect 'foo@host.com' BEGIN:VCAR CARID:XX BEGIN:VRIGHT GRANT:* PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VRIGHT END:VCAR BEGIN:VCAR CARID:YY BEGIN:VRIGHT DENY:foo@host.com PERMISSION:READ SCOPE:SELECT * FROM VEVENT WHERE UID = 'three' END:VRIGHT Now if you add multiple exceptions like (2) above, it seem to me that you are going to enter a undefinable race condition between which VCAR overrides which VCAR. But if they are in the same VCAR, then the entire set of GRANT/DENY is one block that is computed together. If you apply CARID:XX first, then apply CARID:YY then 'foo@host.com' does not have access to UID = 'three'. But if you were to apply UID:YY first then UID:XX, then 'foo@host.com' would have access to UID = 'three'. I don't see any option except to combine them so that one VCAR set is 'the access'. So, I don't think we can mandate they come back separately because for complex exceptions, the order of VCARs is specified in CAP to be insignificant (and it needs to be or we have another huge problem to solve). For this one example, a smart CS could return: BEGIN:VCAR CARID:XX BEGIN:VRIGHT GRANT:foo@host.com PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE UID != 'three' END:VRIGHT END:VCAR But that would require us to mandate that all CSs have what I will call "VCAR optimizers" - and I do not think that is going to happen. I thought of suggesting adding LAST-MODIFIED to VCARs and apply the VCARs in that order, but that will not allow a CUA to override decreed VCARs that would be part of the query result set. Resulting in the same problem, you have to be able to specify multiple VRIGHTS in the same VCAR so you do not have to guess out the correct order to apply VCARs that are by definition unordered. The CS only has to remember the VARs sent to it and be able to return them (non-COALESCED). However it has to apply them all at once (COALESCED) inside the CS. --------------642A306523BF6C85A60D8424 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 ; Thu, 7 Feb 2002 18:28:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17NIr907361 for ietf-calendar-bks; Thu, 7 Feb 2002 15:18:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17NIq307356 for ; Thu, 7 Feb 2002 15:18:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA25325 for ; Thu, 7 Feb 2002 15:18:54 -0800 (PST) Message-ID: <3C630B57.AB69F1A6@Royer.com> Date: Thu, 07 Feb 2002 16:18:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> Content-Type: multipart/mixed; boundary="------------FF875AC5D9C147170DBCD31E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FF875AC5D9C147170DBCD31E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Which is why I was asking - it is not clear to me if it is allowed. > > And if it is not allowed - why not as it can be one of several > > combination of values? It is not fixed to one state per component. > > So why is it single value multiple instance, and not single instance > > multiple value? Or multiple instance, multiple value like CATEGORIES? > > > > Is there are reason? > > It is clear that the current ABNF doesn't allow it. > > perm = "PERMISSION" permparam ":" permvalue CRLF > permparam = *( ";" xparam ) > permvalue = ( "READ" / "WRITE" / "DELETE" / "MODIFY" / all ) > all = "*" > > The allow it the perm rule-part would need to > be written as follow: > > perm = "PERMISSION" permparam ":" permvalue > *( "," permvalue ) CRLF > > Do you have a problem with PERMISSION being single > value multiple instance? My only problem is - why restrict it. it seems the perfect example of why 2445 allows multi valued properties. --------------FF875AC5D9C147170DBCD31E 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 ; Thu, 7 Feb 2002 18:31:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17NGhp07318 for ietf-calendar-bks; Thu, 7 Feb 2002 15:16:43 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17NGg307314 for ; Thu, 7 Feb 2002 15:16:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA25321 for ; Thu, 7 Feb 2002 15:16:43 -0800 (PST) Message-ID: <3C630AD4.4077BC1C@Royer.com> Date: Thu, 07 Feb 2002 16:16:36 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: CAP: VCAR Proposal (#2) - VCAR precedence order References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> Content-Type: multipart/mixed; boundary="------------76A280C0A4E04C91EC6E275F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------76A280C0A4E04C91EC6E275F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: >> >> How about? >> >> Any CALSTORE VCARS must be unique in the CALSTORE. >> Any VCARs in the CALSTORE override any in all contained >> VAGENDAs where the CARID are the same. >> >> Any VAGENDA VCARs must be unique in the VAGENDA. >> Any VAGENDA VCARs override any in all contained components >> where the CARID is the same in the VAGENDA. >> >> Any VCARs contained in any component must have unique CARIDs >> with respect to any other VCAR in that component. > > As you said recently, we all need to keep each other from > inventing new things at this point in time. :-) > > I would like to keep it simple and just say: > > The CARID MUST uniquely identify VCAR components within > the components they are stored (i.e., VAGENDA or CALSTORE). > > Correct? So who wins the access? If we don't specify it, one CS vendor may implement it one way, and another CS vendor the opposite way. I did not think I was inventing anything, just defining what I think is the only precedence order that will work. Other implementation may disagree - then we do not have interoperability. --------------76A280C0A4E04C91EC6E275F 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 ; Thu, 7 Feb 2002 18:32:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17NLL807411 for ietf-calendar-bks; Thu, 7 Feb 2002 15:21:21 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17NLK307407 for ; Thu, 7 Feb 2002 15:21:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA25329 for ; Thu, 7 Feb 2002 15:21:22 -0800 (PST) Message-ID: <3C630BEB.2190AF9F@Royer.com> Date: Thu, 07 Feb 2002 16:21:15 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - DECREED defined? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> Content-Type: multipart/mixed; boundary="------------D74C7F89CC51475A303F5DAC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D74C7F89CC51475A303F5DAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > reading the VCARs? > > > > > > I'll add the DECREED property and I'll modify the > > > restriction tables as follow: > > > > > > . . . . DECREED 0 This property is outside > > > the scope of the protocol. > > > > > > Agree? > > > > I don't follow. I don't think so. > > > > You and others at Steltor have asked several times "how do > > you know that it is DECREED". Are you now saying that > > you don't want to define how to tell if it is decreed? > > :-) Here's the reason: > > > 2.4.2.2 Decreed VCARs > > > > ... > > > > The CAP protocol does not define the semantics used to initially > > create a decreed VCAR. This administrative task is outside the > > scope of the CAP protocol. > > Agree? Did (in your original email) means that that would only apply the above limitation to the command? If so, I misunderstood. --------------D74C7F89CC51475A303F5DAC 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 ; Thu, 7 Feb 2002 18:33:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17NNSI07448 for ietf-calendar-bks; Thu, 7 Feb 2002 15:23:28 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17NNR307443 for ; Thu, 7 Feb 2002 15:23:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA25338 for ; Thu, 7 Feb 2002 15:23:28 -0800 (PST) Message-ID: <3C630C69.241D79D3@Royer.com> Date: Thu, 07 Feb 2002 16:23:21 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - VRIGHS text (UPN) vs (UPNs) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> Content-Type: multipart/mixed; boundary="------------640D1EC56B49A7DF8D0CF368" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------640D1EC56B49A7DF8D0CF368 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > "Purpose: This property identifies the UPN(s) being granted access > in the VRIGHT component." > > UPN with "(s)" since "*@steltor.com" will identify many UPNs. Yes. --------------640D1EC56B49A7DF8D0CF368 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 ; Thu, 7 Feb 2002 18:38:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17NRuF07523 for ietf-calendar-bks; Thu, 7 Feb 2002 15:27:56 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17NRt307518 for ; Thu, 7 Feb 2002 15:27:55 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA25346; Thu, 7 Feb 2002 15:27:55 -0800 (PST) Message-ID: <3C630D74.721AD855@Royer.com> Date: Thu, 07 Feb 2002 16:27:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: lata.kannan@oracle.com, ietf-calendar@imc.org, prashantkumar.shetty@oracle.com Subject: Re: Event owner in ICAL schema References: Content-Type: multipart/mixed; boundary="------------FE32041AD1B6B5DD0A012E16" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FE32041AD1B6B5DD0A012E16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > (emphasis mine). So, as such for calendar entries that do not involve > others there is no 'concept' of an Owner or Organizer as we call them > in iCalendar. Unfortunately at this time I do not recally why we > chose to include this particular restriction (at least the latter half > of it). Perhaps we can nudge Frank Dawson or someone else whose > equally long in the CalSched tooth to recall why. (Im sure once > mentioned Ill probably slap my forehad and say "Oh, of course!" but in > the mean time Ill just scratch my head a bit...) Because ORGANIZER is a scheduling thing, and no one is going to own the contents of a VTIMEZONE. And because the owner of non-iTIP objects is dependent on who stores it in CAP. If I give you a copy of VTIMEZONE for Pacific (US) time, do you or I own it? > You can define your own custom vendor extension (ie: X-ORCL-OWNER) and > include it on all non-workflow entries. For any workflow entities, > ORGANIZER is what you want... By workflow - your mean scheduling as defined by iTIP? --------------FE32041AD1B6B5DD0A012E16 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 ; Thu, 7 Feb 2002 18:55:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g17NewH07811 for ietf-calendar-bks; Thu, 7 Feb 2002 15:40:58 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Neu307806 for ; Thu, 7 Feb 2002 15:40:56 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA25370; Thu, 7 Feb 2002 15:40:57 -0800 (PST) Message-ID: <3C631082.D8CFEC9A@Royer.com> Date: Thu, 07 Feb 2002 16:40:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: lata.kannan@oracle.com, prashantkumar.shetty@oracle.com Subject: Re: Event owner in ICAL schema References: <5.1.0.14.0.20020207171104.02acbdd0@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------BF6DDA6D9938D46040563248" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BF6DDA6D9938D46040563248 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > That text is a very strange (it seems to contradict iTIP 3.2.1, which > specifies that a PUBLISH must have an ORGANIZER, but must not have > ATTENDEEs), but I don't see why our answers were so wrong unless > Lata's original schema does not allow for group scheduling. A PUBLISH is a public announcement of a open calendar object. So you are thinking group only means 'group of named people'. It also means an object where a group of people have access and the members of that group are unknown - PUBLISH. As in it is not privately held. The last part of the 'Conformance:' section of: 4.8.4.3 Organizer ...This property MUST NOT be specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but are entities only on a single user's calendar. PUBLISH is clearly not just for one users calendar. I do not see a contradiction? Or did I miss your point? > When you say 'calendar entries that do not involve others' would the > case of an entity where the ORGANIZER is the sole ATTENDEE count > as involving others, which would therefore allow the ORGANIZER property > to be present? If the object is private to the user calendar and will NOT be distributed to anyone else - that is outside the scope of all of iCalendar, iTIP, iMIP, and CAP - as there would not be a need for interoperability. So if that is the case, the X-property's would be how to deal with that. And the CUA or CS would never distribute it with standard protocols? --------------BF6DDA6D9938D46040563248 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 ; Thu, 7 Feb 2002 20:58:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g181kAY11734 for ietf-calendar-bks; Thu, 7 Feb 2002 17:46:10 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g181k9311730 for ; Thu, 7 Feb 2002 17:46:09 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id UAA32572 for ; Thu, 7 Feb 2002 20:46:07 -0500 Received: from steltor.com ([101.0.0.2]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g181k4Q11695 for ; Thu, 7 Feb 2002 20:46:06 -0500 (EST) Message-ID: <3C632E42.DB6BBFFA@steltor.com> Date: Thu, 07 Feb 2002 20:47:46 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - VCAR precedence order References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630AD4.4077BC1C@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: > > > > Doug Royer wrote: > >> > >> How about? > >> > >> Any CALSTORE VCARS must be unique in the CALSTORE. > >> Any VCARs in the CALSTORE override any in all contained > >> VAGENDAs where the CARID are the same. > >> > >> Any VAGENDA VCARs must be unique in the VAGENDA. > >> Any VAGENDA VCARs override any in all contained components > >> where the CARID is the same in the VAGENDA. > >> > >> Any VCARs contained in any component must have unique CARIDs > >> with respect to any other VCAR in that component. > > > > As you said recently, we all need to keep each other from > > inventing new things at this point in time. :-) > > > > I would like to keep it simple and just say: > > > > The CARID MUST uniquely identify VCAR components within > > the components they are stored (i.e., VAGENDA or CALSTORE). > > > > Correct? > > So who wins the access? If we don't specify it, one CS vendor > may implement it one way, and another CS vendor > the opposite way. > > I did not think I was inventing anything, just defining > what I think is the only precedence order that will work. > Other implementation may disagree - then we do not > have interoperability. Recently, this WG has agreed to drop VCAR inheritance. We should not introduce new rules at this time to specify that VCARs in the CALSTORE can override VCARs in VAGENDAs if they have the same CARID. By doing so CUA would need to worry about the CARIDs in use in the CALSTORE. It would no longer be true that CARID only need to be unique within VAGENDAs. We just need to write a statement to say that all the VCARs stored in a VAGENDA MUST have different CARID, and that all the VCARs stored in the CALSTORE MUST have a different CARID. Regards, 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 Thu Feb 7 21:36:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17243 for ; Thu, 7 Feb 2002 21:36:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g182QsH12784 for ietf-calendar-bks; Thu, 7 Feb 2002 18:26:54 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g182Qq312780 for ; Thu, 7 Feb 2002 18:26:53 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id VAA00010 for ; Thu, 7 Feb 2002 21:26:51 -0500 Received: from steltor.com ([101.0.0.2]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g182QkQ14842 for ; Thu, 7 Feb 2002 21:26:47 -0500 (EST) Message-ID: <3C6337CD.94387F22@steltor.com> Date: Thu, 07 Feb 2002 21:28:29 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: VCAR Proposal (#2) - DECREED defined? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630BEB.2190AF9F@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: > > Did (in your original email) means that that would only > apply the above limitation to the command? If so, > I misunderstood. Decreed VCARs are persistent and immutable. That means you won't be able to , and them with the CAP protocol. Right? Regards, 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 Thu Feb 7 22:01:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17572 for ; Thu, 7 Feb 2002 22:01:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g182kgi13208 for ietf-calendar-bks; Thu, 7 Feb 2002 18:46:42 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g182kf313204 for ; Thu, 7 Feb 2002 18:46:41 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA25602 for ; Thu, 7 Feb 2002 18:46:43 -0800 (PST) Message-ID: <3C633C0A.37CFBA82@Royer.com> Date: Thu, 07 Feb 2002 19:46:34 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - VCAR precedence order References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630AD4.4077BC1C@Royer.com> <3C632E42.DB6BBFFA@steltor.com> Content-Type: multipart/mixed; boundary="------------8394D66B69C5832E317E177E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8394D66B69C5832E317E177E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > > > > I would like to keep it simple and just say: > > > > > > The CARID MUST uniquely identify VCAR components within > > > the components they are stored (i.e., VAGENDA or CALSTORE). > > > > > > Correct? > > > > So who wins the access? If we don't specify it, one CS vendor > > may implement it one way, and another CS vendor > > the opposite way. > > (What I had proposed was not VCAR inheritance, it was VCAR precedence which is not the same issue). > We just need to write a statement to say that all the VCARs > stored in a VAGENDA MUST have different CARID, and that all > the VCARs stored in the CALSTORE MUST have a different CARID. I hope you mean that: 2 or more VAGENDAs may have the same CARID as long as that CARID does not exist in the CALSTORE? And I could live with that. It means that the precedence between the CALSTORE and all VAGENDAs is that the first one to use CARID - wins. The other gets an error. And that two or more VAGENDAs may have the same CARID. Agree? --------------8394D66B69C5832E317E177E 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 ; Thu, 7 Feb 2002 22:07:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g182wms13444 for ietf-calendar-bks; Thu, 7 Feb 2002 18:58:48 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g182wl313440 for ; Thu, 7 Feb 2002 18:58:47 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA25626 for ; Thu, 7 Feb 2002 18:58:49 -0800 (PST) Message-ID: <3C633EE0.6E78D14A@Royer.com> Date: Thu, 07 Feb 2002 19:58:40 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - DECREED defined? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630BEB.2190AF9F@Royer.com> <3C6337CD.94387F22@steltor.com> Content-Type: multipart/mixed; boundary="------------F1C0ADE8F76F795DB9C132A3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F1C0ADE8F76F795DB9C132A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > reading the VCARs? > > > > > > I'll add the DECREED property and I'll modify the > > > restriction tables as follow: > > > > > > . . . . DECREED 0 This property is outside > > > the scope of the protocol. > > > > > > Agree? > > > > I don't follow. I don't think so. Later: > Doug Royer wrote: > > > > Did (in your original email) means that that would only > > apply the above limitation to the command? If so, > > I misunderstood. > > Decreed VCARs are persistent and immutable. > > That means you won't be able to > , and them with > the CAP protocol. Right? So what does the above apply to? I am lost as to what you will add the DECREED property to - which restriction table - you are saying all? . . . . DECREED 0 This property is outside the scope of the protocol. --------------F1C0ADE8F76F795DB9C132A3 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 ; Thu, 7 Feb 2002 22:15:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18335K13545 for ietf-calendar-bks; Thu, 7 Feb 2002 19:03:05 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18334313541 for ; Thu, 7 Feb 2002 19:03:04 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id WAA00250 for ; Thu, 7 Feb 2002 22:03:03 -0500 Received: from steltor.com ([101.0.0.2]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1832xQ17678 for ; Thu, 7 Feb 2002 22:02:59 -0500 (EST) Message-ID: <3C634049.1763CEB6@steltor.com> Date: Thu, 07 Feb 2002 22:04:41 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@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: > > > > I agree that there must be a way to specify that we > > only want the VCARs that pertain to the authenticated > > user to be returned. > > > > But I don't see why you think it will be easier to the > > CUA to handle the following coalesced VCAR: > > ... > > Fist I like the VRIGHTs vs the old VCAR model. It looks > much more clean. :-) > > My reply: > > As the order of VCARs is unspecified and the order they > have been deposited into the CS in interminable: > > (1) Because for the predefined VCARs in a CAR-MIN CS, the second > is not be defined in CAR-MIN, so the CUA would have NO way to ask > for the second one so it MUST HAVE been specified in at least > one of the predefined VCARS. Therefore a CUA must be able to > query for this and it would have to come back in combined format > in at the very least the predefined VCAR it came from. Sorry. I've read this paragraph multiple times and I still can't make sense out of it. Perhaps you can reformulate it. :-( > > (2) Given these two VCARs that effect 'foo@host.com' > > BEGIN:VCAR > CARID:XX > BEGIN:VRIGHT > GRANT:* > PERMISSION:READ > SCOPE:SELECT DTSTART,DTEND FROM VEVENT > END:VRIGHT > END:VCAR > > BEGIN:VCAR > CARID:YY > BEGIN:VRIGHT > DENY:foo@host.com > PERMISSION:READ > SCOPE:SELECT * FROM VEVENT WHERE UID = 'three' > END:VRIGHT > > Now if you add multiple exceptions like (2) above, > it seem to me that you are going to enter a undefinable > race condition between which VCAR overrides which VCAR. > But if they are in the same VCAR, then the entire set > of GRANT/DENY is one block that is computed together. > > If you apply CARID:XX first, then apply CARID:YY > then 'foo@host.com' does not have access to UID = 'three'. > > But if you were to apply UID:YY first then UID:XX, > then 'foo@host.com' would have access to UID = 'three'. > > I don't see any option except to combine them so that one > VCAR set is 'the access'. There is no ambiguity here. CAP is clear: The access for a particular UPN is the union of all grants for that UPN minus the union of its denies. So you compute the union of all the GRANTs of all the VCARs and then subtract the union of all the DENYs of all the VCARs. Precedence is most certainly NOT a reason to group multiple VRIGHT in a single VCAR. The VRIGHT component was introduced to allow multiple rights (VRIGHT) to share the same CARID. > So, I don't think we can mandate they come back separately because > for complex exceptions, the order of VCARs is specified in CAP > to be insignificant (and it needs to be or we have another > huge problem to solve). > > For this one example, a smart CS could return: > > BEGIN:VCAR > CARID:XX > BEGIN:VRIGHT > GRANT:foo@host.com > PERMISSION:READ > SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE UID != 'three' > END:VRIGHT > END:VCAR > > But that would require us to mandate that all CSs have > what I will call "VCAR optimizers" - and I do not think > that is going to happen. Yep! It's not gonna happen! :-) Now that you know that we don't have problems with precedence. Do you still think we need a way to return ALL VRIGHTs in a single VCAR? I still can't see why we would need it. Regards, 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 Thu Feb 7 22:29:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17906 for ; Thu, 7 Feb 2002 22:29:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g183LTD13958 for ietf-calendar-bks; Thu, 7 Feb 2002 19:21:29 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g183LS313954 for ; Thu, 7 Feb 2002 19:21:28 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id WAA00397 for ; Thu, 7 Feb 2002 22:21:26 -0500 Received: from steltor.com ([101.0.0.2]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g183LQQ19299 for ; Thu, 7 Feb 2002 22:21:26 -0500 (EST) Message-ID: <3C63449C.5854245A@steltor.com> Date: Thu, 07 Feb 2002 22:23:08 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - VCAR precedence order References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630AD4.4077BC1C@Royer.com> <3C632E42.DB6BBFFA@steltor.com> <3C633C0A.37CFBA82@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: > > > We just need to write a statement to say that all the VCARs > > stored in a VAGENDA MUST have different CARID, and that all > > the VCARs stored in the CALSTORE MUST have a different CARID. > > I hope you mean that: > > 2 or more VAGENDAs may have the same CARID as long > as that CARID does not exist in the CALSTORE? No. The VCARs stored in the CALSTORE don't have any impact on the VCARs stored VAGENDAs. > > And I could live with that. It means that the precedence > between the CALSTORE and all VAGENDAs is that the first one > to use CARID - wins. The other gets an error. And that two or > more VAGENDAs may have the same CARID. 1- We don't need that. The DEFAULT-VCARS will be copied in each VAGENDA at creation time, and if the administrator wants to override VCARs in VAGENDA he'll simply have to set the VCARs in the VAGENDAs to deny users the right to modify them. 2- By doing so, an administrator could screw up all my access rights if he creates a VCAR with the same CARID as mine by accident. I'm sure nobody wants that. Again, let's keep it simple. We did away with VCAR inheritance. Let's not add back any more complexity. Regards, 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 Feb 8 01:37:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21451 for ; Fri, 8 Feb 2002 01:37:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g186R8N19001 for ietf-calendar-bks; Thu, 7 Feb 2002 22:27:08 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g186R7318997 for ; Thu, 7 Feb 2002 22:27:07 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g186R5704998 for ; Thu, 7 Feb 2002 22:27:05 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GR7B9500.JJ3 for ; Thu, 7 Feb 2002 22:27:05 -0800 Message-ID: <3C636FAC.5709379E@netscape.com> Date: Thu, 07 Feb 2002 22:26:52 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP Consensus Content-Type: multipart/mixed; boundary="------------8296DB6BDEA3806BA971056A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8296DB6BDEA3806BA971056A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, We have several open issues on CAP. We need to reach consensus on the resolutions to these issues so that we can bring the CAP draft to working group last call by IETF 53. The editors will send out proposals for the resolutions between now and Feb 14 so that you'll have time to review them. "CAP Consensus:" will appear in the subject line of these proposals so that you can easily spot them. If there's consensus on the proposals, it needs to be clear to our chairs (Pat and Bob). So please post your support or dissent to the list. Don't assume that silence means assent. We need all your feedback by the Feb 22 so that the editors will have time to get the typing done on the CAP draft. We're not suggesting that consensus will be forced by Feb 22. We're simply emphasizing that in order to get to last call by IETF 53, we need consensus on all the issues by then. We've been working on CAP to a long time and we're almost there. Please help us by actively participating in resolving the remaining issues. -Steve --------------8296DB6BDEA3806BA971056A Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650.937.3351 x-mozilla-html:FALSE org:Netscape adr:;;;;;; version:2.1 title:Director of Engineering fn:Steve Mansour end:vcard --------------8296DB6BDEA3806BA971056A-- From owner-ietf-calendar@mail.imc.org Fri Feb 8 09:26:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07676 for ; Fri, 8 Feb 2002 09:26:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18EDpw06341 for ietf-calendar-bks; Fri, 8 Feb 2002 06:13:51 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18EDo306337 for ; Fri, 8 Feb 2002 06:13:50 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA05838 for ; Fri, 8 Feb 2002 09:13:46 -0500 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 g18EDjQ13059 for ; Fri, 8 Feb 2002 09:13:45 -0500 (EST) Message-ID: <3C63DD89.2BEE1A2D@steltor.com> Date: Fri, 08 Feb 2002 09:15:37 -0500 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: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@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: > > > Do you have a problem with PERMISSION being single > > value multiple instance? > > My only problem is - why restrict it. it seems the > perfect example of why 2445 allows multi valued properties. A property doesn't need to be both multiple instances and multiple values. Furthermore, with multiple instances, multiple values properties you can specify the same thing in different ways that may lead to different results in some situations. For instance, given the following CAL-QUERY values: 1- SELECT perm FROM VCAR USING_PROPERTIES PERMISSION perm WHERE perm = 'READ' 2- SELECT perm FROM VCAR USING_PROPERTIES PERMISSION perm WHERE 'READ' IN perm What would be returned for: a) PERMISSION:READ,WRITE 1- Nothing! 2- PERMISSION:READ,WRITE b) PERMISSION:READ PERMISSION:WRITE 1- PERMISSION:READ 2- PERMISSION:READ If you agree with my results, do you think it is desirable that we get different results? If you disagree with my results, why bother and not use single value multiple instances? Regards, 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 Feb 8 09:43:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08308 for ; Fri, 8 Feb 2002 09:43:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18ET9g06612 for ietf-calendar-bks; Fri, 8 Feb 2002 06:29:09 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18ET7306608 for ; Fri, 8 Feb 2002 06:29:08 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: Event owner in ICAL schema MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 8 Feb 2002 09:36:34 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/08/2002 09:36:52 AM, Serialize complete at 02/08/2002 09:36:52 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >If the object is private to the user calendar and will NOT be >distributed to anyone else Yeah, but consider what happens if the object is modified to invite someone. It seems sort of, mmm, non-orthogonal, to say that you MUST add the ORGANIZER when the first person is invited, and remove it when the last invitee is removed. Why not have ORGANIZER on it all the time? >that is outside the scope of all >of iCalendar, iTIP, iMIP, and CAP - as there would not be a >need for interoperability. Not necessarily; you might use iCalendar format to export it to another CUA for the same CU. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |The problem with any unwritten law is that you don't know where| |to go to erase it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 8 10:37:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11514 for ; Fri, 8 Feb 2002 10:37:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18FG0L09347 for ietf-calendar-bks; Fri, 8 Feb 2002 07:16:00 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18FFw309340 for ; Fri, 8 Feb 2002 07:15:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA08152 for ; Fri, 8 Feb 2002 10:15:54 -0500 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 g18FFrQ21184 for ; Fri, 8 Feb 2002 10:15:53 -0500 (EST) Message-ID: <3C63EC19.63817103@steltor.com> Date: Fri, 08 Feb 2002 10:17:45 -0500 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: CAP: VCAR Proposal (#2) - DECREED defined? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630BEB.2190AF9F@Royer.com> <3C6337CD.94387F22@steltor.com> <3C633EE0.6E78D14A@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: > > > > > > reading the VCARs? > > > > > > > > I'll add the DECREED property and I'll modify the > > > > restriction tables as follow: > > > > > > > > . . . . DECREED 0 This property is outside > > > > the scope of the protocol. > > > > > > > > Agree? > > > > > > I don't follow. I don't think so. > > Later: > > > Doug Royer wrote: > > > > > > Did (in your original email) means that that would only > > > apply the above limitation to the command? If so, > > > I misunderstood. > > > > Decreed VCARs are persistent and immutable. > > > > That means you won't be able to > > , and them with > > the CAP protocol. Right? > > So what does the above apply to? I am lost as to what you will > add the DECREED property to - which restriction table - you > are saying all? > > . . . . DECREED 0 This property is outside > the scope of the protocol. Actually, we only need to specify this in the restriction table of the "create" command (section 6.2.4.1) since the following is specified for the "modify" command: > The modifications MUST only be applied if the > resulting component respects the restriction > table of the "create" command. Agreed? Regards, 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 Feb 8 10:45:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12005 for ; Fri, 8 Feb 2002 10:45:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18FPfN10698 for ietf-calendar-bks; Fri, 8 Feb 2002 07:25:41 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18FPd310694 for ; Fri, 8 Feb 2002 07:25:39 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA08506 for ; Fri, 8 Feb 2002 10:25:35 -0500 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 g18FPYQ22445 for ; Fri, 8 Feb 2002 10:25:34 -0500 (EST) Message-ID: <3C63EE5E.D560379D@steltor.com> Date: Fri, 08 Feb 2002 10:27:26 -0500 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: CAP: RESOLUTION: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BD79.5F37EF52@steltor.com> <3C62CCAE.5B73E250@Royer.com> <3C62D87E.5A53AA72@steltor.com> <3C62E562.8C010A5@Royer.com> <3C62EC27.A65AA059@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 Just to make sure we are all on the same page. We agreed to: - Remove function CONTAINS() ; - Add operator IN ; - Add function CAL-OWNERS( CAL-ADDRESS ) - Add function CURRENT-CALID() ; - Add function SELF() ; That is, previously discussed functions OWNER() and NONOWNER() will NOT be added to CAP-QL. Regards, 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 Feb 8 10:49:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12203 for ; Fri, 8 Feb 2002 10:49:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18FSw310854 for ietf-calendar-bks; Fri, 8 Feb 2002 07:28:58 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18FSv310850 for ; Fri, 8 Feb 2002 07:28:57 -0800 (PST) To: Alan Davies Cc: lata.kannan@oracle.com, prashantkumar.shetty@oracle.com, ietf-calendar@imc.org Subject: Re: Event owner in ICAL schema MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 8 Feb 2002 10:27:52 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/08/2002 10:27:56 AM, Serialize complete at 02/08/2002 10:27:56 AM Content-Type: multipart/alternative; boundary="=_alternative 0054F73285256B5A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054F73285256B5A_= Content-Type: text/plain; charset="US-ASCII" Alan Davies wrote on 02/07/2002 05:31:11 PM: > That text is a very strange (it seems to contradict iTIP 3.2.1, which > specifies that a PUBLISH must have an ORGANIZER, but must not have > ATTENDEEs), but I don't see why our answers were so wrong unless > Lata's original schema does not allow for group scheduling. Guess I was not clear enough so Ill try again. There is NO contradiction w/iTIP since by PUBLISHing the entity it no longer exists in a single calendar! As such, ORGANIZER is allowed in that case. For the simple case of just creating an Appointment in my calendar, it only exists in a single users calendar (mine) and as such has no ORGANIZER. Also I guess you didnt read far enough down my 1st reply. I said "For any workflow entities, ORGANIZER is what you want... ". Workflow entities means group scheduling (or other non-single user activity). > When you say 'calendar entries that do not involve others' would the > case of an entity where the ORGANIZER is the sole ATTENDEE count > as involving others, which would therefore allow the ORGANIZER property > to be present? I think you are mixing up the use of ORGANIZER and ATTENDEE. If you create an appointment on your calendar that does not involve doing any workflow (or PUBLISHing which is unidirectional workflow) then I have no ORGANIZER; no matter the number of ATTENDEE properties. Is that no clear from the cited text?? I MAY have 1 or more ATTENDEE properties but we never spec'd out that it MUST be there since its never going outside the calendar then ATTENDEE is not really necessary in all cases. There are valid cases where you may have ATTENDEEs for non-workflow entries (just think a bit, you will find some). > Doug's reply about CAP and VAGENDAs seemed a more correct > way to represent the concept of 'owner' in a schema, although the > original question was about iCalendar alone. Just to be 110% clear on this: My response said (and still is) that for non-workflow entries ORGANIZER is NOT allowed! For workflow entries ORGANIZER _IS_ the way to go. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0054F73285256B5A_= Content-Type: text/html; charset="US-ASCII"
Alan Davies wrote on 02/07/2002 05:31:11 PM:
> That text is a very strange (it seems to contradict iTIP 3.2.1, which
> specifies that a PUBLISH must have an ORGANIZER, but must not have
> ATTENDEEs), but I don't see why our answers were so wrong unless
> Lata's original schema does not allow for group scheduling.
Guess I was not clear enough so Ill try again.  There is NO contradiction w/iTIP since by PUBLISHing the entity it no longer exists in a single calendar!  As such, ORGANIZER is allowed in that case.  For the simple case of just creating an Appointment in my calendar, it only exists in a single users calendar (mine) and as such has no ORGANIZER.

Also I guess you didnt read far enough down my 1st reply.  I said "For any workflow entities, ORGANIZER is what you want... ".  Workflow entities means group scheduling (or other non-single user activity).

> When you say 'calendar entries that do not involve others' would the
> case of an entity where the ORGANIZER is the sole ATTENDEE count
> as involving others, which would therefore allow the ORGANIZER property
> to be present?
I think you are mixing up the use of ORGANIZER and ATTENDEE.  If you create an appointment on your calendar that does not involve doing any workflow (or PUBLISHing which is unidirectional workflow) then I have no ORGANIZER; no matter the number of ATTENDEE properties.  Is that no clear from the cited text??

I MAY have 1 or more ATTENDEE properties but we never spec'd out that it MUST be there since its never going outside the calendar then ATTENDEE is not really necessary in all cases.  There are valid cases where you may have ATTENDEEs for non-workflow entries (just think a bit, you will find some).

> Doug's reply about CAP and VAGENDAs seemed a more correct
> way to represent the concept of 'owner' in a schema, although the
> original question was about iCalendar alone.
Just to be 110% clear on this: My response said (and still is) that for non-workflow entries ORGANIZER is NOT allowed!  For workflow entries ORGANIZER _IS_ the way to go.  

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


--=_alternative 0054F73285256B5A_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 8 11:01:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12671 for ; Fri, 8 Feb 2002 11:01:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18FkbJ11229 for ietf-calendar-bks; Fri, 8 Feb 2002 07:46:37 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18Fka311219 for ; Fri, 8 Feb 2002 07:46:36 -0800 (PST) To: ietf-calendar@imc.org Cc: lata.kannan@oracle.com, prashantkumar.shetty@oracle.com Subject: Re: Event owner in ICAL schema MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 8 Feb 2002 10:43:53 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/08/2002 10:45:35 AM, Serialize complete at 02/08/2002 10:45:35 AM Content-Type: multipart/alternative; boundary="=_alternative 00566EC485256B5A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00566EC485256B5A_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 02/07/2002 06:27:48 PM: > Because ORGANIZER is a scheduling thing, and no one > is going to own the contents of a VTIMEZONE. Sigh! I think everyone has started to loose sight of some definitions of iCalendar properties. In RFC 2445 we designed ORGANIZER to be the focal point of all scheduling workflow (by definition calendaring has NO workflow). As such, if I have an entry on my calendar that is not involved in workflow then it can have NO ORGANIZER. Is that so hard to grok?? I think you are treating ORGANIZER as "Owner" of an entry and that is NOT what it is designed for. If there is no workflow involved, then the CU who created it is the "Owner". It could be argued that in the case of an AA creating entries on a calendar in something like CAP that the "Owner" is the CU whose calendar it is, not whose actually creating the entry. ("Sue, set up a meeting for me and Doug tomorrow afternoon to discuss IETF stuff...") That however is NOT was was originally asked so you wandered afield (and workflow is involved in my example). WRT to CAP we have yet to actually cover this (at least from what Ive scanned) but in direct answer to Lata's query the answers given were wrong. Thats not my opinion, its RFC 2445 talking. > And because the owner of non-iTIP objects is dependent > on who stores it in CAP. If I give you a copy of VTIMEZONE > for Pacific (US) time, do you or I own it? Digress all you like but it was not what Lata asked about... > > You can define your own custom vendor extension (ie: X-ORCL-OWNER) and > > include it on all non-workflow entries. For any workflow entities, > > ORGANIZER is what you want... > > By workflow - your mean scheduling as defined by iTIP? You know what workflow is but if you need a refresher, may I suggest skimming the RFCs again... Any other definition is not what we've used in this WG and cannot be used safely as a basis for discussion. Just to be sure folks hear Ill say it again: For cases where workflow is involved, ORGANIZER _IS_ the way to go. For cases where no workflow is involves, ORGANIZER _IS NOT_ allowed! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00566EC485256B5A_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 02/07/2002 06:27:48 PM:
> Because ORGANIZER is a scheduling thing, and no one
> is going to own the contents of a VTIMEZONE.
Sigh!  I think everyone has started to loose sight of some definitions of iCalendar properties.

In RFC 2445 we designed ORGANIZER to be the focal point of all scheduling workflow (by definition calendaring has NO workflow).  As such, if I have an entry on my calendar that is not involved in workflow then it can have NO ORGANIZER.  Is that so hard to grok??

I think you are treating ORGANIZER as "Owner" of an entry and that is NOT what it is designed for.  If there is no workflow involved, then the CU who created it is the "Owner".  It could be argued that in the case of an AA creating entries on a calendar in something like CAP that the "Owner" is the CU whose calendar it is, not whose actually creating the entry.  ("Sue, set up a meeting for me and Doug tomorrow afternoon to discuss IETF stuff...")  That however is NOT was was originally asked so you wandered afield (and workflow is involved in my example).

WRT to CAP we have yet to actually cover this (at least from what Ive scanned) but in direct answer to Lata's query the answers given were wrong.  Thats not my opinion, its RFC 2445 talking.  

> And because the owner of non-iTIP objects is dependent
> on who stores it in CAP. If I give you a copy of VTIMEZONE
> for Pacific (US) time, do you or I own it?
Digress all you like but it was not what Lata asked about...

> > You can define your own custom vendor extension (ie: X-ORCL-OWNER) and
> > include it on all non-workflow entries.  For any workflow entities,
> > ORGANIZER is what you want...
>
> By workflow - your mean scheduling as defined by iTIP?

You know what workflow is but if you need a refresher, may I suggest skimming the RFCs again...  Any other definition is not what we've used in this WG and cannot be used safely as a basis for discussion.

Just to be sure folks hear Ill say it again:  For cases where workflow is involved, ORGANIZER _IS_ the way to go.  For cases where no workflow is involves, ORGANIZER _IS NOT_ allowed!

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

--=_alternative 00566EC485256B5A_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 8 12:16:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15511 for ; Fri, 8 Feb 2002 12:16:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18GwaV13043 for ietf-calendar-bks; Fri, 8 Feb 2002 08:58:36 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18GwZ313039 for ; Fri, 8 Feb 2002 08:58:35 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA12187 for ; Fri, 8 Feb 2002 11:58:32 -0500 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 g18GwVQ05456 for ; Fri, 8 Feb 2002 11:58:31 -0500 (EST) Message-ID: <3C640427.1EC67779@steltor.com> Date: Fri, 08 Feb 2002 12:00:23 -0500 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: CAP: Multiple OWNER in VAGENDA? (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BEF6.5CB5C89D@steltor.com> <3C62CF4F.3D1A8B62@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: > > > > You are correct. OWNER is currently 1+ in the draft. > > > > Did this WG thought through the issues involved with > > allowing multiple owners? > > Yes, it was changed to a multi-instances, single value in 05 > or earlier. (this text from 06) > > OWNER N URI A multi-instanced property > indicating the calendar owner. > Each entry returned will be a > UPN. There must be at least one > owner. > > > Since we invite calendars and not users, only one owner > > can (need to) reply to an invitation? > > Also [iTIP] 2.1.3 Acting on Behalf of other Calendar Users > > ...Second, a "sent-by" parameter may be specified in either the > "Organizer" or "Attendee" properties. When specified, the "sent-by" > parameter indicates that the responding CU acted on behalf of the > specified "Attendee" or "Organizer". > > So you can have your assistant be able to connect to your > calendar and REPLY for you - and they do not need to be an OWNER > of your calendar. Do you mean that we DON'T need multiple OWNER for that reason? Beside, given that you could set your VCARs to grant others the rights to fully manage your VAGENDA do we really need multiple OWNERs in VAGENDA? I would say no. Regards, 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 Feb 8 13:56:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19388 for ; Fri, 8 Feb 2002 13:56:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18Ij7V15844 for ietf-calendar-bks; Fri, 8 Feb 2002 10:45:07 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18Ij6315840 for ; Fri, 8 Feb 2002 10:45:06 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA26775 for ; Fri, 8 Feb 2002 10:45:06 -0800 (PST) Message-ID: <3C641CAE.EC953B3E@Royer.com> Date: Fri, 08 Feb 2002 11:45:02 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> Content-Type: multipart/mixed; boundary="------------C9E430A649EA57EA5B90CF81" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C9E430A649EA57EA5B90CF81 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > My reply: > > > > As the order of VCARs is unspecified and the order they > > have been deposited into the CS in interminable: > > > > (1) Because for the predefined VCARs in a CAR-MIN CS, the second > > is not be defined in CAR-MIN, so the CUA would have NO way to ask > > for the second one so it MUST HAVE been specified in at least > > one of the predefined VCARS. Therefore a CUA must be able to > > query for this and it would have to come back in combined format > > in at the very least the predefined VCAR it came from. > > Sorry. I've read this paragraph multiple times and > I still can't make sense out of it. Perhaps you can > reformulate it. :-( Given one predefined VCAR that has several VRIGHT components. The CS is going to return that single complex VCAR when asked. So any CUA that ever asks for any VCAR is going to have to be able to parse complex VCARs. So why split out the VRIGHTs components into separate VCAR - that only increases the byte overhead and gains nothing. I am not saying that they can not be split. I am saying that there is no point in splitting them when they are already defined together. So a CUA MUST be able to deal with them combined - and separate. > There is no ambiguity here. CAP is clear: > > The access for a particular UPN is the union of all grants > for that UPN minus the union of its denies. Yes - duh - I even think I wrote that sentence :-) I must be getting old. > So you compute the union of all the GRANTs of all the > VCARs and then subtract the union of all the DENYs of > all the VCARs. After thinking about it, maybe it should be re-worded the way you have stated (DENYs in the VCARs) which reflects the way it is. Otherwise, as the default is deny, everything gets subtracted. > Now that you know that we don't have problems with > precedence. Do you still think we need a way to > return ALL VRIGHTs in a single VCAR? > > I still can't see why we would need it. Not mandated, but there is no reason for a CS to split an already defined VCAR into multiple parts. So both must be allowed. --------------C9E430A649EA57EA5B90CF81 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 ; Fri, 8 Feb 2002 14:14:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18J3AW16334 for ietf-calendar-bks; Fri, 8 Feb 2002 11:03:10 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18J39316330 for ; Fri, 8 Feb 2002 11:03:09 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA26811 for ; Fri, 8 Feb 2002 11:03:10 -0800 (PST) Message-ID: <3C6420E9.9125192D@Royer.com> Date: Fri, 08 Feb 2002 12:03:05 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> Content-Type: multipart/mixed; boundary="------------D1F3EF63733722CB28AFFA47" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D1F3EF63733722CB28AFFA47 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > If you agree with my results, do you think it is desirable > that we get different results? For multi instance properties the following two are equivalent: PROPERRY:READ,CREATE PROPERTY:READ PROPERTY:CREATE I am looking for it, but I am sure that we have declared in some RFC or draft, that the above two are always equivalent. If what I think is true, you are declaring that PERMISSION is the exception to the rule. That will break parsers. And any VQUERY implementation will already have to take that into account for multiple other multi instance properties. So, I'll add a note to CAP-QL that reminds implementors that as multi-instance properts can also be provided as multi-value, the CS QUERY implementation must take that into account and check all instances and all values when dealing with multiple-instance properties. > If you disagree with my results, why bother and not use > single value multiple instances? My point is that I believe they are supposed to be equivalent (both ways). --------------D1F3EF63733722CB28AFFA47 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 ; Fri, 8 Feb 2002 14:16:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18J5rE16413 for ietf-calendar-bks; Fri, 8 Feb 2002 11:05:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18J5q316409 for ; Fri, 8 Feb 2002 11:05:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA26820 for ; Fri, 8 Feb 2002 11:05:53 -0800 (PST) Message-ID: <3C64218D.8AFA3D55@Royer.com> Date: Fri, 08 Feb 2002 12:05:49 -0700 From: Doug Royer Reply-To: "iietf-calendar@imc.org i" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Event owner in ICAL schema References: Content-Type: multipart/mixed; boundary="------------54A8E155824EE4EEF7412D21" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------54A8E155824EE4EEF7412D21 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >If the object is private to the user calendar and will NOT be > >distributed to anyone else > > Yeah, but consider what happens if the object is modified to invite > someone. It seems sort of, mmm, non-orthogonal, to say that you MUST add > the ORGANIZER when the first person is invited, and remove it when the > last invitee is removed. Why not have ORGANIZER on it all the time? Yes - but still not for VFREEBUSY or VTIMESZONE, (others?). > >that is outside the scope of all > >of iCalendar, iTIP, iMIP, and CAP - as there would not be a > >need for interoperability. > > Not necessarily; you might use iCalendar format to export it to another > CUA for the same CU. Yes - then X- is still used. I was not saying that you can not use X-. I was saying that IF it is never exported - who cares how it is done and if it is never expoerted - then it is out of scope. --------------54A8E155824EE4EEF7412D21 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 ; Fri, 8 Feb 2002 14:16:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18Iwws16212 for ietf-calendar-bks; Fri, 8 Feb 2002 10:58:58 -0800 (PST) Received: from office.jigzaw.com (office.jigzaw.com [63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18Iwu316208 for ; Fri, 8 Feb 2002 10:58:56 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA13043; Fri, 8 Feb 2002 12:54:20 -0600 From: "Shannon J. Clark" To: "John Stracke" , Subject: RE: Event owner in ICAL schema Date: Fri, 8 Feb 2002 12:58:54 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree - the exact relationship required to map a USER to the data for that user's calendar has always been somewhat confusing... and where to store that data gets further complicated. As I understand it we have a number of separate "issues" at stake - and what feels like very differing perceptions as to how to deal with them. One - User runs a calendar application (called CUA) - this may be running on a local to the user device. Two - the CUA connects to a CS to retrieve the data to show as the user's calendar. There may be more than one CS involved (for example a "local" cs for use when not networked, and a networked CS that is the permanent repository of data). --- this does NOT require that ANY scheduling is performed - there are security and access reasons for a networked CS that do not involve scheduling. Now comes some of the linguistic areas of confusion. First - does the "user" have ONE or more then ONE calendars to deal with? If more than one - what "defines" the user? What maps the association of multiple calendars to that particular user? Second - in the above questions does "calendar" associate with VCALENDAR? or to VAGENDA? or something else? Third - how is the "user" defined such that the CUA and CS "know" how to differentiate one user from another? - and how to associate the right set of information (and access rights etc) with a particular user? Four - what is the "owner" vs. the "organizer" difference intended for? Five - how does the CUA, CS (and perhaps the user) "know" that workflow is/is not involved? Furthermore why should this matter - i.e. why should the standard behave differently when only one user is involved vs. when multiple users may be? - and would cases of one user but multiple CUA trigger the requirements for "workflow"? (for example a need to keep three different calendar tools in sync - which seems like a very very reasonable requirement. Finally - since it is confusing - could someone map through the various standards and show the specific data elements are areas that are involved in defining a given user, the data for that user, and how that user gets that data. With the related question of how to add new data - i.e. what a CUA has to do (and has to know) in order to generate a new object for that user's data collection. thanks, Shannon - yes these are perhaps basic questions - but clearly our current explanations result in confusion - and a confusion that I think is indicative of a gap between people who have been doing it one way - and people who are trying to work outward from the standards to a solution. This indicates to me that something is missing from the standards documents that explains this gap in knowledge and assumptions. -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Friday, February 08, 2002 8:37 AM To: ietf-calendar@imc.org Subject: Re: Event owner in ICAL schema >If the object is private to the user calendar and will NOT be >distributed to anyone else Yeah, but consider what happens if the object is modified to invite someone. It seems sort of, mmm, non-orthogonal, to say that you MUST add the ORGANIZER when the first person is invited, and remove it when the last invitee is removed. Why not have ORGANIZER on it all the time? >that is outside the scope of all >of iCalendar, iTIP, iMIP, and CAP - as there would not be a >need for interoperability. Not necessarily; you might use iCalendar format to export it to another CUA for the same CU. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |The problem with any unwritten law is that you don't know where| |to go to erase it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 8 14:24:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21054 for ; Fri, 8 Feb 2002 14:24:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18J6pX16443 for ietf-calendar-bks; Fri, 8 Feb 2002 11:06:51 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18J6o316439 for ; Fri, 8 Feb 2002 11:06:50 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA26824 for ; Fri, 8 Feb 2002 11:06:51 -0800 (PST) Message-ID: <3C6421C7.6A01B71E@Royer.com> Date: Fri, 08 Feb 2002 12:06:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - DECREED defined? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630BEB.2190AF9F@Royer.com> <3C6337CD.94387F22@steltor.com> <3C633EE0.6E78D14A@Royer.com> <3C63EC19.63817103@steltor.com> Content-Type: multipart/mixed; boundary="------------1D7BB6FB745EA4F9EA837B60" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1D7BB6FB745EA4F9EA837B60 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Actually, we only need to specify this in the restriction > table of the "create" command (section 6.2.4.1) since the > following is specified for the "modify" command: > > > The modifications MUST only be applied if the > > resulting component respects the restriction > > table of the "create" command. > > Agreed? Yes. --------------1D7BB6FB745EA4F9EA837B60 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 ; Fri, 8 Feb 2002 14:31:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18JDLg16603 for ietf-calendar-bks; Fri, 8 Feb 2002 11:13:21 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18JDK316599 for ; Fri, 8 Feb 2002 11:13:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA26839; Fri, 8 Feb 2002 11:13:21 -0800 (PST) Message-ID: <3C64234C.F912F1EE@Royer.com> Date: Fri, 08 Feb 2002 12:13:16 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: lata.kannan@oracle.com, prashantkumar.shetty@oracle.com Subject: Re: Event owner in ICAL schema References: Content-Type: multipart/mixed; boundary="------------2D8C8EFF572C69F6ACE1C42D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2D8C8EFF572C69F6ACE1C42D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 02/07/2002 06:27:48 PM: > > Because ORGANIZER is a scheduling thing, and no one > > is going to own the contents of a VTIMEZONE. > > Sigh! I think everyone has started to loose sight of some definitions > of iCalendar properties. Bruce - 'workflow' must have some meaning to you. To me it means iTIP. Is that what it means to you? (it is only used once in 2445, twice in 2446, and never defined). > In RFC 2445 we designed ORGANIZER to be the focal point of all > scheduling workflow (by definition calendaring has NO workflow). As > such, if I have an entry on my calendar that is not involved in > workflow then it can have NO ORGANIZER. Is that so hard to grok?? > ... I think that we are saying the same thing - but I am not sure what you means when you say 'workflow' with respect to 2445. > I think you are treating ORGANIZER as "Owner" of an entry and that is > NOT what it is designed for. > ... No - I was just guessing that he might of meant ORGANIZER. --------------2D8C8EFF572C69F6ACE1C42D 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 ; Fri, 8 Feb 2002 14:38:42 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18JK6U16739 for ietf-calendar-bks; Fri, 8 Feb 2002 11:20:06 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18JK5316735 for ; Fri, 8 Feb 2002 11:20:05 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA26849 for ; Fri, 8 Feb 2002 11:20:05 -0800 (PST) Message-ID: <3C6424E1.3B89D3B9@Royer.com> Date: Fri, 08 Feb 2002 12:20:01 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Multiple OWNER in VAGENDA? (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BEF6.5CB5C89D@steltor.com> <3C62CF4F.3D1A8B62@Royer.com> <3C640427.1EC67779@steltor.com> Content-Type: multipart/mixed; boundary="------------7092BB1784CEF85ADF1D635E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7092BB1784CEF85ADF1D635E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: ers > > > > ...Second, a "sent-by" parameter may be specified in either the > > "Organizer" or "Attendee" properties. When specified, the "sent-by" > > parameter indicates that the responding CU acted on behalf of the > > specified "Attendee" or "Organizer". > > > > So you can have your assistant be able to connect to your > > calendar and REPLY for you - and they do not need to be an OWNER > > of your calendar. > > Do you mean that we DON'T need multiple OWNER for > that reason? No - I was respoding to the fact that the reply can come from a non-OWNER. > Beside, given that you could set your VCARs to grant > others the rights to fully manage your VAGENDA do we > really need multiple OWNERs in VAGENDA? I would say no. Decreed VCARs - grant OWNERs ... How would you manage those? It also simplifies VCARs 'SELECT .... WHERE OWNER() ...' Otherwise you have to specificy tweak possibly multiple VCARs some of which you may not have access to tweak. --------------7092BB1784CEF85ADF1D635E 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 ; Fri, 8 Feb 2002 15:01:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18JiId17312 for ietf-calendar-bks; Fri, 8 Feb 2002 11:44:18 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18JiG317308 for ; Fri, 8 Feb 2002 11:44:17 -0800 (PST) To: "iietf-calendar@imc.org i" Subject: Re: Event owner in ICAL schema MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 8 Feb 2002 14:51:40 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/08/2002 02:52:03 PM, Serialize complete at 02/08/2002 02:52:03 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Yes - but still not for VFREEBUSY or VTIMESZONE, (others?). Mmm, you wouldn't store VFREEBUSY within a CS; you'd fetch it as part of a scheduling process. And VTIMEZONE doesn't need an owner because it doesn't apply to a person, it applies to the other components in the same VCALENDAR. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |I'm a .sig virus...and, boy, am I tired! | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 8 15:50:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24281 for ; Fri, 8 Feb 2002 15:50:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18KYND18559 for ietf-calendar-bks; Fri, 8 Feb 2002 12:34:23 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18KYM318555 for ; Fri, 8 Feb 2002 12:34:22 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA26979 for ; Fri, 8 Feb 2002 12:34:23 -0800 (PST) Message-ID: <3C64364A.8B14315D@Royer.com> Date: Fri, 08 Feb 2002 13:34:18 -0700 From: Doug Royer Reply-To: iietf-calendar@imc.org, i@royer.com Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Event owner in ICAL schema References: Content-Type: multipart/mixed; boundary="------------B8DB6F0A5E084A337B0D6606" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B8DB6F0A5E084A337B0D6606 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >Yes - but still not for VFREEBUSY or VTIMESZONE, (others?). > > Mmm, you wouldn't store VFREEBUSY within a CS; You can. A CUA can VQUERY for a VFREEBUSY that a CUA has deposited into the CS. There is no formula for computing VFREEBUSY, so it is conceivable that the OWNER would deposit a VFREEBUSY in their calendar(s) so that any VFREEEBUSY query would return that result. It is also possible that some implementations may calculate one based on the TRANSP property, but there is no requirement they any CS do that. > you'd fetch it as part of a > scheduling process. And VTIMEZONE doesn't need an owner because it > doesn't apply to a person, it applies to the other components in the same > VCALENDAR. True - and our point. --------------B8DB6F0A5E084A337B0D6606 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 ; Fri, 8 Feb 2002 16:05:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18KmIT18986 for ietf-calendar-bks; Fri, 8 Feb 2002 12:48:18 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18KmH318981 for ; Fri, 8 Feb 2002 12:48:17 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA00714 for ; Fri, 8 Feb 2002 15:48:11 -0500 Received: from earth.in.steltor.com ([101.1.1.100]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id D81S44QJ; Fri, 8 Feb 2002 15:35:54 -0500 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 g18KZoQ01046 for ; Fri, 8 Feb 2002 15:35:51 -0500 (EST) Message-ID: <3C643716.8AC21274@steltor.com> Date: Fri, 08 Feb 2002 15:37:42 -0500 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: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <3C6420E9.9125192D@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: > > > > > If you agree with my results, do you think it is desirable > > that we get different results? > > For multi instance properties the following two are equivalent: > > PROPERRY:READ,CREATE > > PROPERTY:READ > PROPERTY:CREATE > > I am looking for it, but I am sure that we have declared > in some RFC or draft, that the above two are always equivalent. > If what I think is true, you are declaring that PERMISSION > is the exception to the rule. There is no such rule. > That will break parsers. You MUST be joking! Think about it for a second. > And any VQUERY implementation will already have to take > that into account for multiple other multi instance properties. It doesn't mean that every new property needs to be multiple values, multiples instances. Regards, 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 Feb 8 16:21:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25342 for ; Fri, 8 Feb 2002 16:21:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18L8LI19613 for ietf-calendar-bks; Fri, 8 Feb 2002 13:08:21 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18L8K319609 for ; Fri, 8 Feb 2002 13:08:20 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA01745 for ; Fri, 8 Feb 2002 16:08:17 -0500 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 g18L8HQ05938 for ; Fri, 8 Feb 2002 16:08:17 -0500 (EST) Message-ID: <3C643EB1.F19668CB@steltor.com> Date: Fri, 08 Feb 2002 16:10:09 -0500 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: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@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: > > Given one predefined VCAR that has several VRIGHT components. > The CS is going to return that single complex VCAR when asked. > So any CUA that ever asks for any VCAR is going to have to > be able to parse complex VCARs. So why split out the VRIGHTs > components into separate VCAR - that only increases the byte > overhead and gains nothing. > > I am not saying that they can not be split. I am saying that > there is no point in splitting them when they are already > defined together. So a CUA MUST be able to deal with them > combined - and separate. I agree. The CS MUST NOT split out the VRIGHT contained in a single VCAR into separate VCARs. What I'm questionning is why should the CS have the ability to merge VRIGHT components contained in separate VCARs in a single VCAR (a.k.a. the coalescence of VCARs). > > There is no ambiguity here. CAP is clear: > > > > The access for a particular UPN is the union of all grants > > for that UPN minus the union of its denies. > > Yes - duh - I even think I wrote that sentence :-) > I must be getting old. > > > So you compute the union of all the GRANTs of all the > > VCARs and then subtract the union of all the DENYs of > > all the VCARs. > > After thinking about it, maybe it should be re-worded > the way you have stated (DENYs in the VCARs) which reflects > the way it is. Otherwise, as the default is deny, everything > gets subtracted. The precedence rule could also be written as follow: If two rights exist and are in conflict, the right that denies access always takes precedence over the right that grant access. > > Now that you know that we don't have problems with > > precedence. Do you still think we need a way to > > return ALL VRIGHTs in a single VCAR? > > > > I still can't see why we would need it. > > Not mandated, but there is no reason for a CS to split > an already defined VCAR into multiple parts. So both > must be allowed. I agree that both MUST be allowed. The only transformation the CS should apply to the VCARs before returning them is modifying the GRANT and DENY properties for security reasons. As was dicussed and agreed several times. So far we don't seem to need coalescence of VCAR. We just need the ability to have multiple VRIGHT in a single VCAR. Agree? Regards, 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 Feb 8 17:36:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26754 for ; Fri, 8 Feb 2002 17:36:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18MNI622267 for ietf-calendar-bks; Fri, 8 Feb 2002 14:23:18 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18MNH322263 for ; Fri, 8 Feb 2002 14:23:17 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA27142 for ; Fri, 8 Feb 2002 14:23:18 -0800 (PST) Message-ID: <3C644FD1.E7EDA43@Royer.com> Date: Fri, 08 Feb 2002 15:23:13 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> Content-Type: multipart/mixed; boundary="------------D9DAAF9C741ABB090172CA1D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D9DAAF9C741ABB090172CA1D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The precedence rule could also be written as follow: > > If two rights exist and are in conflict, > the right that denies access always takes > precedence over the right that grant access. And add 'in VCARs' (as the denies are implied if they do not exist and those are not to be considered in conflict)? > > The only transformation the CS should apply to the > VCARs before returning them is modifying the GRANT > and DENY properties for security reasons. As was > dicussed and agreed several times. > > So far we don't seem to need coalescence of VCAR. > We just need the ability to have multiple VRIGHT > in a single VCAR. What is the difference? If I make up VCARs that do not really exist so that SELF() can only see a VCAR that only effects SELF() for security reasons - that is a coalesced VCAR. Correct? --------------D9DAAF9C741ABB090172CA1D 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 ; Fri, 8 Feb 2002 17:38:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18ME1C22060 for ietf-calendar-bks; Fri, 8 Feb 2002 14:14:01 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18MDx322056 for ; Fri, 8 Feb 2002 14:13:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA27124 for ; Fri, 8 Feb 2002 14:14:01 -0800 (PST) Message-ID: <3C644DA3.D032B27A@Royer.com> Date: Fri, 08 Feb 2002 15:13:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <3C6420E9.9125192D@Royer.com> <3C643716.8AC21274@steltor.com> Content-Type: multipart/mixed; boundary="------------105B0274D4CBD7AB68503DAF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------105B0274D4CBD7AB68503DAF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > > If you agree with my results, do you think it is desirable > > > that we get different results? > > > > For multi instance properties the following two are equivalent: > > > > PROPERRY:READ,CREATE > > > > PROPERTY:READ > > PROPERTY:CREATE > > > > I am looking for it, but I am sure that we have declared > > in some RFC or draft, that the above two are always equivalent. > > If what I think is true, you are declaring that PERMISSION > > is the exception to the rule. > > There is no such rule. > > > That will break parsers. > > You MUST be joking! Think about it for a second. No I am not. In the example you provided in this thread, replace PERMISSION with RELATED-TO and perform a similar query where you had (edited for RELATED-TO): For instance, given the following CAL-QUERY values: 1- SELECT perm FROM VCAR USING_PROPERTIES RELATED-TO rel WHERE rel = 'relcal-1' 2- SELECT perm FROM VCAR USING_PROPERTIES RELATED-TO rel WHERE 'relcal-1' IN rel What would be returned for: a) RELATED-TO:relcal-1,relcal-2 1- Nothing! 2- RELATED-TO:relcal-1,relcal-2 b) RELATED-TO:relcal-1 RELATED-TO:relcal-2 1- PERMISSION:relcal-1 2- PERMISSION:relcal-1 It has to be true! The CUA must ask for what it wants. If it uses query (1), it better understand why it may get no data back (a-1). And the same is true for RRULE. It is the CUA that did not query for what it wanted. It is not the fact that it allows multiple values or instances. It is because iCalendar allows multiple values and instances that that must be true. And each way of doing it is equivalent. Its the CUA that must understand that. --------------105B0274D4CBD7AB68503DAF 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 ; Fri, 8 Feb 2002 17:39:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18MQx222345 for ietf-calendar-bks; Fri, 8 Feb 2002 14:26:59 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18MQw322341 for ; Fri, 8 Feb 2002 14:26:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA04137 for ; Fri, 8 Feb 2002 17:26:52 -0500 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g18MQpQ15936; Fri, 8 Feb 2002 17:26:51 -0500 (EST) Message-Id: <5.1.0.14.0.20020208172641.02b35970@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 08 Feb 2002 17:30:14 -0500 To: ietf-calendar@imc.org, "ietf-calendar@imc.org" From: Alan Davies Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? In-Reply-To: <3C6420E9.9125192D@Royer.com> References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:03 PM 08/02/2002 -0700, Doug Royer wrote: >For multi instance properties the following two are equivalent: > > PROPERRY:READ,CREATE > > PROPERTY:READ > PROPERTY:CREATE If that's true, than we'd have to make a change to our CAP-QL proposal; we wouldn't need the function that we created for querying comma seperated values; they could just be queried like multi-properties. Of course, an exception to your multi-instance property 'rule' would be the RRULE value, which uses the comma for it's own purposes. --Alan From owner-ietf-calendar@mail.imc.org Fri Feb 8 18:18:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27310 for ; Fri, 8 Feb 2002 18:18:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18N5bV23125 for ietf-calendar-bks; Fri, 8 Feb 2002 15:05:37 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18N5a323119 for ; Fri, 8 Feb 2002 15:05:36 -0800 (PST) To: ietf-calendar@imc.org Cc: lata.kannan@oracle.com, prashantkumar.shetty@oracle.com Subject: Re: Event owner in ICAL schema MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02062002 February 06, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 8 Feb 2002 18:12:25 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 02/08/2002 06:05:41 PM, Serialize complete at 02/08/2002 06:05:41 PM Content-Type: multipart/alternative; boundary="=_alternative 007EC2FA85256B5A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007EC2FA85256B5A_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/08/2002 02:13:16 PM: > > I think you are treating ORGANIZER as "Owner" of an entry and that is > > NOT what it is designed for. > > ... > > No - I was just guessing that he might of meant > ORGANIZER. The relevant part of Latas posting for this is probably this: > In our >existing calendar, we have every appointment owned by a person, namely >an event_owner, every todo owned by a todo_owner and every journal owned >by a journal owner. This is a mandatory field for every appointment, >todo and journal. Unless their system only allows entries that involve other users (that is no entries that never leave the users calendar) then ORGANIZER is not equivalent to an Owner. My take on "every appointment", "every todo" and "every journal" is that it encompasses both those that never leave the single calendar and those that do. For those that never leave, we have nothing to convey the Owner info. For those that leave, ORGANIZER is essentially the equivalent. However, it is possible that they _only_ have entries that are shared among multiple calendars and as such the short answer for them is ORGANIZER... Boy how we like to digress when answering such a seemingly simple question... ;^) Lata: Its not clear if you really need to have "Owner" in the iCalendar schema mapping. If you never map entries that never leave that single calendar (ie: you only use the schema when mapping meeting request, replys, etc) then you can get by with using ORGANIZER and all is well. If you need to map entries that never leave the calendar (ie: for some backup/restore solution you want to build) then you will have to go the X-ORCL-... route... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007EC2FA85256B5A_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/08/2002 02:13:16 PM:
> > I think you are treating ORGANIZER as "Owner" of an entry and that is
> > NOT what it is designed for.
> > ...
>
> No - I was just guessing that he might of meant
> ORGANIZER.

The relevant part of Latas posting for this is probably this:

>                                                              In our
>existing calendar, we have every appointment owned by a person, namely
>an event_owner, every todo owned by a todo_owner and every journal owned
>by a journal owner. This is a mandatory field for every appointment,
>todo and journal.

Unless their system only allows entries that involve other users (that is no entries that never leave the users calendar) then ORGANIZER is not equivalent to an Owner.  My take on "every appointment", "every todo" and "every journal" is that it encompasses both those that never leave the single calendar and those that do.  For those that never leave, we have nothing to convey the Owner info.  For those that leave, ORGANIZER is essentially the equivalent.  However, it is possible that they _only_ have entries that are shared among multiple calendars and as such the short answer for them is ORGANIZER...

Boy how we like to digress when answering such a seemingly simple question...  ;^)

Lata: Its not clear if you really need to have "Owner" in the iCalendar schema mapping.  If you never map entries that never leave that single calendar (ie: you only use the schema when mapping meeting request, replys, etc) then you can get by with using ORGANIZER and all is well.  If you need to map entries that never leave the calendar (ie: for some backup/restore solution you want to build) then you will have to go the X-ORCL-... route...

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

--=_alternative 007EC2FA85256B5A_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 8 18:56:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27666 for ; Fri, 8 Feb 2002 18:56:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18Nfrs23817 for ietf-calendar-bks; Fri, 8 Feb 2002 15:41:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18Nfq323813 for ; Fri, 8 Feb 2002 15:41:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA27311 for ; Fri, 8 Feb 2002 15:41:54 -0800 (PST) Message-ID: <3C64623B.B3A46DF1@Royer.com> Date: Fri, 08 Feb 2002 16:41:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <5.1.0.14.0.20020208172641.02b35970@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------C801DCAA968023E07920C65F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C801DCAA968023E07920C65F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > > At 12:03 PM 08/02/2002 -0700, Doug Royer wrote: > >For multi instance properties the following two are equivalent: > > > > PROPERRY:READ,CREATE > > > > PROPERTY:READ > > PROPERTY:CREATE > > If that's true, than we'd have to make a change to our CAP-QL > proposal; we wouldn't need the function that we created for > querying comma seperated values; they could just be queried > like multi-properties. It was already part of the CAL-QL #3 proposal (see end of this email for a summary) > Of course, an exception to your multi-instance property 'rule' > would be the RRULE value, which uses the comma for it's own > purposes. Any property that has a multiple values and where any of the values contain a comma, must be quoted or escaped as described in 2445. Otherwise the comma would be a value separator. For the values (1), (2), and (3): PROP:1,2,3 One multi valued property Equivalent to: PROP:"1", "2", "3" And is equivalent to: PROP:1 PROP:2 PROP:3 And for values (part,one), (part,two), and (part,three): PROP:"part,one","part,two","part,three" Is equivalent to: PROP:"part,one" PROP:"part,two" PROP:"part,three" But is NOT equivalent to (because the comma means value separator): PROP:part,one PROP:part,two PROP:part,three The RRULE is both multi-valued, and multi-instance. As in both of these are valid in a VEVENT and are equivalent. RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 RRULE:FREQ=YEARLY;BYDAY=-1SA;BYMONTH=10 Is equivalent to: RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=1,FREQ=YEARLY ;BYDAY=-1SA;BYMONTH=10 The following was part of CAP-QL (#3) proposal as note (7 - LIKE) and (8 - CONTAINS [now IN]): The CS must understand the objects being compared and understand how to determine how any multi valued property or parameter values are separated, quoted, and backslash escaped and perform the comparisons as if each value existed by itself and not quoted or backslash escaped when comparing using the CONTAINS() [or LIKE] element. --------------C801DCAA968023E07920C65F 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 ; Fri, 8 Feb 2002 19:45:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g190VOi24815 for ietf-calendar-bks; Fri, 8 Feb 2002 16:31:24 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g190VN324809 for ; Fri, 8 Feb 2002 16:31:23 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA27386 for ; Fri, 8 Feb 2002 16:31:25 -0800 (PST) Message-ID: <3C646DD6.6BE143DD@Royer.com> Date: Fri, 08 Feb 2002 17:31:18 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: CAP: RESOLUTION: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BD79.5F37EF52@steltor.com> <3C62CCAE.5B73E250@Royer.com> <3C62D87E.5A53AA72@steltor.com> <3C62E562.8C010A5@Royer.com> <3C62EC27.A65AA059@steltor.com> <3C63EE5E.D560379D@steltor.com> Content-Type: multipart/mixed; boundary="------------3CDA9881079E2349418120C8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3CDA9881079E2349418120C8 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. > > We agreed to: > > - Remove function CONTAINS() ; I agree. > - Add operator IN ; I agree. And also add NOT IN. > - Add function CAL-OWNERS( CAL-ADDRESS ) I agree, And also add NOT CAL-OWNERS( CAL-ADDRESS ) > - Add function CURRENT-CALID() ; I agree. Which returns the full CALID and not a RELCALID. > - Add function SELF() ; I agree. And allow NOT SELF(). --------------3CDA9881079E2349418120C8 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 ; Fri, 8 Feb 2002 20:04:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g190nkB25471 for ietf-calendar-bks; Fri, 8 Feb 2002 16:49:46 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g190nj325466 for ; Fri, 8 Feb 2002 16:49:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA27408 for ; Fri, 8 Feb 2002 16:49:47 -0800 (PST) Message-ID: <3C647224.5F253A5F@Royer.com> Date: Fri, 08 Feb 2002 17:49:40 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: List Of Items (crisp) References: <3C646373.2336502C@steltor.com> Content-Type: multipart/mixed; boundary="------------4248A0D57297BBFDF738019E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4248A0D57297BBFDF738019E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > George Babics wrote: > > Miscellaneous: > ============== > > - Look at changes required by CAP to make it compatible with CRISP > (If we want to support CRISP, then some changes are needed in CAP. In > section 7.1.5, CAPVERSION, CAR, and QUERYLEVEL all need to be able to > have values of NONE.) > Is this compatibility needed? It is not part of the CAP requirements. (1) CRISP needs to be updated. It is not in sync with CAP (beep). (2) We need to make sure that QUERYLEVEL and CAPABILITIES allow for iana and X-tokens. Do we say that if xxx does not exists, then the CS does not support ANY VCARs? Do we say that if xxx does not exist, then no query is supported on the CS? (3) It is not clear to me if a CRISP server sends some kind of capability specifying the fact it only supports iTIP methods. But ether way (2) above should address that issue. (4) There would have to be some MINIMUM predefined VCAR support in a CRISP server, else how would implementations say that UPN-X can make requests, and UPN-Y can not. For example I could assume that of an object of METHOD:REQUEST would be allowed - to all UPNs? (5) Would we have to generate some kind of capability that specified which components the server supported? Or should this be specified in CRISP as a CAP extension? --------------4248A0D57297BBFDF738019E 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 ; Mon, 11 Feb 2002 09:47:23 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BEVd523373 for ietf-calendar-bks; Mon, 11 Feb 2002 06:31:39 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BEVc323369 for ; Mon, 11 Feb 2002 06:31:38 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA24302 for ; Mon, 11 Feb 2002 09:31:34 -0500 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 g1BEVXQ17408 for ; Mon, 11 Feb 2002 09:31:33 -0500 (EST) Message-ID: <3C67D638.FBA83949@steltor.com> Date: Mon, 11 Feb 2002 09:33:28 -0500 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: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <5.1.0.14.0.20020208172641.02b35970@imap1.in.steltor.com> <3C64623B.B3A46DF1@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 RRULE is both multi-valued, and multi-instance. You are wrong. RRULE is NOT multi-valued. > As in both of these are valid in a VEVENT and are equivalent. > > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 > RRULE:FREQ=YEARLY;BYDAY=-1SA;BYMONTH=10 > > Is equivalent to: > > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=1,FREQ=YEARLY > ;BYDAY=-1SA;BYMONTH=10 This is not legal per RFC 2445. Regards, 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 Feb 11 09:47:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04094 for ; Mon, 11 Feb 2002 09:47:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BES8V23272 for ietf-calendar-bks; Mon, 11 Feb 2002 06:28:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BES7323268 for ; Mon, 11 Feb 2002 06:28:08 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA24116 for ; Mon, 11 Feb 2002 09:28:03 -0500 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 g1BES2Q16753 for ; Mon, 11 Feb 2002 09:28:02 -0500 (EST) Message-ID: <3C67D565.94602BDA@steltor.com> Date: Mon, 11 Feb 2002 09:29:57 -0500 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: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <3C6420E9.9125192D@Royer.com> <3C643716.8AC21274@steltor.com> <3C644DA3.D032B27A@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: > > > > You MUST be joking! Think about it for a second. > > No I am not. In the example you provided in this thread, > replace PERMISSION with RELATED-TO and perform a similar query > where you had (edited for RELATED-TO): 1- What does RELATED-TO has to do with PERMISSION? It's not because some properties are multi-valued that they all need to be. 2- RELATED-TO is NOT a multi-valued property. From RFC 2445: related = "RELATED-TO" [relparam] ":" text CRLF To be multi-valued its rule part would have need to be written as follow: related = "RELATED-TO" [relparam] ":" text *("," text) CRLF But it was NOT. Regards, 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 Feb 11 10:26:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05664 for ; Mon, 11 Feb 2002 10:26:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BFBTm24182 for ietf-calendar-bks; Mon, 11 Feb 2002 07:11:29 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BFBS324176 for ; Mon, 11 Feb 2002 07:11:28 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA25407 for ; Mon, 11 Feb 2002 10:11:23 -0500 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 g1BFBNQ22166 for ; Mon, 11 Feb 2002 10:11:23 -0500 (EST) Message-ID: <3C67DF8E.61589674@steltor.com> Date: Mon, 11 Feb 2002 10:13:18 -0500 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: CAP: RESOLUTION: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BD79.5F37EF52@steltor.com> <3C62CCAE.5B73E250@Royer.com> <3C62D87E.5A53AA72@steltor.com> <3C62E562.8C010A5@Royer.com> <3C62EC27.A65AA059@steltor.com> <3C63EE5E.D560379D@steltor.com> <3C646DD6.6BE143DD@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: > > > > Just to make sure we are all on the same page. > > > > We agreed to: > > > > - Remove function CONTAINS() ; > > I agree. > > > - Add operator IN ; > > I agree. And also add NOT IN. It's not really necessary since we must be able to write: NOT ( elem IN set ) If you really insist on adding this additional operator, I would recommend naming it "NOT-IN" in one word. > > - Add function CAL-OWNERS( CAL-ADDRESS ) > > I agree, And also add NOT CAL-OWNERS( CAL-ADDRESS ) CAL-OWNERS() returns a set of UPNs, not a boolean value. So it doesn't make sense to write "NOT" in front of this function. > > - Add function CURRENT-CALID() ; > > I agree. Which returns the full CALID and not a RELCALID. Yes. > > - Add function SELF() ; > > I agree. And allow NOT SELF(). SELF() returns a UPN value, not a boolean value. So it doesn't make sense to write "NOT" in front of this function. Regards, 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 Feb 11 10:36:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05993 for ; Mon, 11 Feb 2002 10:36:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BFOYW24909 for ietf-calendar-bks; Mon, 11 Feb 2002 07:24:34 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BFOX324903 for ; Mon, 11 Feb 2002 07:24:33 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id HAA00414 for ; Mon, 11 Feb 2002 07:24:33 -0800 (PST) Message-ID: <3C67E22E.B0C06F7D@Royer.com> Date: Mon, 11 Feb 2002 08:24:30 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <5.1.0.14.0.20020208172641.02b35970@imap1.in.steltor.com> <3C64623B.B3A46DF1@Royer.com> <3C67D638.FBA83949@steltor.com> Content-Type: multipart/mixed; boundary="------------ACAE7C8FDB1DD7F2FB3F1C75" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ACAE7C8FDB1DD7F2FB3F1C75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > The RRULE is both multi-valued, and multi-instance. > > You are wrong. RRULE is NOT multi-valued. I guess I was confused when I read in 2445: 4.3.10 Recurrence Rule Description: If the property permits, multiple "recur" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. ... --------------ACAE7C8FDB1DD7F2FB3F1C75 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 ; Mon, 11 Feb 2002 11:11:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BFoGI26853 for ietf-calendar-bks; Mon, 11 Feb 2002 07:50:16 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BFoE326843 for ; Mon, 11 Feb 2002 07:50:14 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26505; Mon, 11 Feb 2002 10:50:09 -0500 Received: from steltor.com ([101.0.0.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BFo9Q26861; Mon, 11 Feb 2002 10:50:09 -0500 (EST) Message-ID: <3C67E87D.7F0ACA90@steltor.com> Date: Mon, 11 Feb 2002 10:51:25 -0500 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: LANGUAGE in CALSTORE References: <3C5D8486.B091254A@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 In RFC 2445 LANGUAGE is a parameter. However in CAP, we have it as a property. Is this OK? If we use it in CAP as a property, would we need to redefine it? If it is not OK we can use LOCALE. Unfortunately, we will still have add a separate definition for it, even if it means the same thing as LANGUAGE. George Doug Royer wrote: > > NEW PROPOSAL. > > (1) mandate BEEP "localize" attribute be sent in CS greeting. > > (2) Add optional LANGUAGE property to VQUERY in order to > specify locale sort order when CS supports more than > one locale. > > (Too late as it is in 2445, but LANGUAGE should be LOCALE) > > Each calendar has a LANGUAGE property, however the > CALSTORE does not and that can be covered in the > beep greeting. > > We need to include text that specifies that a CS MUST include > the "localize" attribute as specified as optional in section 2.3.1.1 > of BEEP (rfc3080). This list is the list (one or more) of locales > that the CS understands. And if multiple are supplied, then > the first is the default locale sort order for any VAGANDA > that does not have the LANGUAGE property value set. > > This is needed as VQUERY can do sorts, so if the CUA > wishes a different locale sort order, then it can specify > a LANGUAGE property in the VQUERY. And this LANGUAGE property > is only supplied in a VQUERY when: > > It is not the VAGAENDAs default locale (LANGUAGE). > > When it is not the CS's default local (first in list), > when if the VAGANDAs LANGUAGE is not set. > > And the LANGUAGE property specified in the VQUERY > was listed in the initial CS BEEP greeting "localize" > attribute (as proof that the CS supports that locale). > > The CUA wishes to specify the locale sort. > > If not supplied, the sort order is in the order sepcified > by the locale (LANGUAGE) of the VAGENDA or if not set, > the first (or only) locale listed in the "localize" > CS greeting attribute. From owner-ietf-calendar@mail.imc.org Mon Feb 11 11:17:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07712 for ; Mon, 11 Feb 2002 11:17:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BG5p800477 for ietf-calendar-bks; Mon, 11 Feb 2002 08:05:51 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BG5n300471 for ; Mon, 11 Feb 2002 08:05:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA00487 for ; Mon, 11 Feb 2002 08:05:50 -0800 (PST) Message-ID: <3C67EBDA.6D3188AE@Royer.com> Date: Mon, 11 Feb 2002 09:05:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: CAP: RESOLUTION: CAP-QL Type Mismatch Problem (Was: Re: CAP: VCAR Proposal (#2)) References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62BD79.5F37EF52@steltor.com> <3C62CCAE.5B73E250@Royer.com> <3C62D87E.5A53AA72@steltor.com> <3C62E562.8C010A5@Royer.com> <3C62EC27.A65AA059@steltor.com> <3C63EE5E.D560379D@steltor.com> <3C646DD6.6BE143DD@Royer.com> <3C67DF8E.61589674@steltor.com> Content-Type: multipart/mixed; boundary="------------BCBCF1DA5321A7F90C09BFA0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BCBCF1DA5321A7F90C09BFA0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Just to make sure we are all on the same page. > > > > > > We agreed to: > > > > > > - Remove function CONTAINS() ; > > > > I agree. > > > > > - Add operator IN ; > > > > I agree. And also add NOT IN. > > It's not really necessary since we must be able to write: > > NOT ( elem IN set ) > If you really insist on adding this additional operator, > I would recommend naming it "NOT-IN" in one word. No, that would be inconsistant with the other 'NOT' operators. And: SELECT * FROM VEVENT WHERE 'abc' NOT IN proprety reads better than SELECT * FROM VEVENT WHERE NOT 'abc' IN propert. > > > - Add function CAL-OWNERS( CAL-ADDRESS ) > > > > I agree, And also add NOT CAL-OWNERS( CAL-ADDRESS ) > > CAL-OWNERS() returns a set of UPNs, not a boolean value. > So it doesn't make sense to write "NOT" in front of this > function. Your right - it would be: 'upn' NOT IN CAL-ONWERS( CAL-ADDRESS ) Ditto - SELF() --------------BCBCF1DA5321A7F90C09BFA0 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 ; Mon, 11 Feb 2002 11:20:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BFuJK28763 for ietf-calendar-bks; Mon, 11 Feb 2002 07:56:19 -0800 (PST) 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 g1BFuG328751 for ; Mon, 11 Feb 2002 07:56:16 -0800 (PST) Received: from jsoft.com (IDENT:2EC73+HNQzMdaribiTEv2bWWeyxyenxr@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g1BFt8j09398 for ; Mon, 11 Feb 2002 09:55:08 -0600 Message-ID: <3C67E95C.5090804@jsoft.com> Date: Mon, 11 Feb 2002 09:55:08 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: 4.8.1.7 Location question 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 Reading RFC 2445 I understand that LOCATION can be in an event once and that it's text is not multi-valued. We would like to use LOCATION to 'hold' several 'locations'. For example, one could be the location of the event, one could be the actual room the event was in, one could be a location that's less precise. Say we have a homeschooling event that is held in Spring, TX. Spring is just north of Houston. I would like to have some sort of variation on the following: LOCATION:Spring LOCATION:Houston LOCATION:Spring Baptist Church 1027 Spring Cypress Or LOCATION:Houston, Spring, Spring Baptist Church 1027 Spring Cypress The above lets me use LOCATION to hold location info that's useful when searching the data later. Eg. give me all events that are close to Houston... I know we can use xparam. What am I not understanding? Gary From owner-ietf-calendar@mail.imc.org Mon Feb 11 11:49:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09521 for ; Mon, 11 Feb 2002 11:49:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BGVxF01215 for ietf-calendar-bks; Mon, 11 Feb 2002 08:31:59 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BGVw301211 for ; Mon, 11 Feb 2002 08:31:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA00533 for ; Mon, 11 Feb 2002 08:31:59 -0800 (PST) Message-ID: <3C67F1FB.D5E48440@Royer.com> Date: Mon, 11 Feb 2002 09:31:55 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: LANGUAGE in CALSTORE References: <3C5D8486.B091254A@Royer.com> <3C67E87D.7F0ACA90@steltor.com> Content-Type: multipart/mixed; boundary="------------6A8883C0DFD633F15156336D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6A8883C0DFD633F15156336D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > In RFC 2445 LANGUAGE is a parameter. However in CAP, we have > it as a property. Is this OK? If we use it in CAP as a property, > would we need to redefine it? > > If it is not OK we can use LOCALE. Unfortunately, we will still have > add a separate definition for it, even if it means the same thing > as LANGUAGE. I agree, anyone looking up 'LANGUAGE' is going to get confused. I think that the property name should be 'LOCALE'. --------------6A8883C0DFD633F15156336D 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 ; Mon, 11 Feb 2002 12:00:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BGgdw01479 for ietf-calendar-bks; Mon, 11 Feb 2002 08:42:39 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BGgc301475 for ; Mon, 11 Feb 2002 08:42:38 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA28593 for ; Mon, 11 Feb 2002 11:42:34 -0500 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 g1BGgYQ04185 for ; Mon, 11 Feb 2002 11:42:34 -0500 (EST) Message-ID: <3C67F4ED.DB1009D@steltor.com> Date: Mon, 11 Feb 2002 11:44:29 -0500 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: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@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 precedence rule could also be written as follow: > > > > If two rights exist and are in conflict, > > the right that denies access always takes > > precedence over the right that grant access. > > And add 'in VCARs' (as the denies are implied if they > do not exist and those are not to be considered in conflict)? "If two rights specified in VCAR components are in conflict, the right that denies access always takes precedence over the right that grant access." Correct? > > The only transformation the CS should apply to the > > VCARs before returning them is modifying the GRANT > > and DENY properties for security reasons. As was > > dicussed and agreed several times. > > > > So far we don't seem to need coalescence of VCAR. > > We just need the ability to have multiple VRIGHT > > in a single VCAR. > > What is the difference? If I make up VCARs that do not > really exist so that SELF() can only see a VCAR that > only effects SELF() for security reasons - that is a > coalesced VCAR. Correct? We need to stop talking about coalescence of VCARs since there is no coalescence per say. Returned VCARs will never contain more VRIGHT components than their stored version. We only need the ability to return VCARs with the GRANT and DENY properties "instantiated" to SELF(). Could we simply specify that: "When EXPAND is TRUE, only VCARs that pertain to the authenticated user MUST be returned, and the GRANT and DENY properties of the returned VCARs MUST only specify the UPN of the authenticated users." Agree? Regards, 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 Feb 11 12:07:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10542 for ; Mon, 11 Feb 2002 12:07:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BGrKi01764 for ietf-calendar-bks; Mon, 11 Feb 2002 08:53:20 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BGrJ301758 for ; Mon, 11 Feb 2002 08:53:19 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA28910; Mon, 11 Feb 2002 11:53:14 -0500 Received: from steltor.com ([101.0.0.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BGrDQ05449; Mon, 11 Feb 2002 11:53:13 -0500 (EST) Message-ID: <3C67F745.2BE33F4D@steltor.com> Date: Mon, 11 Feb 2002 11:54:29 -0500 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: LANGUAGE in CALSTORE References: <3C5D8486.B091254A@Royer.com> <3C67E87D.7F0ACA90@steltor.com> <3C67F1FB.D5E48440@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 On second thought, I am not sure if we should use LOCALE. RFC 2277, "IETF Policy on Character Sets and Languages", uses the POSIX definition of locale: The POSIX standard [POSIX] defines a concept called a "locale", which includes a lot of information about collating order for sorting, date format, currency format and so on. I do not think this is what we want to mean by LOCALE. The concept of language in RFC 2277 seems to fit what we want this property to mean. Given all this, how about using DEFAULT-LANGUAGE? But then, BEEP seems to use the "localize" attribute means language, so perhaps LOCALE is OK? George Doug Royer wrote: > > George Babics wrote: > > > > In RFC 2445 LANGUAGE is a parameter. However in CAP, we have > > it as a property. Is this OK? If we use it in CAP as a property, > > would we need to redefine it? > > > > If it is not OK we can use LOCALE. Unfortunately, we will still have > > add a separate definition for it, even if it means the same thing > > as LANGUAGE. > > I agree, anyone looking up 'LANGUAGE' is going to get confused. > I think that the property name should be 'LOCALE'. From owner-ietf-calendar@mail.imc.org Mon Feb 11 12:09:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10650 for ; Mon, 11 Feb 2002 12:09:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BGq9d01706 for ietf-calendar-bks; Mon, 11 Feb 2002 08:52:09 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BGq8301702 for ; Mon, 11 Feb 2002 08:52:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA00563 for ; Mon, 11 Feb 2002 08:52:07 -0800 (PST) Message-ID: <3C67F6B4.5A2EDB90@Royer.com> Date: Mon, 11 Feb 2002 09:52:04 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: 4.8.1.7 Location question References: <3C67E95C.5090804@jsoft.com> Content-Type: multipart/mixed; boundary="------------C861A2EB871CEE3BCFE6430A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C861A2EB871CEE3BCFE6430A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > > Reading RFC 2445 > > I understand that LOCATION can be in an event once and that it's text is > not multi-valued. > > We would like to use LOCATION to 'hold' several 'locations'. For > example, one could be the location of the event, one could be the actual > room the event was in, one could be a location that's less precise. > > Say we have a homeschooling event that is held in Spring, TX. Spring is > just north of Houston. I would like to have some sort of variation on > the following: > > LOCATION:Spring > LOCATION:Houston > LOCATION:Spring Baptist Church 1027 Spring Cypress The value of the LOCATION property is currently just TEXT, so it has no format. I was *thinking* of *proposing* a vCard (RFC 2426) 'ADR' format specifier for location as a new iCalendar VALUE type. In addition use the 2426 TYPE paramater. So that it could be: LOCATION;TYPE="home,work";VALUE=ADR: ;;123 Main Street;Any Town;CA;91921-1234 Or, perhaps just keep LOCATION the way it is, and add the ADR property directly as is from vCard. [Data below from 2426]: [2426] 3.2.1 ADR Type Definition [2426] [2426] To: ietf-mime-directory@imc.org [2426] [2426] Subject: Registration of text/directory MIME type ADR [2426] [2426] Type name: ADR [2426] [2426] [2426] Type purpose: To specify the components of the delivery address for [2426] the vCard object. [2426] [2426] Type encoding: 8bit [2426] [2426] Type value: A single structured text value, separated by the [2426] SEMI-COLON character (ASCII decimal 59). [2426] [2426] Type special notes: The structured type value consists of a [2426] sequence of address components. The component values MUST be [2426] specified in their corresponding position. The structured type [2426] value corresponds, in sequence, to the post office box; the [2426] extended address; the street address; the locality (e.g., city); [2426] the region (e.g., state or province); the postal code; the [2426] country name. When a component value is missing, the associated [2426] component separator MUST still be specified. [2426] [2426] The text components are separated by the SEMI-COLON character [2426] (ASCII decimal 59). Where it makes semantic sense, individual [2426] text components can include multiple text values (e.g., a "street" [2426] component with multiple lines) separated by the COMMA character [2426] (ASCII decimal 44). [2426] [2426] The type can include the type parameter "TYPE" to specify the [2426] delivery address type. The TYPE parameter values can include "dom" [2426] to indicate a domestic delivery address; "intl" to indicate an [2426] international delivery address; "postal" to indicate a postal [2426] delivery address; "parcel" to indicate a parcel delivery address; [2426] "home" to indicate a delivery address for a residence; "work" to [2426] indicate delivery address for a place of work; and "pref" to [2426] indicate the preferred delivery address when more than one address [2426] is specified. These type parameter values can be specified as a [2426] parameter list (i.e., "TYPE=dom;TYPE=postal") or as a value list [2426] (i.e., "TYPE=dom,postal"). This type is based on semantics of the [2426] X.520 geographical and postal addressing attributes. The default is [2426] "TYPE=intl,postal,parcel,work". The default can be overridden to [2426] some other set of values by specifying one or more alternate [2426] values. For example, the default can be reset to [2426] "TYPE=dom,postal,work,home" to specify a domestic delivery address [2426] for postal delivery to a residence that is also used for work. [2426] [2426] Type example: In this example the post office box and the extended [2426] address are absent. [2426] [2426] ADR;TYPE=dom,home,postal,parcel:;;123 Main [2426] Street;Any Town;CA;91921-1234 --------------C861A2EB871CEE3BCFE6430A 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 ; Mon, 11 Feb 2002 12:23:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BHAxM02237 for ietf-calendar-bks; Mon, 11 Feb 2002 09:10:59 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BHAw302233 for ; Mon, 11 Feb 2002 09:10:59 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA29436 for ; Mon, 11 Feb 2002 12:10:55 -0500 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BHApQ07707 for ; Mon, 11 Feb 2002 12:10:51 -0500 (EST) Message-Id: <5.1.0.14.0.20020211112535.01c5ddc8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Feb 2002 12:14:50 -0500 To: "ietf-calendar@imc.org" From: Alan Davies Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? In-Reply-To: <3C64623B.B3A46DF1@Royer.com> References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <5.1.0.14.0.20020208172641.02b35970@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:41 PM 08/02/2002 -0700, Doug Royer wrote: >The RRULE is both multi-valued, and multi-instance. >As in both of these are valid in a VEVENT and are equivalent. > > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 > RRULE:FREQ=YEARLY;BYDAY=-1SA;BYMONTH=10 > >Is equivalent to: > > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=1,FREQ=YEARLY > ;BYDAY=-1SA;BYMONTH=10 But RFC2445 has examples where RRULEs contain unescaped commas within them, such as: RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 So I repeat my original statement about RRULE being a special case: "an exception to your multi-instance property 'rule' would be the RRULE value, which uses the comma for it's own purposes." > > If that's true, than we'd have to make a change to our CAP-QL > > proposal; we wouldn't need the function that we created for > > querying comma seperated values; they could just be queried > > like multi-properties. > >It was already part of the CAL-QL #3 proposal (see end of >this email for a summary) [sections rearranged for clarity...] > The CS must understand the objects being compared and > understand how to determine how any multi valued property > or parameter values are separated, quoted, and backslash > escaped and perform the comparisons as if each value >existed > by itself and not quoted or backslash escaped when >comparing > using the CONTAINS() [or LIKE] element. I was just pointing out that when CONTAINS() was originally proposed, it was to allow multi-value properties to be queried like this: SELECT * FROM VTODO WHERE CONTAINS( CATEGORIES, 'BUSINESS' ) = TRUE But if your statement above is correct, and multi-instance is equivalent to multi-value (for the purposes of the query), then the more powerful and flexible multi-instance syntax could be used instead: SELECT * FROM VTODO USING_PROPERTIES CATEGORIES cat1 WHERE cat1 = 'BUSINESS' As an aside, I feel that for consistency this query should also be considered equivalent with the others: SELECT * FROM VTODO WHERE CATEGORIES = 'BUSINESS' i.e. a reference to a multi-instance/value property by name refers to _any_ instance/value of that property within the component. --Alan From owner-ietf-calendar@mail.imc.org Mon Feb 11 12:34:30 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12056 for ; Mon, 11 Feb 2002 12:34:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BHEp302348 for ietf-calendar-bks; Mon, 11 Feb 2002 09:14:51 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BHEn302344 for ; Mon, 11 Feb 2002 09:14:50 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA29584 for ; Mon, 11 Feb 2002 12:14:46 -0500 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BHEjQ08181 for ; Mon, 11 Feb 2002 12:14:45 -0500 (EST) Message-Id: <5.1.0.14.0.20020211121607.0326eb20@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Feb 2002 12:18:44 -0500 To: "ietf-calendar@imc.org" From: Alan Davies Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? In-Reply-To: <3C67E22E.B0C06F7D@Royer.com> References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <5.1.0.14.0.20020208172641.02b35970@imap1.in.steltor.com> <3C64623B.B3A46DF1@Royer.com> <3C67D638.FBA83949@steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:24 AM 11/02/2002 -0700, Doug Royer wrote: >Bernard Desruisseaux wrote: > > > > Doug Royer wrote: > > > > > > The RRULE is both multi-valued, and multi-instance. > > > > You are wrong. RRULE is NOT multi-valued. > >I guess I was confused when I read in 2445: > > 4.3.10 Recurrence Rule > > > Description: If the property permits, multiple "recur" values are > specified by a COMMA character (US-ASCII decimal 44) separated list > of values. ... I think 2445 was confused, as just a few lines below that it states: The BYSECOND rule part specifies a COMMA character (US-ASCII decimal 44) separated list of seconds within a minute. (and similar for other rule parts), and then gives examples that use the COMMA in this way. --Alan From owner-ietf-calendar@mail.imc.org Mon Feb 11 13:39:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13651 for ; Mon, 11 Feb 2002 13:39:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BIMgx03934 for ietf-calendar-bks; Mon, 11 Feb 2002 10:22:42 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BIMf303930 for ; Mon, 11 Feb 2002 10:22:41 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA31295; Mon, 11 Feb 2002 13:22:37 -0500 Received: from steltor.com ([101.0.0.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BIMaQ15648; Mon, 11 Feb 2002 13:22:36 -0500 (EST) Message-ID: <3C680C38.E16EE7D6@steltor.com> Date: Mon, 11 Feb 2002 13:23:52 -0500 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VALARM: UID VS ALARMID [Was: Re: (ALARMREF?) ALARMID to VALARM after stored?] References: <3BFD80A5.4F481F2D@steltor.com> <3BFEB264.634AA9C5@Royer.com> <3C04F209.7EB6CE09@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 This was brought up a few times. We should resolve it once and for all. CAP added a property to VALARM called "ALARMID." Its value is unique within the scope of the event, todo, or journal that it is found in. It allows one to uniquely identify a VALARM within a component. A suggestion was made to use UID instead of ALARMID. UIDs are globally unique, thus one can have global VALARMs in a future version of CAP, if this feature is ever needed. Furthermore, we reuse a property and do not have to defined a new one. Thus I await you opinions. ALARMID or UID? George George Babics wrote: > > This is what we can do: > > 1) Not allow global VALARMs > > 2) Replace ALARMID by UID. It will be one less property to > define. Furthermore, if in a future version of CAP we will > want to have global VALARMs, they will be easier to add. > > Everyone agree? If not, speak up now! > > George > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > > The required transformation would be pretty straightforward. > > > Really minor compared to the required conversion of CAP calendar > > > addresses to mailto URLs. Furthermore, in most cases you should > > > probably not send the VALARM to the other attendees. What's the > > > point of sending your VALARM to other people? > > > > Maybe they want it? Maybe it is not a person, but a program > > that is doing work for you and the action in the alarm is > > a program to run? Maybe the real need for the request is > > to synchronize or copy a calendar? I think the point is that > > they can send VALARMs, and you can get VALARMs. So John's point > > is valid - if we do this - there must be an iTIP transformation > > process when sending/getting iTIP messages. > > > > iTIP does not handle them, so any iTIP messages sent would > > have to include them and not reference them. But the same > > is true for VCARs and VTIMEZONEs. We can't break RFC2446, so > > there MUST BE a transformation. > > > > > A CUA could easily remind the CU about the impact of changing a > > > VALARM referenced by other VALARMs before sending the "modify" > > > command to the CAP server. > > > > > > Personally, I would be more concerned about the consequences of > > > modifying a VCAR referenced by other VCARs, or a VTIMEZONE on > > > which multiple VEVENTs may depend. > > > > Time zones do change and thus any good implementation MUST NOT > > think they are static. The same is true of a VCAR, they > > are not static. And a CUA can change any VALARM already. > > > > The only real change is do we allow VALARMs outside of a VEVENT > > or VTODO? If yes, then we MUST specify rules for modification. > > Do we say that if a CUA modifies a VALARM that is common to > > more than one VEVENT do we: > > > > 1) MODIFY the one global and warn the user? > > > > 2) Replace the VALARM in the component with the global VALARM. > > Remove the ALARMREF in the copy. > > Then modify the copy in that target component? > > > > 3) Add a parameter that says 'target components only' or 'all'. > > Then apply rule (2). > > > > 4) Not allow global VALARMs? > > > > I would lean to (4) in CAP, just to get it out the door. However > > if the WG wants global VALARMs - I would not object. > > > > -Doug From owner-ietf-calendar@mail.imc.org Mon Feb 11 15:10:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15867 for ; Mon, 11 Feb 2002 15:10:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BJpjm05316 for ietf-calendar-bks; Mon, 11 Feb 2002 11:51:45 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BJpi305312 for ; Mon, 11 Feb 2002 11:51:44 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA00904 for ; Mon, 11 Feb 2002 14:51:41 -0500 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 g1BJpeQ26289 for ; Mon, 11 Feb 2002 14:51:41 -0500 (EST) Message-ID: <3C682140.659FA9EF@steltor.com> Date: Mon, 11 Feb 2002 14:53:36 -0500 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: CAP: Querying VALARM 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 What is the proper VQUERY to get the VALARM components of all the calendar components stored in a VAGENDA? BEGIN:VQUERY QUERYNAME:Query-1 QUERY:SELECT * FROM VALARM END:VQUERY BEGIN:VQUERY QUERYNAME:Query-2 QUERY:SELECT VALARM FROM VTODO QUERY:SELECT VALARM FROM VEVENT END:VQUERY I would say (2). Since (1) should be used to get only the VALARM components stored directly in the VAGENDA (which is currently not allowed). Correct? Regards, 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 Feb 11 15:26:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16273 for ; Mon, 11 Feb 2002 15:26:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BKEbU05826 for ietf-calendar-bks; Mon, 11 Feb 2002 12:14:37 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BKEZ305821 for ; Mon, 11 Feb 2002 12:14:35 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: List Of Items (crisp) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 11 Feb 2002 15:22:22 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/11/2002 03:22:32 PM, Serialize complete at 02/11/2002 03:22:32 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >(1) CRISP needs to be updated. It is not in sync with CAP (beep). True. I'll see if I can get to that soon. >(2) We need to make sure that QUERYLEVEL and CAPABILITIES > allow for iana and X-tokens. > > Do we say that if xxx does not exists, then > the CS does not support ANY VCARs? > > Do we say that if xxx does not > exist, then no query is supported on the CS? It might be better if these statements are made explicitly (e.g., "" or "none"), so that it's obvious that a missing element is a bug. >(3) It is not clear to me if a CRISP server sends some kind > of capability specifying the fact it only supports iTIP > methods. That's the intent in my older drafts. I'll have to dig into the latest CAP version to see whether I can say that explicitly, or (as you suggested a month or few ago) just say "I'm CRISP". >(4) There would have to be some MINIMUM predefined VCAR support > in a CRISP server, else how would implementations say > that UPN-X can make requests, and UPN-Y can not. Um...I don't think we can do that, really. The point of CRISP is to carry iTIP operations from users who don't have accounts on the local CS; and we have no way of authenticating remote users. >(5) Would we have to generate some kind of capability that > specified which components the server supported? Or > should this be specified in CRISP as a CAP extension? Hmm. I've always thought that a base CAP client (written by someone who never read the CRISP spec) should be able to talk to a CRISP server and understand its capabilities; that's why I took the approach of defining "NONE" capabilities. However, it now occurs to me that a client has to be written specifically to take advantage of CRISP, because a CRISP client has to log in with no credentials, which it would never do in CAP. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |A successful tool is one that was used to do something undreamed| |of by its author. | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 11 15:34:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16482 for ; Mon, 11 Feb 2002 15:34:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BKH3r05896 for ietf-calendar-bks; Mon, 11 Feb 2002 12:17:03 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BKH1305892 for ; Mon, 11 Feb 2002 12:17:01 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: VALARM: UID VS ALARMID [Was: Re: (ALARMREF?) ALARMID to VALARM after stored?] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 11 Feb 2002 15:24:49 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/11/2002 03:24:58 PM, Serialize complete at 02/11/2002 03:24:58 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Thus I await you opinions. ALARMID or UID? I favor UID. Consider what happens if we add global alarms someday, and someone wants to merge the contents of two CSes. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |Until you stalk and overrun, you can't devour anyone. --Hobbes| \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 11 15:51:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16843 for ; Mon, 11 Feb 2002 15:51:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BKdRs06333 for ietf-calendar-bks; Mon, 11 Feb 2002 12:39:27 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BKdQ306329 for ; Mon, 11 Feb 2002 12:39:26 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA00842; Mon, 11 Feb 2002 12:39:24 -0800 (PST) Message-ID: <3C682BF6.3190D012@Royer.com> Date: Mon, 11 Feb 2002 13:39:18 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Desruisseaux CC: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> Content-Type: multipart/mixed; boundary="------------3D457020EEC02CC1A4D4A23C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3D457020EEC02CC1A4D4A23C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > > The precedence rule could also be written as follow: > > > > > > If two rights exist and are in conflict, > > > the right that denies access always takes > > > precedence over the right that grant access. > > > > And add 'in VCARs' (as the denies are implied if they > > do not exist and those are not to be considered in conflict)? > > "If two rights specified in VCAR components are in conflict, > the right that denies access always takes precedence over > the right that grant access." > > Correct? Yes. > We need to stop talking about coalescence of VCARs since > there is no coalescence per say. Returned VCARs will > never contain more VRIGHT components than their stored > version. > > We only need the ability to return VCARs with the GRANT > and DENY properties "instantiated" to SELF(). > > Could we simply specify that: > > "When EXPAND is TRUE, only VCARs that pertain to the > authenticated user MUST be returned, and the GRANT > and DENY properties of the returned VCARs MUST only > specify the UPN of the authenticated users." > > Agree? No did not agree to drooping COALESCE. :-) So how about adding this: "A CS MAY return a dynamically generated VCAR in response to a query that is generated by the CS at the time of the query. This generated VCAR will have the DECREED property set to true. This will allow an implementations to limit the contents to the currently authenticated UPNs access when security does not permit non-owner UPNs to see the access rights that may effect other UPNs. The CARID of this dynamically generated VCAR MUST BE 'DYNAMIC'. Okay? --------------3D457020EEC02CC1A4D4A23C 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 ; Mon, 11 Feb 2002 16:13:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BL1oF06761 for ietf-calendar-bks; Mon, 11 Feb 2002 13:01:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BL1m306752 for ; Mon, 11 Feb 2002 13:01:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA00888 for ; Mon, 11 Feb 2002 13:01:49 -0800 (PST) Message-ID: <3C683138.EC5F2283@Royer.com> Date: Mon, 11 Feb 2002 14:01:44 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <5.1.0.14.0.20020208172641.02b35970@imap1.in.steltor.com> <5.1.0.14.0.20020211112535.01c5ddc8@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------47F99106E3964BD661814DEF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------47F99106E3964BD661814DEF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > > At 04:41 PM 08/02/2002 -0700, Doug Royer wrote: > >The RRULE is both multi-valued, and multi-instance. > >As in both of these are valid in a VEVENT and are equivalent. > > > > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 > > RRULE:FREQ=YEARLY;BYDAY=-1SA;BYMONTH=10 > > > >Is equivalent to: > > > > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=1,FREQ=YEARLY > > ;BYDAY=-1SA;BYMONTH=10 > > But RFC2445 has examples where RRULEs contain unescaped > commas within them, such as: > > RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 > > So I repeat my original statement about RRULE being a special case: > > "an exception to your multi-instance property 'rule' would > be the RRULE value, which uses the comma for it's own purposes." Well, it seems that the RECUR value type, breaks the rules in iCalendar :-) The text that defines RRULE specifically says that RRULE may be multi-value, then the examples break the rules. I think we need to re-quote John Postel's famous statement, something like,: Be liberal in what you accept, and conservative in what you generate. So, I think I will put quotes around the any RECUR values when I generate them, And I'll just have to figure it out when I parse them. > But if your statement above is correct, and multi-instance is > equivalent to multi-value (for the purposes of the query), then > the more powerful and flexible multi-instance syntax could be > used instead: > > SELECT * FROM VTODO > USING_PROPERTIES CATEGORIES cat1 > WHERE cat1 = 'BUSINESS' > > As an aside, I feel that for consistency this query should also > be considered equivalent with the others: > > SELECT * FROM VTODO > WHERE CATEGORIES = 'BUSINESS' > > i.e. a reference to a multi-instance/value property by name > refers to _any_ instance/value of that property within the component. Yes - I agree. If not for RRULE, but in general for any MULTI-INSTANCE, or MULTI-VALUE - properties that MAY exist, they MUST be equivalent. --------------47F99106E3964BD661814DEF 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 ; Mon, 11 Feb 2002 16:13:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BL42J06811 for ietf-calendar-bks; Mon, 11 Feb 2002 13:04:02 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BL41306807 for ; Mon, 11 Feb 2002 13:04:01 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA00892 for ; Mon, 11 Feb 2002 13:04:03 -0800 (PST) Message-ID: <3C6831BD.71606E8C@Royer.com> Date: Mon, 11 Feb 2002 14:03:57 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VCAR Proposal (#2) - PERMISSION - multi-valued? References: <3C606D02.70689642@steltor.com> <3C60880A.17B840FC@Royer.com> <3C62C0EF.AF1657E8@steltor.com> <3C62DE37.6712BE28@Royer.com> <3C62F8C4.C47A4D83@steltor.com> <3C630B57.AB69F1A6@Royer.com> <3C63DD89.2BEE1A2D@steltor.com> <5.1.0.14.0.20020208172641.02b35970@imap1.in.steltor.com> <3C64623B.B3A46DF1@Royer.com> <3C67D638.FBA83949@steltor.com> <5.1.0.14.0.20020211121607.0326eb20@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------004C3133B85FF2440A784FFE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------004C3133B85FF2440A784FFE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > > At 08:24 AM 11/02/2002 -0700, Doug Royer wrote: > >Bernard Desruisseaux wrote: > > > > > > Doug Royer wrote: > > > > > > > > The RRULE is both multi-valued, and multi-instance. > > > > > > You are wrong. RRULE is NOT multi-valued. > > > >I guess I was confused when I read in 2445: > > > > 4.3.10 Recurrence Rule > > > > > > Description: If the property permits, multiple "recur" values are > > specified by a COMMA character (US-ASCII decimal 44) separated list > > of values. ... > > I think 2445 was confused, as just a few lines below that it states: > > The BYSECOND rule part specifies a COMMA character (US-ASCII decimal > 44) separated list of seconds within a minute. > > (and similar for other rule parts), and then gives examples that use > the COMMA in this way. Yes, but in multi-value 'values', you have to quote the values in order to find the sets. I am willing to accept that if there is exactly one, it may contain anything including quotes. We need to make sure we are more conservative in CAP and do not make any mistakes :-) --------------004C3133B85FF2440A784FFE 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 ; Mon, 11 Feb 2002 16:22:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BL7fM06883 for ietf-calendar-bks; Mon, 11 Feb 2002 13:07:41 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BL7e306879 for ; Mon, 11 Feb 2002 13:07:40 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA00898 for ; Mon, 11 Feb 2002 13:07:41 -0800 (PST) Message-ID: <3C683297.EAFB620E@Royer.com> Date: Mon, 11 Feb 2002 14:07:35 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VALARM: UID VS ALARMID [Was: Re: (ALARMREF?) ALARMID to VALARM after stored?] References: <3BFD80A5.4F481F2D@steltor.com> <3BFEB264.634AA9C5@Royer.com> <3C04F209.7EB6CE09@steltor.com> <3C680C38.E16EE7D6@steltor.com> Content-Type: multipart/mixed; boundary="------------A4EFF79C4F1E0029ADA1E6CD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A4EFF79C4F1E0029ADA1E6CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > This was brought up a few times. We should > resolve it once and for all. > > CAP added a property to VALARM called "ALARMID." > Its value is unique within the scope of the > event, todo, or journal that it is found in. > It allows one to uniquely identify a VALARM > within a component. > > A suggestion was made to use UID instead of > ALARMID. UIDs are globally unique, thus one > can have global VALARMs in a future version > of CAP, if this feature is ever needed. > Furthermore, we reuse a property and do not > have to defined a new one. > > Thus I await you opinions. ALARMID or UID? I prefer ALARMID. I will be sending out in a day or so the 'LOCAL ONLY' proposal. If that or an idea like that goes, then I could go with UID. But if we don't somehow agree to mark the VALARMs as local, then there would be NO way to separate out who's VALARM+UID should be forwarded to delagated-to UPNs or which ones belong to the ORGANIZER and would be sent in COUNTER messages, and other such problems. --------------A4EFF79C4F1E0029ADA1E6CD 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 ; Mon, 11 Feb 2002 16:26:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BLAn106939 for ietf-calendar-bks; Mon, 11 Feb 2002 13:10:49 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BLAm306935 for ; Mon, 11 Feb 2002 13:10:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA00902 for ; Mon, 11 Feb 2002 13:10:50 -0800 (PST) Message-ID: <3C683354.C4558C24@Royer.com> Date: Mon, 11 Feb 2002 14:10:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Querying VALARM References: <3C682140.659FA9EF@steltor.com> Content-Type: multipart/mixed; boundary="------------30A23DFB2AA6ED4CA67C36A3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------30A23DFB2AA6ED4CA67C36A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > What is the proper VQUERY to get the VALARM components > of all the calendar components stored in a VAGENDA? > > BEGIN:VQUERY > QUERYNAME:Query-1 > QUERY:SELECT * FROM VALARM > END:VQUERY > > BEGIN:VQUERY > QUERYNAME:Query-2 > QUERY:SELECT VALARM FROM VTODO > QUERY:SELECT VALARM FROM VEVENT > END:VQUERY > > I would say (2). I also agree. > Since (1) should be used to get only > the VALARM components stored directly in the VAGENDA > (which is currently not allowed). We need to add text that says if the QUERY does not specify then it is from the 'TARGET'. So if the TARGET is the CALSTORE, then it comes from the CALSTORE, if the TARGET is the CALID or RELCALID, then it comes from the VAGENDA. Agree? --------------30A23DFB2AA6ED4CA67C36A3 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 ; Mon, 11 Feb 2002 16:28:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BLIcu07082 for ietf-calendar-bks; Mon, 11 Feb 2002 13:18:38 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BLIb307078 for ; Mon, 11 Feb 2002 13:18:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA00930 for ; Mon, 11 Feb 2002 13:18:38 -0800 (PST) Message-ID: <3C683528.52BE4451@Royer.com> Date: Mon, 11 Feb 2002 14:18:32 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: List Of Items (crisp) References: Content-Type: multipart/mixed; boundary="------------3715AE456ADEA2B116D5CB42" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3715AE456ADEA2B116D5CB42 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >(1) CRISP needs to be updated. It is not in sync with CAP (beep). > > True. I'll see if I can get to that soon. > > >(2) We need to make sure that QUERYLEVEL and CAPABILITIES > > allow for iana and X-tokens. > > > > Do we say that if xxx does not exists, then > > the CS does not support ANY VCARs? > > > > Do we say that if xxx does not > > exist, then no query is supported on the CS? > > It might be better if these statements are made explicitly (e.g., > "" or "none"), so that it's obvious that a missing > element is a bug. Sounds good to me. As you are the most interested. Be sure to PING us when we do last call if 'none' is not a valid querylevel. > >(3) It is not clear to me if a CRISP server sends some kind > > of capability specifying the fact it only supports iTIP > > methods. > > That's the intent in my older drafts. I'll have to dig into the > latest CAP version to see whether I can say that explicitly, or (as > you suggested a month or few ago) just say "I'm CRISP". get-capabilities returns ? > >(4) There would have to be some MINIMUM predefined VCAR support > > in a CRISP server, else how would implementations say > > that UPN-X can make requests, and UPN-Y can not. > > Um...I don't think we can do that, really. The point of CRISP is to > carry iTIP operations from users who don't have accounts on the local > CS; and we have no way of authenticating remote users. I see your point. But how about defining in CRISP the VCAR that allows users to understand what they are being allowed to do? At the very least, they are allowed to deposit: METHOD:REQUEST Perhaps: METHOD:COUNTER METHOD:ADD Maybe: METHOD:DECLINE-COUNTER What about: METHOD:CANCEL See my point? What can they do - EVERYTHING as long as it is an iTIP METHOD? If yes - then I would like to see the VCAR that you are proposing as the restriction. > >(5) Would we have to generate some kind of capability that > > specified which components the server supported? Or > > should this be specified in CRISP as a CAP extension? > > Hmm. I've always thought that a base CAP client (written by someone > who never read the CRISP spec) should be able to talk to a CRISP > server and understand its capabilities; that's why I took the approach > of defining "NONE" capabilities. However, it now occurs to me that a > client has to be written specifically to take advantage of CRISP, > because a CRISP client has to log in with no credentials, which it > would never do in CAP. Or how about they just authenticate as anonymous? --------------3715AE456ADEA2B116D5CB42 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 ; Mon, 11 Feb 2002 16:50:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BLan307503 for ietf-calendar-bks; Mon, 11 Feb 2002 13:36:49 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BLal307499 for ; Mon, 11 Feb 2002 13:36:48 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA04313; Mon, 11 Feb 2002 16:36:44 -0500 Received: from steltor.com ([101.0.0.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BLahQ09933; Mon, 11 Feb 2002 16:36:43 -0500 (EST) Message-ID: <3C6839B8.18B1D187@steltor.com> Date: Mon, 11 Feb 2002 16:38:00 -0500 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: List Of Remaining Items To Resolve For Last Call 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 The list of items that we need consensus on or that we need to fix in order to achieve last call is available at: http://calsch.org/ietf/items.html The people responsible for these items should be making proposals this week. If there are any mistakes or anything that is missing please let us know. George From owner-ietf-calendar@mail.imc.org Mon Feb 11 17:01:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18991 for ; Mon, 11 Feb 2002 17:01:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BLoA407814 for ietf-calendar-bks; Mon, 11 Feb 2002 13:50:10 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BLo9307810 for ; Mon, 11 Feb 2002 13:50:09 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA04715; Mon, 11 Feb 2002 16:50:06 -0500 Received: from steltor.com ([101.0.0.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BLo1Q11724; Mon, 11 Feb 2002 16:50:02 -0500 (EST) Message-ID: <3C683CD6.4A99D3E8@steltor.com> Date: Mon, 11 Feb 2002 16:51:18 -0500 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP (ICAL Version 2.0) - latest intem draft References: <3C3B5909.79854088@Royer.com> <3C3DEE7C.341FC8D7@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 Fixed! George Babics wrote: > > Doug Royer wrote: > > > > In 2.2 is says near the top: > > > > > [ICAL] Version 2.0 describes components such as events, todos, > > > alarms, and timezones. > > > > Version 2.0 is NOT the vesion of ICAL, it is the version > > of the data format. > > > > Replace with? : > > > > [ICAL] describes components such as events, todos, > > alarms, and timezones. > > Yes we should. > > George From owner-ietf-calendar@mail.imc.org Mon Feb 11 17:48:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19876 for ; Mon, 11 Feb 2002 17:48:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BMYhF08705 for ietf-calendar-bks; Mon, 11 Feb 2002 14:34:43 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BMYa308701 for ; Mon, 11 Feb 2002 14:34:42 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: List Of Items (crisp) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 11 Feb 2002 17:42:23 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/11/2002 05:42:39 PM, Serialize complete at 02/11/2002 05:42:39 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Sounds good to me. As you are the most interested. Be sure >to PING us when we do last call if 'none' is not a valid >querylevel. OK, will do. >> latest CAP version to see whether I can say that explicitly, or (as >> you suggested a month or few ago) just say "I'm CRISP". > > get-capabilities returns ? Yeah, like that. >I see your point. But how about defining in CRISP the VCAR >that allows users to understand what they are being allowed to do? That makes sense. It wouldn't be modifiable, but making it expressible would help. >> because a CRISP client has to log in with no credentials, which it >> would never do in CAP. > >Or how about they just authenticate as anonymous? Sure...but, either way, "send an iTIP message to a server where I don't have an account" is a sharp departure from "perform operations on my home server", so we don't need to make the interaction models completely congruent. This makes it easier to write CRISP in a way that won't hold back CAP. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Cogito ergo Spud. (I think, therefore I yam.) | \========================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 11 17:50:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19933 for ; Mon, 11 Feb 2002 17:50:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1BMau008761 for ietf-calendar-bks; Mon, 11 Feb 2002 14:36:56 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BMat308757 for ; Mon, 11 Feb 2002 14:36:55 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA05858; Mon, 11 Feb 2002 17:36:49 -0500 Received: from steltor.com ([101.0.0.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BMalQ17148; Mon, 11 Feb 2002 17:36:48 -0500 (EST) Message-ID: <3C6847CC.5BCCEB5C@steltor.com> Date: Mon, 11 Feb 2002 17:38:04 -0500 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: John Stracke , calsch WG Subject: Re: CAP: inconsistency in Overlapped Booking definition References: <3B7C1184.2070801@ecal.com> <3B7EBB55.D160133F@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 I propose we change the definition to: Overlapped Booking A policy which indicates whether or not OPAQUE entries can overlap one another in a calendar. Or we remove the definition. It seems to refer to the ALLOW-CONFLICT property in VAGENDA. Do we need the definition of two different terms that mean the same thing? The old definition was: Overlapped Booking A policy which indicates whether or not OPAQUE events can overlap one another. When the policy is applied to a calendar it indicates whether or not the time span of any entry (VEVENT, VTODO, ...) in the calendar can overlap the time span of any other entry in the same calendar. When applied to an individual entry, it indicates whether or not any other entry's time span can overlap that individual entry. George George Babics wrote: > > Yes it seems wrong. Anyone know of why we need or wanted Overlapped > Booking policies for individual entries? > > If there are no objections, I'll fix the definition of > Overlapped Booking. > > George > > John Stracke wrote: > > > > In section 1.3, the definition of Overlapped Booking says it's a > > policy that can be applied to a calendar or an individual entry. > > However, the definition of Calendar Policy seems to indicate that > > policies apply only to calendars; this is inconsistent. > > > > In any case, it seems like an Overlapped Booking policy for individual > > entries would be redundant, since the same effect can be obtained by the > > TRANSP property on VEVENTs. > > > > -- > > /=================================================================\ > > |John Stracke | http://www.ecal.com |My opinions are my own. | > > |Chief Scientist |================================================| > > |eCal Corp. |Dave Barry for President! He'll Keep Dan Quayle.| > > |francis@ecal.com |(OK, it's old) | > > \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 11 18:04:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20076 for ; Mon, 11 Feb 2002 18:04:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BMrmr09045 for ietf-calendar-bks; Mon, 11 Feb 2002 14:53:48 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BMrl309041 for ; Mon, 11 Feb 2002 14:53:47 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: ALARMID to VALARM after stored? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02062002 February 06, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Feb 2002 18:00:42 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02042002|February 04, 2002) at 02/11/2002 05:49:07 PM, Serialize complete at 02/11/2002 05:49:07 PM Content-Type: multipart/alternative; boundary="=_alternative 007DAAE385256B5D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007DAAE385256B5D_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 14-Nov-2001: > I think we should declare that this is a '1' and not > a '0 or 1'. Any CUA that gets a non-CAP object can > easily add a ALARMID, but it would be a pain to add > one later. Just how does a CUA that added an ALARMID (or UID) to a VALARM keep track of it when a reschedule comes in from a non-CAP source? There may be > 1 VALARM on iCalendar stream and the order is not guaranteed to be preserved. So how does a CAP client go about 'fixing up' the ALARMID on the update(s) to match those it created originally? Or does it just toss away any existing VALARMS and recreate and reassign new ALARMIDs? This is somewhat problematic in that a CU can add their own VALARMs to the entry and blindly destroying all VALARMS and reassigning new ALARMIDs effectively removes any custom alarms they set. It also makes doing sync hard/impossible in that depending on how ALARMIDs are re/assigned multiple instances may get created or worse, VALARMS may not get set as expected. In the past there was no issue with "which VALARM was edited" because the entity was self contained; no deltas were sent. As such, the VALARMs on the iCalendar stream were the ones that belonged. In an attempt to make CAP utilize a delta model (one where only changes are sent over the wire) you introduce a set of problems we did not have when always sending a complete snapshot (ie: iTIP). Im not sure that this proposal will solve the issue related to delta detection in multiple VALARMs if you have to also deal w/data that comes from outside CAP where there is no concept of having to deal w/it. Perhaps its just the end of a long day and Im not seeing it so perhaps someone can explain how CAP<->non-CAP interactions where multiple VALARMs (or any other contained component for that matte) fully works when CAP is on the receiving side of the data... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007DAAE385256B5D_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 14-Nov-2001:
> I think we should declare that this is a '1' and not
> a '0 or 1'.  Any CUA that gets a non-CAP object can
> easily add a ALARMID, but it would be a pain to add
> one later.

Just how does a CUA that added an ALARMID (or UID) to a VALARM keep track of it when a reschedule comes in from a non-CAP source?  There may be > 1 VALARM on iCalendar stream and the order is not guaranteed to be preserved.  So how does a CAP client go about 'fixing up' the ALARMID on the update(s) to match those it created originally?  

Or does it just toss away any existing VALARMS and recreate and reassign new ALARMIDs?  This is somewhat problematic in that a CU can add their own VALARMs to the entry and blindly destroying all VALARMS and reassigning new ALARMIDs effectively removes any custom alarms they set.  It also makes doing sync hard/impossible in that depending on how ALARMIDs are re/assigned multiple instances may get created or worse, VALARMS may not get set as expected.

In the past there was no issue with "which VALARM was edited" because the entity was self contained; no deltas were sent.  As such, the VALARMs on the iCalendar stream were the ones that belonged.  In an attempt to make CAP utilize a delta model (one where only changes are sent over the wire) you introduce a set of problems we did not have when always sending a complete snapshot (ie: iTIP).  Im not sure that this proposal will solve the issue related to delta detection in multiple VALARMs if you have to also deal w/data that comes from outside CAP where there is no concept of having to deal w/it.

Perhaps its just the end of a long day and Im not seeing it so perhaps someone can explain how CAP<->non-CAP interactions where multiple VALARMs (or any other contained component for that matte) fully works when CAP is on the receiving side of the data...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 007DAAE385256B5D_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 11 19:22:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20841 for ; Mon, 11 Feb 2002 19:22:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1C0BgG10192 for ietf-calendar-bks; Mon, 11 Feb 2002 16:11:42 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C0Bd310183 for ; Mon, 11 Feb 2002 16:11:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA01203 for ; Mon, 11 Feb 2002 16:11:41 -0800 (PST) Message-ID: <3C685DB5.5A1E56DA@Royer.com> Date: Mon, 11 Feb 2002 17:11:33 -0700 From: Doug Royer Reply-To: calsch@royer.com, WG@royer.com Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: inconsistency in Overlapped Booking definition References: <3B7C1184.2070801@ecal.com> <3B7EBB55.D160133F@steltor.com> <3C6847CC.5BCCEB5C@steltor.com> Content-Type: multipart/mixed; boundary="------------D99D79608B4388524411BCF8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D99D79608B4388524411BCF8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > I propose we change the definition to: > > Overlapped Booking > > A policy which indicates whether or not OPAQUE entries can > overlap one another in a calendar. I am not sure what you are saying. If you are saying there are two definitions and you want to clean that up - GREAT. However the new text your are proposing seems to drop some information. If you are saying drop the component specific: TRANSP:TRANSPARENT-NOCONFLICT and TRANSP:OPAQUE-NOCONFLICT No - they were debated and added for a reason. There were two needs: (1) Setting a rule for the calendar which the components can not violate. Which allows the calendar to never allow overlapped bookings. This was ALLOW-CONFLICTS and I think it needs to stay. Otherwise it is difficult to have a resource calendar. If you are saying you want to change the name of the property - I have no problem with that. (2) The other is when a specific component can not be overlapped with any other component but other components in the same calendar might allow overlapping between each other. We need to keep both, that is we need to keep the calendar level ALLOW-CONFLICTS and both of the new TRANSP property values TRANSPARENT-NOCONFLICT and OPAQUE-NOCONFLICT that are defined in CAP. And the text definition for Overlapped Booking need to describe both (1) and (2). > Or we remove the definition. It seems to refer to the ALLOW-CONFLICT > property in VAGENDA. Do we need the definition of two different terms > that mean the same thing? I am not sure what the 'other' term is? (1) ALLOW-CONFLICT and (2) ??? See my comments to John's post below. > The old definition was: > > Overlapped Booking > > A policy which indicates whether or not OPAQUE events can > overlap one another. When the policy is applied to a calendar > it indicates whether or not the time span of any entry (VEVENT, > VTODO, ...) in the calendar can overlap the time span of any > other entry in the same calendar. When applied to an > individual entry, it indicates whether or not any other entry's > time span can overlap that individual entry. > > George > > George Babics wrote: > > > > Yes it seems wrong. Anyone know of why we need or wanted Overlapped > > Booking policies for individual entries? > > > > If there are no objections, I'll fix the definition of > > Overlapped Booking. > > > > George > > > > John Stracke wrote: > > > > > > In section 1.3, the definition of Overlapped Booking says it's a > > > policy that can be applied to a calendar or an individual entry. > > > However, the definition of Calendar Policy seems to indicate that > > > policies apply only to calendars; this is inconsistent. > > > > > > In any case, it seems like an Overlapped Booking policy for > > > individual entries would be redundant, since the same effect > > > can be obtained by the TRANSP property on VEVENTs. The definition for Overlapped booking in section 1.3 describes both the TRANSP and calendar wide setting ALLOW-CONFLICTS. I don't see the conflict you are describing. 5.2 Access Control and NOCONFLICT The TRANSP property can take on values (TRANSPARENT-NOCONFLICT, OPAQUE-NOCONFLICT) that prohibit other events from overlapping it. This setting overrides access. The ALLOW-CONFLICT Calendar or component setting may also prevent overlap, returning an error code "6.3" And as it is an 'or'; Then ALLOW-CONFLICT set to FALSE means that the entire calendar is blocked from overlapped components no matter what the component entry says. A meeting room calendar for example would have ALLOW-CONFLICT set to FALSE and no one could double book the same time. This was preferred to forcing the CUA to guess why the bookings failed with permission denied if they did not book a time slot. Even if the CUA deposited an entry that said TRANSP:OPAQUE and not TRANSP:OPAQUE-NOCONFLICT as pre-CAP CUA will do. The reason for allowing single component overlap blocking: There are times when you can't be two places at once (vacation for example) and yet you may wish to have other times slots where you have not yet decided which to attend (This boring meeting or the other boring meeting). --------------D99D79608B4388524411BCF8 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 ; Mon, 11 Feb 2002 19:38:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1C0Mbb10371 for ietf-calendar-bks; Mon, 11 Feb 2002 16:22:37 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C0MN310367 for ; Mon, 11 Feb 2002 16:22:26 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA01223; Mon, 11 Feb 2002 16:22:10 -0800 (PST) Message-ID: <3C68602B.B1EFBDB9@Royer.com> Date: Mon, 11 Feb 2002 17:22:03 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: George Babics , "ietf-calendar@imc.org" Subject: Re: CAP: List Of Remaining Items To Resolve For Last Call References: <3C6839B8.18B1D187@steltor.com> Content-Type: multipart/mixed; boundary="------------B9C3D15DFF5B60A9314D27FF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B9C3D15DFF5B60A9314D27FF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > The list of items that we need consensus on or that we need to > fix in order to achieve last call is available at: > > http://calsch.org/ietf/items.html > > The people responsible for these items should be making proposals > this week. > > If there are any mistakes or anything that is missing > please let us know. Missing: How to tag local changes so you don't break iTIP Byte reduction in BEEP layer. Remove as it is a subset of create. Add METHOD back to objects. Modify back to 05 modify - part of byte reduction. --------------B9C3D15DFF5B60A9314D27FF 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 ; Mon, 11 Feb 2002 19:44:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1C0XeC10531 for ietf-calendar-bks; Mon, 11 Feb 2002 16:33:40 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C0Xc310526 for ; Mon, 11 Feb 2002 16:33:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA01231; Mon, 11 Feb 2002 16:33:40 -0800 (PST) Message-ID: <3C6862DD.E2EC8433@Royer.com> Date: Mon, 11 Feb 2002 17:33:33 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ALARMID to VALARM after stored? References: Content-Type: multipart/mixed; boundary="------------909E0CE9FCD84C733B312CF5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------909E0CE9FCD84C733B312CF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 14-Nov-2001: > > I think we should declare that this is a '1' and not > > a '0 or 1'. Any CUA that gets a non-CAP object can > > easily add a ALARMID, but it would be a pain to add > > one later. > > Just how does a CUA that added an ALARMID (or UID) to a VALARM keep > track of it when a reschedule comes in from a non-CAP source? I think this email you are quoting was part of my email (or thread) that led to the discussion about how to tag data as local only. The rest of that thread (and a new version of my proposal will be out tomorrow night). > There > may be > 1 VALARM on iCalendar stream and the order is not guaranteed > to be preserved. So how does a CAP client go about 'fixing up' the > ALARMID on the update(s) to match those it created originally? Fixing up? I had proposed that SEQUENCE be used and not ALARMID. And I had proposed a parameter that tagged as local only and NEVER to be given to a non-owner. > Or does it just toss away any existing VALARMS and recreate and > reassign new ALARMIDs? I really don't think you think I think that :) I had proposed how to tag local only VALARMS so that there would never be any such conflict. Global UID's have a similar problem. If we don't agree how to tag local-only VALARMs, then it may be impossible to REFRESH your entry and not blow away your VALARMs when the CUA and CS are not from the same vendor. > This is somewhat problematic in that a CU can > add their own VALARMs to the entry and blindly destroying all VALARMS > and reassigning new ALARMIDs effectively removes any custom alarms > they set. It also makes doing sync hard/impossible in that depending > on how ALARMIDs are re/assigned multiple instances may get created or > worse, VALARMS may not get set as expected. I am not sure why you think that I proposed that a CUA blow away existing VALARMS. At no point did I say that a CUA can reuse ALARMIDs that already exist in a component. > In the past there was no issue with "which VALARM was edited" because > the entity was self contained; no deltas were sent. As such, the > VALARMs on the iCalendar stream were the ones that belonged. In an > attempt to make CAP utilize a delta model (one where only changes are > sent over the wire) you introduce a set of problems we did not have > when always sending a complete snapshot (ie: iTIP). Im not sure that > this proposal will solve the issue related to delta detection in > multiple VALARMs if you have to also deal w/data that comes from > outside CAP where there is no concept of having to deal w/it. ALARMID was used as a way to say which VALARM you were referring to in a VQUERY or MODIFY. At that time I don't recall that we ever discussed local vs ORGANIZER VALARMs. With my proposal (which I am re-writing), a CUA can tell if they came from the ORGANIZER or not. No matter what we do, existing CUAs will not uniquely tag the VALARMs. But they don't have to because existing CUAs can only iTIP and as you point out they will send the entire object again when needed. We are trying to figure out a way that will allow the full iTIP and OLD CUAs to still work - and at the same time give new CUAs the ability to tag VALARMS and a way for the CAP-CUA to 'know' how to not send local-VALARMs back up the pipe to the iTIP only ORGANIZER. Plus adding a new property to VALARM will not break old CUAs - they simply will not know what to do with it. > Perhaps its just the end of a long day and Im not seeing it so perhaps > someone can explain how CAP<->non-CAP interactions where multiple > VALARMs (or any other contained component for that matte) fully works > when CAP is on the receiving side of the data... Tomorrow. --------------909E0CE9FCD84C733B312CF5 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 ; Mon, 11 Feb 2002 20:15:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1C12Bd10969 for ietf-calendar-bks; Mon, 11 Feb 2002 17:02:11 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C129310965 for ; Mon, 11 Feb 2002 17:02:09 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA01282 for ; Mon, 11 Feb 2002 17:02:11 -0800 (PST) Message-ID: <3C68698B.6CFC51A7@Royer.com> Date: Mon, 11 Feb 2002 18:02:03 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: (#2) Byte reduction in BEEP commands. Content-Type: multipart/mixed; boundary="------------FB3EA2514CC5C6CF55D01CE4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FB3EA2514CC5C6CF55D01CE4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When NOT synching calendars, the command byte overhead used in draft 06 exceeds the size of the data. If we switch to CDATA and eliminate what I will call a couple of "wrapper tag"s, the byte count goes way down. Just as an example, I'll use "3.3 Bounded Latency", followed by brief examples of the other commands. Put the METHOD, TARGET, and optional CMDID back into the data. (Assume they are in these brief examples). Change the command in the existing example: FROM: C: Content-Type: multipart/related; boundary="boundary-zxy123"; C: start="1@cal.example.com"; C: type="application/beep+xml" C: C: --boundary-zxy123 C: Content-Type: application/beep+xml C: Content-ID: 1@cal.example.com C: C: C: C: C: C: --boundary-zxy123 C: Content-Type: text/calendar C: Content-ID: 2@cal.example.com C: C: BEGIN:VCALENDAR C: BEGIN:VQUERY C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT C: WHERE DTEND >= '19990714T080000Z' AND C: DTSTART <= '19990715T080000Z' C: END:VQUERY C: END:VCALENDAR TO: C:Content-Type: application/...beep... C: C: C: = '19990714T080000' AND C: DTSTART <= '19990715T080000' C: END:VQUERY C: END:VCALENDAR C: ]]> S: C: C: ]]> ----------------------------------------------------------- [ Assume all of the following examples have the MIME and BEEP MIME headers...] [ And assume that when the server reply is not listed, it is like the above example] ----------------------------------------------------------- 6.1.1 "generate-uid" Command [remove the and tags> in the reply. TO: C: S: S: 20011121T120000Z-12342@cal.example.com S: 20011121T120000Z-12343@cal.example.com S: 20011121T120000Z-12344@cal.example.com S: -------------------------------------------------------------- And I changed the names to MATCH (case) the iCalendar objects. As iCalendar objects are upper case, the same named objects should be here. And I upper cased the new ones in CAP to be consistent with iCalendar. And I changed the names of the CAPABILITY replies to be the same as the PROPERTY names they map to (same case). There is a typo in 06 on the name of date max and date min. 6.1.2 "capability" Command C: S: S:1.0 S:bla bla bla S:... S:CAR-FULL-1 S:00000101T000000Z S:99991231T235959Z S:0 S:1.0 S: ----------------------------------------------------------------- 6.1.3 "identify" Command There was NO example for IDENTIFY, so I propose: C: S: ...empty BEEP RPY is success... S: ...else CAP error message in BEEP CDATA reply... ----------------------------------------------------------------- 6.1.4 "noop" Command C: [ As there is nothing to fail, an empty BEEP reply] ------------------------------------------------------------------- 6.2.4.1 "create" Command C: C: ------------------------------------------------------------------- 6.2.4.2 "delete" Command C: C: ------------------------------------------------------------------- Plus change the MODIFY iCalendar objects back to the way they were in the 05 draft. C: C: ------------------------------------------------------------------- 6.2.4.4 "move" Command [MOVE OF CALENDAR HAD BEEN DELETED] ------------------------------------------------------------------- 6.2.4.5 "search" Command C: C: [ The REPLY contains REPLY-STATUS on failure, or the data in CDATA format] ------------------------------------------------------------------- Drop this section entirely. As the METHOD is now back in the iCalendar objects, just deposit them with the command into the CS. 6.3 Scheduling Commands 6.3.1 "schedule" Command 6.3.2 Processing Scheduling Components A CUA processes iTIP data, the CS just stores them. Change to description on how the CUA performs VQUERY to get the data that has been deposited. Drop the command. ------------------------------------------------------------------- --------------FB3EA2514CC5C6CF55D01CE4 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 ; Mon, 11 Feb 2002 22:06:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1C2sK313292 for ietf-calendar-bks; Mon, 11 Feb 2002 18:54:20 -0800 (PST) Received: from notes-int01.santista.com.br ([200.245.196.235]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C2sH313282 for ; Mon, 11 Feb 2002 18:54:18 -0800 (PST) Subject: Resposta =?iso-8859-1?q?Autom=E1tica_de_Walter_Sanches_[_Automatic_Reply_]?= From: wsanches@santista.com.br To: "ietf-calendar@imc.org" Message-ID: Date: Tue, 12 Feb 2002 01:00:38 -0300 X-MIMETrack: Serialize by Router on NOTES-INT01/SANTISTA/BR(Release 5.0.4 |June 8, 2000) at 02/12/2002 01:05:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1C2sI313285 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I will be out of the office starting 09/02/2002 and will not return until 13/02/2002. I will respond to your message when I return. -------------- Estarei fora da empresa no período de 09/02 a 13/02 (feriado de Carnaval) From owner-ietf-calendar@mail.imc.org Tue Feb 12 10:08:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14358 for ; Tue, 12 Feb 2002 10:08:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CEpZc04884 for ietf-calendar-bks; Tue, 12 Feb 2002 06:51:35 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CEpY304880 for ; Tue, 12 Feb 2002 06:51:34 -0800 (PST) To: calsch WG Subject: Re: CAP: inconsistency in Overlapped Booking definition MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 12 Feb 2002 09:59:24 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/12/2002 09:59:33 AM, Serialize complete at 02/12/2002 09:59:33 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Overlapped Booking > > A policy which indicates whether or not OPAQUE entries can > overlap one another in a calendar. > >Or we remove the definition. It seems to refer to the ALLOW-CONFLICT >property in VAGENDA. Do we need the definition of two different terms >that mean the same thing? They're not quite the same thing, though. If the CS has a policy against overlapped booking, then you can't turn on the ALLOW-CONFLICT property. Having them both, though, does introduce some extra complication: if overlapped booking is forbidden, and I try to turn on ALLOW-CONFLICT, then what kind of error message do I get? /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Vote for Ron, and nobody gets hurt! --actual campaign poster from| |Chicago | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 12 10:10:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14464 for ; Tue, 12 Feb 2002 10:10:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CExaM05130 for ietf-calendar-bks; Tue, 12 Feb 2002 06:59:36 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CExY305122 for ; Tue, 12 Feb 2002 06:59:34 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA14925 for ; Tue, 12 Feb 2002 09:59:30 -0500 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 g1CExUQ12432 for ; Tue, 12 Feb 2002 09:59:30 -0500 (EST) Subject: Re: (#2) Byte reduction in BEEP commands. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C68698B.6CFC51A7@Royer.com> References: <3C68698B.6CFC51A7@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Feb 2002 10:06:56 -0500 Message-Id: <1013526416.24764.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 Mon, 2002-02-11 at 20:02, Doug Royer wrote: ... > > Put the METHOD, TARGET, and optional CMDID back into > the data. (Assume they are in these brief examples). As mentioned in: http://www.imc.org/ietf-calendar/mail-archive/msg03701.html CMDID is used by other commands that do not include an iCalendar object. > > -------------------------------------------------------------- > > And I changed the names to MATCH (case) the iCalendar objects. > As iCalendar objects are upper case, the same named objects > should be here. And I upper cased the new ones in CAP to > be consistent with iCalendar. And I changed the names > of the CAPABILITY replies to be the same as the PROPERTY > names they map to (same case). I don't understand, your example is in lower case. Furthermore as mentioned by John iCalender in case insensitive. see: http://www.imc.org/ietf-calendar/mail-archive/msg03749.html > > There is a typo in 06 on the name of date max and date min. > > 6.1.2 "capability" Command > > C: > > S: > S:1.0 > S:bla bla bla > S:... > S:CAR-FULL-1 > S:00000101T000000Z > S:99991231T235959Z > S:0 > S:1.0 > S: > > ----------------------------------------------------------------- > 6.1.3 "identify" Command > > There was NO example for IDENTIFY, so I propose: > > C: > > S: ...empty BEEP RPY is success... > S: ...else CAP error message in BEEP CDATA reply... As mentioned in: http://www.imc.org/ietf-calendar/mail-archive/msg03704.html I find the empty RPY very awkward. If you send a command in XML you should receive a response in XML. It's consistent and easy to document in the BEEP registration template (all entries refers to the DTD). > ------------------------------------------------------------------- > > Plus change the MODIFY iCalendar objects back to the way > they were in the 05 draft. > > C: > C: C: BEGIN:VCALENDAR > C: CMDID:unique-id > C: TARGET:opaqueid101 > C: METHOD:DELETE > C: ... > C: BEGIN:VQUERY > C: ...selection criteria... > C: END:VQUERY > C: BEGIN:VCALENDAR > C: ...old was data... > C: END:VCALENDAR > C: BEGIN:VCALENDAR > C: ...new going to be data... > C: END:VCALENDAR > C: END:VCALENDAR > C: ]]> I don't understand, what is the purpose of a METHOD:DELETE in a modify command? > ------------------------------------------------------------------- > > Drop this section entirely. As the METHOD is now back in > the iCalendar objects, just deposit them with the command > into the CS. > > 6.3 Scheduling Commands > 6.3.1 "schedule" Command > 6.3.2 Processing Scheduling Components > > A CUA processes iTIP data, the CS just stores them. That's not exactly true. When storing an iTIP object, the CS do perform some processing on the iTIP object. e.g,., The following iTIP object: BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT ... END:VEVENT END:VCALENDAR is stored as: BEGIN:VEVENT METHOD:REQUEST ... END:VEVENT As such the schedule command is not identical to the create command. From owner-ietf-calendar@mail.imc.org Tue Feb 12 10:14:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14696 for ; Tue, 12 Feb 2002 10:14:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CF3Ch05339 for ietf-calendar-bks; Tue, 12 Feb 2002 07:03:12 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CF3B305335 for ; Tue, 12 Feb 2002 07:03:11 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA14991 for ; Tue, 12 Feb 2002 10:03:07 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CF36Q12567 for ; Tue, 12 Feb 2002 10:03:06 -0500 (EST) Message-ID: <3C692F25.28A97663@steltor.com> Date: Tue, 12 Feb 2002 10:05:09 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@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: > > > > We need to stop talking about coalescence of VCARs since > > there is no coalescence per say. Returned VCARs will > > never contain more VRIGHT components than their stored > > version. > > > > We only need the ability to return VCARs with the GRANT > > and DENY properties "instantiated" to SELF(). > > > > Could we simply specify that: > > > > "When EXPAND is TRUE, only VCARs that pertain to the > > authenticated user MUST be returned, and the GRANT > > and DENY properties of the returned VCARs MUST only > > specify the UPN of the authenticated users." > > > > Agree? > > No did not agree to drooping COALESCE. :-) > > So how about adding this: > > "A CS MAY return a dynamically generated VCAR in response to > a query that is generated by the CS at the time of the query. > This generated VCAR will have the DECREED property set to true. > This will allow an implementations to limit the contents to > the currently authenticated UPNs access when security does > not permit non-owner UPNs to see the access rights that may > effect other UPNs. The CARID of this dynamically generated > VCAR MUST BE 'DYNAMIC'. 1- I don't see the shadow of a hint of a suggestion of the concept of "COALESCE" in this proposal. Coalesce means "unite into one". We don't need to unite multiple VCAR components into one to limit their contents to the access rights that pertain to the currently authenticated user. Under no circumstances will the CS need to return VCAR components with more VRIGHT components than their stored version. On the contrary, the CS MAY return VCAR components with less VRIGHT components than their stored version. 2- By definition DECREED VCARs are persistent and immutable. A DECREED VCAR with CARID:DYNAMIC is simply nonsensical. CAP just need to specify the following: When EXPAND is TRUE, the CS MUST only specify the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components. VRIGHT components that don't pertain to the currently authenticated user MUST be left out of the returned VCAR components. The CS MAY only specify the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components not owned by the currently authenticated user for security reasons. VRIGHT components that don't pertain to the currently authenticated user MAY be left out of the returned VCAR not owned by the currently authenticated user for security reasons. Agree? Regards, 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 Feb 12 10:35:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15395 for ; Tue, 12 Feb 2002 10:35:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CFOuK06569 for ietf-calendar-bks; Tue, 12 Feb 2002 07:24:56 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CFOs306563 for ; Tue, 12 Feb 2002 07:24:54 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 12 Feb 2002 10:32:44 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/12/2002 10:32:53 AM, Serialize complete at 02/12/2002 10:32:53 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >BEGIN:VCALENDAR >METHOD:REQUEST >BEGIN:VEVENT >... >END:VEVENT >END:VCALENDAR > >is stored as: > >BEGIN:VEVENT >METHOD:REQUEST >... >END:VEVENT Wait a minute--what happens if the iTIP VCALENDAR contains more than one component (e.g., a VEVENT and a VTIMEZONE)? How are they kept together? /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |"Baldric, how did you manage to find a turnip that cost 400,000| |pounds?" "Well, I had to haggle." --Blackadder III | \===============================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 12 11:13:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16730 for ; Tue, 12 Feb 2002 11:13:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1CFuYp08565 for ietf-calendar-bks; Tue, 12 Feb 2002 07:56:34 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CFuX308561 for ; Tue, 12 Feb 2002 07:56:33 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA16719 for ; Tue, 12 Feb 2002 10:56:29 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CFuRQ19448 for ; Tue, 12 Feb 2002 10:56:28 -0500 (EST) Message-ID: <3C693BA5.78614FEB@steltor.com> Date: Tue, 12 Feb 2002 10:58:29 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: (#2) Byte reduction in BEEP commands. 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: > > >BEGIN:VCALENDAR > >METHOD:REQUEST > >BEGIN:VEVENT > >... > >END:VEVENT > >END:VCALENDAR > > > >is stored as: > > > >BEGIN:VEVENT > >METHOD:REQUEST > >... > >END:VEVENT > > Wait a minute--what happens if the iTIP VCALENDAR contains more than one > component (e.g., a VEVENT and a VTIMEZONE)? How are they kept together? And what happens with recurring VEVENT with exceptions? BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT UID:abc123 RRULE:... ... END:VEVENT BEGIN:VEVENT UID:abc123 ... exception 1... END:VEVENT BEGIN:VEVENT UID:abc123 ... exception 2... END:VEVENT END:VCALENDAR Which VEVENT ends up with METHOD:REQUEST in the CS? Regards, 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 Feb 12 11:20:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16939 for ; Tue, 12 Feb 2002 11:19:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CGA0208925 for ietf-calendar-bks; Tue, 12 Feb 2002 08:10:00 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CG9x308921 for ; Tue, 12 Feb 2002 08:09:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA02233 for ; Tue, 12 Feb 2002 08:09:59 -0800 (PST) Message-ID: <3C693E53.56773327@Royer.com> Date: Tue, 12 Feb 2002 09:09:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> Content-Type: multipart/mixed; boundary="------------70B5AB3EC0892C514ABFCE10" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------70B5AB3EC0892C514ABFCE10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > No did not agree to drooping COALESCE. :-) > > > > So how about adding this: > > > > "A CS MAY return a dynamically generated VCAR in response to > > a query that is generated by the CS at the time of the query. > > This generated VCAR will have the DECREED property set to true. > > This will allow an implementations to limit the contents to > > the currently authenticated UPNs access when security does > > not permit non-owner UPNs to see the access rights that may > > effect other UPNs. The CARID of this dynamically generated > > VCAR MUST BE 'DYNAMIC'. > > 1- I don't see the shadow of a hint of a suggestion of > the concept of "COALESCE" in this proposal. Coalesce > means "unite into one". We don't need to unite multiple > VCAR components into one to limit their contents to the > access rights that pertain to the currently authenticated > user. I am certain you don't. Your implementation is free to return everything to everyone. I am certain I do need the filtering described in CAP. I need them so that I can limit what access a authenticated UPN can see. And that limit must include the ability to NOT show the currently authenticated UPN what access right other users have as this is for security reasons. If I see VCAR CARID:foo and CARID:foo has: PERMISION:another-upn ... Then I have given out security information that the current user does not need to have permission to see. This still exists in CAP and it needs to stay: The return values are subject to VCAR filtering. That is, if the request contains properties to which the UPN does not have access, those properties will not appear in the return values. If the UPN has access to at least one property of events, but has been denied access to all properties called out in the request, the response will contain a single REQUEST-STATUS property indicating the error. ... This applies to all components - including VCARs. Which means that what you get MAY not include all of any component contents when you don't have access. I do not see a valid reason to limit this only non-VCARs. --------------70B5AB3EC0892C514ABFCE10 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 ; Tue, 12 Feb 2002 11:39:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CGVK909581 for ietf-calendar-bks; Tue, 12 Feb 2002 08:31:20 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CGVI309577 for ; Tue, 12 Feb 2002 08:31:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA02280 for ; Tue, 12 Feb 2002 08:31:19 -0800 (PST) Message-ID: <3C694353.8D79059D@Royer.com> Date: Tue, 12 Feb 2002 09:31:15 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: Content-Type: multipart/mixed; boundary="------------FE6C89ACD5608D17174153ED" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FE6C89ACD5608D17174153ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >BEGIN:VCALENDAR > >METHOD:REQUEST > >BEGIN:VEVENT > >... > >END:VEVENT > >END:VCALENDAR > > > >is stored as: > > > >BEGIN:VEVENT > >METHOD:REQUEST > >... > >END:VEVENT > > Wait a minute--what happens if the iTIP VCALENDAR contains more than one > component (e.g., a VEVENT and a VTIMEZONE)? How are they kept together? Execelent point. But I think it is more accurate to say: CAP does not specify how a CS stores data. Which makes that example a bit mute. We only agree how to exchange information and not how to store it. CS - Here is the data as the WG list aggreed to exchange it, now stote it. --------------FE6C89ACD5608D17174153ED 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 ; Tue, 12 Feb 2002 11:43:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CGRbD09501 for ietf-calendar-bks; Tue, 12 Feb 2002 08:27:37 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CGRZ309496 for ; Tue, 12 Feb 2002 08:27:35 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA02274 for ; Tue, 12 Feb 2002 08:27:35 -0800 (PST) Message-ID: <3C694274.F894CDE4@Royer.com> Date: Tue, 12 Feb 2002 09:27:32 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------644A3869193A4D61C8D32380" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------644A3869193A4D61C8D32380 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > On Mon, 2002-02-11 at 20:02, Doug Royer wrote: > ... > > > > Put the METHOD, TARGET, and optional CMDID back into > > the data. (Assume they are in these brief examples). > > As mentioned in: > > http://www.imc.org/ietf-calendar/mail-archive/msg03701.html > > CMDID is used by other commands that do not include an iCalendar > object. There was also replies that indicated that the BEEP MSGNO field served the same purpose. So I thought that meant that people were okay with taking it out of the command. I'll add text like: If the CUA wishes to perform more than one simultaneous command to the CS, then the 'cmdid' attribute must be added to any commands in order for the CUA and the CS to uniquely identify which command is being referred to in the abort and continue commands. Plus I did forget some of the email, so I will also add: If it is supplied at all, it MUST be in the iCalendar object and also supplied in the command as an attribute. (then I'll show what I mean in an example) I'll also add text like: If a CUA wishes to abort a command in progress, the CUA MUST issue the command on a separate channel with the cmdid attribute set to the CMDID of the command to be aborted. (plus add BEEP example). > > > > -------------------------------------------------------------- > > > > And I changed the names to MATCH (case) the iCalendar objects. > > As iCalendar objects are upper case, the same named objects > > should be here. And I upper cased the new ones in CAP to > > be consistent with iCalendar. And I changed the names > > of the CAPABILITY replies to be the same as the PROPERTY > > names they map to (same case). > > I don't understand, your example is in lower case. Furthermore > as mentioned by John iCalender in case insensitive. Yes - that was an old comment that and I missed removing it from (#2). Thanks - I'll remove that comment. > see: > http://www.imc.org/ietf-calendar/mail-archive/msg03749.html > > > > > There is a typo in 06 on the name of date max and date min. I don't see it - where? > > S:00000101T000000Z > > S:99991231T235959Z > > > > ----------------------------------------------------------------- > > 6.1.3 "identify" Command > > > > There was NO example for IDENTIFY, so I propose: > > > > C: > > > > S: ...empty BEEP RPY is success... > > S: ...else CAP error message in BEEP CDATA reply... > > As mentioned in: > > http://www.imc.org/ietf-calendar/mail-archive/msg03704.html > > I find the empty RPY very awkward. If you send a command in > XML you should receive a response in XML. It's consistent and > easy to document in the BEEP registration template (all entries > refers to the DTD). If you re-read BEEP you will see that it allows for empty replies to mean success. If your logic is correct, then a BEEP reply could never be empty - clearly not what they intended. > > ------------------------------------------------------------------- > > > > Plus change the MODIFY iCalendar objects back to the way > > they were in the 05 draft. > > > > C: > > ... > > C: METHOD:DELETE > > C: ... > > C: ]]> > > I don't understand, what is the purpose of a METHOD:DELETE > in a modify command? Typo, it should have been METHOD:MODIFY > > ------------------------------------------------------------------- > > > > Drop this section entirely. As the METHOD is now back in > > the iCalendar objects, just deposit them with the command > > into the CS. > > > > 6.3 Scheduling Commands > > 6.3.1 "schedule" Command > > 6.3.2 Processing Scheduling Components > > > > A CUA processes iTIP data, the CS just stores them. > > That's not exactly true. When storing an iTIP object, the CS do > perform some processing on the iTIP object. NO - only CUA process iTIP objects > e.g,., The following iTIP object: > > BEGIN:VCALENDAR > METHOD:REQUEST > BEGIN:VEVENT > ... > END:VEVENT > END:VCALENDAR > > is stored as: > > BEGIN:VEVENT > METHOD:REQUEST > ... > END:VEVENT > > As such the schedule command is not identical to the create command. The same is true for the command. The METHOD is put into the object - no difference at all. --------------644A3869193A4D61C8D32380 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 ; Tue, 12 Feb 2002 11:57:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1CGkPN09924 for ietf-calendar-bks; Tue, 12 Feb 2002 08:46:25 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CGkO309920 for ; Tue, 12 Feb 2002 08:46:24 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA02307 for ; Tue, 12 Feb 2002 08:46:25 -0800 (PST) Message-ID: <3C6946DD.DA88AD75@Royer.com> Date: Tue, 12 Feb 2002 09:46:21 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C693BA5.78614FEB@steltor.com> Content-Type: multipart/mixed; boundary="------------A76E5496EFE8AC91197328D5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A76E5496EFE8AC91197328D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > And what happens with recurring VEVENT with exceptions? > > BEGIN:VCALENDAR > METHOD:REQUEST > BEGIN:VEVENT > UID:abc123 > RRULE:... > ... > END:VEVENT > BEGIN:VEVENT > UID:abc123 > ... exception 1... > END:VEVENT > BEGIN:VEVENT > UID:abc123 > ... exception 2... > END:VEVENT > END:VCALENDAR > > Which VEVENT ends up with METHOD:REQUEST in the CS? It is not up to CAP to specify how the CS stores the data. --------------A76E5496EFE8AC91197328D5 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 ; Tue, 12 Feb 2002 12:12:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CH3AE10417 for ietf-calendar-bks; Tue, 12 Feb 2002 09:03:10 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CH38310413 for ; Tue, 12 Feb 2002 09:03:09 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 12 Feb 2002 12:11:01 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/12/2002 12:11:08 PM, Serialize complete at 02/12/2002 12:11:08 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >CAP does not specify how a CS stores data. Which makes that >example a bit mute. We only agree how to exchange information >and not how to store it. We don't specify how the CS *really* stores data; but the CAP model presents a *virtual* store. That's what we were talking about. If, as Patrice said, the CAP model separates out the subcomponents of an incoming iTIP VCALENDAR, we need some other way of relating them. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |"But she calls her ship _Mercy of the Goddess_!" "Kali." "Oh."| \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 12 12:21:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19214 for ; Tue, 12 Feb 2002 12:21:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CH1xr10390 for ietf-calendar-bks; Tue, 12 Feb 2002 09:01:59 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CH1v310383 for ; Tue, 12 Feb 2002 09:01:57 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA18772 for ; Tue, 12 Feb 2002 12:01:53 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CH1qQ28559 for ; Tue, 12 Feb 2002 12:01:52 -0500 (EST) Message-ID: <3C694AFA.C003AB99@steltor.com> Date: Tue, 12 Feb 2002 12:03:54 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@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: > > > > No did not agree to drooping COALESCE. :-) > > > > > > So how about adding this: > > > > > > "A CS MAY return a dynamically generated VCAR in response to > > > a query that is generated by the CS at the time of the query. > > > This generated VCAR will have the DECREED property set to true. > > > This will allow an implementations to limit the contents to > > > the currently authenticated UPNs access when security does > > > not permit non-owner UPNs to see the access rights that may > > > effect other UPNs. The CARID of this dynamically generated > > > VCAR MUST BE 'DYNAMIC'. > > > > 1- I don't see the shadow of a hint of a suggestion of > > the concept of "COALESCE" in this proposal. Coalesce > > means "unite into one". We don't need to unite multiple > > VCAR components into one to limit their contents to the > > access rights that pertain to the currently authenticated > > user. > > I am certain you don't. Your implementation is free to > return everything to everyone. > > I am certain I do need the filtering described in CAP. > I need them so that I can limit what access a authenticated > UPN can see. And that limit must include the ability to NOT > show the currently authenticated UPN what access right other > users have as this is for security reasons. If I see VCAR CARID:foo > and CARID:foo has: > > PERMISION:another-upn ... PERMISSION does not specify UPN. GRANT and DENY do. > > Then I have given out security information that the current > user does not need to have permission to see. > > This still exists in CAP and it needs to stay: > > The return values are subject to VCAR filtering. That is, if the > request contains properties to which the UPN does not have access, > those properties will not appear in the return values. If the UPN > has access to at least one property of events, but has been denied > access to all properties called out in the request, the response will > contain a single REQUEST-STATUS property indicating the error. ... > > This applies to all components - including VCARs. Which > means that what you get MAY not include all of any component > contents when you don't have access. I do not see a valid reason to > limit this only non-VCARs. Douglas, you digress again. How did you come up with the idea that my proposal was meant to replace the text you quoted? My proposal --- have you simply read it? --- provides text for what YOU proposed back in December and which was agreed on the list. http://www.imc.org/ietf-calendar/mail-archive/msg02372.html http://www.imc.org/ietf-calendar/mail-archive/msg02535.html http://www.imc.org/ietf-calendar/mail-archive/msg02376.html So again, I propose to add the following text to CAP: When EXPAND is TRUE, the CS MUST only specify the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components. VRIGHT components that don't pertain to the currently authenticated user MUST be left out of the returned VCAR components. The CS MAY only specify the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components not owned by the currently authenticated user for security reasons. VRIGHT components that don't pertain to the currently authenticated user MAY be left out of the returned VCAR not owned by the currently authenticated user for security reasons. Regards, 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 Feb 12 12:37:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19653 for ; Tue, 12 Feb 2002 12:37:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CHGS810662 for ietf-calendar-bks; Tue, 12 Feb 2002 09:16:28 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CHGR310657 for ; Tue, 12 Feb 2002 09:16:27 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) Byte reduction in BEEP commands. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 12 Feb 2002 12:24:19 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/12/2002 12:24:26 PM, Serialize complete at 02/12/2002 12:24:26 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Which VEVENT ends up with METHOD:REQUEST in the CS? > >It is not up to CAP to specify how the CS stores the data. Yes, we know. We are speaking in terms of the virtual model; you're not making anything clearer by insisting on listening in terms of a physical model. Bernard could have asked, "Which VEVENT, when the CUA queries the CS, will have the METHOD:REQUEST on it?"; but that would've obfuscated the point he was trying to make. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |Nondeterminism may or may not mean never having to say you're| |wrong. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 12 12:48:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20011 for ; Tue, 12 Feb 2002 12:48:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CHUpw10949 for ietf-calendar-bks; Tue, 12 Feb 2002 09:30:51 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CHUo310944 for ; Tue, 12 Feb 2002 09:30:50 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA02426 for ; Tue, 12 Feb 2002 09:30:50 -0800 (PST) Message-ID: <3C695146.57959859@Royer.com> Date: Tue, 12 Feb 2002 10:30:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: Content-Type: multipart/mixed; boundary="------------4781DD4371A8BFF2777D2A83" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4781DD4371A8BFF2777D2A83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >CAP does not specify how a CS stores data. Which makes that > >example a bit mute. We only agree how to exchange information > >and not how to store it. > > We don't specify how the CS *really* stores data; but the CAP model > presents a *virtual* store. That's what we were talking about. If, as > Patrice said, the CAP model separates out the subcomponents of an incoming > iTIP VCALENDAR, we need some other way of relating them. They are marked as related: - They are encapsulated in the same BEGIN/END VCALENDAR. Which has the METHOD: in it. --------------4781DD4371A8BFF2777D2A83 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 ; Tue, 12 Feb 2002 13:09:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1CHoHQ11331 for ietf-calendar-bks; Tue, 12 Feb 2002 09:50:17 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CHoF311327 for ; Tue, 12 Feb 2002 09:50:15 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA19945 for ; Tue, 12 Feb 2002 12:50:10 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CHo8Q06107 for ; Tue, 12 Feb 2002 12:50:08 -0500 (EST) Message-ID: <3C695649.A18BA86C@steltor.com> Date: Tue, 12 Feb 2002 12:52:09 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C693BA5.78614FEB@steltor.com> <3C6946DD.DA88AD75@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: > > > > > And what happens with recurring VEVENT with exceptions? > > > > BEGIN:VCALENDAR > > METHOD:REQUEST > > BEGIN:VEVENT > > UID:abc123 > > RRULE:... > > ... > > END:VEVENT > > BEGIN:VEVENT > > UID:abc123 > > ... exception 1... > > END:VEVENT > > BEGIN:VEVENT > > UID:abc123 > > ... exception 2... > > END:VEVENT > > END:VCALENDAR > > > > Which VEVENT ends up with METHOD:REQUEST in the CS? > > It is not up to CAP to specify how the CS stores the data. Then, given that the VEVENT quoted above has been created in the CS. What would be returned for the following VQUERY component: 1- BEGIN:VQUERY QUERYNAME:Query-01 QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' END:VQUERY 2- BEGIN:VQUERY QUERYNAME:Query-02 EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' END:VQUERY Regards, 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 Feb 12 13:24:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21099 for ; Tue, 12 Feb 2002 13:24:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CHwGP11488 for ietf-calendar-bks; Tue, 12 Feb 2002 09:58:16 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CHwE311484 for ; Tue, 12 Feb 2002 09:58:14 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 12 Feb 2002 13:06:07 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/12/2002 01:06:14 PM, Serialize complete at 02/12/2002 01:06:14 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > - They are encapsulated in the same BEGIN/END VCALENDAR. OK, good. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |"I think we'd get fewer bug reports if we stopped selling our| |software off planet." | \=============================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 12 13:24:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21111 for ; Tue, 12 Feb 2002 13:24:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CI5WC11618 for ietf-calendar-bks; Tue, 12 Feb 2002 10:05:32 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CI5V311614 for ; Tue, 12 Feb 2002 10:05:31 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA02493 for ; Tue, 12 Feb 2002 10:05:32 -0800 (PST) Message-ID: <3C695967.A525485C@Royer.com> Date: Tue, 12 Feb 2002 11:05:27 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@Royer.com> <3C694AFA.C003AB99@steltor.com> Content-Type: multipart/mixed; boundary="------------B2745DEA85CF6C10A61D9E69" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B2745DEA85CF6C10A61D9E69 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > How did you come up with the idea that my proposal was > meant to replace the text you quoted? When you said in the email that I replied to: "...We don't need to unite multiple VCAR components into one to limit their contents to the access rights that pertain to the currently authenticated user. ..." > So again, I propose to add the following text to CAP: > > When EXPAND is TRUE, the CS MUST only specify the UPN of the > currently authenticated user in the GRANT or DENY property of > the VRIGHT components of the returned VCAR components. VRIGHT > components that don't pertain to the currently authenticated > user MUST be left out of the returned VCAR components. And add: And their contents MAY BE filtered or modified to eliminate from the reply set any information that does not directly effect the currently authenticated UPN. And for the purpose of this UPN at the time they ask, the result is in effect decreed to them, add: And when an existing VCAR reply is modified, it MUST BE tagged with the property DECREED set to TRUE as this filtered VCAR can not be modified by its CARID by the currently authenticated UPN or any UPN. OR add: The CS MUST include as part of that filtered VCAR, a VRIGHTS component that prohibits the currently authenticated UPN from modifying or deleting this virtual VCAR. And these filtered or modified VCAR replies need to be tagged so the UPN does not think that they are 'the' VCAR with CARID. So I think we need to add something like: And the name of any filtered VCAR that is a subset of existing VCARs needs to have a CARID that does not conflict with existing CARID. So I propose we call those filtered virtually decreed VCARS 'DYNAMIC'. > The CS MAY only specify the UPN of the currently authenticated > user in the GRANT or DENY property of the VRIGHT components > of the returned VCAR components not owned by the currently > authenticated user for security reasons. VRIGHT components > that don't pertain to the currently authenticated user MAY be > left out of the returned VCAR not owned by the currently > authenticated user for security reasons. Add: Or modified so that only the currently authenticated UPN is in the result set. Example: GRANT:joe,sam,tom May be returned as: GRANT:joe So that JOE can't tell that sam and tom even exist as valid UPNs. --------------B2745DEA85CF6C10A61D9E69 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 ; Tue, 12 Feb 2002 13:28:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1CI6fS11641 for ietf-calendar-bks; Tue, 12 Feb 2002 10:06:41 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CI6e311637 for ; Tue, 12 Feb 2002 10:06:40 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA02497 for ; Tue, 12 Feb 2002 10:06:41 -0800 (PST) Message-ID: <3C6959AC.8E741132@Royer.com> Date: Tue, 12 Feb 2002 11:06:36 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: Content-Type: multipart/mixed; boundary="------------5F7E6CB8CDBDCE74650A6701" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5F7E6CB8CDBDCE74650A6701 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >> Which VEVENT ends up with METHOD:REQUEST in the CS? > > > >It is not up to CAP to specify how the CS stores the data. > > Yes, we know. We are speaking in terms of the virtual model; you're not > making anything clearer by insisting on listening in terms of a physical > model. Bernard could have asked, "Which VEVENT, when the CUA queries the > CS, will have the METHOD:REQUEST on it?"; but that would've obfuscated the > point he was trying to make. They would all be REQUEST because they were encapsulated in a single BEGIN/END VCALENDAR that had METHOD:REQUEST. --------------5F7E6CB8CDBDCE74650A6701 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 ; Tue, 12 Feb 2002 13:39:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CIKaJ12177 for ietf-calendar-bks; Tue, 12 Feb 2002 10:20:36 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CIKX312173 for ; Tue, 12 Feb 2002 10:20:33 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA20515 for ; Tue, 12 Feb 2002 13:20:29 -0500 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 g1CIKTQ10779 for ; Tue, 12 Feb 2002 13:20:29 -0500 (EST) Subject: Re: (#2) Byte reduction in BEEP commands. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C694274.F894CDE4@Royer.com> References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Feb 2002 13:27:54 -0500 Message-Id: <1013538474.24840.65.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-02-12 at 11:27, Doug Royer wrote: > Patrice Lapierre wrote: ... > > > > CMDID is used by other commands that do not include an iCalendar > > object. > > There was also replies that indicated that the BEEP MSGNO > field served the same purpose. So I thought that meant > that people were okay with taking it out of the command. > The MSGNO doesn't serve the same purpose. It's it used to map the response(s) (RPY, ERR, ANS, NULL) with the request (MSG). The id (or cmdid) provides an identifier to allow a CUA to abort a command (possibly from a different channel as we already discussed). > I'll add text like: > > If the CUA wishes to perform more than one simultaneous > command to the CS, then the 'cmdid' attribute must be > added to any commands in order for the CUA and the CS > to uniquely identify which command is being referred to > in the abort and continue commands. > I don't think that cmdid needs be a MUST when several commands are executed. If not provided then we have the following problems: (1) The CUA cannot "abort" the command (by sending a message from another BEEP channel). (2) The CUA can't unambiguously determine which command is referred by a "timeout" message. The first doesn't mater, if the CUA wants to be able to cancel a command, it just have to provide an id. For the second, I would also leave it up the the CUA, since it doesn't impact the server. But if others see this as a problem, then we could simply add the restriction that id MUST be provided iff action='ask'. > Plus I did forget some of the email, so I will also add: > > If it is supplied at all, it MUST be in the iCalendar > object and also supplied in the command as an attribute. > Since mapping between commands and the associated responces is no longer handled by the cmdid, is there a real need to place it in the iCalendar object as well? > (then I'll show what I mean in an example) > > I'll also add text like: > > If a CUA wishes to abort a command in progress, the CUA > MUST issue the command on a separate channel with > the cmdid attribute set to the CMDID of the command to > be aborted. > I agree. > (plus add BEEP example). > > > > > > > -------------------------------------------------------------- > > > > > > And I changed the names to MATCH (case) the iCalendar objects. > > > As iCalendar objects are upper case, the same named objects > > > should be here. And I upper cased the new ones in CAP to > > > be consistent with iCalendar. And I changed the names > > > of the CAPABILITY replies to be the same as the PROPERTY > > > names they map to (same case). > > > > I don't understand, your example is in lower case. Furthermore > > as mentioned by John iCalender in case insensitive. > > Yes - that was an old comment that and I missed removing it > from (#2). Thanks - I'll remove that comment. > > > see: > > http://www.imc.org/ietf-calendar/mail-archive/msg03749.html > > > > > > > > There is a typo in 06 on the name of date max and date min. > > I don't see it - where? > If you referring to the typo, then don't ask me, you are the one who mentioned it in you original post. > > > S:00000101T000000Z > > > S:99991231T235959Z > > > > > > > ----------------------------------------------------------------- > > > 6.1.3 "identify" Command > > > > > > There was NO example for IDENTIFY, so I propose: > > > > > > C: > > > > > > S: ...empty BEEP RPY is success... > > > S: ...else CAP error message in BEEP CDATA reply... > > > > As mentioned in: > > > > http://www.imc.org/ietf-calendar/mail-archive/msg03704.html > > > > I find the empty RPY very awkward. If you send a command in > > XML you should receive a response in XML. It's consistent and > > easy to document in the BEEP registration template (all entries > > refers to the DTD). > > If you re-read BEEP you will see that it allows for empty > replies to mean success. If your logic is correct, then > a BEEP reply could never be empty - clearly not what they > intended. > Please! Just because we can do it, doesn't mean that we should. If it's such a good practice, then can you give me an example of a BEEP profile that returns an empty RPY to indicate success. Also in BEEP if the payload doesn't include a mime header the default content-type is "application/octect-stream". Do we really want to introduce another content-type in CAP? -- Patrice. From owner-ietf-calendar@mail.imc.org Tue Feb 12 14:04:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22110 for ; Tue, 12 Feb 2002 14:04:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CIdnM12573 for ietf-calendar-bks; Tue, 12 Feb 2002 10:39:49 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CIdl312568 for ; Tue, 12 Feb 2002 10:39:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA02551 for ; Tue, 12 Feb 2002 10:39:48 -0800 (PST) Message-ID: <3C69616F.5FC125C5@Royer.com> Date: Tue, 12 Feb 2002 11:39:43 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C693BA5.78614FEB@steltor.com> <3C6946DD.DA88AD75@Royer.com> <3C695649.A18BA86C@steltor.com> Content-Type: multipart/mixed; boundary="------------67731C339FCE56CB24A7F7A3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------67731C339FCE56CB24A7F7A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > > And what happens with recurring VEVENT with exceptions? > > > > > > BEGIN:VCALENDAR > > > METHOD:REQUEST > > > BEGIN:VEVENT > > > UID:abc123 > > > RRULE:... > > > ... > > > END:VEVENT > > > BEGIN:VEVENT > > > UID:abc123 > > > ... exception 1... > > > END:VEVENT > > > BEGIN:VEVENT > > > UID:abc123 > > > ... exception 2... > > > END:VEVENT > > > END:VCALENDAR > > > > > > Which VEVENT ends up with METHOD:REQUEST in the CS? > > > > It is not up to CAP to specify how the CS stores the data. > > Then, given that the VEVENT quoted above has been created > in the CS. What would be returned for the following VQUERY > component: > > 1- BEGIN:VQUERY > QUERYNAME:Query-01 > QUERY:SELECT * FROM VEVENT > WHERE METHOD = 'REQUEST' > END:VQUERY > > 2- BEGIN:VQUERY > QUERYNAME:Query-02 > EXPAND:TRUE > QUERY:SELECT * FROM VEVENT > WHERE METHOD = 'REQUEST' > END:VQUERY I would never ask for expanded un-booked iTIP objects. I would ask for all iTIP objects and then merge them in the CUA, then deposit the result in the CS, then delete all merged un-booked objects. They would both return the same data except the EXPAND:TRUE results would contain more and those would contain RECURRANCE-ID's. So the result would be as provided in the example at the top of this email (as supplied to the CS), or each one BEGIN/END VCALENDAR would be returned separately as we (I think) agreed would be valid. So they would both return (as supplied to the CS above - by whoever asked the question) [and optional with more instances that included RECURRANCE-ID] OR (beep ANS 1) BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT UID:abc123 RRULE:... ... END:VEVENT END:VCALENDAR ... (beep ANS n (or NUL for the last?)) BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT UID:abc123 ... exception 2... END:VEVENT END:VCALENDAR --------------67731C339FCE56CB24A7F7A3 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 ; Tue, 12 Feb 2002 14:30:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CJGVR13302 for ietf-calendar-bks; Tue, 12 Feb 2002 11:16:31 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CJGU313298 for ; Tue, 12 Feb 2002 11:16:30 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA22814 for ; Tue, 12 Feb 2002 14:16:26 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CJGPQ23149 for ; Tue, 12 Feb 2002 14:16:25 -0500 (EST) Message-ID: <3C696A82.9D1597D@steltor.com> Date: Tue, 12 Feb 2002 14:18:26 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@Royer.com> <3C694AFA.C003AB99@steltor.com> <3C695967.A525485C@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: > > > So again, I propose to add the following text to CAP: > > > > When EXPAND is TRUE, the CS MUST only specify the UPN of the > > currently authenticated user in the GRANT or DENY property of > > the VRIGHT components of the returned VCAR components. VRIGHT > > components that don't pertain to the currently authenticated > > user MUST be left out of the returned VCAR components. > > And add: > > And their contents MAY BE filtered or modified to eliminate > from the reply set any information that does not directly effect > the currently authenticated UPN. But I don't understand, that's already covered in the text I proposed. The VRIGHT component that pertains to you will only specify your UPN in the GRANT or DENY property: "... the CS MUST only specify the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components." and the VRIGHT component that don't pertain to you will not be returned to you: "VRIGHT components that don't pertain to the currently authenticated user MUST be left out of the returned VCAR components." what information is left to be "filtered" or "modified" ? > And for the purpose of this UPN at the time they ask, the > result is in effect decreed to them, add: > > And when an existing VCAR reply is modified, it MUST BE > tagged with the property DECREED set to TRUE as this filtered > VCAR can not be modified by its CARID by the currently > authenticated UPN or any UPN. This is not needed. And again, DECREED:TRUE means that the VCAR is PERSISTENT and IMMUTABLE, that is, a decreed VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE. > > OR add: > > The CS MUST include as part of that filtered VCAR, a > VRIGHTS component that prohibits the currently authenticated > UPN from modifying or deleting this virtual VCAR. That doesn't make sense. That VCAR would not exist on the CS, so the CU could still modify the VCAR anyway, that is, if he is granted the right to do so. On the other hand, I should probably change the second paragraph of my proposal to apply to the "VCAR components for which the currently authenticated user doesn't have the MODIFY permission granted" instead of the "VCAR components not owned by the currently authenticated user". > And these filtered or modified VCAR replies need to be tagged > so the UPN does not think that they are 'the' VCAR with CARID. > So I think we need to add something like: > > And the name of any filtered VCAR that is a subset of > existing VCARs needs to have a CARID that does not conflict > with existing CARID. > > So I propose we call those filtered virtually decreed VCARS > 'DYNAMIC'. I disagree. If I query the VCAR with CARID:REQUESTONLY in your VAGENDA it must be returned with CARID:REQUESTONLY, even if all the GRANT and DENY that does not pertain to you have been removed. Otherwise the CUA would be totally confused when performing the following search: BEGIN:VQUERY QUERY:SELECT * FROM VCAR WHERE CARID = 'REQUESTONLY' OR CARID = 'READBUSYTIMEINFO' END:VQUERY How would the CUA be able to distinguish which of the 2 returned VCAR components is which? > > The CS MAY only specify the UPN of the currently authenticated > > user in the GRANT or DENY property of the VRIGHT components > > of the returned VCAR components not owned by the currently > > authenticated user for security reasons. VRIGHT components > > that don't pertain to the currently authenticated user MAY be > > left out of the returned VCAR not owned by the currently > > authenticated user for security reasons. > > Add: > Or modified so that only the currently authenticated UPN > is in the result set. Example: > > GRANT:joe,sam,tom > > May be returned as: > > GRANT:joe > > So that JOE can't tell that sam and tom even exist as valid UPNs. Again, that's already covered in the text I proposed. "The CS MAY only specify the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components ... " Proposal (#2) : When EXPAND is TRUE, the CS MUST only specify the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components. VRIGHT components that don't pertain to the currently authenticated user MUST be left out of the returned VCAR components. For security reasons, the CS MAY specify only the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components for which the currently authenticated user doesn't have the MODIFY permission granted. Furthermore, VRIGHT components that don't pertain to the currently authenticated user MAY be left out of the returned VCAR for which the currently authenticated user doesn't have the MODIFY permission granted. Okay? Regards, 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 Feb 12 15:56:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27093 for ; Tue, 12 Feb 2002 15:56:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CKfV815103 for ietf-calendar-bks; Tue, 12 Feb 2002 12:41:31 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CKfT315099 for ; Tue, 12 Feb 2002 12:41:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA02701 for ; Tue, 12 Feb 2002 12:41:30 -0800 (PST) Message-ID: <3C697DF3.FD2D4782@Royer.com> Date: Tue, 12 Feb 2002 13:41:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@Royer.com> <3C694AFA.C003AB99@steltor.com> <3C695967.A525485C@Royer.com> <3C696A82.9D1597D@steltor.com> Content-Type: multipart/mixed; boundary="------------E867811A0C6222AA1CA0EDBB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E867811A0C6222AA1CA0EDBB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: I think we may be agreeing, it may be a wording issue. >> ... > This is not needed. And again, DECREED:TRUE means that > the VCAR is PERSISTENT and IMMUTABLE, that is, a decreed > VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE. No - it means the CUA can not change it. The CS administrator may change it over time. To the CUA for any given session, they do not change. > Proposal (#2) : > > When EXPAND is TRUE, the CS MUST only specify the UPN of the > currently authenticated user in the GRANT or DENY property of > the VRIGHT components of the returned VCAR components. VRIGHT > components that don't pertain to the currently authenticated > user MUST be left out of the returned VCAR components. (supply? not specify?) When EXPAND is TRUE, the CS MUST only supply the UPN of the ... ^^^^^^ > For security reasons, the CS MAY specify only the UPN of the > currently authenticated user in the GRANT or DENY property of the > VRIGHT components of the returned VCAR components for which the > currently authenticated user doesn't have the MODIFY permission > granted. Furthermore, VRIGHT components that don't pertain to > the currently authenticated user MAY be left out of the returned > VCAR for which the currently authenticated user doesn't have the > MODIFY permission granted. > Okay? Yes. Now a question. Will the CUA EVER be able to modify the results of the EXPAND:TRUE generated VCAR that the CS sent back to the CUA as the result of a query? I would think 'no' because this made up VCAR does not really exist as sent back. If no - then it needs to be marked DECREED? Because for the life of the CAP session - it is not changing. If not marked DECREED, then there MUST be a made up VRIGHT in the returned set that tells the CUA it can not modify the returned VCAR by using the returned CARID? Otherwise it may apply another VCAR results from another EXPAND:FALSE query and assume that the EXPAND:TRUE VCAR results are modifiable. But this seem like too much data - so just mark it DECREED? OR - The result set coming back from the CS as the result of a query from EXPAND:TRUE must NEVER use a CARID that already exists - otherwise, it will be impossible to tell what the VCAR with CARID really is. Or if the VRIGHTS of the EXPAND:FALSE CARID apply to the EXPAND:TRUE CARID VCARs. So I proposed that these generated VCARs always have a CARID of DYNAMIC. And we define that any contents of a CARID:DYNAMIC VCAR are read-only, and only valid for the current session for the curren UPN. Then ONE VCAR can be used that only gives them READ access and denies WRITE, MODIFY, and DELETE access to any generated (dynamic) VCAR. Otherwise there has to be one more VRIGHT for each made up on the fly results. Agree? --------------E867811A0C6222AA1CA0EDBB 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 ; Tue, 12 Feb 2002 15:58:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1CKkkG15204 for ietf-calendar-bks; Tue, 12 Feb 2002 12:46:46 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CKkj315200 for ; Tue, 12 Feb 2002 12:46:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA02706 for ; Tue, 12 Feb 2002 12:46:46 -0800 (PST) Message-ID: <3C697F30.E5E272B@Royer.com> Date: Tue, 12 Feb 2002 13:46:40 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------B3363CC86AC9581966713F02" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B3363CC86AC9581966713F02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > > > If you re-read BEEP you will see that it allows for empty > > replies to mean success. If your logic is correct, then > > a BEEP reply could never be empty - clearly not what they > > intended. > > > > Please! Just because we can do it, doesn't mean that > we should. > > If it's such a good practice, then can you give me an example > of a BEEP profile that returns an empty RPY to indicate success. Can you show me where in BEEP it defines it is bad practice? Why was it defined in BEEP as valid: > Also in BEEP if the payload doesn't include a mime header > the default content-type is "application/octect-stream". > Do we really want to introduce another content-type in CAP? If payload lenght == 0 -> success. I can do that and never care what the content-type is. It works for XML and non-XML content types. --------------B3363CC86AC9581966713F02 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 ; Tue, 12 Feb 2002 16:37:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1CLOf716004 for ietf-calendar-bks; Tue, 12 Feb 2002 13:24:41 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CLOc316000 for ; Tue, 12 Feb 2002 13:24:38 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA26978 for ; Tue, 12 Feb 2002 16:24:34 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CLOWQ10283 for ; Tue, 12 Feb 2002 16:24:32 -0500 (EST) Message-ID: <3C698887.64C7FF38@steltor.com> Date: Tue, 12 Feb 2002 16:26:31 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@Royer.com> <3C694AFA.C003AB99@steltor.com> <3C695967.A525485C@Royer.com> <3C696A82.9D1597D@steltor.com> <3C697DF3.FD2D4782@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: > > I think we may be agreeing, it may be a wording issue. > > > Proposal (#2) : > > > > When EXPAND is TRUE, the CS MUST only specify the UPN of the > > currently authenticated user in the GRANT or DENY property of > > the VRIGHT components of the returned VCAR components. VRIGHT > > components that don't pertain to the currently authenticated > > user MUST be left out of the returned VCAR components. > > (supply? not specify?) > When EXPAND is TRUE, the CS MUST only supply the UPN of the ... > ^^^^^^ Agreed with "supply". > > Yes. Now a question. > > Will the CUA EVER be able to modify the results of the > EXPAND:TRUE generated VCAR that the CS sent back to the CUA > as the result of a query? 1- The CUA doesn't "modify results", it modifies components stored in the CS. 2- The means used by the CUA to come up with a replacement value for a stored component is beyond our control. 3- When managing VCAR components it is expected that CUA will NOT specify EXPAND:TRUE. But again, there is nothing we can do to prevent CUA to do stupid things! 4- CUA MAY specify EXPAND:TRUE when they are querying VCAR components for evaluation purposes. I hope that answer your question. Regards, 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 Feb 12 16:50:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28689 for ; Tue, 12 Feb 2002 16:50:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CLanw16260 for ietf-calendar-bks; Tue, 12 Feb 2002 13:36:49 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CLak316256 for ; Tue, 12 Feb 2002 13:36:46 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA27335 for ; Tue, 12 Feb 2002 16:36:42 -0500 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 g1CLagQ11638 for ; Tue, 12 Feb 2002 16:36:42 -0500 (EST) Subject: Re: (#2) Byte reduction in BEEP commands. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C697F30.E5E272B@Royer.com> References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C697F30.E5E272B@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Feb 2002 16:44:07 -0500 Message-Id: <1013550248.25003.30.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-02-12 at 15:46, Doug Royer wrote: > Patrice Lapierre wrote: ... > > > Also in BEEP if the payload doesn't include a mime header > > the default content-type is "application/octect-stream". > > Do we really want to introduce another content-type in CAP? > > If payload lenght == 0 -> success. > I can do that and never care what the content-type is. > It works for XML and non-XML content types. Not for XML content-types, since XML document (or data) must have a single root. From owner-ietf-calendar@mail.imc.org Tue Feb 12 17:25:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29466 for ; Tue, 12 Feb 2002 17:25:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CMDKj17082 for ietf-calendar-bks; Tue, 12 Feb 2002 14:13:20 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMDJ317078 for ; Tue, 12 Feb 2002 14:13:19 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA28310 for ; Tue, 12 Feb 2002 17:13:12 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CMDAQ15955 for ; Tue, 12 Feb 2002 17:13:10 -0500 (EST) Message-ID: <3C6993F0.ADFAB1D5@steltor.com> Date: Tue, 12 Feb 2002 17:15:12 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C693BA5.78614FEB@steltor.com> <3C6946DD.DA88AD75@Royer.com> <3C695649.A18BA86C@steltor.com> <3C69616F.5FC125C5@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: > > > > Doug Royer wrote: > > > > > > Bernard Desruisseaux wrote: > > > > > > > > > > > And what happens with recurring VEVENT with exceptions? > > > > > > > > BEGIN:VCALENDAR > > > > METHOD:REQUEST > > > > BEGIN:VEVENT > > > > UID:abc123 > > > > RRULE:... > > > > ... > > > > END:VEVENT > > > > BEGIN:VEVENT > > > > UID:abc123 > > > > ... exception 1... > > > > END:VEVENT > > > > BEGIN:VEVENT > > > > UID:abc123 > > > > ... exception 2... > > > > END:VEVENT > > > > END:VCALENDAR > > > > > > > > Which VEVENT ends up with METHOD:REQUEST in the CS? > > > > > > It is not up to CAP to specify how the CS stores the data. > > > > Then, given that the VEVENT quoted above has been created > > in the CS. What would be returned for the following VQUERY > > component: > > > > 1- BEGIN:VQUERY > > QUERYNAME:Query-01 > > QUERY:SELECT * FROM VEVENT > > WHERE METHOD = 'REQUEST' > > END:VQUERY > > > > 2- BEGIN:VQUERY > > QUERYNAME:Query-02 > > EXPAND:TRUE > > QUERY:SELECT * FROM VEVENT > > WHERE METHOD = 'REQUEST' > > END:VQUERY > > I would never ask for expanded un-booked iTIP objects. I would > ask for all iTIP objects and then merge them in the CUA, then > deposit the result in the CS, then delete all merged > un-booked objects. > > They would both return the same data except the EXPAND:TRUE > results would contain more and those would contain RECURRANCE-ID's. > > So the result would be as provided in the example at the top of > this email (as supplied to the CS), or each one BEGIN/END > VCALENDAR would be returned separately as we (I think) agreed > would be valid. Ordering would be lost if they were returned separately. > > So they would both return > > (as supplied to the CS above - by whoever asked the question) > [and optional with more instances that included RECURRANCE-ID] > > OR > > (beep ANS 1) > BEGIN:VCALENDAR > METHOD:REQUEST > BEGIN:VEVENT > UID:abc123 > RRULE:... > ... > END:VEVENT > END:VCALENDAR > > ... > > (beep ANS n (or NUL for the last?)) > BEGIN:VCALENDAR > METHOD:REQUEST > BEGIN:VEVENT > UID:abc123 > ... exception 2... > END:VEVENT > END:VCALENDAR 1- That's not what one is lead to believe in reading draft-05 or draft-06: > An incoming event (indicated by the value of the "METHOD" property) > then appears in relcal2 and relcal3, with the following data: > > BEGIN:VEVENT > METHOD:REQUEST > UID:abcd12345 > DTSTART:19990307T180000Z > DTEND:19990307T190000Z > ORGANIZER:cap://cal.foo.com/relcal1 > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c > om/relcal2 > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c > om/relcal3 > SUMMARY:Important Meeting > END:VEVENT 2- It would seem that you are making assumptions on how the CS stores the data. You are telling me that my VQUERY that selects VEVENT components that have the METHOD property set to 'REQUEST', would return me VEVENT with no METHOD property. Quite surprising at the very least! 3- Let's look at another example. Given: BEGIN:VCALENDAR METHOD:REQUEST BEGIN:VEVENT UID:abc123 RRULE:... ... END:VEVENT BEGIN:VEVENT UID:abc123 LOCATION:Montreal ... exception 1... END:VEVENT BEGIN:VEVENT UID:abc123 LOCATION:Toronto ... exception 2... END:VEVENT END:VCALENDAR What would be returned for the following VQUERY components: a) BEGIN:VQUERY QUERYNAME:Query-01 QUERY:SELECT * FROM VEVENT WHERE LOCATION = 'Montreal' END:VQUERY b) BEGIN:VQUERY QUERYNAME:Query-02 EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE LOCATION = 'Montreal' END:VQUERY Regards, 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 Feb 12 17:28:30 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29545 for ; Tue, 12 Feb 2002 17:28:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CMFdh17144 for ietf-calendar-bks; Tue, 12 Feb 2002 14:15:39 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMFb317140 for ; Tue, 12 Feb 2002 14:15:38 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA28363; Tue, 12 Feb 2002 17:15:33 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CMFWQ16421; Tue, 12 Feb 2002 17:15:33 -0500 (EST) Message-ID: <3C699404.DAF9AE4A@steltor.com> Date: Tue, 12 Feb 2002 17:15:32 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: VAGENDA and CALSTORE: Component And Property Defintions 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 The following is a proposal for the definitions of the VAGENDA and CALSTORE components and their properties. These definitions are based on the descriptions found in the CAP draft. This is the first iteration. Please review. Once I get people's fixes and suggestions in, I will make a formal proposal. Summary: The VAGENDA component describes the calendars belonging to users. It contains VEVENTs, VJOURNALs, VTIMEZONEs, VTODOs, VQUERYs, and VCARs. The properties that a VAGENDA may have are: ALLOW-CONFLICT: whether conflicts are allowed in the agenda CALSCALE: default calendar scale used (e.g. Gregorian) CHARSET: default character set CREATED: the time the VAGENDA was created LOCALE: the default language LAST-MODIFIED: the last time the VAGENDA was modified NAME: the name of the calendar (e.g., "Work") OWNER: the users that own the calendar RELATED-TO: other VAGENDAs that are linked to this one RELCALID: identifier for the VAGENDA TOMBSTONE: whether the VAGENDA is marked as deleted or not The CALSTORE component is used to contain the properties of the calendar store. These properties are: CALMASTER: e-mail address of the calendar administrator CSID: unique identifier for the CALSTORE CURRENT-DATETIME: the current date and time on the CS DEFAULT-VCARS: default access rights MAXDATE: last date time that is supported by the CWS MINDATE: first date-time that is supported by the CS RECUR-ACCEPTED: whether the CS accepts recurrence rules RECUR-EXPAND : whether or not the CS supports the expansion of recurrence rules. RECUR-LIMIT: the maximum number of occurrences or a recurrence rule that are expanded by the CS VERSION: iCalendar version Note that some of the above properties are not defined here since they are defined in iCalendar. The only exception is the "NAME" property that is defined in the VCAR proposal. The following should be modified in the CAP draft due to these definitions: - These definitions should appear in section 11 "Extensions To iCalendar" - Section 10 should be removed since they are its contents are contained within these definitions and the restriction tables for the various commands. - The following properties should be added to the restriction tables that refer to VAGENDA: ALLOW-CONFLICT, CALSCALE, CREATED, DEFAULT-VCARS, LOCALE, LAST-MODIFIED, RELATED-TO, TOMBSTONE, CHARSET - The following should be removed from the VAGENDA section of the restriction tables: CALMASTER. It is not a VAGENDA property. - Simplify the definition of UPN in section 1.3 since a formal definition is supplied here. The following have been changed vis-a-vis the CAP draft: - Renamed VAGENDA property LANGUAGE to LOCALE since LANGUAGE is defined as a parameter in RFC 2445. - Removed the CHILD and PARENT properties from VAGENDA, since the list seems to be in favour of using RELATED-TO instead. - Added TZID to CALSTORE since it is needed if a local time is specified for CURRENT-DATETIME - Refer to RFC 2822 rather than RFC 822, since the latter has been obsoloted by the former. Open Issues: - Should OWNER be a multi-valued property, or should it be single valued and allowed to occur more than once. If the latter than we can easily add parameters if they are needed in the future, e.g, OWNER;TYPE=MAIN:cap:jsmith@acme.com - Should the calendar store component be CALSTORE or VCALSTORE. - Should the CHARSET property become DEFAULT-CHARSET and should we instead define a charset value type? - Do the RECUR-EXPAND and RECUR-LIMIT properties still make sense given the recent changed to VQUERY? - We still need to decide what type of characters are valid for RELCALID. We should comply with RFC 2396 (URI Generic Syntax) (See section 2, URI Characters and Escape Sequences). - What should be the name of the property used to specify the default language for a calendar: LANGUAGE, DEFAULT-LANGUAGE, LOCALE? - Should we use METHOD:DELETE instead of the TOMBSTONE property to indicate whether a VAGENDA has been marked as deleted? - Do we need a limit for bonded recurrences? RECUR-LIMIT only applies to unbounded recurrences. - According to the definition of VERSION in iCalendar, VERSION MUST appear once in a VCALENDAR. The VERSION in CALSTORE is slightly different, in that it defines the version of iCalendar user in the calendar store, and not the version of an iCalendar. Furthermore, by adding a version to CALSTORE we may have: BEGIN:VCALENDAR VERSION:2.0 ... BEGIN:CALSTORE VERSION:2.0 ... END:CALSTORE END:VCALENDAR Which is inconsistent with the RFC 2445 definition: Conformance: This property MUST be specified by an iCalendar object, but MUST only be specified once. Perhaps we should use ICALENDAR-VERSION? However, if CALSTORE is contained in a VCALENDAR, then CALSTORE doesn't need a VERSION at all? =============================================================================== Proposed new text in CAP: x.x Property Value Data Types x.x.1 UPN To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME value type UPN Value Name: UPN Purpose: This value type is used to identify values that contain user principal name of CU or group of CU. Formal Definition: The value type is defined by the following notation: upn = "@" / [ dot-atom-text ] "@" dot-atom-text ; dot-atom-text is defined in RFC 2822 Description: This data type is an identifier that denotes a CU or a group of CU. A UPN is a RFC 2822 compliant e-mail address, with exceptions listed below, and in most cases it is deliverable to the CU. In some cases it is identical to the CU's well known email address. A CU's UPN MUST never be an e-mail address that is deliverable to a different person as there is no requirement that a person's UPN must be his e-mail address. In certain cases a UPN will not be RFC 2822 compliant. When anonymous authentication is used, or anonymous authorization is being defined, the special UPN "@" will be used. When authentication must be used, but unique identity must be obscured, a UPN of the form @DNS-domain-name may be used. Example: The following is a UPN for a CU: jdoe@acme.com The following is a UPN for a group of CU: staff@acme.com The following is a UPN for an anonymous CU belonging to a specific realm: @acme.com The following is a UPN for an anonymous CU: @ x.2 Component Properties x.2.1 Agenda Component Properties x.2.1.1 Allow-Conflict Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property ALLOW-CONFLICT Property Name: ALLOW-CONFLICT Purpose: This property indicates whether or not the calendar supports event conflicts. That is, whether or not any of the events in the calendar can overlap. Value Type: BOOLEAN Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VAGENDA" calendar components. Description: In a "VAGENDA", this property is used to indicate whether events may conflict. If it has a value of TRUE, then conflicts are allowed. If FALSE, the no two events may conflict. If not specified, the default is TRUE. Format Definition: The property is defined by the following notation: allow-conflict = "ALLOW-CONFLICT" allowconflictparam ":" boolean CRLF allowconflictvalue = *(";" xparam) Example: The following is an example of this property for a "VAGENDA" calendar component: ALLOW-CONFLICT:FALSE x.2.1.2 Charset Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property CHARSET Property Name: CHARSET Purpose: This property indicates the default charset for localized strings. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VAGENDA" calendar components. Description: In a "VAGENDA", this property is used to indicate the charset of the localized strings of all its components. If not specified, the default is UTF-8. The value MUST be an IANA registered character set as defined in [RFC 2278]. Format Definition: The property is defined by the following notation: charset = "CHARSET" charsetparam ":" text CRLF charsetparam = *(";" xparam) Example: The following is an example of this property for a "VAGENDA" calendar component: CHARSET:Shift_JIS x.2.1.3 Locale Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property LOCALE Property Name: LOCALE Purpose: This property specifies the default language for text values. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VAGENDA" calendar components. Description: In a "VAGENDA", this property is used to indicate the default language for text values in the components, e.g., "VEVENT", of the "VAGENDA." Format Definition: The property is defined by the following notation: locale = "LOCALE" localeparam ":" language CRLF localeparam = *(";" xparam) locale = Example: The following is an example of this property: LOCALE:da x.2.1.4 Owner Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property OWNER Property Name: OWNER Purpose: The property specifies an owner of a calendar. Value Type: UPN Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: The property MUST be specified at in a "VAGENDA" component. Description: A multi-instanced property indicating the calendar owner. Format Definition: The property is defined by the following notation: owner = "OWNER" ownerparam ":" upn CRLF ownerparam = *(";" xparam) Example: The following is an example of this property: OWNER:jsmith@acme.com OWNER:jdoe@acme.com x.2.1.5 Relative Calendar Identifier Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property RELCALID Property Name: RELCALID Purpose: The property specifies an identifier for a "VAGENDA." It must be unique within the CS. Value Type: URI Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: The property MUST be specified in a "VAGENDA" component. Description: The parameter value MUST be a UTF-8 string. It MUST NOT be empty. [EDITORS NOTE: the actual format of the string has not been defined yet. In cap 06 it is made out of 7 bit printable characters. People suggested it be a utf-8 string. It is an issue being looked at by Pat or Steve. See the issues list.] Format Definition: The property is defined by the following notation: recalid = "RELCALID" recalidparam ":" uri CRLF recalidparam = *(";" xparam) Example: The following is an example of this property: RELCALID:hjik123A001 x.2.1.6 Tombstone Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property TOMBSTONE Property Name: TOMBSTONE Purpose: This property indicates whether or not the calendar has been marked as deleted. Value Type: BOOLEAN Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VAGENDA" calendar components. Description: When this property is TRUE it indicates that the calendar component has been marked as deleted. If FALSE, then it indicates that the calendar component has not been marked as deleted. The default value is FALSE. Format Definition: The property is defined by the following notation: tombstone = "TOMBSTONE" tombstoneparam ":" boolean CRLF tombstoneparam = *(";" xparam) Example: The following is an example of this property: TOMBSTONE:FALSE x.2.2 Calendar Store Component Properties x.2.1.1 Calmaster Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property CALMASTER Property Name: CALMASTER Purpose: The property specifies an e-mail address of a person responsible for the calendar store. Value Type: URI Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified in a "CALSTORE" component. Description: The parameter value MUST be a MAILTO URI as defined in [RFC 1738]. Format Definition: The property is defined by the following notation: calmaster = "CALMASTER" calmasterparam ":" uri CRLF calmasterparam = *(";" xparam) uri = Example: The following is an example of this property: CALMASTER:mailto:administrator@acme.com x.2.1.2 Calendar Store Identifier Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property CSID Property Name: CSID Purpose: The property specifies a the globally unique identifier for the calendar store. Value Type: URI Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified in a "CALSTORE" component. Description: The identifier MUST be globally unique. If not specified, it is the same as the hostname. Format Definition: The property is defined by the following notation: csid = "CSID" csid ":" uri CRLF csid = *(";" xparam) Example: The following is an example of this property: CSID:cap://calendar.acme.com x.2.1.3 Current Date-Time Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property CURRENT-DATETIME Property Name: CURRENT-DATETIME Purpose: This property specifies the current time of the CS. Value Type: DATE-TIME Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property MUST be specified once in "CALSTORE". Description: The date and time MAY be a local time. Format Definition: The property is defined by the following notation: current-datetime = "CURRENT-DATETIME" current-datetimeparam ":" date-time CRLF current-datetimeparam = *(";" xparam) Example: The following is an example of this property: CURRENT-DATETIME;TZID=US-Eastern:20020210T165547 x.2.1.4 Default Access Rights Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property DEFAULT-VCARS Property Name: DEFAULT-VCARS Purpose: This property is used to specify the CARID of the default VCAR components for newly created VAGENDA components. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property MUST be specified in "CALSTORE" calendar components and MUST at least specify the following values: READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER. Description: This property is used in the "CALSTORE" calendar component to specify the CARID of the VCAR components that must be copied in VAGENDA at creation time. Format Definition: The property is defined by the following notation: def-vcars = "DEFAULT-VCARS" def-vcarsparam ":" text *( "," text ) CRLF def-vcarsparam = *( ";" xparam ) Example: The following is an example of this property: DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY DEFAULT-VCARS:UPDATEPARTSTATUS,DEFAULTOWNER x.2.1.5 Maximum Date Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property MAXDATE Property Name: MAXDATE Purpose: This property specifies the date/time in the future beyond which the server cannot represent. Value Type: DATE-TIME Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified once in "CALSTORE". Description: The date and time MUST be a UTC value. If not specified, then 99991231T235959Z will be assumed. Format Definition: The property is defined by the following notation: maxdate = "MAXDATE" maxdateparam ":" date-time CRLF maxdateparam = *(";" xparam) Example: The following is an example of this property: MAXDATE:20990101T000000Z x.2.1.6 Minimum Date Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property MINDATE Property Name: MINDATE Purpose: This property specifies the date/time in the past prior to which the server cannot represent. Value Type: DATE-TIME Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified once in "CALSTORE". Description: The date and time MUST be a UTC value. If not specified, then 00000101T000000Z will be assumed. Format Definition: The property is defined by the following notation: mindate = "MINDATE" mindateparam ":" date-time CRLF mindateparam = *(";" xparam) Example: The following is an example of this property: MINDATE:19710101T000000Z x.2.1.7 Recurrences Accepted Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property RECUR-ACCEPTED Property Name: RECUR-ACCEPTED Purpose: This property indicates whether or not the calendar store accepts recurrence rule. Value Type: BOOLEAN Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "CALSTORE" calendar components. Description: Boolean value will be set to TRUE if the server will accept recurrence rules. It will be set to FALSE if the server will not accept recurrence rules. The default is TRUE. Format Definition: The property is defined by the following notation: recur-accepted = "RECUR-ACCEPTED" recur-acceptedparam ":" boolean CRLF recur-acceptedparam = *(";" xparam) Example: The following is an example of this property: RECUR-ACCEPTED:FALSE x.2.1.8 Recurrences Expand Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property RECUR-EXPAND Property Name: RECUR-EXPAND Purpose: This property indicates whether or not the CS supports the expansion of recurrence rules. Value Type: BOOLEAN Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "CALSTORE" calendar components. Description: If set to TRUE, the CS supports the expansion of recurrence rules. If set to FALSE, the CS is incapable of expanding recurrence rules. The default is TRUE. Format Definition: The property is defined by the following notation: recur-expand = "RECUR-EXPAND" recur-expandparam ":" boolean CRLF recur-expandparam = *(";" xparam) Example: The following is an example of this property: RECUR-EXPAND:FALSE x.2.1.9 Recurences Limit Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property RECUR-LIMIT Property Name: RECUR-LIMIT Purpose: This property describes how the CS handles unbounded recurrences. Value Type: INTEGER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "CALSTORE" calendar components. Description: This numeric value describes how the CS handles unbounded recurrences. The value is only valid if RECURRENCE is TRUE. If the value is 0 it means that the server supports unbounded recurrence rules. If it is non-zero, it is a positive integer indicating the number of instances that will be created when the server expands an unbounded recurrence rule when fetched from the CS. A CUA MUST query for date ranges when this value is zero. Format Definition: The property is defined by the following notation: recur-limit = "RECUR-LIMIT" recur-limitexpand ":" boolean CRLF recur-limitexpand = *(";" xparam) Example: The following is an example of this property: RECUR-LIMIT:100 x.x.2 Calendar Components x.x.2.1 Agenda Component To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME component VAGENDA Component Name: VAGENDA Purpose: Provide a grouping of component properties that defines an agenda. Formal Definition: A "VAGENDA" calendar component is defined by the following notation: agendac = "BEGIN" ":" "VAGENDA" CRLF agendaprop "END" ":" "VAGENDA" CRLF agendaprop = *( ; the following MUST occur exactly once created / owner / recalid / last-mod / ; the following are optional, ; but MUST NOT occur more than once allow-conflict / calscale / charset / locale / tombstone / ; the following are optional, ; and MAY occur more than once name / iana-token / x-prop ) x.x.2.2 Calendar Store Component To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME component CALSTORE Component Name: CALSTORE Purpose: Provide a grouping of component properties that defines a calendar store. Formal Definition: A "CALSTORE" calendar component is defined by the following notation: calstorec = "BEGIN" ":" "CALSTORE" CRLF calstoreprop "END" ":" "CALSTORE" CRLF calstoreprop = *( ; the following MUST occur exactly once calmaster / current-datetime / version / ; the following must occur at least once default-vcar / ; the following are optional, ; but MUST NOT occur more than once maxdate / mindate / recur-accepted / recur-expand / recur-limit / csid / ; the following are optional, ; and MAY occur more than once related / iana-token / x-prop ) From owner-ietf-calendar@mail.imc.org Tue Feb 12 17:55:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00158 for ; Tue, 12 Feb 2002 17:55:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CMjNb17547 for ietf-calendar-bks; Tue, 12 Feb 2002 14:45:23 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (adsl-64-168-10-253.dsl.scrm01.pacbell.net [64.168.10.253]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMjM317543 for ; Tue, 12 Feb 2002 14:45:22 -0800 (PST) Received: from kalia (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.3nb1/8.11.6) with SMTP id g1CMhgP00294; Tue, 12 Feb 2002 14:43:42 -0800 (PST) Date: Tue, 12 Feb 2002 14:43:42 -0800 From: Marshall Rose To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. Message-Id: <20020212144342.76a2ff1a.mrose@dbc.mtview.ca.us> In-Reply-To: <3C697F30.E5E272B@Royer.com> References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C697F30.E5E272B@Royer.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.0claws (GTK+ 1.2.10; i386-netbsd) Mime-Version: 1.0 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 > Patrice Lapierre wrote: > > > > > > > If you re-read BEEP you will see that it allows for empty > > > replies to mean success. If your logic is correct, then > > > a BEEP reply could never be empty - clearly not what they > > > intended. > > > > > > > Please! Just because we can do it, doesn't mean that > > we should. > > > > If it's such a good practice, then can you give me an example > > of a BEEP profile that returns an empty RPY to indicate success. > > Can you show me where in BEEP it defines it is bad practice? > Why was it defined in BEEP as valid: > > > Also in BEEP if the payload doesn't include a mime header > > the default content-type is "application/octect-stream". > > Do we really want to introduce another content-type in CAP? > > If payload lenght == 0 -> success. > I can do that and never care what the content-type is. > It works for XML and non-XML content types. would someone be kind enough to post a succinct message illuminating the issues on this? one can certainly send an empty RPY and have it mean something in the context of a given profile. i'm just trying to understand the motivation for doing so... /mtr From owner-ietf-calendar@mail.imc.org Tue Feb 12 18:08:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00361 for ; Tue, 12 Feb 2002 18:08:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CMwnY17806 for ietf-calendar-bks; Tue, 12 Feb 2002 14:58:49 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMwm317800 for ; Tue, 12 Feb 2002 14:58:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA02931 for ; Tue, 12 Feb 2002 14:58:49 -0800 (PST) Message-ID: <3C699E23.9D845917@Royer.com> Date: Tue, 12 Feb 2002 15:58:43 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C697F30.E5E272B@Royer.com> <1013550248.25003.30.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------E19480DCD4904DC6DA268DFA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E19480DCD4904DC6DA268DFA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > On Tue, 2002-02-12 at 15:46, Doug Royer wrote: > > Patrice Lapierre wrote: > ... > > > > > Also in BEEP if the payload doesn't include a mime header > > > the default content-type is "application/octect-stream". > > > Do we really want to introduce another content-type in CAP? > > > > If payload lenght == 0 -> success. > > I can do that and never care what the content-type is. > > It works for XML and non-XML content types. > > Not for XML content-types, since XML document (or data) must > have a single root. If the BEEP payload is ZERO length, then it does not matter what the MSG content type was, the result is succeess. --------------E19480DCD4904DC6DA268DFA 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 ; Tue, 12 Feb 2002 18:08:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CMvag17780 for ietf-calendar-bks; Tue, 12 Feb 2002 14:57:36 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMvZ317776 for ; Tue, 12 Feb 2002 14:57:35 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA02927 for ; Tue, 12 Feb 2002 14:57:36 -0800 (PST) Message-ID: <3C699DD9.C126126E@Royer.com> Date: Tue, 12 Feb 2002 15:57:29 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@Royer.com> <3C694AFA.C003AB99@steltor.com> <3C695967.A525485C@Royer.com> <3C696A82.9D1597D@steltor.com> <3C697DF3.FD2D4782@Royer.com> <3C698887.64C7FF38@steltor.com> Content-Type: multipart/mixed; boundary="------------DB98B5A7662FABCB8A4AD6DD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DB98B5A7662FABCB8A4AD6DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > I think we may be agreeing, it may be a wording issue. > > > > > Proposal (#2) : > > > > > > When EXPAND is TRUE, the CS MUST only specify the UPN of the > > > currently authenticated user in the GRANT or DENY property of > > > the VRIGHT components of the returned VCAR components. VRIGHT > > > components that don't pertain to the currently authenticated > > > user MUST be left out of the returned VCAR components. > > > > (supply? not specify?) > > When EXPAND is TRUE, the CS MUST only supply the UPN of the ... > > ^^^^^^ > > Agreed with "supply". > > > > > Yes. Now a question. > > > > Will the CUA EVER be able to modify the results of the > > EXPAND:TRUE generated VCAR that the CS sent back to the CUA > > as the result of a query? > > 1- The CUA doesn't "modify results", it modifies components > stored in the CS. The 'results' are a valid VCAR with a BOGUS CARID. Because the CARID is not 'the' CARID. > 2- The means used by the CUA to come up with a replacement > value for a stored component is beyond our control. No, if the CS restores a filtered VCAR with a valid CARID, then how would the CUA know that it is filtered? So it would not know that it can't try. > 3- When managing VCAR components it is expected that CUA > will NOT specify EXPAND:TRUE. But again, there is > nothing we can do to prevent CUA to do stupid things! The CUA will specify EXPAND:TRUE in the query. That is the proposal that I sent out as "Alternate to COALESCE" that we are not debating. > 4- CUA MAY specify EXPAND:TRUE when they are querying > VCAR components for evaluation purposes. Then why in (3) above do you call it 'stupid' ? > I hope that answer your question. You have answered none of my questions, you edited them out of your reply and ignored them completely. Here they are again: Yes. Now a question. Will the CUA EVER be able to modify the results of the EXPAND:TRUE generated VCAR that the CS sent back to the CUA as the result of a query? I would think 'no' because this made up VCAR does not really exist as sent back. If no - then it needs to be marked DECREED? Because for the life of the CAP session - it is not changing. If not marked DECREED, then there MUST be a made up VRIGHT in the returned set that tells the CUA it can not modify the returned VCAR by using the returned CARID? Otherwise it may apply another VCAR results from another EXPAND:FALSE query and assume that the EXPAND:TRUE VCAR results are modifiable. But this seem like too much data - so just mark it DECREED? OR - The result set coming back from the CS as the result of a query from EXPAND:TRUE must NEVER use a CARID that already exists - otherwise, it will be impossible to tell what the VCAR with CARID really is. Or if the VRIGHTS of the EXPAND:FALSE CARID apply to the EXPAND:TRUE CARID VCARs. So I proposed that these generated VCARs always have a CARID of DYNAMIC. And we define that any contents of a CARID:DYNAMIC VCAR are read-only, and only valid for the current session for the current UPN. Then ONE VCAR can be used that only gives them READ access and denies WRITE, MODIFY, and DELETE access to any generated (dynamic) VCAR. Otherwise there has to be one more VRIGHT for each made up on the fly results. Agree? --------------DB98B5A7662FABCB8A4AD6DD 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 ; Tue, 12 Feb 2002 18:16:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CN81D17947 for ietf-calendar-bks; Tue, 12 Feb 2002 15:08:01 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CN80317943 for ; Tue, 12 Feb 2002 15:08:00 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA29166 for ; Tue, 12 Feb 2002 18:07:57 -0500 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 g1CN7vQ21332 for ; Tue, 12 Feb 2002 18:07:57 -0500 (EST) Subject: Re: (#2) Byte reduction in BEEP commands. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <20020212144342.76a2ff1a.mrose@dbc.mtview.ca.us> References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C697F30.E5E272B@Royer.com> <20020212144342.76a2ff1a.mrose@dbc.mtview.ca.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Feb 2002 18:15:22 -0500 Message-Id: <1013555722.25003.50.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-02-12 at 17:43, Marshall Rose wrote: > > > > If payload lenght == 0 -> success. > > I can do that and never care what the content-type is. > > It works for XML and non-XML content types. > > would someone be kind enough to post a succinct message illuminating > the issues on this? > > one can certainly send an empty RPY and have it mean something in the context of a given profile. i'm just trying to understand the motivation for doing so... > > /mtr > Doug suggested sending a RPY with an empty payload for a successful response instead of: The sole motivation was to reduce the number of bytes. For consistency, I would prefer always sending an XML response to a XML command (I'm not arguing that empty payload are invalid). -- Patrice. From owner-ietf-calendar@mail.imc.org Tue Feb 12 18:27:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00661 for ; Tue, 12 Feb 2002 18:27:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CNFHZ18054 for ietf-calendar-bks; Tue, 12 Feb 2002 15:15:17 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CNFG318050 for ; Tue, 12 Feb 2002 15:15:16 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA02963 for ; Tue, 12 Feb 2002 15:15:17 -0800 (PST) Message-ID: <3C69A1FE.A052B5B9@Royer.com> Date: Tue, 12 Feb 2002 16:15:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C693BA5.78614FEB@steltor.com> <3C6946DD.DA88AD75@Royer.com> <3C695649.A18BA86C@steltor.com> <3C69616F.5FC125C5@Royer.com> <3C6993F0.ADFAB1D5@steltor.com> Content-Type: multipart/mixed; boundary="------------6C4F22417F02F781752947E0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6C4F22417F02F781752947E0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > BEGIN:VCALENDAR > > > > > METHOD:REQUEST > > > > > BEGIN:VEVENT > > > > > UID:abc123 > > > > > RRULE:... > > > > > ... > > > > > END:VEVENT > > > > > BEGIN:VEVENT > > > > > UID:abc123 > > > > > ... exception 1... > > > > > END:VEVENT > > > > > BEGIN:VEVENT > > > > > UID:abc123 > > > > > ... exception 2... > > > > > END:VEVENT > > > > > END:VCALENDAR > > > > > > > > > I would never ask for expanded un-booked iTIP objects. I would > > ask for all iTIP objects and then merge them in the CUA, then > > deposit the result in the CS, then delete all merged > > un-booked objects. > > > > They would both return the same data except the EXPAND:TRUE > > results would contain more and those would contain RECURRANCE-ID's. > > > > So the result would be as provided in the example at the top of > > this email (as supplied to the CS), or each one BEGIN/END > > VCALENDAR would be returned separately as we (I think) agreed > > would be valid. > > Ordering would be lost if they were returned separately. Why? - BEEP serialize data in the order it was provided. And there is NO ordering in iTIP objects outside of their own contents. That is why SEQUENCE and UID exist inside objects. So each VEVENT MUST contain that information. If they were received out of order, iTIP tells you how to reassemble them anyway. > 1- That's not what one is lead to believe in reading draft-05 > or draft-06: I am one also - an I belive :-) > 3- Let's look at another example. Given: > > BEGIN:VCALENDAR > METHOD:REQUEST > BEGIN:VEVENT > UID:abc123 > RRULE:... > ... > END:VEVENT > BEGIN:VEVENT > UID:abc123 > LOCATION:Montreal > ... exception 1... > END:VEVENT > BEGIN:VEVENT > UID:abc123 > LOCATION:Toronto > ... exception 2... > END:VEVENT > END:VCALENDAR > > What would be returned for the following VQUERY components: > > a) BEGIN:VQUERY > QUERYNAME:Query-01 > QUERY:SELECT * FROM VEVENT > WHERE LOCATION = 'Montreal' > END:VQUERY You would get the entire contents of UID 'abc123', together or in separate BEEP payloads. > b) BEGIN:VQUERY > QUERYNAME:Query-02 > EXPAND:TRUE > QUERY:SELECT * FROM VEVENT > WHERE LOCATION = 'Montreal' > END:VQUERY You would get the entire contents of UID 'abc123', together or in separate BEEP payloads expanded into its instances. --------------6C4F22417F02F781752947E0 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 ; Tue, 12 Feb 2002 18:45:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CNZSa18410 for ietf-calendar-bks; Tue, 12 Feb 2002 15:35:28 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CNZQ318406 for ; Tue, 12 Feb 2002 15:35:26 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA02989 for ; Tue, 12 Feb 2002 15:35:28 -0800 (PST) Message-ID: <3C69A6B8.A25872B0@Royer.com> Date: Tue, 12 Feb 2002 16:35:20 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------88E2E4ED7C294FF8A0FD023B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------88E2E4ED7C294FF8A0FD023B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: I broke your text into multiple replies. > The following is a proposal for the definitions of the VAGENDA > and CALSTORE components and their properties. These definitions > are based on the descriptions found in the CAP draft. > > This is the first iteration. Please review. Once I get people's > fixes and suggestions in, I will make a formal proposal. > > Summary: > > The VAGENDA component describes the calendars belonging to users. > It contains VEVENTs, VJOURNALs, VTIMEZONEs, VTODOs, VQUERYs, and > VCARs. The properties that a VAGENDA may have are: > LOCALE: the default language > NAME: the name of the calendar (e.g., "Work") Must NAME be in LOCALE? Can there be multiple instances of this property? - I would say yes. - each with its own unique LANGUAGE parameter? - Yes. If it can not be multiple, then I would say it MUST BE in LOCALE. You forgot 'TZID' (in this section) : the default TZ for the VAGENDA so that CUAs know what is meant when 'localtime' date-time values are used. > The CALSTORE component is used to contain the properties of > the calendar store. These properties are: > CURRENT-DATETIME: the current date and time on the CS Did we agree to drop CURRENT-DATETIME ? As an option, if it is wanted, maybe we can return the current date-time as part of the greeting or capability reply? > MAXDATE: last date time that is supported by the CWS > MINDATE: first date-time that is supported by the CS MAXDATE and MINDATE are in capabilities lets take them out of CS properties. > RECUR-ACCEPTED: whether the CS accepts recurrence rules > RECUR-EXPAND : whether or not the CS supports the > expansion of recurrence rules. > RECUR-LIMIT: the maximum number of occurrences or a recurrence > rule that are expanded by the CS Move the above 4 properties into capabilities? As they are will effect what commands the CUA sends to the CS. > VERSION: iCalendar version Move it to CAP-VERSION and make it a capability? I think we agreed that it is CAP version 1.0 which is unrelated to iCalendar version. The CAPABILITIES section should specify the iCalendar and iTIP version that are supported in addition to the CAP-VERSION. AND: We drop DEFAULT-VARS from the calendar properties, it only applied to CALSTORE - correct? --------------88E2E4ED7C294FF8A0FD023B 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 ; Tue, 12 Feb 2002 18:49:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1CNdEm18471 for ietf-calendar-bks; Tue, 12 Feb 2002 15:39:14 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CNdD318466 for ; Tue, 12 Feb 2002 15:39:13 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA29554 for ; Tue, 12 Feb 2002 18:39:11 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CNdAQ24395 for ; Tue, 12 Feb 2002 18:39:10 -0500 (EST) Message-ID: <3C69A818.659702FA@steltor.com> Date: Tue, 12 Feb 2002 18:41:12 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C693BA5.78614FEB@steltor.com> <3C6946DD.DA88AD75@Royer.com> <3C695649.A18BA86C@steltor.com> <3C69616F.5FC125C5@Royer.com> <3C6993F0.ADFAB1D5@steltor.com> <3C69A1FE.A052B5B9@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: > > > 3- Let's look at another example. Given: > > > > BEGIN:VCALENDAR > > METHOD:REQUEST > > BEGIN:VEVENT > > UID:abc123 > > RRULE:... > > ... > > END:VEVENT > > BEGIN:VEVENT > > UID:abc123 > > LOCATION:Montreal > > ... exception 1... > > END:VEVENT > > BEGIN:VEVENT > > UID:abc123 > > LOCATION:Toronto > > ... exception 2... > > END:VEVENT > > END:VCALENDAR > > > > What would be returned for the following VQUERY components: > > > > a) BEGIN:VQUERY > > QUERYNAME:Query-01 > > QUERY:SELECT * FROM VEVENT > > WHERE LOCATION = 'Montreal' > > END:VQUERY > > You would get the entire contents of UID 'abc123', together > or in separate BEEP payloads. At this point we can't guess what you mean exactly. Can you specify the VCALENDAR you think would be returned? > > b) BEGIN:VQUERY > > QUERYNAME:Query-02 > > EXPAND:TRUE > > QUERY:SELECT * FROM VEVENT > > WHERE LOCATION = 'Montreal' > > END:VQUERY > > You would get the entire contents of UID 'abc123', together > or in separate BEEP payloads expanded into its instances. Ditto. Regards, 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 Feb 12 19:08:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01230 for ; Tue, 12 Feb 2002 19:08:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CNvrS18858 for ietf-calendar-bks; Tue, 12 Feb 2002 15:57:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CNvq318854 for ; Tue, 12 Feb 2002 15:57:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA03020 for ; Tue, 12 Feb 2002 15:57:53 -0800 (PST) Message-ID: <3C69ABF9.5F2A14F4@Royer.com> Date: Tue, 12 Feb 2002 16:57:45 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP open issues References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------39508A5869AB6DB7243597D8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------39508A5869AB6DB7243597D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > Open Issues: > > - Should OWNER be a multi-valued property, or should it be > single valued and allowed to occur more than once. > If the latter than we can easily add parameters if they > are needed in the future, e.g, > OWNER;TYPE=MAIN:cap:jsmith@acme.com I agree - multi instance. > - Should the calendar store component be CALSTORE or > VCALSTORE. I noticed in 2445, it says that ALL iCalendar objects start with a 'V', so I guess we should do that. > - Should the CHARSET property become DEFAULT-CHARSET and > should we instead define a charset value type? Yes I agree - DEFAULT-CHARSET is a better choice for a name. Yes I agree - we do need to specify what the format is, I am sure that some RFC covers that. AND: And I think that a charset-list should be returned in the capabilities reply - with the first one being the default for the CS and any other being what the CS supports. > - Do the RECUR-EXPAND and RECUR-LIMIT properties still make sense > given the recent changed to VQUERY? I think they should be capabilities. AND: we need to re-add expansion limits to VQUERY, what if something goes on forever - how many will EXPAND:TRUE with NO date time limit return with out it? > - We still need to decide what type of characters are valid for > RELCALID. We should comply with RFC 2396 (URI Generic Syntax) Yes - and say that RELCALID MUST BE 8 bit capable so that when URI's are 8-bit we will not require any changes. > - What should be the name of the property used to specify the > default language for a calendar: LANGUAGE, DEFAULT-LANGUAGE, > LOCALE? I would opt for DEFAULT-LOCALE. It's not LANGUAGE, its the locale. or maybe LOCALE. And making the BEEP 'localize' attribute sent in the BEEP greeting RPY a MUST in the CAP greeting so CUA can select the locale for any CS error messages. > - Should we use METHOD:DELETE instead of the TOMBSTONE property > to indicate whether a VAGENDA has been marked as deleted? Yes - I agree. > - Do we need a limit for bonded recurrences? RECUR-LIMIT only applies > to unbounded recurrences. A CUA reading on a TCP connection is not forced to read more that it wants. If you get too much. Stop reading and throw away the rest - or/and abort the command using a separate channel. We need a limit in the VQUERY so that unbounded recurrence rules don't go on for ever. A CUA might not know in advance if "SELECT * FROM VEVENT" with EXPAND:TRUE has any recurrence rules set - so we need to allow the CUA to bound the number of replies. > - According to the definition of VERSION in iCalendar, VERSION MUST > appear once in a VCALENDAR. The VERSION in CALSTORE is slightly > different, in that it defines the version of iCalendar user in > the calendar store, and not the version of an iCalendar. Furthermore, > by adding a version to CALSTORE we may have: The 2445 VERSION is the version of the 2445 record format, is not the VERSION of iTIP or CAP. Do we mandate it as part of ANY query reply - so the CUA knows that the data coming back conforms to iCalendar 2.0 record format? > Perhaps we should use ICALENDAR-VERSION? How about CAP-VERSION as it is the VERSION of the CAP protocol. And lets move it from a property to a capability. > However, if CALSTORE is contained in a VCALENDAR, then CALSTORE > doesn't need a VERSION at all? Again - CAP protocol version vs iCalendar record format. --------------39508A5869AB6DB7243597D8 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 ; Tue, 12 Feb 2002 19:08:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CNvag18844 for ietf-calendar-bks; Tue, 12 Feb 2002 15:57:36 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (adsl-64-168-10-253.dsl.scrm01.pacbell.net [64.168.10.253]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CNvZ318838 for ; Tue, 12 Feb 2002 15:57:35 -0800 (PST) Received: from kalia (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.3nb1/8.11.6) with SMTP id g1CNtTP00455; Tue, 12 Feb 2002 15:55:29 -0800 (PST) Date: Tue, 12 Feb 2002 15:55:29 -0800 From: Marshall Rose To: "Patrice Lapierre" Cc: ietf-calendar@imc.org Subject: Re: (#2) Byte reduction in BEEP commands. Message-Id: <20020212155529.5f3416d6.mrose@dbc.mtview.ca.us> In-Reply-To: <1013555722.25003.50.camel@c-1241.in.steltor.com> References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C697F30.E5E272B@Royer.com> <20020212144342.76a2ff1a.mrose@dbc.mtview.ca.us> <1013555722.25003.50.camel@c-1241.in.steltor.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.0claws (GTK+ 1.2.10; i386-netbsd) Mime-Version: 1.0 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 suggested sending a RPY with an empty payload for a successful > response instead of: > > > > > > The sole motivation was to reduce the number of bytes. > > For consistency, I would prefer always sending an XML response > to a XML command (I'm not arguing that empty payload are invalid). from the beep-perspective, you can pretty much define whatever rules that make sense in the context of the profile in question. if folks are comfortable, that this isn't going to turn into one of those "obvious optimizations that end up causing problems down the road", then an empty RPY doesn't violate any rules. in other beep profiles, typically "" is used to indicate generic success and ... is used to differentiate failure. this is pretty much the same, though slightly less verbose, than what calsch is doing, although i can't get too worked-up over the issue myself. certainly in the "" case, many more octets are wasted on the content-type than anything else. the reason is that the beep wg decided (after a nice pitch from joe touch) that it was better to explicilty tag the content-type for the purpose of sniffers, etc. /mtr From owner-ietf-calendar@mail.imc.org Tue Feb 12 19:21:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01395 for ; Tue, 12 Feb 2002 19:21:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D07D219061 for ietf-calendar-bks; Tue, 12 Feb 2002 16:07:13 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D07C319057 for ; Tue, 12 Feb 2002 16:07:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03039 for ; Tue, 12 Feb 2002 16:07:14 -0800 (PST) Message-ID: <3C69AE2A.43C4FEEB@Royer.com> Date: Tue, 12 Feb 2002 17:07:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------DC8748F9DA956284F0E78B41" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DC8748F9DA956284F0E78B41 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > x.2 Component Properties > > x.2.1 Agenda Component Properties > > x.2.1.1 Allow-Conflict Component Property > Conformance: This property can be specified in "VAGENDA" calendar > components. Components or component? > Description: In a "VAGENDA", this property is used to indicate > whether events may conflict. If it has a value of TRUE, then > conflicts are allowed. If FALSE, the no two events may conflict. ... If FALSE, then ... (not 'the') And how about replace: If FALSE, then no two events may conflict With: If FALSE, then no two components or their expanded instances can share the same time or overlap the same time periods. --------------DC8748F9DA956284F0E78B41 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 ; Tue, 12 Feb 2002 19:25:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D0GIG19342 for ietf-calendar-bks; Tue, 12 Feb 2002 16:16:18 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0GC319332 for ; Tue, 12 Feb 2002 16:16:13 -0800 (PST) To: Marshall Rose Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: (#2) Byte reduction in BEEP commands. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 12 Feb 2002 19:15:48 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 02/12/2002 07:16:20 PM, Serialize complete at 02/12/2002 07:16:20 PM Content-Type: multipart/alternative; boundary="=_alternative 000172C385256B5F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000172C385256B5F_= Content-Type: text/plain; charset="us-ascii" Marshall Rose wrote: >>would someone be kind enough to post a succinct message illuminating the issues on this? AMEN! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 000172C385256B5F_= Content-Type: text/html; charset="us-ascii"
Marshall Rose wrote:

>>would someone be kind enough to post a succinct message illuminating the issues on this?

AMEN!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 000172C385256B5F_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 12 19:28:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01517 for ; Tue, 12 Feb 2002 19:28:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D0HMG19367 for ietf-calendar-bks; Tue, 12 Feb 2002 16:17:22 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0HL319362 for ; Tue, 12 Feb 2002 16:17:21 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03053 for ; Tue, 12 Feb 2002 16:17:23 -0800 (PST) Message-ID: <3C69B08B.7BA24C66@Royer.com> Date: Tue, 12 Feb 2002 17:17:15 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------48859E779B24ACC52D67CF41" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------48859E779B24ACC52D67CF41 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > x.2.1.2 Charset Component Property > > To: ietf-calendar@imc.org > > Subject: Registration of text/calendar MIME property CHARSET > > Property Name: CHARSET > > Purpose: This property indicates the default charset for localized > strings. > > Value Type: TEXT > > Property Parameters: Non-standard property parameters can be > specified on this property. > > Conformance: This property can be specified in "VAGENDA" calendar > components. Again, components or component? > Description: In a "VAGENDA", this property is used to indicate the > charset of the localized strings of all its components. If not > specified, the default is UTF-8. The value MUST be an IANA registered > character set as defined in [RFC 2278]. Dilemma: How do you know the charset the reply that includes CHARSET is going to come back in? Example, the default charset for a calendar is X, then how can you read X if you don't know that X is described in the X charset? Proposal - We add this to the VQUERY notes: When querying for only the CHARSET property and nothing else, the results MUST be returned in the UTF-8 charset as in the following example: TARGET:relcalid QUERY:SELECT CHARSET FROM VAGENDA When querying and CHARSET is one of at least one more property, then the CHARSET is returned in the CHARSET charset as shown by the following example: TARGET:relcalid QUERY:SELECT * FROM VAGENDA --------------48859E779B24ACC52D67CF41 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 ; Tue, 12 Feb 2002 19:35:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D0Od119459 for ietf-calendar-bks; Tue, 12 Feb 2002 16:24:39 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0Oc319454 for ; Tue, 12 Feb 2002 16:24:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03064 for ; Tue, 12 Feb 2002 16:24:40 -0800 (PST) Message-ID: <3C69B240.43D9269D@Royer.com> Date: Tue, 12 Feb 2002 17:24:32 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Locale Component Property References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------DC855AAF5A0408D5340DA9F2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DC855AAF5A0408D5340DA9F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > x.2.1.3 Locale Component Property > > To: ietf-calendar@imc.org > > Subject: Registration of text/calendar MIME property LOCALE > > Property Name: LOCALE > > Purpose: This property specifies the default language for text values. > > Value Type: TEXT > > Property Parameters: Non-standard property parameters can be > specified on this property. > > Conformance: This property can be specified in "VAGENDA" calendar > components. Component not components. > Description: In a "VAGENDA", this property is used to indicate > the default language for text values in the components, e.g., > "VEVENT", of the "VAGENDA." > > Format Definition: The property is defined by the following notation: > > locale = "LOCALE" localeparam ":" language CRLF > > localeparam = *(";" xparam) > > locale = Add (IANA values are 3-8 characters per 3066)? And the preferred values are the ones that include both the language and country. > LOCALE:da Change to (or some other 3 to 8 letter IANA registered value: LOCALE:fr_CA --------------DC855AAF5A0408D5340DA9F2 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 ; Tue, 12 Feb 2002 19:41:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D0WcP19596 for ietf-calendar-bks; Tue, 12 Feb 2002 16:32:38 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0Wb319592 for ; Tue, 12 Feb 2002 16:32:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03087 for ; Tue, 12 Feb 2002 16:32:40 -0800 (PST) Message-ID: <3C69B420.9A2889B@Royer.com> Date: Tue, 12 Feb 2002 17:32:32 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Calendar Store Identifier Component Property > References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------16CBEB637A3537969F6A4990" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------16CBEB637A3537969F6A4990 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > x.2.1.2 Calendar Store Identifier Component Property > Value Type: URI > > Property Parameters: Non-standard property parameters can be > specified on this property. > > Conformance: The property can be specified in a "CALSTORE" component. > > Description: The identifier MUST be globally unique. If not specified, > it is the same as the hostname. I think we need to add the same 8-bit note here, so that when there are 8-bit URIs, we don't have to add anything. --------------16CBEB637A3537969F6A4990 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 ; Tue, 12 Feb 2002 19:45:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D0Zam19664 for ietf-calendar-bks; Tue, 12 Feb 2002 16:35:36 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0ZZ319660 for ; Tue, 12 Feb 2002 16:35:35 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03091 for ; Tue, 12 Feb 2002 16:35:37 -0800 (PST) Message-ID: <3C69B4D2.AD9B8EF9@Royer.com> Date: Tue, 12 Feb 2002 17:35:30 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------2E777C6CF5F718E879B76DA6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2E777C6CF5F718E879B76DA6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > x.2.1.3 Current Date-Time Component Property I again propose that we drop this from CAP and make it part of the capability reply and that it must be in UTC and it MUST be supplied. 20020212T173455Z --------------2E777C6CF5F718E879B76DA6 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 ; Tue, 12 Feb 2002 19:45:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D0brD19693 for ietf-calendar-bks; Tue, 12 Feb 2002 16:37:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0bq319689 for ; Tue, 12 Feb 2002 16:37:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id TAA30218 for ; Tue, 12 Feb 2002 19:37:50 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1D0bnQ29698 for ; Tue, 12 Feb 2002 19:37:49 -0500 (EST) Message-ID: <3C69B5D6.F4AB5F77@steltor.com> Date: Tue, 12 Feb 2002 19:39:50 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@Royer.com> <3C694AFA.C003AB99@steltor.com> <3C695967.A525485C@Royer.com> <3C696A82.9D1597D@steltor.com> <3C697DF3.FD2D4782@Royer.com> <3C698887.64C7FF38@steltor.com> <3C699DD9.C126126E@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: > > > > > Yes. Now a question. > > > > > > Will the CUA EVER be able to modify the results of the > > > EXPAND:TRUE generated VCAR that the CS sent back to the CUA > > > as the result of a query? > > > > 1- The CUA doesn't "modify results", it modifies components > > stored in the CS. > > The 'results' are a valid VCAR with a BOGUS CARID. > Because the CARID is not 'the' CARID. It's not because you don't get the full content of the VCAR that its CARID is BOGUS. What next? You are going to tell me that the UID of a VEVENT for which I'm not granted the RIGHT to READ the LOCATION property should be returned to me with a different UID? Think about it. Come on. > > 2- The means used by the CUA to come up with a replacement > > value for a stored component is beyond our control. > > No, if the CS restores a filtered VCAR with a valid CARID, > then how would the CUA know that it is filtered? So it > would not know that it can't try. Read the proposal. The CUA will only get partial VCAR components if (1) he explicitly requests the CS by specifying EXPAND:TRUE in the VQUERY (in which case it knows that the VCAR may not be complete) or if (2) he is not granted the right to modify the VCAR (in which case there is no issue). > > 3- When managing VCAR components it is expected that CUA > > will NOT specify EXPAND:TRUE. But again, there is > > nothing we can do to prevent CUA to do stupid things! > > The CUA will specify EXPAND:TRUE in the query. That is > the proposal that I sent out as "Alternate to COALESCE" > that we are not debating. The CUA should only specify EXPAND:TRUE if it wants to figure out the access right of the currently authenticated user NOT when it wants to administer them. That's the whole point! > > 4- CUA MAY specify EXPAND:TRUE when they are querying > > VCAR components for evaluation purposes. > > Then why in (3) above do you call it 'stupid' ? If the CUA's intent is to administer VCAR, that is, get them from the CS to modify their content later on, well yes, it would have to be very stupid. If the CUA's intent is to figure out rights that are granted and denied to the currently authenticated user, then it may specify EXPAND:TRUE to only get the useful information. > > I hope that answer your question. > > You have answered none of my questions, you edited them out > of your reply and ignored them completely. Here they are again: Well, I've had entire proposals edited out and ignored completely in replies. Very annoying isn't it? > > Yes. Now a question. > > Will the CUA EVER be able to modify the results of the > EXPAND:TRUE generated VCAR that the CS sent back to the CUA > as the result of a query? I would think 'no' because this > made up VCAR does not really exist as sent back. That's irrelevant. See above. > > If no - then it needs to be marked DECREED? Because for > the life of the CAP session - it is not changing. That's not true. You read a VCAR stored in my VAGENDA in which you are granted some rights. 2 seconds later I deny you those rights. The VCAR changed. QED. > If not marked DECREED, then there MUST be a made up > VRIGHT in the returned set that tells the CUA it can not > modify the returned VCAR by using the returned CARID? > Otherwise it may apply another VCAR results from another > EXPAND:FALSE query and assume that the EXPAND:TRUE VCAR > results are modifiable. But this seem like too much > data - so just mark it DECREED? That doesn't make sense. What if the CUA simply wants to know if it can modify a given VCAR in his VAGENDA? Querying with EXPAND:TRUE would always have him believe that he is denied the right? That's ridiculous. > OR - The result set coming back from the CS as the result > of a query from EXPAND:TRUE must NEVER use a CARID that already > exists - otherwise, it will be impossible to tell what the > VCAR with CARID really is. Or if the VRIGHTS of the EXPAND:FALSE > CARID apply to the EXPAND:TRUE CARID VCARs. So I proposed > that these generated VCARs always have a CARID of DYNAMIC. > And we define that any contents of a CARID:DYNAMIC VCAR > are read-only, and only valid for the current session for > the current UPN. > > Then ONE VCAR can be used that only gives them READ access > and denies WRITE, MODIFY, and DELETE access to any generated > (dynamic) VCAR. Otherwise there has to be one more VRIGHT > for each made up on the fly results. Very clever! I would then receive all the VCAR components with predefined CARID with CARID:DYNAMIC. Do you really want to make VCAR with predefined CARIDs unusable? Are we done yet? Regards, 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 Feb 12 19:53:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01928 for ; Tue, 12 Feb 2002 19:53:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D0gUv19791 for ietf-calendar-bks; Tue, 12 Feb 2002 16:42:30 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0gT319787 for ; Tue, 12 Feb 2002 16:42:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03104 for ; Tue, 12 Feb 2002 16:42:29 -0800 (PST) Message-ID: <3C69B669.785A1060@Royer.com> Date: Tue, 12 Feb 2002 17:42:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Default Access Rights Component Property References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------895ED7DD53E6004EE4CABA1C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------895ED7DD53E6004EE4CABA1C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > x.2.1.4 Default Access Rights Component Property > > To: ietf-calendar@imc.org > > Subject: Registration of text/calendar MIME property DEFAULT-VCARS > > Property Name: DEFAULT-VCARS > > Purpose: This property is used to specify the CARID of the > default VCAR components for newly created VAGENDA components. > > Value Type: TEXT > > Property Parameters: Only non-standard property parameters can be > specified on this property. > > Conformance: This property MUST be specified in "CALSTORE" calendar > components and MUST at least specify the following values: > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER. > > Description: This property is used in the "CALSTORE" calendar > component to specify the CARID of the VCAR components that > must be copied in VAGENDA at creation time. Add: And as CARIDs may contain spaces, those values must be wrapped in quotes. > Format Definition: The property is defined by the following notation: > > def-vcars = "DEFAULT-VCARS" def-vcarsparam ":" text > *( "," text ) CRLF > > def-vcarsparam = *( ";" xparam ) > > Example: The following is an example of this property: > > DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY > DEFAULT-VCARS:UPDATEPARTSTATUS,DEFAULTOWNER Add something like: DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY ,UPDATEPARTSTATUS,DEFAULTOWNER,"My Private CARID" --------------895ED7DD53E6004EE4CABA1C 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 ; Tue, 12 Feb 2002 19:57:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D0mk519925 for ietf-calendar-bks; Tue, 12 Feb 2002 16:48:46 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0mj319921 for ; Tue, 12 Feb 2002 16:48:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03128 for ; Tue, 12 Feb 2002 16:48:47 -0800 (PST) Message-ID: <3C69B7E7.76FA6566@Royer.com> Date: Tue, 12 Feb 2002 17:48:39 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Agenda Component References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------0FFB0CD98B3A6CDBD35B0321" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0FFB0CD98B3A6CDBD35B0321 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > x.x.2.1 Agenda Component > > agendaprop = *( > ; the following MUST occur exactly once > > created / owner / recalid / last-mod / > > ; the following are optional, > ; but MUST NOT occur more than once > > allow-conflict / calscale / charset / locale / > tombstone / > > ; the following are optional, > ; and MAY occur more than once > > name / iana-token / x-prop Add: x-component --------------0FFB0CD98B3A6CDBD35B0321 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 ; Tue, 12 Feb 2002 19:58:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D0kGj19882 for ietf-calendar-bks; Tue, 12 Feb 2002 16:46:16 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0kF319878 for ; Tue, 12 Feb 2002 16:46:15 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03119 for ; Tue, 12 Feb 2002 16:46:17 -0800 (PST) Message-ID: <3C69B751.2F50B1B2@Royer.com> Date: Tue, 12 Feb 2002 17:46:09 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: MIN/MAX date and RECUR properties. References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------C6B87FD1FAFD52D0C11ACD88" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C6B87FD1FAFD52D0C11ACD88 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: I propose all of these be dropped as properties and moved into categories - as they effect what the CUA will send on the wire to the CS and reduce the chattiness of the protocol by not having to do both a get-capabilities and query. > x.2.1.5 Maximum Date Component Property > x.2.1.6 Minimum Date Component Property > x.2.1.7 Recurrences Accepted Component Property > x.2.1.8 Recurrences Expand Component Property --------------C6B87FD1FAFD52D0C11ACD88 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 ; Tue, 12 Feb 2002 20:00:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D0pjb20005 for ietf-calendar-bks; Tue, 12 Feb 2002 16:51:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0pi320000 for ; Tue, 12 Feb 2002 16:51:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03145 for ; Tue, 12 Feb 2002 16:51:46 -0800 (PST) Message-ID: <3C69B89B.BB990DD3@Royer.com> Date: Tue, 12 Feb 2002 17:51:39 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> Content-Type: multipart/mixed; boundary="------------EDA9E7552823DB029183C109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EDA9E7552823DB029183C109 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > x.x.2.2 Calendar Store Component > related / iana-token / x-prop Add: vcar Do we want to add: x-component --------------EDA9E7552823DB029183C109 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 ; Tue, 12 Feb 2002 20:04:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D0ti420089 for ietf-calendar-bks; Tue, 12 Feb 2002 16:55:44 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0th320085 for ; Tue, 12 Feb 2002 16:55:43 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03158; Tue, 12 Feb 2002 16:55:43 -0800 (PST) Message-ID: <3C69B987.A31F78B2@Royer.com> Date: Tue, 12 Feb 2002 17:55:35 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marshall Rose , "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C697F30.E5E272B@Royer.com> <20020212144342.76a2ff1a.mrose@dbc.mtview.ca.us> Content-Type: multipart/mixed; boundary="------------567EDFE1EF6FDD0CCB24B7F9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------567EDFE1EF6FDD0CCB24B7F9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Marshall Rose wrote: ks for XML and non-XML content types. > > would someone be kind enough to post a succinct message illuminating > the issues on this? > > one can certainly send an empty RPY and have it mean something in the > context of a given profile. i'm just trying to understand the > motivation for doing so... It is in the context of reducing the byte count in the CAP protocol for replies that have no data other than to say success. I just don't see the need to add a message that says if you got me you must read me to know that there are not any problems. When "if payload.length == 0" will work. --------------567EDFE1EF6FDD0CCB24B7F9 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 ; Tue, 12 Feb 2002 20:08:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D0xeq20170 for ietf-calendar-bks; Tue, 12 Feb 2002 16:59:40 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0xd320166 for ; Tue, 12 Feb 2002 16:59:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA03168 for ; Tue, 12 Feb 2002 16:59:41 -0800 (PST) Message-ID: <3C69BA75.12ABA021@Royer.com> Date: Tue, 12 Feb 2002 17:59:33 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C693BA5.78614FEB@steltor.com> <3C6946DD.DA88AD75@Royer.com> <3C695649.A18BA86C@steltor.com> <3C69616F.5FC125C5@Royer.com> <3C6993F0.ADFAB1D5@steltor.com> <3C69A1FE.A052B5B9@Royer.com> <3C69A818.659702FA@steltor.com> Content-Type: multipart/mixed; boundary="------------CDC1846E4E88A14BA882E4D3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CDC1846E4E88A14BA882E4D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > 3- Let's look at another example. Given: > > > > > > BEGIN:VCALENDAR > > > METHOD:REQUEST > > > BEGIN:VEVENT > > > UID:abc123 > > > RRULE:... > > > ... > > > END:VEVENT > > > BEGIN:VEVENT > > > UID:abc123 > > > LOCATION:Montreal > > > ... exception 1... > > > END:VEVENT > > > BEGIN:VEVENT > > > UID:abc123 > > > LOCATION:Toronto > > > ... exception 2... > > > END:VEVENT > > > END:VCALENDAR > > > > > > What would be returned for the following VQUERY components: > > > > > > a) BEGIN:VQUERY > > > QUERYNAME:Query-01 > > > QUERY:SELECT * FROM VEVENT > > > WHERE LOCATION = 'Montreal' > > > END:VQUERY > > > > You would get the entire contents of UID 'abc123', together > > or in separate BEEP payloads. > > At this point we can't guess what you mean exactly. > Can you specify the VCALENDAR you think would be > returned? The same as the data initially supplied in your example. -If you put in in that way, you should get it out that way. As to multiple replies: I was not the one that proposed that a reply can be in multiple ANS messages. I am just agreeing that it can be. --------------CDC1846E4E88A14BA882E4D3 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 ; Tue, 12 Feb 2002 20:08:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D0uOj20109 for ietf-calendar-bks; Tue, 12 Feb 2002 16:56:24 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0uN320105 for ; Tue, 12 Feb 2002 16:56:23 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id TAA30351 for ; Tue, 12 Feb 2002 19:56:21 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1D0uKQ01405 for ; Tue, 12 Feb 2002 19:56:20 -0500 (EST) Message-ID: <3C69BA2E.2B1B4958@steltor.com> Date: Tue, 12 Feb 2002 19:58:22 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: CALSTORE vs VCALSTORE / VRIGHT vs RIGHT (Was: Re: CAP open issues) References: <3C699404.DAF9AE4A@steltor.com> <3C69ABF9.5F2A14F4@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: > > George Babics wrote: > > > Open Issues: > > > > - Should OWNER be a multi-valued property, or should it be > > single valued and allowed to occur more than once. > > If the latter than we can easily add parameters if they > > are needed in the future, e.g, > > OWNER;TYPE=MAIN:cap:jsmith@acme.com > > I agree - multi instance. > > > - Should the calendar store component be CALSTORE or > > VCALSTORE. > > I noticed in 2445, it says that ALL iCalendar objects > start with a 'V', so I guess we should do that. I also think that we should call it VCALSTORE, but on the other hand, it should be noted that RFC 2445 also defines two components that don't start with 'V'. > standardc = "BEGIN" ":" "STANDARD" CRLF > tzprop > "END" ":" "STANDARD" CRLF > > daylightc = "BEGIN" ":" "DAYLIGHT" CRLF > tzprop > "END" ":" "DAYLIGHT" CRLF Are these not considered "calendar components"? The reason I'm asking is that I might have to rename "VRIGHT" to "RIGHT". Regards, 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 Feb 12 21:13:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03574 for ; Tue, 12 Feb 2002 21:13:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D22SX21389 for ietf-calendar-bks; Tue, 12 Feb 2002 18:02:28 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D22R321381 for ; Tue, 12 Feb 2002 18:02:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA03305 for ; Tue, 12 Feb 2002 18:02:28 -0800 (PST) Message-ID: <3C69C92C.E7B24B7C@Royer.com> Date: Tue, 12 Feb 2002 19:02:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@Royer.com> <3C694AFA.C003AB99@steltor.com> <3C695967.A525485C@Royer.com> <3C696A82.9D1597D@steltor.com> <3C697DF3.FD2D4782@Royer.com> <3C698887.64C7FF38@steltor.com> <3C699DD9.C126126E@Royer.com> <3C69B5D6.F4AB5F77@steltor.com> Content-Type: multipart/mixed; boundary="------------6BC4477B9CA63C4986701C11" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6BC4477B9CA63C4986701C11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > Yes. Now a question. > > > > > > > > Will the CUA EVER be able to modify the results of the > > > > EXPAND:TRUE generated VCAR that the CS sent back to the CUA > > > > as the result of a query? > > > > > > 1- The CUA doesn't "modify results", it modifies components > > > stored in the CS. > > > > The 'results' are a valid VCAR with a BOGUS CARID. > > Because the CARID is not 'the' CARID. > > It's not because you don't get the full content of > the VCAR that its CARID is BOGUS. > > What next? You are going to tell me that the UID of > a VEVENT for which I'm not granted the RIGHT to READ > the LOCATION property should be returned to me with a > different UID? Think about it. Come on. The difference is that the OWNER will generally have full access to the owners VEVENTS. But may not have full access to some of the VCARs that effect the owner. How will OWNER know that the results of the VQUERY are trimmed? For that I am going to send DECREED so that the OWNER does not attempt to change them, even when another UPN may not get DECREED for the exact same query. My only other choice is to generate N number of VRIGHTs, one for each UPN times the number of VCARs they might see just so they can be returned when EXPAND:FALSE. I elect to use DECREED and dynamically return them when the UPN does not have MODIFY rights (and maybe DELETE rights - I am still think about that). > > > 2- The means used by the CUA to come up with a replacement > > > value for a stored component is beyond our control. > > > > No, if the CS restores a filtered VCAR with a valid CARID, > > then how would the CUA know that it is filtered? So it > > would not know that it can't try. > > Read the proposal. The CUA will only get partial VCAR > components if (1) he explicitly requests the CS by specifying > EXPAND:TRUE in the VQUERY (in which case it knows that the > VCAR may not be complete) or if (2) he is not granted the > right to modify the VCAR (in which case there is no issue). I for one am going to dynamically add DECREED when the UPN does not have MODIFY rights. The effect is the same and requires less VRIGHTS with complex VCARs. And I am going to return dynamically created CARIDs so that they do not have to exist in your next session. I am also going to dynamically return results. I think that you are missing a big security issue here that may be solved by using DECREED and trimming the results. > > > 3- When managing VCAR components it is expected that CUA > > > will NOT specify EXPAND:TRUE. But again, there is > > > nothing we can do to prevent CUA to do stupid things! > > > > The CUA will specify EXPAND:TRUE in the query. That is > > the proposal that I sent out as "Alternate to COALESCE" > > that we are not debating. > > The CUA should only specify EXPAND:TRUE if it wants to > figure out the access right of the currently authenticated > user NOT when it wants to administer them. That's the > whole point! No. I am not going to let you see all of some CALSTORE VCARs that were copied to your calendar when it was created. If you don't need to administer them - that is my point. If you ask for REQUESTONLY and EXPAND:FALSE, I am going to trim out what you don't need to see so that a hacker-CUA can not find out what to try next. So that you can't see that user 'JOE' is explicitly restricted from the CS - which includes your calendar. The same will be true for ANY VCAR where UPN does not have MODIFY rights. > > > 4- CUA MAY specify EXPAND:TRUE when they are querying > > > VCAR components for evaluation purposes. > > > > Then why in (3) above do you call it 'stupid' ? > > If the CUA's intent is to administer VCAR, that is, > get them from the CS to modify their content later > on, well yes, it would have to be very stupid. Yes, but for the CUA that is not administering VCARS, they don't need to see everything that does not effect them. No matter what the value of EXPAND - for security reasons. I am just making sure that when I mark them as DECREED and trim them down, that we still have interoperability. I think we do. > If the CUA's intent is to figure out rights that are > granted and denied to the currently authenticated user, > then it may specify EXPAND:TRUE to only get the useful > information. Unless they are malicious - and that is why they will be trimmed down anyway and marked as DECREED for any UPN that does not have MODIFY permission. > > > > If no - then it needs to be marked DECREED? Because for > > the life of the CAP session - it is not changing. > > That's not true. You read a VCAR stored in my VAGENDA in > which you are granted some rights. 2 seconds later I deny > you those rights. The VCAR changed. QED. Good, then we agree that your statement was a typo when you said: "This is not needed. And again, DECREED:TRUE means that the VCAR is PERSISTENT and IMMUTABLE, that is, a decreed VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE." > > > OR - The result set coming back from the CS as the result > > of a query from EXPAND:TRUE must NEVER use a CARID that already > > exists - otherwise, it will be impossible to tell what the > > VCAR with CARID really is. Or if the VRIGHTS of the EXPAND:FALSE > > CARID apply to the EXPAND:TRUE CARID VCARs. So I proposed > > that these generated VCARs always have a CARID of DYNAMIC. > > And we define that any contents of a CARID:DYNAMIC VCAR > > are read-only, and only valid for the current session for > > the current UPN. > > > > Then ONE VCAR can be used that only gives them READ access > > and denies WRITE, MODIFY, and DELETE access to any generated > > (dynamic) VCAR. Otherwise there has to be one more VRIGHT > > for each made up on the fly results. > > Very clever! I would then receive all the VCAR components > with predefined CARID with CARID:DYNAMIC. Do you really > want to make VCAR with predefined CARIDs unusable? Only the ones where you do not have MODIFY permission and did not explicitly ask for them. Because any random CUA does not need to know them. Any random CUA only needs to know what it has access to in the CS. It does not need to know why or the name of the CARID if it can't do anything with it and it does not matter the value of EXPAND in that case. And it does not stop the CUA from asking for CARID's by name (predefined or not). It means that if you do EXPAND:TRUE, your MAY see one VCAR and its name is DYNAMIC. If you have EXPAND:FALSE, your are going to see a lot of VCARs:  Some of them with predefined CARIDs which MAY be marked DECREED. Some with CARID's when you have MODIFY access. And the rest will be bunched into a factious CARID of DYNAMIC and it will be marked DECREED. --------------6BC4477B9CA63C4986701C11 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 ; Tue, 12 Feb 2002 21:17:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D27jS21468 for ietf-calendar-bks; Tue, 12 Feb 2002 18:07:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D27h321463 for ; Tue, 12 Feb 2002 18:07:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA03342 for ; Tue, 12 Feb 2002 18:07:46 -0800 (PST) Message-ID: <3C69CA69.CE9CE0F3@Royer.com> Date: Tue, 12 Feb 2002 19:07:37 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternate to COALESCE Content-Type: multipart/mixed; boundary="------------79E7FBEF12EE96902B612A2F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------79E7FBEF12EE96902B612A2F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (This may be a duplicate - Netscape crashe just as I pressed send, and no new message ID was saved in my outgoing email logs). Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > Yes. Now a question. > > > > > > > > Will the CUA EVER be able to modify the results of the > > > > EXPAND:TRUE generated VCAR that the CS sent back to the CUA > > > > as the result of a query? > > > > > > 1- The CUA doesn't "modify results", it modifies components > > > stored in the CS. > > > > The 'results' are a valid VCAR with a BOGUS CARID. > > Because the CARID is not 'the' CARID. > > It's not because you don't get the full content of > the VCAR that its CARID is BOGUS. > > What next? You are going to tell me that the UID of > a VEVENT for which I'm not granted the RIGHT to READ > the LOCATION property should be returned to me with a > different UID? Think about it. Come on. The difference is that the OWNER will generally have full access to the owners VEVENTS. But may not have full access to some of the VCARs that effect the owner. How will OWNER know that the results of the VQUERY are trimmed? For that I am going to send DECREED so that the OWNER does not attempt to change them, even when another UPN may not get DECREED for the exact same query. My only other choice is to generate N number of VRIGHTs, one for each UPN times the number of VCARs they might see just so they can be returned when EXPAND:FALSE. I elect to use DECREED and dynamically return them when the UPN does not have MODIFY rights (and maybe DELETE rights - I am still think about that). > > > 2- The means used by the CUA to come up with a replacement > > > value for a stored component is beyond our control. > > > > No, if the CS restores a filtered VCAR with a valid CARID, > > then how would the CUA know that it is filtered? So it > > would not know that it can't try. > > Read the proposal. The CUA will only get partial VCAR > components if (1) he explicitly requests the CS by specifying > EXPAND:TRUE in the VQUERY (in which case it knows that the > VCAR may not be complete) or if (2) he is not granted the > right to modify the VCAR (in which case there is no issue). I for one am going to dynamically add DECREED when the UPN does not have MODIFY rights. The effect is the same and requires less VRIGHTS with complex VCARs. And I am going to return dynamically created CARIDs so that they do not have to exist in your next session. I am also going to dynamically return results. I think that you are missing a big security issue here that may be solved by using DECREED and trimming the results. > > > 3- When managing VCAR components it is expected that CUA > > > will NOT specify EXPAND:TRUE. But again, there is > > > nothing we can do to prevent CUA to do stupid things! > > > > The CUA will specify EXPAND:TRUE in the query. That is > > the proposal that I sent out as "Alternate to COALESCE" > > that we are not debating. > > The CUA should only specify EXPAND:TRUE if it wants to > figure out the access right of the currently authenticated > user NOT when it wants to administer them. That's the > whole point! No. I am not going to let you see all of some CALSTORE VCARs that were copied to your calendar when it was created. If you don't need to administer them - that is my point. If you ask for REQUESTONLY and EXPAND:FALSE, I am going to trim out what you don't need to see so that a hacker-CUA can not find out what to try next. So that you can't see that user 'JOE' is explicitly restricted from the CS - which includes your calendar. The same will be true for ANY VCAR where UPN does not have MODIFY rights. > > > 4- CUA MAY specify EXPAND:TRUE when they are querying > > > VCAR components for evaluation purposes. > > > > Then why in (3) above do you call it 'stupid' ? > > If the CUA's intent is to administer VCAR, that is, > get them from the CS to modify their content later > on, well yes, it would have to be very stupid. Yes, but for the CUA that is not administering VCARS, they don't need to see everything that does not effect them. No matter what the value of EXPAND - for security reasons. I am just making sure that when I mark them as DECREED and trim them down, that we still have interoperability. I think we do. > If the CUA's intent is to figure out rights that are > granted and denied to the currently authenticated user, > then it may specify EXPAND:TRUE to only get the useful > information. Unless they are malicious - and that is why they will be trimmed down anyway and marked as DECREED for any UPN that does not have MODIFY permission. > > > > If no - then it needs to be marked DECREED? Because for > > the life of the CAP session - it is not changing. > > That's not true. You read a VCAR stored in my VAGENDA in > which you are granted some rights. 2 seconds later I deny > you those rights. The VCAR changed. QED. Good, then we agree that your statement was a typo when you said: "This is not needed. And again, DECREED:TRUE means that the VCAR is PERSISTENT and IMMUTABLE, that is, a decreed VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE." > > > OR - The result set coming back from the CS as the result > > of a query from EXPAND:TRUE must NEVER use a CARID that already > > exists - otherwise, it will be impossible to tell what the > > VCAR with CARID really is. Or if the VRIGHTS of the EXPAND:FALSE > > CARID apply to the EXPAND:TRUE CARID VCARs. So I proposed > > that these generated VCARs always have a CARID of DYNAMIC. > > And we define that any contents of a CARID:DYNAMIC VCAR > > are read-only, and only valid for the current session for > > the current UPN. > > > > Then ONE VCAR can be used that only gives them READ access > > and denies WRITE, MODIFY, and DELETE access to any generated > > (dynamic) VCAR. Otherwise there has to be one more VRIGHT > > for each made up on the fly results. > > Very clever! I would then receive all the VCAR components > with predefined CARID with CARID:DYNAMIC. Do you really > want to make VCAR with predefined CARIDs unusable? Only the ones where you do not have MODIFY permission and did not explicitly ask for them. Because any random CUA does not need to know them. Any random CUA only needs to know what it has access to in the CS. It does not need to know why or the name of the CARID if it can't do anything with it and it does not matter the value of EXPAND in that case. And it does not stop the CUA from asking for CARID's by name (predefined or not). It means that if you do EXPAND:TRUE, your MAY see one VCAR and its name is DYNAMIC. If you have EXPAND:FALSE, your are going to see a lot of VCARs:  Some of them with predefined CARIDs which MAY be marked DECREED. Some with CARID's when you have MODIFY access. And the rest will be bunched into a factious CARID of DYNAMIC and it will be marked DECREED. --------------79E7FBEF12EE96902B612A2F 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 ; Tue, 12 Feb 2002 21:22:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D29sv21522 for ietf-calendar-bks; Tue, 12 Feb 2002 18:09:54 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D29r321518 for ; Tue, 12 Feb 2002 18:09:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA03346 for ; Tue, 12 Feb 2002 18:09:56 -0800 (PST) Message-ID: <3C69CAEB.29016B70@Royer.com> Date: Tue, 12 Feb 2002 19:09:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: CALSTORE vs VCALSTORE / VRIGHT vs RIGHT (Was: Re: CAP open issues) References: <3C699404.DAF9AE4A@steltor.com> <3C69ABF9.5F2A14F4@Royer.com> <3C69BA2E.2B1B4958@steltor.com> Content-Type: multipart/mixed; boundary="------------1935ECD68978B021D5B1B8CB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1935ECD68978B021D5B1B8CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > I noticed in 2445, it says that ALL iCalendar objects > > start with a 'V', so I guess we should do that. > > I also think that we should call it VCALSTORE, but > on the other hand, it should be noted that RFC 2445 > also defines two components that don't start with 'V'. :-) > Are these not considered "calendar components"? > The reason I'm asking is that I might have to > rename "VRIGHT" to "RIGHT". I think that those were a mistake. Ether way - not a big issue - that name that is. --------------1935ECD68978B021D5B1B8CB 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 ; Tue, 12 Feb 2002 22:56:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D3SUZ23301 for ietf-calendar-bks; Tue, 12 Feb 2002 19:28:30 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D3SS323296 for ; Tue, 12 Feb 2002 19:28:29 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id WAA31332 for ; Tue, 12 Feb 2002 22:28:27 -0500 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1D3SPQ13794 for ; Tue, 12 Feb 2002 22:28:26 -0500 (EST) Message-ID: <3C69DDD3.12687522@steltor.com> Date: Tue, 12 Feb 2002 22:30:27 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Alternate to COALESCE References: <3C61A010.E3942645@Royer.com> <3C62E62F.24A46FF@steltor.com> <3C630586.122EEE4F@Royer.com> <3C634049.1763CEB6@steltor.com> <3C641CAE.EC953B3E@Royer.com> <3C643EB1.F19668CB@steltor.com> <3C644FD1.E7EDA43@Royer.com> <3C67F4ED.DB1009D@steltor.com> <3C682BF6.3190D012@Royer.com> <3C692F25.28A97663@steltor.com> <3C693E53.56773327@Royer.com> <3C694AFA.C003AB99@steltor.com> <3C695967.A525485C@Royer.com> <3C696A82.9D1597D@steltor.com> <3C697DF3.FD2D4782@Royer.com> <3C698887.64C7FF38@steltor.com> <3C699DD9.C126126E@Royer.com> <3C69B5D6.F4AB5F77@steltor.com> <3C69C92C.E7B24B7C@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: > > > > Doug Royer wrote: > > > > > > Bernard Desruisseaux wrote: > > > > > > > > > Yes. Now a question. > > > > > > > > > > Will the CUA EVER be able to modify the results of the > > > > > EXPAND:TRUE generated VCAR that the CS sent back to the CUA > > > > > as the result of a query? > > > > > > > > 1- The CUA doesn't "modify results", it modifies components > > > > stored in the CS. > > > > > > The 'results' are a valid VCAR with a BOGUS CARID. > > > Because the CARID is not 'the' CARID. > > > > It's not because you don't get the full content of > > the VCAR that its CARID is BOGUS. > > > > What next? You are going to tell me that the UID of > > a VEVENT for which I'm not granted the RIGHT to READ > > the LOCATION property should be returned to me with a > > different UID? Think about it. Come on. > > The difference is that the OWNER will generally have > full access to the owners VEVENTS. But may not have > full access to some of the VCARs that effect the owner. > How will OWNER know that the results of the VQUERY are > trimmed? If the owner specified EXPAND:TRUE he knows. If the owner doesn't have the right to modify the components he doesn't need to know. That's not rocket science... > For that I am going to send DECREED so that > the OWNER does not attempt to change them, even > when another UPN may not get DECREED for the exact > same query. Why do you insist on giving out security information that the current user does not need to know? The thruth of the matter, is that the user should not know that he is given a trimmed version (unless he's granted the right to modify the component and did not specified EXPAND:TRUE). > My only other choice is to generate N number of VRIGHTs, > one for each UPN times the number of VCARs they might see > just so they can be returned when EXPAND:FALSE. I elect to > use DECREED and dynamically return them when the UPN does > not have MODIFY rights (and maybe DELETE rights - I am still > think about that). > > > > > 2- The means used by the CUA to come up with a replacement > > > > value for a stored component is beyond our control. > > > > > > No, if the CS restores a filtered VCAR with a valid CARID, > > > then how would the CUA know that it is filtered? So it > > > would not know that it can't try. > > > > Read the proposal. The CUA will only get partial VCAR > > components if (1) he explicitly requests the CS by specifying > > EXPAND:TRUE in the VQUERY (in which case it knows that the > > VCAR may not be complete) or if (2) he is not granted the > > right to modify the VCAR (in which case there is no issue). > > I for one am going to dynamically add DECREED when the > UPN does not have MODIFY rights. The effect is the same > and requires less VRIGHTS with complex VCARs. And I am > going to return dynamically created CARIDs so that they > do not have to exist in your next session. Well I wish you the best of luck with the VCAR with predefined CARID! > I am also going to dynamically return results. I think that > you are missing a big security issue here that may be > solved by using DECREED and trimming the results. I don't think so. In fact, you will be the one leaking security information. "Attention hacker attention, the returned VCAR is trimmed. I repeat: The returned VCAR is trimmed." > > > > 3- When managing VCAR components it is expected that CUA > > > > will NOT specify EXPAND:TRUE. But again, there is > > > > nothing we can do to prevent CUA to do stupid things! > > > > > > The CUA will specify EXPAND:TRUE in the query. That is > > > the proposal that I sent out as "Alternate to COALESCE" > > > that we are not debating. > > > > The CUA should only specify EXPAND:TRUE if it wants to > > figure out the access right of the currently authenticated > > user NOT when it wants to administer them. That's the > > whole point! > > No. I am not going to let you see all of some CALSTORE > VCARs that were copied to your calendar when it was created. > If you don't need to administer them - that is my > point. If you ask for REQUESTONLY and EXPAND:FALSE, I am > going to trim out what you don't need to see so that a > hacker-CUA can not find out what to try next. So that > you can't see that user 'JOE' is explicitly restricted > from the CS - which includes your calendar. > > The same will be true for ANY VCAR where UPN does not > have MODIFY rights. What is the problem? If I don't have the right to modify them, then I'll be given a trimmed version. That's all. > > > > 4- CUA MAY specify EXPAND:TRUE when they are querying > > > > VCAR components for evaluation purposes. > > > > > > Then why in (3) above do you call it 'stupid' ? > > > > If the CUA's intent is to administer VCAR, that is, > > get them from the CS to modify their content later > > on, well yes, it would have to be very stupid. > > Yes, but for the CUA that is not administering VCARS, > they don't need to see everything that does not effect them. > No matter what the value of EXPAND - for security reasons. If the CUA doesn't provide the ability to administer VCAR components then it should specify EXPAND:TRUE. If it does not. Too bad. It will receive the full content of the VCAR components for which it is granted the right to modify. No problem here. > I am just making sure that when I mark them as DECREED > and trim them down, that we still have interoperability. > I think we do. Marking VCAR on the fly as DECREED:TRUE is a sure way to break interoperability. Some CUA could assume that the VCAR will not change while it might (since the stored version is not DECREED). > > If the CUA's intent is to figure out rights that are > > granted and denied to the currently authenticated user, > > then it may specify EXPAND:TRUE to only get the useful > > information. > > Unless they are malicious - and that is why they will be trimmed > down anyway and marked as DECREED for any UPN that does not > have MODIFY permission. If the UPN doesn't have the right to modify the VCAR, sure, trimmed it down. There is not need to mark the VCAR has DECREED though. If the user can't modify the VCAR, that's none of his business that he was given a trimmed down version of the VCAR. In fact, you really don't want him to know that! > > > If no - then it needs to be marked DECREED? Because for > > > the life of the CAP session - it is not changing. > > > > That's not true. You read a VCAR stored in my VAGENDA in > > which you are granted some rights. 2 seconds later I deny > > you those rights. The VCAR changed. QED. > > Good, then we agree that your statement was a typo > when you said: > > "This is not needed. And again, DECREED:TRUE means that > the VCAR is PERSISTENT and IMMUTABLE, that is, a decreed > VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE." No. We are in total disagreement. VCAR components with DECREED:TRUE in the calendar store are persistent and immutable. What you are proposing is to add DECREED:TRUE on the fly to trimmed VCAR components. Since the VCAR stored in the CS may not have DECREED:TRUE, yes, I could changed it. Adding DECREED:TRUE on the fly to VCAR is evil. > > > OR - The result set coming back from the CS as the result > > > of a query from EXPAND:TRUE must NEVER use a CARID that already > > > exists - otherwise, it will be impossible to tell what the > > > VCAR with CARID really is. Or if the VRIGHTS of the EXPAND:FALSE > > > CARID apply to the EXPAND:TRUE CARID VCARs. So I proposed > > > that these generated VCARs always have a CARID of DYNAMIC. > > > And we define that any contents of a CARID:DYNAMIC VCAR > > > are read-only, and only valid for the current session for > > > the current UPN. > > > > > > Then ONE VCAR can be used that only gives them READ access > > > and denies WRITE, MODIFY, and DELETE access to any generated > > > (dynamic) VCAR. Otherwise there has to be one more VRIGHT > > > for each made up on the fly results. > > > > Very clever! I would then receive all the VCAR components > > with predefined CARID with CARID:DYNAMIC. Do you really > > want to make VCAR with predefined CARIDs unusable? > > Only the ones where you do not have MODIFY permission > and did not explicitly ask for them. Why are you wasting your time trying to come up with odd exception to something we don't need in the first place? > Because any random CUA does not > need to know them. Any random CUA only needs to know what it > has access to in the CS. It does not need to know why or the > name of the CARID if it can't do anything with it and it does > not matter the value of EXPAND in that case. So what you are saying is that VCAR with predefined CARID must retain their orignal CARID, and for the other VCAR, well the CUA doesn't care. So why bother changing the CARID to DYNAMIC then? > And it does not stop the CUA from asking for CARID's by > name (predefined or not). It means that if you do EXPAND:TRUE, > your MAY see one VCAR and its name is DYNAMIC. > > If you have EXPAND:FALSE, your are going to see a lot > of VCARs: >  > Some of them with predefined CARIDs which MAY be marked DECREED. > > Some with CARID's when you have MODIFY access. > > And the rest will be bunched into a factious CARID of DYNAMIC > and it will be marked DECREED. Marking VCAR as DECREED:TRUE on the fly: 1- Is not needed; 2- Leaks security information; 3- Breaks interoperability. Changing the CARID of VCAR on the fly: 1- Is not needed; 2- Makes using predefined CARID a pain. Regards, 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 Wed Feb 13 10:08:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06160 for ; Wed, 13 Feb 2002 10:08:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DEsw518275 for ietf-calendar-bks; Wed, 13 Feb 2002 06:54:58 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DEsu318271 for ; Wed, 13 Feb 2002 06:54:56 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP open issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 10:02:48 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 10:02:58 AM, Serialize complete at 02/13/2002 10:02:58 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >George Babics wrote: > >> - Should the CHARSET property become DEFAULT-CHARSET and >> should we instead define a charset value type? > >Yes I agree - we do need to specify what the format is, I am sure >that some RFC covers that. I've been looking, but I can't find a syntax specification (except for something informal in RFC-1345, which is Informational). What I have found is the IANA registry of character set identifiers, at . /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |Never underestimate the power of human stupidity. --I forget who| \================================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 10:09:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06191 for ; Wed, 13 Feb 2002 10:09:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DEiZZ17959 for ietf-calendar-bks; Wed, 13 Feb 2002 06:44:35 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DEiY317955 for ; Wed, 13 Feb 2002 06:44:34 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA04096; Wed, 13 Feb 2002 09:44:27 -0500 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 g1DEiRQ11057; Wed, 13 Feb 2002 09:44:27 -0500 (EST) Message-ID: <3C6A7C40.568FCB0@steltor.com> Date: Wed, 13 Feb 2002 09:46:24 -0500 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 CC: John Stracke Subject: Re: CAP: VCAR - limiting READ References: <3BF94A22.A791DF21@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 [ John, I've CC'ed you as you originally were involved in that thread. -- Bernard ] Doug Royer wrote: > > For security reasons, a site may wish a CUA to only see GRANT and DENY > values for which it has access. So I propose an additional paragraph > to section "2.4.4 Access Rights - Summary": > > A CS may limit the results sent to a CUA in reply to a METHOD READ > on a VCAR to a set that applies to the current session identity. > That is if user 'Joe' is the current session identity, then when > 'Joe' asks to see the VCARs, the CS might only return a VCAR that effects > 'Joe'. In this way 'Joe' can not see who does have other access. Back in December 2001 this WG agreed on Doug's idea, but nobody proposed text to describe the resolution. I propose that we add the following text in the section describing the search command. When the EXPAND property of the VQUERY component is set to TRUE, the CS MUST only supply the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components. VRIGHT components that don't pertain to the currently authenticated user MUST be left out of the returned VCAR components. For security reasons, the CS MAY supply only the UPN of the currently authenticated user in the GRANT or DENY property of the VRIGHT components of the returned VCAR components for which the currently authenticated user doesn't have the MODIFY permission granted. Furthermore, VRIGHT components that don't pertain to the currently authenticated user MAY be left out of the returned VCAR for which the currently authenticated user doesn't have the MODIFY permission granted. Regards, 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 Wed Feb 13 10:11:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06887 for ; Wed, 13 Feb 2002 10:11:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DEum918351 for ietf-calendar-bks; Wed, 13 Feb 2002 06:56:48 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DEuk318347 for ; Wed, 13 Feb 2002 06:56:47 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP open issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 10:04:38 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 10:04:48 AM, Serialize complete at 02/13/2002 10:04:48 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >AND: And I think that a charset-list should be returned in >the capabilities reply - with the first one being the default >for the CS and any other being what the CS supports. Shouldn't the CS be able to support any character set? The set of *locales* might be limited, because a locale requires a sort order; but character sets are really a UI issue, a mapping from octets to characters--and CAP should only care about the octets. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |"Fly Heisenberg Airlines! We may not know where we are, but we're| |making real good time." -- _Synners_ by Pat Cadigan | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 10:12:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06950 for ; Wed, 13 Feb 2002 10:12:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DExFn18439 for ietf-calendar-bks; Wed, 13 Feb 2002 06:59:15 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DExE318435 for ; Wed, 13 Feb 2002 06:59:14 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP open issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 10:07:06 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 10:07:16 AM, Serialize complete at 02/13/2002 10:07: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've been looking, but I can't find a syntax specification Please ignore this; as George wrote, the ABNF for the syntax is in RFC-2278. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |"Fly Heisenberg Airlines! We may not know where we are, but we're| |making real good time." -- _Synners_ by Pat Cadigan | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 10:14:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07003 for ; Wed, 13 Feb 2002 10:14:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DF59k18760 for ietf-calendar-bks; Wed, 13 Feb 2002 07:05:09 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DF57318755 for ; Wed, 13 Feb 2002 07:05:07 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 10:12:59 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 10:13:09 AM, Serialize complete at 02/13/2002 10:13:09 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> x.2.1.3 Current Date-Time Component Property > >I again propose that we drop this from CAP I agree. We have NTP for time synchronization; it can do a much better job than anything we might build over TCP. >and that it must >be in UTC and it MUST be supplied. Why UTC? /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |The plural of mongoose is polygoose. | \========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 10:40:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07862 for ; Wed, 13 Feb 2002 10:40:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DFMwC19956 for ietf-calendar-bks; Wed, 13 Feb 2002 07:22:58 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DFMu319952 for ; Wed, 13 Feb 2002 07:22:56 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA05222; Wed, 13 Feb 2002 10:22:52 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DFMpQ15538; Wed, 13 Feb 2002 10:22:51 -0500 (EST) Message-ID: <3C6A84CB.FD36B9B9@steltor.com> Date: Wed, 13 Feb 2002 10:22:51 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> <3C69A6B8.A25872B0@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: > > George Babics wrote: > > I broke your text into multiple replies. > > > The following is a proposal for the definitions of the VAGENDA > > and CALSTORE components and their properties. These definitions > > are based on the descriptions found in the CAP draft. > > > > This is the first iteration. Please review. Once I get people's > > fixes and suggestions in, I will make a formal proposal. > > > > Summary: > > > > The VAGENDA component describes the calendars belonging to users. > > It contains VEVENTs, VJOURNALs, VTIMEZONEs, VTODOs, VQUERYs, and > > VCARs. The properties that a VAGENDA may have are: > > > LOCALE: the default language > > NAME: the name of the calendar (e.g., "Work") > > Must NAME be in LOCALE? > > Can there be multiple instances of this property? - I would say yes. > - each with its own unique LANGUAGE parameter? - Yes. Yes. It can be multiple. If no LANGUAGE parameter is supplied, the one in LOCALE (or DEFAULT-LANGAUGE) should be used. > > If it can not be multiple, then I would say it MUST BE in LOCALE. > > You forgot 'TZID' (in this section) : the default TZ for the VAGENDA > so that CUAs know what is meant when 'localtime' date-time values > are used. You're right. However, TZID is a parameter and also a property. Perhaps we should add something like DEFAULT-TZID? Where are 'localtime' date-time values used? Do you mean times without a timzone, e.g., 20020213T100000. > > > The CALSTORE component is used to contain the properties of > > the calendar store. These properties are: > > > CURRENT-DATETIME: the current date and time on the CS > > Did we agree to drop CURRENT-DATETIME ? > As an option, if it is wanted, maybe we can return > the current date-time as part of the greeting or capability reply? I would like to drop it. I will remove it from the proposal. It anyone still thinks we need it, speak up. > > > MAXDATE: last date time that is supported by the CWS > > MINDATE: first date-time that is supported by the CS > > MAXDATE and MINDATE are in capabilities lets take them > out of CS properties. > > > RECUR-ACCEPTED: whether the CS accepts recurrence rules > > > RECUR-EXPAND : whether or not the CS supports the > > expansion of recurrence rules. > > > RECUR-LIMIT: the maximum number of occurrences or a recurrence > > rule that are expanded by the CS > > Move the above 4 properties into capabilities? As they > are will effect what commands the CUA sends to the CS. > > > VERSION: iCalendar version > > Move it to CAP-VERSION and make it a capability? > I think we agreed that it is CAP version 1.0 which is unrelated > to iCalendar version. There is already a version that is returned by capability. I'll remove the VERSION from the calstore. > > The CAPABILITIES section should specify the iCalendar and > iTIP version that are supported in addition to the CAP-VERSION. Yes. > > AND: > > We drop DEFAULT-VARS from the calendar properties, it only > applied to CALSTORE - correct? Yes. From owner-ietf-calendar@mail.imc.org Wed Feb 13 10:48:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08315 for ; Wed, 13 Feb 2002 10:48:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DFXPI20817 for ietf-calendar-bks; Wed, 13 Feb 2002 07:33:25 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DFXO320810 for ; Wed, 13 Feb 2002 07:33:24 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA05701 for ; Wed, 13 Feb 2002 10:33:20 -0500 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 g1DFXJQ17217 for ; Wed, 13 Feb 2002 10:33:19 -0500 (EST) Message-ID: <3C6A87B4.2C2D9CA8@steltor.com> Date: Wed, 13 Feb 2002 10:35:16 -0500 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: CAP: VQUERY new MATCH operator 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 Given the following VCAR components, BEGIN:VCAR CARID:Car-01 BEGIN:VRIGHT GRANT:*@steltor.com ... END:VRIGHT END:VCAR BEGIN:VCAR CARID:Car-02 BEGIN:VRIGHT GRANT:bernard@steltor.com ... END:VRIGHT END:VCAR I would like to introduce a new MATCH operator such that: BEGIN:VQUERY QUERYNAME:Query-01 QUERY:SELECT * FROM VCAR USING_PROPERTIES GRANT oneGrant WHERE 'bernard@steltor.com' MATCH oneGrant END:VQUERY would return both VCAR components with CARID:Car-01 and CARID:Car-02, while BEGIN:VQUERY QUERYNAME:Query-01 QUERY:SELECT * FROM VCAR USING_PROPERTIES GRANT oneGrant WHERE 'bernard@steltor.com' = oneGrant END:VQUERY would only return CARID:Car-02. For the time being, the semantic of the MATCH operator would only be defined for: upn MATCH upn-filter and as it's the case for other operators its semantic could be defined later on for other value types. Regards, 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 Wed Feb 13 11:31:30 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10759 for ; Wed, 13 Feb 2002 11:31:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DG9qu22661 for ietf-calendar-bks; Wed, 13 Feb 2002 08:09:52 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DG9p322657 for ; Wed, 13 Feb 2002 08:09:51 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: VQUERY new MATCH operator MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 11:17:42 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 11:17:54 AM, Serialize complete at 02/13/2002 11:17:54 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I would like to introduce a new MATCH operator such that: It's not clear to me what good this would be. Can you give us a use case? /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===========================================================| |"This horse has made a career out of being dead." -- Harald| |Alvestrand | \===========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 11:37:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10875 for ; Wed, 13 Feb 2002 11:37:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DGOkZ23213 for ietf-calendar-bks; Wed, 13 Feb 2002 08:24:46 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGOi323209 for ; Wed, 13 Feb 2002 08:24:44 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA07587; Wed, 13 Feb 2002 11:24:40 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DGOeQ24710; Wed, 13 Feb 2002 11:24:40 -0500 (EST) Message-ID: <3C6A9347.79D6B54F@steltor.com> Date: Wed, 13 Feb 2002 11:24:39 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP open issues References: <3C699404.DAF9AE4A@steltor.com> <3C69ABF9.5F2A14F4@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: > > George Babics wrote: > > > Open Issues: > > > > - Should OWNER be a multi-valued property, or should it be > > single valued and allowed to occur more than once. > > If the latter than we can easily add parameters if they > > are needed in the future, e.g, > > OWNER;TYPE=MAIN:cap:jsmith@acme.com > > I agree - multi instance. I'll make the change. > > > - Should the calendar store component be CALSTORE or > > VCALSTORE. > > I noticed in 2445, it says that ALL iCalendar objects > start with a 'V', so I guess we should do that. I'll rename it. > > > - Should the CHARSET property become DEFAULT-CHARSET and > > should we instead define a charset value type? > > Yes I agree - DEFAULT-CHARSET is a better choice for a name. I'll rename it. > > Yes I agree - we do need to specify what the format is, I am sure > that some RFC covers that. > > AND: And I think that a charset-list should be returned in > the capabilities reply - with the first one being the default > for the CS and any other being what the CS supports. I agree. > > > - Do the RECUR-EXPAND and RECUR-LIMIT properties still make sense > > given the recent changed to VQUERY? > > I think they should be capabilities. > Yes, they should probably be capabilities. > AND: we need to re-add expansion limits to VQUERY, what > if something goes on forever - how many will EXPAND:TRUE > with NO date time limit return with out it? Doesn't RECUR-LIMIT also apply to VQUERY? > > > - We still need to decide what type of characters are valid for > > RELCALID. We should comply with RFC 2396 (URI Generic Syntax) > > Yes - and say that RELCALID MUST BE 8 bit capable so that > when URI's are 8-bit we will not require any changes. > > > - What should be the name of the property used to specify the > > default language for a calendar: LANGUAGE, DEFAULT-LANGUAGE, > > LOCALE? > > I would opt for DEFAULT-LOCALE. It's not LANGUAGE, its the locale. > or maybe LOCALE. > > And making the BEEP 'localize' attribute sent in the BEEP greeting RPY > a MUST in the CAP greeting so CUA can select the locale for > any CS error messages. > > > - Should we use METHOD:DELETE instead of the TOMBSTONE property > > to indicate whether a VAGENDA has been marked as deleted? > > Yes - I agree. I'll make the change. > > > - Do we need a limit for bonded recurrences? RECUR-LIMIT only applies > > to unbounded recurrences. > > A CUA reading on a TCP connection is not forced to read > more that it wants. If you get too much. Stop reading and throw > away the rest - or/and abort the command using a separate channel. However, the CS may also not want to expand all occurrences. I believe the CS should be able to have limits to the number of occurrences it expands. A good way to attack the CS would be for a few CUA to create recurring events that occur every second for the next 100 years, then to read the expanded events a few times. Perhaps RECUR-LIMIT should apply to both bounded and unbounded recurrences? > > We need a limit in the VQUERY so that unbounded recurrence > rules don't go on for ever. A CUA might not know in advance > if "SELECT * FROM VEVENT" with EXPAND:TRUE has any recurrence > rules set - so we need to allow the CUA to bound the number > of replies. > > > - According to the definition of VERSION in iCalendar, VERSION MUST > > appear once in a VCALENDAR. The VERSION in CALSTORE is slightly > > different, in that it defines the version of iCalendar user in > > the calendar store, and not the version of an iCalendar. Furthermore, > > by adding a version to CALSTORE we may have: > > The 2445 VERSION is the version of the 2445 record format, is not > the VERSION of iTIP or CAP. > > Do we mandate it as part of ANY query reply - so the CUA knows > that the data coming back conforms to iCalendar 2.0 record format? > > > Perhaps we should use ICALENDAR-VERSION? The version is already part of the VCALENDAR object that is returned: BEGIN:VCALENDAR VERSION:2.0 BEGIN:VEVENT ... END:VEVENT END:VCALENDAR RFC 2445 states that the VERSION and PRODID must occur exactly once. However, most of our examples are missing them. From RFC 2445: An iCalendar object MUST include the "PRODID" and "VERSION" calendar properties. In addition, it MUST include at least one calendar component. > > How about CAP-VERSION as it is the VERSION of the CAP protocol. > And lets move it from a property to a capability. > > > However, if CALSTORE is contained in a VCALENDAR, then CALSTORE > > doesn't need a VERSION at all? > > Again - CAP protocol version vs iCalendar record format. The iCalendar, iTIP, and CAP versions are already returned by the capability command. I'll remove VERSION from the calendar store component. George From owner-ietf-calendar@mail.imc.org Wed Feb 13 11:40:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10998 for ; Wed, 13 Feb 2002 11:40:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DGSHQ23303 for ietf-calendar-bks; Wed, 13 Feb 2002 08:28:17 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGSF323299 for ; Wed, 13 Feb 2002 08:28:15 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA07686; Wed, 13 Feb 2002 11:28:11 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DGSBQ24936; Wed, 13 Feb 2002 11:28:11 -0500 (EST) Message-ID: <3C6A941A.61A2BC79@steltor.com> Date: Wed, 13 Feb 2002 11:28:10 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP open issues References: <3C699404.DAF9AE4A@steltor.com> <3C69ABF9.5F2A14F4@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: > > George Babics wrote: > [snip] > I would opt for DEFAULT-LOCALE. It's not LANGUAGE, its the locale. > or maybe LOCALE. > And making the BEEP 'localize' attribute sent in the BEEP greeting RPY > a MUST in the CAP greeting so CUA can select the locale for > any CS error messages. From an earlier post that I made: On second thought, I am not sure if we should use LOCALE. RFC 2277, "IETF Policy on Character Sets and Languages", uses the POSIX definition of locale: The POSIX standard [POSIX] defines a concept called a "locale", which includes a lot of information about collating order for sorting, date format, currency format and so on. I do not think this is what we want to mean by LOCALE. The concept of language in RFC 2277 seems to fit what we want this property to mean. Given all this, how about using DEFAULT-LANGUAGE? But then, BEEP seems to use the "localize" attribute means language, so perhaps LOCALE is OK? What is our DEFAULT-LOCALE supposed to mean? Default language" Default language and some other localized settings? George > > > - Should we use METHOD:DELETE instead of the TOMBSTONE property > > to indicate whether a VAGENDA has been marked as deleted? > > Yes - I agree. > > > - Do we need a limit for bonded recurrences? RECUR-LIMIT only applies > > to unbounded recurrences. > > A CUA reading on a TCP connection is not forced to read > more that it wants. If you get too much. Stop reading and throw > away the rest - or/and abort the command using a separate channel. > > We need a limit in the VQUERY so that unbounded recurrence > rules don't go on for ever. A CUA might not know in advance > if "SELECT * FROM VEVENT" with EXPAND:TRUE has any recurrence > rules set - so we need to allow the CUA to bound the number > of replies. > > > - According to the definition of VERSION in iCalendar, VERSION MUST > > appear once in a VCALENDAR. The VERSION in CALSTORE is slightly > > different, in that it defines the version of iCalendar user in > > the calendar store, and not the version of an iCalendar. Furthermore, > > by adding a version to CALSTORE we may have: > > The 2445 VERSION is the version of the 2445 record format, is not > the VERSION of iTIP or CAP. > > Do we mandate it as part of ANY query reply - so the CUA knows > that the data coming back conforms to iCalendar 2.0 record format? > > > Perhaps we should use ICALENDAR-VERSION? > > How about CAP-VERSION as it is the VERSION of the CAP protocol. > And lets move it from a property to a capability. > > > However, if CALSTORE is contained in a VCALENDAR, then CALSTORE > > doesn't need a VERSION at all? > > Again - CAP protocol version vs iCalendar record format. From owner-ietf-calendar@mail.imc.org Wed Feb 13 11:49:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11249 for ; Wed, 13 Feb 2002 11:49:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DGZkK23547 for ietf-calendar-bks; Wed, 13 Feb 2002 08:35:46 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGZj323543 for ; Wed, 13 Feb 2002 08:35:45 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA07986; Wed, 13 Feb 2002 11:35:40 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DGZeQ26193; Wed, 13 Feb 2002 11:35:40 -0500 (EST) Message-ID: <3C6A95DB.A3E61921@steltor.com> Date: Wed, 13 Feb 2002 11:35:39 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> <3C69AE2A.43C4FEEB@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: > > George Babics wrote: > > > x.2 Component Properties > > > > x.2.1 Agenda Component Properties > > > > x.2.1.1 Allow-Conflict Component Property > > > Conformance: This property can be specified in "VAGENDA" calendar > > components. > > Components or component? Fixed all of them. > > > Description: In a "VAGENDA", this property is used to indicate > > whether events may conflict. If it has a value of TRUE, then > > conflicts are allowed. If FALSE, the no two events may conflict. > > ... If FALSE, then ... (not 'the') Fixed. > > And how about replace: > > If FALSE, then no two events may conflict > > With: > If FALSE, then no two components or their expanded > instances can share the same time or overlap the same > time periods. Is this not implied by "no two events may conflict"? George From owner-ietf-calendar@mail.imc.org Wed Feb 13 11:51:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11336 for ; Wed, 13 Feb 2002 11:51:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DGdVh23654 for ietf-calendar-bks; Wed, 13 Feb 2002 08:39:31 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGdU323650 for ; Wed, 13 Feb 2002 08:39:30 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA08209; Wed, 13 Feb 2002 11:39:25 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DGdOQ26941; Wed, 13 Feb 2002 11:39:24 -0500 (EST) Message-ID: <3C6A96BB.8033E0C3@steltor.com> Date: Wed, 13 Feb 2002 11:39:23 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Locale Component Property References: <3C699404.DAF9AE4A@steltor.com> <3C69B240.43D9269D@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: > > > > > x.2.1.3 Locale Component Property > > > > To: ietf-calendar@imc.org > > > > Subject: Registration of text/calendar MIME property LOCALE > > > > Property Name: LOCALE > > > > Purpose: This property specifies the default language for text values. > > > > Value Type: TEXT > > > > Property Parameters: Non-standard property parameters can be > > specified on this property. > > > > Conformance: This property can be specified in "VAGENDA" calendar > > components. > > Component not components. > > > Description: In a "VAGENDA", this property is used to indicate > > the default language for text values in the components, e.g., > > "VEVENT", of the "VAGENDA." > > > > Format Definition: The property is defined by the following notation: > > > > locale = "LOCALE" localeparam ":" language CRLF > > > > localeparam = *(";" xparam) > > > > locale = > > Add (IANA values are 3-8 characters per 3066)? > > And the preferred values are the ones that include both > the language and country. Done. > > > LOCALE:da > > Change to (or some other 3 to 8 letter IANA registered value: > > LOCALE:fr_CA Done. From owner-ietf-calendar@mail.imc.org Wed Feb 13 11:52:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11394 for ; Wed, 13 Feb 2002 11:52:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DGfrm23756 for ietf-calendar-bks; Wed, 13 Feb 2002 08:41:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGfq323752 for ; Wed, 13 Feb 2002 08:41:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA08275 for ; Wed, 13 Feb 2002 11:41:48 -0500 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 g1DGflQ27114 for ; Wed, 13 Feb 2002 11:41:47 -0500 (EST) Message-ID: <3C6A97C1.2FD8D6A2@steltor.com> Date: Wed, 13 Feb 2002 11:43:45 -0500 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: CAP: VQUERY new MATCH operator 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 would like to introduce a new MATCH operator such that: > > It's not clear to me what good this would be. Can you give us a use case? Mary would like to review the access rights she has granted to Bob. By submitting the following VQUERY: BEGIN:VQUERY QUERYNAME:Query-01 QUERY:SELECT * FROM VCAR USING_PROPERTIES GRANT oneGrant WHERE 'bob@acme.com' = oneGrant END:VQUERY Mary will only find the VCAR with a GRANT property *explicitly* set to "bob@acme.com", that is, she won't find all the VCAR that apply to Bob (e.g., those with "GRANT:*"). To do so, Mary could submit the following VQUERY: BEGIN:VQUERY QUERYNAME:Query-01 QUERY:SELECT * FROM VCAR USING_PROPERTIES GRANT oneGrant WHERE 'bob@acme.com' MATCH oneGrant END:VQUERY Regards, 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 Wed Feb 13 11:54:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11426 for ; Wed, 13 Feb 2002 11:54:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DGfv523763 for ietf-calendar-bks; Wed, 13 Feb 2002 08:41:57 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGft323758 for ; Wed, 13 Feb 2002 08:41:55 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA04430 for ; Wed, 13 Feb 2002 08:41:54 -0800 (PST) Message-ID: <3C6A974E.38DDEE4F@Royer.com> Date: Wed, 13 Feb 2002 09:41:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP open issues References: Content-Type: multipart/mixed; boundary="------------4DBE7650942633119F604FF5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4DBE7650942633119F604FF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >AND: And I think that a charset-list should be returned in > >the capabilities reply - with the first one being the default > >for the CS and any other being what the CS supports. > > Shouldn't the CS be able to support any character set? The set of > *locales* might be limited, because a locale requires a sort order; but > character sets are really a UI issue, a mapping from octets to > characters--and CAP should only care about the octets. Not true. Below is some snipits from email that I sent to the editors 12-Jan-02. After downloading the data, look at the files. They are binary. And you can't read them if you don't know the charset. The files each contain a UTF-8 MIME header so you can see that much, followed by the one example in 629 difference charset (names) - one per file. ----- Snipits from a previous editors email ------ Per a previous editors phone call, here is a sample of iCalendar objects in various charsets. I have converted the following sample ENGLISH iCalendar entry into 629 different charsets. Some of these may be the same when you compare the binaries, however the charset names in the MIME header are unique. Example ISO8859-1 and ISO_8859-1 are the same binaries, but the MIME headers are not the same because someone uses each. .. not all of them are IETF or IANA known. ... If someone can provide me non-english iCalendar objects in just about any charset, I'll convert those to any other charset for which I have the conversion tools. It would be best if it were some multi-byte or at least 8-bit charset who's contents used those features. A TAR file is at royer.com via anonymous ftp: ftp://Royer.com/pub/english.samples.tar.gz A file list of all of the files below the included iCalendar object example below. The DESCRIPTION property below is split into multiple lines in this email, the original file 'en/UTF8.en.ics' does NOT have the line wrapped. They were converted using the POSIX iconv utility. THERE MAY BE ERRORS. I believe they are converted correctly. Here is the sample that was converted: ContentType:text/calendar; method=REQUEST charset=UTF8 BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//INET-Consulting LLC (beta)/iCalender V1.0//EN VERSION:2.0 BEGIN:VEVENT CREATED:20011209T111616 UID:Royer.com-inet-llc-20020112T171413Z-doug SEQUENCE:2 LAST-MODIFIED:20011209T111637 DTSTAMP:20011209T111700 ORGANIZER:MAILTO:Doug@Royer.com ATTENDEE;RSVP=TRUE:MAILTO:Doug@Royer.com DTSTART:20011209T080000 DESCRIPTION:This is the default table. It contains the built-in chains INPUT\n(for packets coming into the box itself)\, FORWARD (for packets\nbeing routed through the box)\, and OUTPUT (for locally-generated packets).\n SUMMARY:This is a calendar apppointment with the summary in english CLASS:PUBLIC DTEND:20011209T100000 END:VEVENT END:VCALENDAR List of files in tar file follow. The format is: /..ics ./english.sample.ics ./en/ ./en/437.en.ics ./en/500.en.ics ./en/500V1.en.ics ./en/850.en.ics ./en/851.en.ics ./en/852.en.ics ./en/855.en.ics ./en/856.en.ics ./en/857.en.ics ./en/860.en.ics ./en/861.en.ics ./en/862.en.ics ./en/863.en.ics ./en/864.en.ics ./en/865.en.ics ./en/866.en.ics ./en/869.en.ics ./en/874.en.ics ./en/904.en.ics ./en/1026.en.ics ./en/1046.en.ics ./en/1047.en.ics ./en/8859_1.en.ics ./en/8859_2.en.ics ./en/8859_3.en.ics ./en/8859_4.en.ics ./en/8859_5.en.ics ./en/8859_6.en.ics ./en/8859_7.en.ics ./en/8859_8.en.ics ./en/8859_9.en.ics ./en/ANSI_X3.4-1968.en.ics ./en/ANSI_X3.4-1986.en.ics ./en/ANSI_X3.4.en.ics ./en/ANSI_X3.110-1983.en.ics ./en/ANSI_X3.110.en.ics ./en/ARABIC.en.ics ./en/ASCII.en.ics ./en/ASMO-708.en.ics ./en/BALTIC.en.ics ./en/BIG-5.en.ics ./en/BIG-FIVE.en.ics ./en/BIG5-HKSCS.en.ics ./en/BIG5.en.ics ./en/BIG5HKSCS.en.ics ./en/BIGFIVE.en.ics ./en/BS_4730.en.ics ./en/CN-BIG5.en.ics ./en/CN-GB.en.ics ./en/CN.en.ics ./en/CP-AR.en.ics ./en/CP-GR.en.ics ./en/CP-HU.en.ics ./en/CP037.en.ics ./en/CP038.en.ics ./en/CP273.en.ics ./en/CP278.en.ics ./en/CP280.en.ics ./en/CP282.en.ics ./en/CP284.en.ics ./en/CP285.en.ics ./en/CP297.en.ics ./en/CP367.en.ics ./en/CP424.en.ics ./en/CP437.en.ics ./en/CP500.en.ics ./en/CP737.en.ics ./en/CP775.en.ics ./en/CP813.en.ics ./en/CP819.en.ics ./en/CP850.en.ics ./en/CP851.en.ics ./en/CP852.en.ics ./en/CP855.en.ics ./en/CP856.en.ics ./en/CP857.en.ics ./en/CP860.en.ics ./en/CP861.en.ics ./en/CP862.en.ics ./en/CP863.en.ics ./en/CP864.en.ics ./en/CP865.en.ics ./en/CP866.en.ics ./en/CP868.en.ics ./en/CP869.en.ics ./en/CP870.en.ics ./en/CP871.en.ics ./en/CP874.en.ics ./en/CP875.en.ics ./en/CP880.en.ics ./en/CP891.en.ics ./en/CP903.en.ics ./en/CP904.en.ics ./en/CP905.en.ics ./en/CP912.en.ics ./en/CP915.en.ics ./en/CP916.en.ics ./en/CP918.en.ics ./en/CP920.en.ics ./en/CP922.en.ics ./en/CP930.en.ics ./en/CP932.en.ics ./en/CP933.en.ics ./en/CP935.en.ics ./en/CP936.en.ics ./en/CP937.en.ics ./en/CP939.en.ics ./en/CP949.en.ics ./en/CP950.en.ics ./en/CP1004.en.ics ./en/CP1026.en.ics ./en/CP1046.en.ics ./en/CP1047.en.ics ./en/CP1070.en.ics ./en/CP1079.en.ics ./en/CP1081.en.ics ./en/CP1084.en.ics ./en/CP1089.en.ics ./en/CP1124.en.ics ./en/CP1129.en.ics ./en/CP1250.en.ics ./en/CP1251.en.ics ./en/CP1252.en.ics ./en/CP1253.en.ics ./en/CP1254.en.ics ./en/CP1255.en.ics ./en/CP1256.en.ics ./en/CP1257.en.ics ./en/CP1258.en.ics ./en/CP10007.en.ics ./en/CPIBM861.en.ics ./en/CSASCII.en.ics ./en/CSA_T500-1983.en.ics ./en/CSA_T500.en.ics ./en/CSDECMCS.en.ics ./en/CSEBCDICES.en.ics ./en/CSEBCDICESS.en.ics ./en/CSEBCDICUK.en.ics ./en/CSEBCDICUS.en.ics ./en/CSEUCKR.en.ics ./en/CSEUCPKDFMTJAPANESE.en.ics ./en/CSGB2312.en.ics ./en/CSHPROMAN8.en.ics ./en/CSIBM037.en.ics ./en/CSIBM038.en.ics ./en/CSIBM273.en.ics ./en/CSIBM277.en.ics ./en/CSIBM278.en.ics ./en/CSIBM280.en.ics ./en/CSIBM284.en.ics ./en/CSIBM285.en.ics ./en/CSIBM297.en.ics ./en/CSIBM424.en.ics ./en/CSIBM500.en.ics ./en/CSIBM851.en.ics ./en/CSIBM855.en.ics ./en/CSIBM856.en.ics ./en/CSIBM857.en.ics ./en/CSIBM860.en.ics ./en/CSIBM863.en.ics ./en/CSIBM864.en.ics ./en/CSIBM865.en.ics ./en/CSIBM866.en.ics ./en/CSIBM868.en.ics ./en/CSIBM869.en.ics ./en/CSIBM870.en.ics ./en/CSIBM871.en.ics ./en/CSIBM880.en.ics ./en/CSIBM891.en.ics ./en/CSIBM903.en.ics ./en/CSIBM904.en.ics ./en/CSIBM905.en.ics ./en/CSIBM918.en.ics ./en/CSIBM922.en.ics ./en/CSIBM930.en.ics ./en/CSIBM932.en.ics ./en/CSIBM933.en.ics ./en/CSIBM935.en.ics ./en/CSIBM937.en.ics ./en/CSIBM939.en.ics ./en/CSIBM943.en.ics ./en/CSIBM1026.en.ics ./en/CSIBM1124.en.ics ./en/CSIBM1129.en.ics ./en/CSISO4UNITEDKINGDOM.en.ics ./en/CSISO58GB1988.en.ics ./en/CSISO90.en.ics ./en/CSISO99NAPLPS.en.ics ./en/CSISO111ECMACYRILLIC.en.ics ./en/CSISO139CSN369103.en.ics ./en/CSISO143IECP271.en.ics ./en/CSISO153GOST1976874.en.ics ./en/CSISO2022CN.en.ics ./en/CSISO2022JP.en.ics ./en/CSISO2022JP2.en.ics ./en/CSISO2022KR.en.ics ./en/CSISO10367BOX.en.ics ./en/CSISOLATIN1.en.ics ./en/CSISOLATIN2.en.ics ./en/CSISOLATIN3.en.ics ./en/CSISOLATIN4.en.ics ./en/CSISOLATIN5.en.ics ./en/CSISOLATIN6.en.ics ./en/CSISOLATINARABIC.en.ics ./en/CSISOLATINCYRILLIC.en.ics ./en/CSISOLATINGREEK.en.ics ./en/CSISOLATINHEBREW.en.ics ./en/CSKOI8R.en.ics ./en/CSMACINTOSH.en.ics ./en/CSN_369103.en.ics ./en/CSPC8CODEPAGE437.en.ics ./en/CSPC775BALTIC.en.ics ./en/CSPC850MULTILINGUAL.en.ics ./en/CSPC862LATINHEBREW.en.ics ./en/CSPCP852.en.ics ./en/CSSHIFTJIS.en.ics ./en/CSUCS4.en.ics ./en/CSUNICODE.en.ics ./en/CWI-2.en.ics ./en/CWI.en.ics ./en/CYRILLIC.en.ics ./en/DEC-MCS.en.ics ./en/DEC.en.ics ./en/DECMCS.en.ics ./en/EBCDIC-CP-AR2.en.ics ./en/EBCDIC-CP-BE.en.ics ./en/EBCDIC-CP-CA.en.ics ./en/EBCDIC-CP-CH.en.ics ./en/EBCDIC-CP-DK.en.ics ./en/EBCDIC-CP-ES.en.ics ./en/EBCDIC-CP-FI.en.ics ./en/EBCDIC-CP-FR.en.ics ./en/EBCDIC-CP-GB.en.ics ./en/EBCDIC-CP-HE.en.ics ./en/EBCDIC-CP-IS.en.ics ./en/EBCDIC-CP-IT.en.ics ./en/EBCDIC-CP-NL.en.ics ./en/EBCDIC-CP-NO.en.ics ./en/EBCDIC-CP-ROECE.en.ics ./en/EBCDIC-CP-SE.en.ics ./en/EBCDIC-CP-TR.en.ics ./en/EBCDIC-CP-US.en.ics ./en/EBCDIC-CP-WT.en.ics ./en/EBCDIC-CP-YU.en.ics ./en/EBCDIC-CYRILLIC.en.ics ./en/EBCDIC-ES-S.en.ics ./en/EBCDIC-ES.en.ics ./en/EBCDIC-GREEK.en.ics ./en/EBCDIC-INT.en.ics ./en/EBCDIC-INT1.en.ics ./en/EBCDIC-UK.en.ics ./en/EBCDIC-US.en.ics ./en/EBCDICES.en.ics ./en/EBCDICESS.en.ics ./en/EBCDICUK.en.ics ./en/EBCDICUS.en.ics ./en/ECMA-114.en.ics ./en/ECMA-118.en.ics ./en/ECMA-128.en.ics ./en/ECMA-CYRILLIC.en.ics ./en/ECMACYRILLIC.en.ics ./en/ELOT_928.en.ics ./en/EUC-CN.en.ics ./en/EUC-JP.en.ics ./en/EUC-KR.en.ics ./en/EUC-TW.en.ics ./en/EUCCN.en.ics ./en/EUCJP.en.ics ./en/EUCKR.en.ics ./en/EUCTW.en.ics ./en/GB.en.ics ./en/GB2312.en.ics ./en/GB13000.en.ics ./en/GB18030.en.ics ./en/GBK.en.ics ./en/GB_1988-80.en.ics ./en/GB_198880.en.ics ./en/GEORGIAN-ACADEMY.en.ics ./en/GEORGIAN-PS.en.ics ./en/GOST_19768-74.en.ics ./en/GOST_19768.en.ics ./en/GOST_1976874.en.ics ./en/GREEK.en.ics ./en/GREEK8.en.ics ./en/HEBREW.en.ics ./en/HP-ROMAN8.en.ics ./en/HPROMAN8.en.ics ./en/IBM-856.en.ics ./en/IBM-922.en.ics ./en/IBM-930.en.ics ./en/IBM-932.en.ics ./en/IBM-933.en.ics ./en/IBM-935.en.ics ./en/IBM-937.en.ics ./en/IBM-939.en.ics ./en/IBM-943.en.ics ./en/IBM-1046.en.ics ./en/IBM-1124.en.ics ./en/IBM-1129.en.ics ./en/IBM037.en.ics ./en/IBM038.en.ics ./en/IBM256.en.ics ./en/IBM273.en.ics ./en/IBM277.en.ics ./en/IBM278.en.ics ./en/IBM280.en.ics ./en/IBM284.en.ics ./en/IBM285.en.ics ./en/IBM297.en.ics ./en/IBM367.en.ics ./en/IBM424.en.ics ./en/IBM437.en.ics ./en/IBM500.en.ics ./en/IBM775.en.ics ./en/IBM813.en.ics ./en/IBM819.en.ics ./en/IBM850.en.ics ./en/IBM851.en.ics ./en/IBM852.en.ics ./en/IBM855.en.ics ./en/IBM856.en.ics ./en/IBM857.en.ics ./en/IBM860.en.ics ./en/IBM861.en.ics ./en/IBM862.en.ics ./en/IBM863.en.ics ./en/IBM864.en.ics ./en/IBM865.en.ics ./en/IBM866.en.ics ./en/IBM868.en.ics ./en/IBM869.en.ics ./en/IBM870.en.ics ./en/IBM871.en.ics ./en/IBM874.en.ics ./en/IBM875.en.ics ./en/IBM880.en.ics ./en/IBM891.en.ics ./en/IBM903.en.ics ./en/IBM904.en.ics ./en/IBM905.en.ics ./en/IBM912.en.ics ./en/IBM915.en.ics ./en/IBM916.en.ics ./en/IBM918.en.ics ./en/IBM920.en.ics ./en/IBM922.en.ics ./en/IBM930.en.ics ./en/IBM932.en.ics ./en/IBM933.en.ics ./en/IBM935.en.ics ./en/IBM937.en.ics ./en/IBM939.en.ics ./en/IBM943.en.ics ./en/IBM1004.en.ics ./en/IBM1026.en.ics ./en/IBM1046.en.ics ./en/IBM1047.en.ics ./en/IBM1089.en.ics ./en/IBM1124.en.ics ./en/IBM1129.en.ics ./en/IEC_P27-1.en.ics ./en/IEC_P271.en.ics ./en/ISIRI-3342.en.ics ./en/ISIRI3342.en.ics ./en/ISO-2022-CN-EXT.en.ics ./en/ISO-2022-CN.en.ics ./en/ISO-2022-JP-2.en.ics ./en/ISO-2022-JP.en.ics ./en/ISO-2022-KR.en.ics ./en/ISO-2022-KR.en.ics ./en/ISO-8859-1.en.ics ./en/ISO-8859-2.en.ics ./en/ISO-8859-3.en.ics ./en/ISO-8859-4.en.ics ./en/ISO-8859-5.en.ics ./en/ISO-8859-6.en.ics ./en/ISO-8859-7.en.ics ./en/ISO-8859-8.en.ics ./en/ISO-8859-9.en.ics ./en/ISO-8859-10.en.ics ./en/ISO-8859-11.en.ics ./en/ISO-8859-13.en.ics ./en/ISO-8859-14.en.ics ./en/ISO-8859-15.en.ics ./en/ISO-8859-16.en.ics ./en/ISO-10646.en.ics ./en/ISO-CELTIC.en.ics ./en/ISO-IR-4.en.ics ./en/ISO-IR-6.en.ics ./en/ISO-IR-57.en.ics ./en/ISO-IR-90.en.ics ./en/ISO-IR-99.en.ics ./en/ISO-IR-100.en.ics ./en/ISO-IR-101.en.ics ./en/ISO-IR-109.en.ics ./en/ISO-IR-110.en.ics ./en/ISO-IR-111.en.ics ./en/ISO-IR-126.en.ics ./en/ISO-IR-127.en.ics ./en/ISO-IR-138.en.ics ./en/ISO-IR-139.en.ics ./en/ISO-IR-143.en.ics ./en/ISO-IR-144.en.ics ./en/ISO-IR-148.en.ics ./en/ISO-IR-153.en.ics ./en/ISO-IR-155.en.ics ./en/ISO-IR-156.en.ics ./en/ISO-IR-157.en.ics ./en/ISO-IR-166.en.ics ./en/ISO-IR-179.en.ics ./en/ISO-IR-193.en.ics ./en/ISO-IR-197.en.ics ./en/ISO-IR-199.en.ics ./en/ISO-IR-203.en.ics ./en/ISO-IR-209.en.ics ./en/ISO-IR-226.en.ics ./en/ISO646-CN.en.ics ./en/ISO646-GB.en.ics ./en/ISO646-US.en.ics ./en/ISO2022CN.en.ics ./en/ISO2022CNEXT.en.ics ./en/ISO2022JP.en.ics ./en/ISO2022JP2.en.ics ./en/ISO2022KR.en.ics ./en/ISO6937.en.ics ./en/ISO8859-1.en.ics ./en/ISO8859-2.en.ics ./en/ISO8859-3.en.ics ./en/ISO8859-4.en.ics ./en/ISO8859-5.en.ics ./en/ISO8859-6.en.ics ./en/ISO8859-7.en.ics ./en/ISO8859-8.en.ics ./en/ISO8859-9.en.ics ./en/ISO8859-10.en.ics ./en/ISO8859-13.en.ics ./en/ISO8859-14.en.ics ./en/ISO8859-15.en.ics ./en/ISO8859-16.en.ics ./en/ISO88591.en.ics ./en/ISO88592.en.ics ./en/ISO88593.en.ics ./en/ISO88594.en.ics ./en/ISO88595.en.ics ./en/ISO88596.en.ics ./en/ISO88597.en.ics ./en/ISO88598.en.ics ./en/ISO88599.en.ics ./en/ISO885910.en.ics ./en/ISO885913.en.ics ./en/ISO885914.en.ics ./en/ISO885915.en.ics ./en/ISO885916.en.ics ./en/ISO_6937-2.en.ics ./en/ISO_6937.en.ics ./en/ISO_8859-1.en.ics ./en/ISO_8859-2.en.ics ./en/ISO_8859-3.en.ics ./en/ISO_8859-4.en.ics ./en/ISO_8859-5.en.ics ./en/ISO_8859-6.en.ics ./en/ISO_8859-7.en.ics ./en/ISO_8859-8.en.ics ./en/ISO_8859-9.en.ics ./en/ISO_8859-10.en.ics ./en/ISO_8859-14.en.ics ./en/ISO_10367-BOX.en.ics ./en/ISO_10367BOX.en.ics ./en/ISO_69372.en.ics ./en/KOI-8.en.ics ./en/KOI8-R.en.ics ./en/KOI8-T.en.ics ./en/KOI8-U.en.ics ./en/KOI8.en.ics ./en/KOI8R.en.ics ./en/KOI8U.en.ics ./en/L1.en.ics ./en/L2.en.ics ./en/L3.en.ics ./en/L4.en.ics ./en/L5.en.ics ./en/L6.en.ics ./en/L7.en.ics ./en/L8.en.ics ./en/L10.en.ics ./en/LATIN1.en.ics ./en/LATIN2.en.ics ./en/LATIN3.en.ics ./en/LATIN4.en.ics ./en/LATIN5.en.ics ./en/LATIN6.en.ics ./en/LATIN7.en.ics ./en/LATIN8.en.ics ./en/LATIN10.en.ics ./en/MAC-CYRILLIC.en.ics ./en/MAC-IS.en.ics ./en/MAC-SAMI.en.ics ./en/MAC-UK.en.ics ./en/MAC.en.ics ./en/MACCYRILLIC.en.ics ./en/MACINTOSH.en.ics ./en/MACIS.en.ics ./en/MACUK.en.ics ./en/MACUKRAINIAN.en.ics ./en/MS-ANSI.en.ics ./en/MS-ARAB.en.ics ./en/MS-CYRL.en.ics ./en/MS-EE.en.ics ./en/MS-GREEK.en.ics ./en/MS-HEBR.en.ics ./en/MS-MAC-CYRILLIC.en.ics ./en/MS-TURK.en.ics ./en/MSCP949.en.ics ./en/MSMACCYRILLIC.en.ics ./en/MS_KANJI.en.ics ./en/NAPLPS.en.ics ./en/OS2LATIN1.en.ics ./en/OSF00010001.en.ics ./en/OSF00010002.en.ics ./en/OSF00010003.en.ics ./en/OSF00010004.en.ics ./en/OSF00010005.en.ics ./en/OSF00010006.en.ics ./en/OSF00010007.en.ics ./en/OSF00010008.en.ics ./en/OSF00010009.en.ics ./en/OSF0001000A.en.ics ./en/OSF00010020.en.ics ./en/OSF00010100.en.ics ./en/OSF00010101.en.ics ./en/OSF00010102.en.ics ./en/OSF00010104.en.ics ./en/OSF00010105.en.ics ./en/OSF00010106.en.ics ./en/OSF00030010.en.ics ./en/OSF0004000A.en.ics ./en/OSF0005000A.en.ics ./en/OSF05010001.en.ics ./en/OSF100201A8.en.ics ./en/OSF100201B5.en.ics ./en/OSF100201F4.en.ics ./en/OSF100203B5.en.ics ./en/OSF1002011C.en.ics ./en/OSF1002011D.en.ics ./en/OSF1002035D.en.ics ./en/OSF1002035E.en.ics ./en/OSF1002035F.en.ics ./en/OSF1002036B.en.ics ./en/OSF1002037B.en.ics ./en/OSF10010001.en.ics ./en/OSF10020025.en.ics ./en/OSF10020111.en.ics ./en/OSF10020115.en.ics ./en/OSF10020116.en.ics ./en/OSF10020118.en.ics ./en/OSF10020129.en.ics ./en/OSF10020352.en.ics ./en/OSF10020354.en.ics ./en/OSF10020357.en.ics ./en/OSF10020359.en.ics ./en/OSF10020360.en.ics ./en/OSF10020364.en.ics ./en/OSF10020365.en.ics ./en/OSF10020366.en.ics ./en/OSF10020367.en.ics ./en/OSF10020370.en.ics ./en/OSF10020387.en.ics ./en/OSF10020388.en.ics ./en/OSF10020396.en.ics ./en/OSF10020402.en.ics ./en/OSF10020417.en.ics ./en/R8.en.ics ./en/ROMAN8.en.ics ./en/SHIFT-JIS.en.ics ./en/SHIFT_JIS.en.ics ./en/SJIS.en.ics ./en/ST_SEV_358-88.en.ics ./en/TIS-620.en.ics ./en/TIS620-0.en.ics ./en/TIS620.2529-1.en.ics ./en/TIS620.2533-0.en.ics ./en/TIS620.en.ics ./en/TS-5881.en.ics ./en/UCS-2.en.ics ./en/UCS-2BE.en.ics ./en/UCS-2LE.en.ics ./en/UCS-4.en.ics ./en/UCS-4BE.en.ics ./en/UCS-4LE.en.ics ./en/UCS2.en.ics ./en/UCS4.en.ics ./en/UHC.en.ics ./en/UJIS.en.ics ./en/UK.en.ics ./en/UNICODE.en.ics ./en/UNICODEBIG.en.ics ./en/UNICODELITTLE.en.ics ./en/US-ASCII.en.ics ./en/US.en.ics ./en/UTF-7.en.ics ./en/UTF-8.en.ics ./en/UTF-16.en.ics ./en/UTF-16BE.en.ics ./en/UTF-16LE.en.ics ./en/UTF-32.en.ics ./en/UTF-32BE.en.ics ./en/UTF-32LE.en.ics ./en/UTF7.en.ics ./en/UTF8.en.ics ./en/UTF16.en.ics ./en/UTF16BE.en.ics ./en/UTF16LE.en.ics ./en/UTF32.en.ics ./en/UTF32BE.en.ics ./en/UTF32LE.en.ics ./en/VISCII.en.ics ./en/WCHAR_T.en.ics ./en/WIN-SAMI-2.en.ics ./en/WINBALTRIM.en.ics ./en/WINDOWS-1250.en.ics ./en/WINDOWS-1251.en.ics ./en/WINDOWS-1252.en.ics ./en/WINDOWS-1253.en.ics ./en/WINDOWS-1254.en.ics ./en/WINDOWS-1255.en.ics ./en/WINDOWS-1256.en.ics ./en/WINDOWS-1257.en.ics ./en/WINDOWS-1258.en.ics ./en/WINSAMI2.en.ics ./en/WS2.en.ics --------------4DBE7650942633119F604FF5 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 ; Wed, 13 Feb 2002 11:56:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DGj4K23879 for ietf-calendar-bks; Wed, 13 Feb 2002 08:45:04 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGj3323875 for ; Wed, 13 Feb 2002 08:45:03 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA04435 for ; Wed, 13 Feb 2002 08:45:03 -0800 (PST) Message-ID: <3C6A980B.5A3BAD72@Royer.com> Date: Wed, 13 Feb 2002 09:44:59 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > References: Content-Type: multipart/mixed; boundary="------------81C4B9F4003F4AB603363FA4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------81C4B9F4003F4AB603363FA4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >> x.2.1.3 Current Date-Time Component Property > > > >I again propose that we drop this from CAP > > I agree. We have NTP for time synchronization; it can do a much better > job than anything we might build over TCP. > > >and that it must > >be in UTC and it MUST be supplied. > > Why UTC? Because the TZID is in each calendar, not the CS. So it would have to be in some time zone or it would be useless - UTC seemed the best. --------------81C4B9F4003F4AB603363FA4 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 ; Wed, 13 Feb 2002 11:58:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DGmO724019 for ietf-calendar-bks; Wed, 13 Feb 2002 08:48:24 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGmN324014 for ; Wed, 13 Feb 2002 08:48:23 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA08510; Wed, 13 Feb 2002 11:48:19 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DGmHQ27905; Wed, 13 Feb 2002 11:48:18 -0500 (EST) Message-ID: <3C6A98D0.695976D9@steltor.com> Date: Wed, 13 Feb 2002 11:48:16 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: John Stracke CC: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > 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: > > >> x.2.1.3 Current Date-Time Component Property > > > >I again propose that we drop this from CAP > > I agree. We have NTP for time synchronization; it can do a much better > job than anything we might build over TCP. I agree. Can we remove CURRENT-DATETIME from CAP? I still see no reasons why we need it. > > >and that it must > >be in UTC and it MUST be supplied. > > Why UTC? > > /========================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc.| > |http://www.incentivesystems.com |My opinions are my own.| > |========================================================| > |The plural of mongoose is polygoose. | > \========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 11:58:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11780 for ; Wed, 13 Feb 2002 11:58:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DGlBr23969 for ietf-calendar-bks; Wed, 13 Feb 2002 08:47:11 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGlA323965 for ; Wed, 13 Feb 2002 08:47:10 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA04439 for ; Wed, 13 Feb 2002 08:47:10 -0800 (PST) Message-ID: <3C6A988A.1B98307E@Royer.com> Date: Wed, 13 Feb 2002 09:47:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> <3C69A6B8.A25872B0@Royer.com> <3C6A84CB.FD36B9B9@steltor.com> Content-Type: multipart/mixed; boundary="------------4AE148FD8D8D637AB7927C65" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4AE148FD8D8D637AB7927C65 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > You forgot 'TZID' (in this section) : the default TZ for the VAGENDA > > so that CUAs know what is meant when 'localtime' date-time values > > are used. > > You're right. However, TZID is a parameter and also a property. > Perhaps we should add something like DEFAULT-TZID? > > Where are 'localtime' date-time values used? Do you mean times > without a timzone, e.g., 20020213T100000. Yes that is what I meant - thanks. --------------4AE148FD8D8D637AB7927C65 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 ; Wed, 13 Feb 2002 12:09:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DGtrj24297 for ietf-calendar-bks; Wed, 13 Feb 2002 08:55:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGtq324293 for ; Wed, 13 Feb 2002 08:55:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA08812; Wed, 13 Feb 2002 11:55:48 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DGtlQ29218; Wed, 13 Feb 2002 11:55:48 -0500 (EST) Message-ID: <3C6A9A92.E0CAD17A@steltor.com> Date: Wed, 13 Feb 2002 11:55:46 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Default Access Rights Component Property References: <3C699404.DAF9AE4A@steltor.com> <3C69B669.785A1060@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: > > George Babics wrote: > > > x.2.1.4 Default Access Rights Component Property > > > > To: ietf-calendar@imc.org > > > > Subject: Registration of text/calendar MIME property DEFAULT-VCARS > > > > Property Name: DEFAULT-VCARS > > > > Purpose: This property is used to specify the CARID of the > > default VCAR components for newly created VAGENDA components. > > > > Value Type: TEXT > > > > Property Parameters: Only non-standard property parameters can be > > specified on this property. > > > > Conformance: This property MUST be specified in "CALSTORE" calendar > > components and MUST at least specify the following values: > > READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER. > > > > Description: This property is used in the "CALSTORE" calendar > > component to specify the CARID of the VCAR components that > > must be copied in VAGENDA at creation time. > > Add: > And as CARIDs may contain spaces, those values must be > wrapped in quotes. I don't think so. Spaces are valid values for "text." For instance, CATEGORIES is defined as a multi-valued property, each value of type "text." From RFC 2445, this is a valid CATEGORY: CATEGORIES:BUSINESS,HUMAN RESOURCES > > > Format Definition: The property is defined by the following notation: > > > > def-vcars = "DEFAULT-VCARS" def-vcarsparam ":" text > > *( "," text ) CRLF > > > > def-vcarsparam = *( ";" xparam ) > > > > Example: The following is an example of this property: > > > > DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY > > DEFAULT-VCARS:UPDATEPARTSTATUS,DEFAULTOWNER > > Add something like: > > DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY > ,UPDATEPARTSTATUS,DEFAULTOWNER,"My Private CARID" It can be: DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY ,UPDATEPARTSTATUS,DEFAULTOWNER,My Private CARID George From owner-ietf-calendar@mail.imc.org Wed Feb 13 12:11:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14137 for ; Wed, 13 Feb 2002 12:11:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DGvUv24376 for ietf-calendar-bks; Wed, 13 Feb 2002 08:57:30 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGvT324372 for ; Wed, 13 Feb 2002 08:57:29 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA08859; Wed, 13 Feb 2002 11:57:25 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DGvOQ29302; Wed, 13 Feb 2002 11:57:25 -0500 (EST) Message-ID: <3C6A9AF3.283AE528@steltor.com> Date: Wed, 13 Feb 2002 11:57:23 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: MIN/MAX date and RECUR properties. References: <3C699404.DAF9AE4A@steltor.com> <3C69B751.2F50B1B2@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 I agree. They should be moved into the capabilities. Doug Royer wrote: > > George Babics wrote: > > I propose all of these be dropped as properties and > moved into categories - as they effect what the CUA > will send on the wire to the CS and reduce the chattiness > of the protocol by not having to do both a get-capabilities > and query. > > > x.2.1.5 Maximum Date Component Property > > x.2.1.6 Minimum Date Component Property > > x.2.1.7 Recurrences Accepted Component Property > > x.2.1.8 Recurrences Expand Component Property From owner-ietf-calendar@mail.imc.org Wed Feb 13 12:20:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14378 for ; Wed, 13 Feb 2002 12:20:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DH4Nn24658 for ietf-calendar-bks; Wed, 13 Feb 2002 09:04:23 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DH4L324653 for ; Wed, 13 Feb 2002 09:04:21 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA09059 for ; Wed, 13 Feb 2002 12:04:18 -0500 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 g1DH4EQ00288 for ; Wed, 13 Feb 2002 12:04:14 -0500 (EST) Message-ID: <3C6A9D03.F57A1EC5@steltor.com> Date: Wed, 13 Feb 2002 12:06:11 -0500 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: (#3) VCAR Proposal 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 Here's the third version of my proposal on VCAR. Highlight of changes: - Added missing "To:" and "Subject:" fields in each section. - Changed the upn-filter rule part to make use of the rule part dot-atom-text defined in RFC 2822. - Changed examples in UPN-FILTER to reflect the fact that VAGENDA can have more than one OWNER. Changed description of examples to use "null" and "non-null" instead of "unamed and "named" to be consistent with section 2.4.4 "CAP Session Identity" of the draft. - Changed examples to use new CAP-QL operator "IN" and new functions CAL-OWNERS() and CURRENT-CALID(). - Remove double quote (") in values of the NAME property. - Changed references to value type 'capselect' to 'CAL-QUERY' and references to rule part 'capselect' to 'cal-query'. - Changed description of the VCAR with "NAME:No CAR At All" to read "should be specified with great care" instead of "should not be specified". - Changed CARIDs to be unique. - Renamed section for the CARID property. - Changed purpose of GRANT and DENY to talk of UPN. - Added new DECREED property. - Specified that the draft only suggest defintions for the VCAR components with the predefined CARID. Open issues: - I've used "iana-prop" in the ABNF of VCAR and VRIGHT but it's not defined anywhere. Is "x-prop" sufficient or shall we defined "iana-prop" ourselves? - Should we add "iana-comp / x-comp" in the ABNF of VCAR and VRIGHT? --------------------------------------------------------------------- x.x.1 Property Value Data Types x.x.1.1 UPN Filter To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME value type UPN-FILTER Value Name: UPN-FILTER Purpose: This value type is used to identify values that contain a user principal name filter. Formal Definition: The value type is defined by the following notation: upn-filter = "OWNER" / "NONOWNER" / "*" / [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text ) ; dot-atom-text is defined in RFC 2822 Description: The value is used to match user principal names (UPNs). Example: The following are examples of this value type: OWNER Matches the UPNs equal to any instance of the OWNER property of the VAGENDA in which the encapsulating VCAR is stored. NONOWNER Matches all UPNs different from all instances of the OWNER property of the VAGENDA in which the encapsulating VCAR is stored. * Matches all UPNs. @ Matches the UPN of anonymous CUs belonging to the null realm @* Matches the UPN of anonymous CUs belonging to any non-null realm @realm Matches the UPN of anonymous CUs belonging to the specified realm *@* Matches the UPN of non-anonymous CUs belonging to any non-null realm *@realm Matches the UPN of non-anonymous CUs belonging to the specified realm user@realm Matches the UPN of the specified CU belonging to the specified realm user@* Matches the UPN of the specified CU belonging to any non-null realm x.x.2 Calendar Components x.x.2.1 Calendar Access Right Component To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME component VCAR Component Name: "VCAR" Purpose: Provide a grouping of calendar access rights. Format Definition: A "VCAR" calendar component is defined by the following notation: carc = "BEGIN" ":" "VCAR" CRLF carprop 1*rightc "END" ":" "VCAR" CRLF carprop = 1*( ; 'carid' is REQUIRED, ; but MUST NOT occur more than once carid / ; the following are OPTIONAL, ; and MAY occur more than once name / x-prop / iana-prop ) Description: A "VCAR" calendar component is a grouping of component properties, and "VRIGHT" calendar components, that represents access rights granted or denied to calendar users. The "CARID" property specifies the local identifier for the "VCAR" calendar component. The "NAME" property specifies a localizable display name. Example: In the following example, the UPN "foo@host.com" is given read access to the "DTSTART" and "DTEND" VEVENT properties. No other access is specified: BEGIN:VCAR CARID:xyzzy-001 NAME:View Start and End Times BEGIN:VRIGHT GRANT:foo@host.com PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VRIGHT END:VCAR In this example, all UPNs are given read access to "DTSTART" and "DTEND" properties of VEVENT components. "All CUs and UGs" are specified by the UPN value "*". Note that this enumerated UPN value is not in quotes: BEGIN:VCAR CARID:xyzzy-002 NAME:View Start and End Times 2 BEGIN:VRIGHT GRANT:* PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VRIGHT END:VCAR In this example, rights are specified for all UPNs to read VEVENT components classified as PUBLIC: BEGIN:VCAR CARID:xyzzy-003 NAME:View PUBLIC Start and End Times BEGIN:VRIGHT GRANT:* PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' END:VRIGHT END:VCAR In this example, rights are specified for all UPNs to read or modify existing VEVENT components classified as PUBLIC: BEGIN:VCAR CARID:xyzzy-004 NAME:Read and Modify PUBLIC Calendar Entries BEGIN:VRIGHT GRANT:* PERMISSION:READ PERMISSION:MODIFY SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC' END:VRIGHT END:VCAR In these examples, full calendar access rights are given to the OWNER, and a hypothetical administrator is given access rights to specify calendar access rights. If no other rights are specified, only these two UPNs can specify calendar access rights: BEGIN:VCAR CARID:xyzzy-005 NAME:Only OWNER or ADMIN Settable CARs BEGIN:VRIGHT GRANT:OWNER PERMISSION:* SCOPE:SELECT * FROM VAGENDA END:VRIGHT BEGIN:VRIGHT GRANT:cal-admin@host.com PERMISSION:* SCOPE:SELECT * FROM VCAR RESTRICTION:SELECT * FROM VCAR END:VRIGHT END:VCAR In this example, rights to write, read, modify or delete calendar access rights are denied to all UPNs. This example would disable providing different access rights to the calendar store or calendar. This calendar access right should be specified with great care, as it remove the ability to change calendar access; even for the owner or administrator: BEGIN:VCAR CARID:xyzzy-006 NAME:No CAR At All BEGIN:VRIGHT DENY:* PERMISSION:* SCOPE:SELECT * FROM VCAR END:VRIGHT END:VCAR x.x.2.2 VRIGHT Calendar Component To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME component VRIGHT Component Name: "VRIGHT" Purpose: Provide a grouping of component properties that describe an access right. Format Definition: A "VRIGHT" calendar component is defined by the following notation: rightc = "BEGIN" ":" "VRIGHT" CRLF rightprop "END" ":" "VRIGHT" CRLF rightprop = 2*( ; either 'grant' or 'deny' MUST ; occur at least once ; and MAY occur more than once grant / deny / ; 'permission' MUST occur at least once ; and MAY occur more than once permission / ; the following are optional, ; and MAY occur more than once scope / restriction / x-prop / iana-prop ) Description: A "VRIGHT" calendar component is a grouping of calendar access right component properties. The "GRANT" property specifies the CU or UG to whom a calendar access right is granted. The "DENY" property specifies the CU or UG to whom a calendar access right is denied. The "PERMISSION" property specifies the actual permission being set. The "SCOPE" property identifies the calendar store properties, calendar properties, calendar components, component properties to which the access right applies. The "RESTRICTION" property specifies restriction on the value that may take calendar store properties, calendar properties, calendar components, and component properties after a WRITE or MODIFY operation. Values MUST match all the instances of the RESTRICTION property to be valid. x.x.3 Component Properties The following properties can appear within calendar components, as specified by each component property definition. x.x.3.1 Descriptive Component Properties The following properties specify descriptive information about calendar components. x.x.3.1.1 Name Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property NAME Property Name: NAME Purpose: This property provides a localizable display name for a calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VAGENDA" and "VCAR" calendar components. Description: This property is used in the "VAGENDA" and in the "VCAR" calendar components to specify a localizable display name. Format Definition: The property is defined by the following notation: name = "NAME" nameparam ":" text CRLF nameparam = *( ; the following is optional, ; but MUST NOT occur more than once ( ";" languageparam ) / ; the following is optional, ; and MAY occur more than once ( ";" xparam ) ) Example: The following is an example of this property: NAME:Restrict Guests From Creating ALARMs On Events x.x.3.2 Calendar Access Right Component Properties x.x.3.2.1 VCAR Identifier Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property CARID Property Name: CARID Purpose: This property specifies the identifier for an access right calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified once in a "VCAR" calendar component. Description: This property is used in the "VCAR" calendar component to specify an identifier. Format Definition: The property is defined by the following notation: carid = "CARID" caridparam ":" text CRLF caridparam = *( ";" xparam ) Example: The following is an example of this property: CARID:xyzzy-007 x.x.3.2.2 VCAR Decreed Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property DECREED Property Name: DECREED Purpose: This property specifies if an access right calendar component is decreed or not. Value Type: BOOLEAN Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCAR" calendar component. Description: This property is used in the "VCAR" calendar component to specify whether the component is decreed or not. Format Definition: The property is defined by the following notation: decreed = "DECREED" decreedparam ":" boolean CRLF decreedparam = *( ";" xparam ) Example: The following is an example of this property: DECREED:TRUE x.x.3.3 Right Component Properties x.x.3.3.1 Grant Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property GRANT Property Name: GRANT Purpose: This property identifies the UPN(s) being granted access in the VRIGHT component. Value Type: UPN-FILTER Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components. Description: This property is used in the "VRIGHT" calendar component to specify the CU or UG being granted access. Format Definition: The property is defined by the following notation: grant = "GRANT" grantparam ":" upn-filter CRLF grantparam = *( ";" xparam ) Example: The following are examples of this property: GRANT:* GRANT:bob@example.com x.x.3.3.2 Deny Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property DENY Property Name: DENY Purpose: This property identifies the UPN(s) being denied access in the VRIGHT component. Value Type: UPN-FILTER Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components. Description: This property is used in the "VRIGHT" calendar component to define the CU or UG being denied access. Format Definition: The property is defined by the following notation: deny = "DENY" denyparam ":" upn-filter CRLF denyparam = *( ";" xparam ) Example: The following are examples of this property: DENY:* DENY:bob@example.com x.x.3.3.3 Permission Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property PERMISSION Property Name: PERMISSION Purpose: This property defines a permission that is granted or denied in a VRIGHT component. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components. Description: This property is used in the "VRIGHT" calendar component to define a permission that is granted or denied. Format Definition: The property is defined by the following notation: perm = "PERMISSION" permparam ":" permvalue CRLF permparam = *( ";" xparam ) permvalue = ( "READ" / "WRITE" / "DELETE" / "MODIFY" / all ) all = "*" Example: The following is an example of this property: PERMISSION:READ x.x.3.3.4 Scope Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property SCOPE Property Name: SCOPE Purpose: This property identifies the objects in the CS to which the access rights applies. Value Type: CAL-QUERY Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components. Description: This property is used in the "VRIGHT" calendar component to define the set of objects subject to the access right being defined. Format Definition: The property is defined by the following notation: scope = "SCOPE" scopeparam ":" cal-query CRLF scopeparam = *( ";" xparam ) Example: The following is an example of this property: SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' x.x.3.3.5 Restriction Component Property To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property RESTRICTION Property Name: RESTRICTION Purpose: This property defines restrictions on the value that may take new or existent calendar components. Value Type: CAL-QUERY Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VRIGHT" calendar components, but only when the PERMISSION property is set to "WRITE", "MODIFY", or "*". Description: This property is used in the "VRIGHT" calendar component to define restrictions on the calendar components that can be written (i.e., by using the "create" or "move" commands) as well as on the values that may take existent calendar store properties, calendar properties, calendar components, and component properties (i.e., by using the "modify" command). Accepted values MUST match the specified RESTRICTION. Format Definition: The property is defined by the following notation: restrict = "RESTRICTION" restrictparam ":" cal-query CRLF restrictparam = *( ";" xparam ) Example: The following are examples of this property: RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' RESTRICTION:SELECT * FROM VEVENT WHERE ORGANIZER = SELF() RESTRICTION:SELECT * FROM VEVENT WHERE CONTAINS(CATEGORIES,'BUSINESS') ------------------------------------------------------------------------ Predefined calendar access CARIDs that MUST be implemented are: CARID:READBUSYTIMEINFO - grants all authenticated users the right to read VFREEBUSY components. Suggested definition for this VCAR: BEGIN:VCAR CARID:READBUSYTIMEINFO BEGIN:VRIGHT GRANT:* PERMISSION:READ SCOPE:SELECT * FROM VFREEBUSY END:VRIGHT END:VCAR CARID:REQUESTONLY - grants to users other than the owner of the calendar the right to write new events with the property METHOD set to REQUEST. Suggested definition for this VCAR: BEGIN:VCAR CARID:REQUESTONLY BEGIN:VRIGHT GRANT:NONOWNER PERMISSION:WRITE RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' END:VRIGHT END:VCAR CARID:UPDATEPARTSTATUS - grants all authenticated users the right to modify the instances of the ATTENDEE property set to one of their calendar adresses in the VEVENT and VTODO components for which the ORGANIZER property is set to the address of the VAGENDA in which the VEVENT or VTODO is stored, given that the submitted value of the ATTENDEE property is one of their calendar adresses. Suggested definition for this VCAR: BEGIN:VCAR CARID:UPDATEPARTSTATUS BEGIN:VRIGHT GRANT:* PERMISSION:MODIFY SCOPE:SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE SELF() IN CAL-OWNERS(att) AND ORGANIZER = CURRENT-CALID() RESTRICTION:SELECT * FROM VEVENT WHERE SELF() IN CAL-OWNERS(ATTENDEE) END:VRIGHT BEGIN:VRIGHT GRANT:* PERMISSION:MODIFY SCOPE:SELECT att FROM VTODO USING_PROPERTIES ATTENDEE att WHERE SELF() IN CAL-OWNERS(att) AND ORGANIZER = CURRENT-CALID() RESTRICTION:SELECT * FROM VTODO WHERE SELF() IN CAL-OWNERS(ATTENDEE) END:VRIGHT END:VCAR CARID:DEFAULTOWNER - grants to the owner all permissions on all the objects in the calendar. Suggested definition for this VCAR: BEGIN:VCAR CARID:DEFAULTOWNER BEGIN:VRIGHT GRANT:OWNER PERMISSION:* SCOPE:SELECT * FROM VAGENDA END:VRIGHT END:VCAR ------------------------------------------------------------------------ [ Editor's note: Information that needs to be added to the restriction table of the "create" command in section 6.2.4.1. ] Component/Property Presence Comment ------------------- -------- ----------------------------- . . VCAR 0+ . . . CARID 1 . . . NAME 0+ Note, there MUST NOT be more than one NAME with no LANGUAGE parameter, and there MUST NOT be more than one NAME with the same LANGUAGE value. . . . DECREED 0 This property is outside the scope of the protocol. . . . X-PROPERTY 0+ . . . [IANA-PROP] 0+ any IANA registered property . . . VRIGHT 1+ . . . . PERMISSION 1+ . . . . DENY 0+ Note, there must be at least one GRANT or DENY within the VRIGHT. . . . . GRANT 0+ Note, there must be at least one GRANT or DENY within the VRIGHT. . . . . SCOPE 0+ Note, there must be at least one SCOPE if PERMISSION is set to "READ", "MODIFY", "DELETE", or "*". . . . . RESTRICTION 0 or 0+ Note, allowed only if PERMISSION is set to "WRITE", "MODIFY", or "*". . . . . X-PROPERTY 0+ . . . . [IANA-PROP] 0+ any IANA registered property ------------------------------------------------------------------------ Regards, 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 Wed Feb 13 12:26:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14572 for ; Wed, 13 Feb 2002 12:26:22 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DH98H24803 for ietf-calendar-bks; Wed, 13 Feb 2002 09:09:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DH96324794 for ; Wed, 13 Feb 2002 09:09:06 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA09244; Wed, 13 Feb 2002 12:09:02 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DH91Q00691; Wed, 13 Feb 2002 12:09:02 -0500 (EST) Message-ID: <3C6A9DAD.11528DA1@steltor.com> Date: Wed, 13 Feb 2002 12:09:01 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> <3C69B89B.BB990DD3@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: > > George Babics wrote: > > > > > x.x.2.2 Calendar Store Component > > > related / iana-token / x-prop > > Add: > > vcar Why? > > Do we want to add: > > x-component Done. From owner-ietf-calendar@mail.imc.org Wed Feb 13 12:27:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14616 for ; Wed, 13 Feb 2002 12:27:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DH7Ax24732 for ietf-calendar-bks; Wed, 13 Feb 2002 09:07:10 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DH78324727 for ; Wed, 13 Feb 2002 09:07:09 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA09158; Wed, 13 Feb 2002 12:07:04 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DH74Q00547; Wed, 13 Feb 2002 12:07:04 -0500 (EST) Message-ID: <3C6A9D37.47587A2F@steltor.com> Date: Wed, 13 Feb 2002 12:07:03 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Agenda Component References: <3C699404.DAF9AE4A@steltor.com> <3C69B7E7.76FA6566@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 Added. Doug Royer wrote: > > George Babics wrote: > > > x.x.2.1 Agenda Component > > > > agendaprop = *( > > ; the following MUST occur exactly once > > > > created / owner / recalid / last-mod / > > > > ; the following are optional, > > ; but MUST NOT occur more than once > > > > allow-conflict / calscale / charset / locale / > > tombstone / > > > > ; the following are optional, > > ; and MAY occur more than once > > > > name / iana-token / x-prop > > Add: > > x-component From owner-ietf-calendar@mail.imc.org Wed Feb 13 12:38:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14969 for ; Wed, 13 Feb 2002 12:38:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DHIe025184 for ietf-calendar-bks; Wed, 13 Feb 2002 09:18:40 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DHId325179 for ; Wed, 13 Feb 2002 09:18:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA04523 for ; Wed, 13 Feb 2002 09:18:40 -0800 (PST) Message-ID: <3C6A9FEC.A18FCD00@Royer.com> Date: Wed, 13 Feb 2002 10:18:36 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP open issues References: <3C699404.DAF9AE4A@steltor.com> <3C69ABF9.5F2A14F4@Royer.com> <3C6A9347.79D6B54F@steltor.com> Content-Type: multipart/mixed; boundary="------------17FF8753F94888CC42EB7BCC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------17FF8753F94888CC42EB7BCC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > AND: we need to re-add expansion limits to VQUERY, what > > if something goes on forever - how many will EXPAND:TRUE > > with NO date time limit return with out it? > > Doesn't RECUR-LIMIT also apply to VQUERY? I think they are the sam thing? Or are they different? > > > > > > - Do we need a limit for bonded recurrences? RECUR-LIMIT only applies > > > to unbounded recurrences. > > > > A CUA reading on a TCP connection is not forced to read > > more that it wants. If you get too much. Stop reading and throw > > away the rest - or/and abort the command using a separate channel. > > However, the CS may also not want to expand all occurrences. > I believe the CS should be able to have limits to the number of > occurrences it expands. A good way to attack the CS would be for > a few CUA to create recurring events that occur every second for > the next 100 years, then to read the expanded events a few times. > > Perhaps RECUR-LIMIT should apply to both bounded and unbounded > recurrences? Yes -I agree. > > > - According to the definition of VERSION in iCalendar, VERSION MUST > > > appear once in a VCALENDAR. The VERSION in CALSTORE is slightly > > > different, in that it defines the version of iCalendar user in > > > the calendar store, and not the version of an iCalendar. Furthermore, > > > by adding a version to CALSTORE we may have: > > > > The 2445 VERSION is the version of the 2445 record format, is not > > the VERSION of iTIP or CAP. > > > > Do we mandate it as part of ANY query reply - so the CUA knows > > that the data coming back conforms to iCalendar 2.0 record format? > > > > > Perhaps we should use ICALENDAR-VERSION? > > The version is already part of the VCALENDAR object that is returned: > > BEGIN:VCALENDAR > VERSION:2.0 > BEGIN:VEVENT > ... > END:VEVENT > END:VCALENDAR > > RFC 2445 states that the VERSION and PRODID must occur exactly > once. However, most of our examples are missing them. From RFC 2445: > > An iCalendar object MUST include the "PRODID" and "VERSION" calendar > properties. In addition, it MUST include at least one calendar > component. Okay - I am really lost :-) Was your point that we need to add it to all query replies? (That is what I thought you meant) Or that we need to add it as a property (or capability)? Or does this next reply cover it (I think it does): > The iCalendar, iTIP, and CAP versions are already returned by the capability > command. > > I'll remove VERSION from the calendar store component. > > George --------------17FF8753F94888CC42EB7BCC 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 ; Wed, 13 Feb 2002 12:43:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DHTMR25554 for ietf-calendar-bks; Wed, 13 Feb 2002 09:29:22 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DHTK325550 for ; Wed, 13 Feb 2002 09:29:20 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA09683; Wed, 13 Feb 2002 12:29:16 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1DHTFQ03157; Wed, 13 Feb 2002 12:29:15 -0500 (EST) Message-ID: <3C6AA26B.BBD38B76@steltor.com> Date: Wed, 13 Feb 2002 12:29:15 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP open issues References: <3C699404.DAF9AE4A@steltor.com> <3C69ABF9.5F2A14F4@Royer.com> <3C6A9347.79D6B54F@steltor.com> <3C6A9FEC.A18FCD00@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: > > George Babics wrote: > > > > AND: we need to re-add expansion limits to VQUERY, what > > > if something goes on forever - how many will EXPAND:TRUE > > > with NO date time limit return with out it? > > > > Doesn't RECUR-LIMIT also apply to VQUERY? > > I think they are the sam thing? > Or are they different? > > > > > > > > > > - Do we need a limit for bonded recurrences? RECUR-LIMIT only applies > > > > to unbounded recurrences. > > > > > > A CUA reading on a TCP connection is not forced to read > > > more that it wants. If you get too much. Stop reading and throw > > > away the rest - or/and abort the command using a separate channel. > > > > However, the CS may also not want to expand all occurrences. > > I believe the CS should be able to have limits to the number of > > occurrences it expands. A good way to attack the CS would be for > > a few CUA to create recurring events that occur every second for > > the next 100 years, then to read the expanded events a few times. > > > > Perhaps RECUR-LIMIT should apply to both bounded and unbounded > > recurrences? > > Yes -I agree. > > > > > - According to the definition of VERSION in iCalendar, VERSION MUST > > > > appear once in a VCALENDAR. The VERSION in CALSTORE is slightly > > > > different, in that it defines the version of iCalendar user in > > > > the calendar store, and not the version of an iCalendar. Furthermore, > > > > by adding a version to CALSTORE we may have: > > > > > > The 2445 VERSION is the version of the 2445 record format, is not > > > the VERSION of iTIP or CAP. > > > > > > Do we mandate it as part of ANY query reply - so the CUA knows > > > that the data coming back conforms to iCalendar 2.0 record format? > > > > > > > Perhaps we should use ICALENDAR-VERSION? > > > > The version is already part of the VCALENDAR object that is returned: > > > > BEGIN:VCALENDAR > > VERSION:2.0 > > BEGIN:VEVENT > > ... > > END:VEVENT > > END:VCALENDAR > > > > RFC 2445 states that the VERSION and PRODID must occur exactly > > once. However, most of our examples are missing them. From RFC 2445: > > > > An iCalendar object MUST include the "PRODID" and "VERSION" calendar > > properties. In addition, it MUST include at least one calendar > > component. > > Okay - I am really lost :-) > > Was your point that we need to add it to all query replies? > (That is what I thought you meant) > > Or that we need to add it as a property (or capability)? I was simply saying that the version of iCalendar used in each object is already returned in every VCALENDAR, since it is a requirement in RFC 2445. (Also the examples in CAP are missing the PRODID and VERSION in the VCALENDARs.) > Or does this next reply cover it (I think it does): > > > The iCalendar, iTIP, and CAP versions are already returned by the capability > > command. > > > > I'll remove VERSION from the calendar store component. > > > > George From owner-ietf-calendar@mail.imc.org Wed Feb 13 12:43:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15119 for ; Wed, 13 Feb 2002 12:43:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DHVog25658 for ietf-calendar-bks; Wed, 13 Feb 2002 09:31:50 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DHVl325654 for ; Wed, 13 Feb 2002 09:31:47 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 12:39:37 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 12:39:50 PM, Serialize complete at 02/13/2002 12:39:50 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> I agree. We have NTP for time synchronization; it can do a much better >> job than anything we might build over TCP. > > I agree. Can we remove CURRENT-DATETIME from CAP? >I still see no reasons why we need it. Well, there are times when you can't use NTP (e.g., if there's a firewall in the way that doesn't permit it), so getting the CS's current time when you first connect gives you at least a crude idea (to within seconds, usually). /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===========================================================| |"I only wish I had time to get married myself, as I've told| |m'wife many's the time." | \===========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 12:51:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15345 for ; Wed, 13 Feb 2002 12:51:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DHWiK25695 for ietf-calendar-bks; Wed, 13 Feb 2002 09:32:44 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DHWh325691 for ; Wed, 13 Feb 2002 09:32:43 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 12:40:34 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 12:40:46 PM, Serialize complete at 02/13/2002 12:40:46 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> And how about replace: >> >> If FALSE, then no two events may conflict >> >> With: >> If FALSE, then no two components or their expanded >> instances can share the same time or overlap the same >> time periods. > >Is this not implied by "no two events may conflict"? Only if you know what "conflict" means. The latter text defines it. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |This is the .sig that says... Ni! | \========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 12:52:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15387 for ; Wed, 13 Feb 2002 12:52:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DHaSp25808 for ietf-calendar-bks; Wed, 13 Feb 2002 09:36:28 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DHaR325804 for ; Wed, 13 Feb 2002 09:36:27 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP open issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 12:44:17 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 12:44:30 PM, Serialize complete at 02/13/2002 12:44:30 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >And you can't read them if you don't know >the charset. Oh--duh. OK, then. I wish the charset names had some sort of "is ASCII-compatible" notation. Then we could mandate that the CS MUST accept all ASCII-compatible charsets (since iCalendar's syntax is expressed in ASCII, and can just treat high-bit octets as opaque content). As it is, though, there'd be no way for a CS to know that an incoming message was ASCII-compatible. I suppose we could define an "charset-is-ASCII-compatible" parameter for the Content-type. Kind of icky, though. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |This is the .sig that says... Ni! | \========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 13:22:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16141 for ; Wed, 13 Feb 2002 13:22:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DI8oC26658 for ietf-calendar-bks; Wed, 13 Feb 2002 10:08:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DI8m326654 for ; Wed, 13 Feb 2002 10:08:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA04663 for ; Wed, 13 Feb 2002 10:08:49 -0800 (PST) Message-ID: <3C6AABAD.4C45282A@Royer.com> Date: Wed, 13 Feb 2002 11:08:45 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: CAP open issues References: <3C699404.DAF9AE4A@steltor.com> <3C69ABF9.5F2A14F4@Royer.com> <3C6A941A.61A2BC79@steltor.com> Content-Type: multipart/mixed; boundary="------------7C2C56D348D882DD9D3B8A59" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7C2C56D348D882DD9D3B8A59 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > Doug Royer wrote: > > > > George Babics wrote: > > > [snip] > > > I would opt for DEFAULT-LOCALE. It's not LANGUAGE, its the locale. > > or maybe LOCALE. > > > And making the BEEP 'localize' attribute sent in the BEEP greeting RPY > > a MUST in the CAP greeting so CUA can select the locale for > > any CS error messages. > > >From an earlier post that I made: > > On second thought, I am not sure if we should use > LOCALE. RFC 2277, "IETF Policy on Character Sets and Languages", > uses the POSIX definition of locale: > > The POSIX standard [POSIX] defines a concept called a "locale", which > includes a lot of information about collating order for sorting, date > format, currency format and so on. > > I do not think this is what we want to mean by LOCALE. I thought that fr_CA is a locale, and depending on if you apply in in your POSIX program (On my system the POSIX 'LC' values are set to): LANG=en_US LC_CTYPE="en_US" Character classification and case conversion. LC_NUMERIC="en_US" Non-monetary numeric formats. LC_TIME="en_US" Date and time formats. LC_COLLATE="en_US" Collation order. LC_MONETARY="en_US" Monetary formats. LC_MESSAGES="en_US" Formats of informative and diagnostic messages and interactive responses. LC_ALL="en_US" A CS would ignore LC_TIME for DATE, TIME, and DATE-TIME property values. But a locale aware CS could be smart about error messages, time and data 'messages', and so on. So if we return the 'locale' then an application program can decide which or how the POSIX locale issues to apply to the command. [the terms 'full' and 'partial' I made up here because I did not know what to call them] The full locale could be (per 2277): en_US.iso-8859-1 I think that CAP needs to use SHOULD and encourage implementations to return the full locale as first choice, partial locale (no charset) as a second choice, just the language as a third choice and per 2277 if not defined, the default locale is 'POSIX' (aka 'C' or english). BEEP 'localize' only supports the partial locale ("en_US" and no charset) as the charset would be in the MIME header for the data. As I have pointed out in a separate email, I think we do need to specify the partial locale at least so that when the CS sorts strings it can set LC_COLLATE to the supplied (or calendar default) locale for that query and the CU sees the results sorted in a way that makes sense to the CU. So I propose: We use LOCALE as defined in 2277 and encourage implementations to supply as much of the locale information as available for the CU to get the desired result. Any CUA or CS that does not fully support locales simply does not return them in the 'localize' attribute of the BEEP greeting reply. And a CUA can only expect a CS to support a locale if it is supplied in the 'localize' attribute. (and per 2277 - if we have not yet) The default and minimum locale is POSIX if not supplied in the UTF-8 charset as defined in RFC-2277. > The concept of language in RFC 2277 seems to fit what we want > this property to mean. > > Given all this, how about using DEFAULT-LANGUAGE? > > But then, BEEP seems to use the "localize" attribute means language, > so perhaps LOCALE is OK? The BEEP localize is a RFC-3066 value which seems to be a partial locale - and does not include charset. > What is our DEFAULT-LOCALE supposed to mean? Default language" > Default language and some other localized settings? I think it had existed for one reason - to allow the CS to localize the error messages. I would like to also use it for LC_COLLATE when the CS sorts by strings. And I really don't care if we call it 'FOO' as long as the definition is clear. --------------7C2C56D348D882DD9D3B8A59 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 ; Wed, 13 Feb 2002 13:24:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DICpE26924 for ietf-calendar-bks; Wed, 13 Feb 2002 10:12:51 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DICn326919 for ; Wed, 13 Feb 2002 10:12:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA04676 for ; Wed, 13 Feb 2002 10:12:50 -0800 (PST) Message-ID: <3C6AAC9E.FAA3BBB1@Royer.com> Date: Wed, 13 Feb 2002 11:12:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> <3C69AE2A.43C4FEEB@Royer.com> <3C6A95DB.A3E61921@steltor.com> Content-Type: multipart/mixed; boundary="------------322874C00B2FAF002F4419FE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------322874C00B2FAF002F4419FE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > Doug Royer wrote: > > > > And how about replace: > > > > If FALSE, then no two events may conflict > > > > With: > > If FALSE, then no two components or their expanded > > instances can share the same time or overlap the same > > time periods. > > Is this not implied by "no two events may conflict"? Two points: (1) 'events' implied VEVENT to me. (2) I just was not clear from reading the text if it meant expanded or not. (You and I know what it means, but it did not say that). --------------322874C00B2FAF002F4419FE 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 ; Wed, 13 Feb 2002 13:27:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DIINK27142 for ietf-calendar-bks; Wed, 13 Feb 2002 10:18:23 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DIIM327138 for ; Wed, 13 Feb 2002 10:18:22 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA04698 for ; Wed, 13 Feb 2002 10:18:22 -0800 (PST) Message-ID: <3C6AADEA.A27F533A@Royer.com> Date: Wed, 13 Feb 2002 11:18:18 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Default Access Rights Component Property References: <3C699404.DAF9AE4A@steltor.com> <3C69B669.785A1060@Royer.com> <3C6A9A92.E0CAD17A@steltor.com> Content-Type: multipart/mixed; boundary="------------C7145F2BD4CD462D23F04719" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C7145F2BD4CD462D23F04719 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > > > Format Definition: The property is defined by the following notation: > > > > > > def-vcars = "DEFAULT-VCARS" def-vcarsparam ":" text > > > *( "," text ) CRLF > > > > > > def-vcarsparam = *( ";" xparam ) > > > > > > Example: The following is an example of this property: > > > > > > DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY > > > DEFAULT-VCARS:UPDATEPARTSTATUS,DEFAULTOWNER > > > > Add something like: > > > > DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY > > ,UPDATEPARTSTATUS,DEFAULTOWNER,"My Private CARID" > > It can be: > > DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY > ,UPDATEPARTSTATUS,DEFAULTOWNER,My Private CARID As can: DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY ,UPDATEPARTSTATUS,DEFAULTOWNER,"My,Private CARID" It is not my intent to encourage a comma in a value. But between iCalendar, iTIP, iMIP and CAP; there does not seem to be many examples that show how multi-valued data can sometimes contain commas, escaped characters, or even includes the '\n' in a value. For example, from the CAP text as it exists, this is a valid CARID: CARID:"This, is a \n two line CARID" --------------C7145F2BD4CD462D23F04719 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 ; Wed, 13 Feb 2002 13:34:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DILF527224 for ietf-calendar-bks; Wed, 13 Feb 2002 10:21:15 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DILE327219 for ; Wed, 13 Feb 2002 10:21:14 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA04704 for ; Wed, 13 Feb 2002 10:21:14 -0800 (PST) Message-ID: <3C6AAE96.5B52E56B@Royer.com> Date: Wed, 13 Feb 2002 11:21:10 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> <3C69B89B.BB990DD3@Royer.com> <3C6A9DAD.11528DA1@steltor.com> Content-Type: multipart/mixed; boundary="------------03192D718F53558CBDF60EAD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------03192D718F53558CBDF60EAD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > Doug Royer wrote: > > > > George Babics wrote: > > > > > > > > x.x.2.2 Calendar Store Component > > > > > related / iana-token / x-prop > > > > Add: > > > > vcar > > Why? That is where the DEFAULT-VCARS are stored. In the CALSTORE - correct? --------------03192D718F53558CBDF60EAD 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 ; Wed, 13 Feb 2002 13:55:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DIhGC27752 for ietf-calendar-bks; Wed, 13 Feb 2002 10:43:16 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DIhF327748 for ; Wed, 13 Feb 2002 10:43:15 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA04736 for ; Wed, 13 Feb 2002 10:43:15 -0800 (PST) Message-ID: <3C6AB3BF.CB5ADBDB@Royer.com> Date: Wed, 13 Feb 2002 11:43:11 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VQUERY new MATCH operator References: <3C6A87B4.2C2D9CA8@steltor.com> Content-Type: multipart/mixed; boundary="------------269D60A5FD575E73CAB8CC17" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------269D60A5FD575E73CAB8CC17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > I would like to introduce a new MATCH operator such that: > > BEGIN:VQUERY > QUERYNAME:Query-01 > QUERY:SELECT * FROM VCAR > USING_PROPERTIES GRANT oneGrant > WHERE 'bernard@steltor.com' MATCH oneGrant > END:VQUERY Can't we just add another VQUERY note like his: (x) When the CAL-QUERY WHERE clause compares a literal UPN to a property that may contain wildcard UPN values, the CS MUST return any wildcard matches that would expandable into the literal UPN supplied. Example (and I'll fill them more in in the real proposal): BEGIN:VCAR CARID:wildcard-1 ... GRANT:* ... END:VCAR BEGIN:VCAR CARID:literal-1 ... GRANT:a-user@realm ... END:VCAR So that the following QUERY returns 'wildcard-1' and 'literal-1': QUERY:SELECT * FROM VCAR WHERE GRANT = 'a-user@realm' --------------269D60A5FD575E73CAB8CC17 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 ; Wed, 13 Feb 2002 14:35:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DJOss28813 for ietf-calendar-bks; Wed, 13 Feb 2002 11:24:54 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJOr328809 for ; Wed, 13 Feb 2002 11:24:53 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA13122 for ; Wed, 13 Feb 2002 14:24:50 -0500 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 g1DJOnQ17528 for ; Wed, 13 Feb 2002 14:24:49 -0500 (EST) Message-ID: <3C6ABDF6.8EF2CE4D@steltor.com> Date: Wed, 13 Feb 2002 14:26:46 -0500 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: CAP: VQUERY new MATCH operator References: <3C6A87B4.2C2D9CA8@steltor.com> <3C6AB3BF.CB5ADBDB@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: > > > I would like to introduce a new MATCH operator such that: > > > > BEGIN:VQUERY > > QUERYNAME:Query-01 > > QUERY:SELECT * FROM VCAR > > USING_PROPERTIES GRANT oneGrant > > WHERE 'bernard@steltor.com' MATCH oneGrant > > END:VQUERY > > Can't we just add another VQUERY note like his: > > (x) When the CAL-QUERY WHERE clause compares a literal > UPN to a property that may contain wildcard UPN values, > the CS MUST return any wildcard matches that would > expandable into the literal UPN supplied. > > Example (and I'll fill them more in in the real proposal): > > BEGIN:VCAR > CARID:wildcard-1 > ... > GRANT:* > ... > END:VCAR > > BEGIN:VCAR > CARID:literal-1 > ... > GRANT:a-user@realm > ... > END:VCAR > > So that the following QUERY returns 'wildcard-1' and > 'literal-1': > > QUERY:SELECT * FROM VCAR WHERE GRANT = 'a-user@realm' But then I wouldn't have a way of only getting the VCAR VCAR component with "GRANT:a-user@realm" explicitly set. Regards, 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 Wed Feb 13 14:45:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18807 for ; Wed, 13 Feb 2002 14:45:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DJWQf29050 for ietf-calendar-bks; Wed, 13 Feb 2002 11:32:26 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJWP329046 for ; Wed, 13 Feb 2002 11:32:25 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA04812 for ; Wed, 13 Feb 2002 11:32:26 -0800 (PST) Message-ID: <3C6ABF45.B030B1CF@Royer.com> Date: Wed, 13 Feb 2002 12:32:21 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Consensus? CALMASTER - stays a MAILTO uri Content-Type: multipart/mixed; boundary="------------220A1BCB1DA0DC6A75DD068B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------220A1BCB1DA0DC6A75DD068B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Someone proposed in the past that CALMASTER allow more than an MAILTO: URI. I think that the replies send indicate that it is a contact address and a MAILTO uri makes more sense. Agree? --------------220A1BCB1DA0DC6A75DD068B 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 ; Wed, 13 Feb 2002 14:46:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DJaM429156 for ietf-calendar-bks; Wed, 13 Feb 2002 11:36:22 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJaL329152 for ; Wed, 13 Feb 2002 11:36:21 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA04817 for ; Wed, 13 Feb 2002 11:36:22 -0800 (PST) Message-ID: <3C6AC031.250159FF@Royer.com> Date: Wed, 13 Feb 2002 12:36:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Consensus? Default TRANSP for CAP is allow overlapped Content-Type: multipart/mixed; boundary="------------FC6F564D5C63A4CAC83C6878" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FC6F564D5C63A4CAC83C6878 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Some email that was sent raised the issue about the default for this property. The issue died without a specific proposal. CAP currently has the following defaut and I think there is consensus to keep this as tthe default. ALLOW-CONFLICT N BOOLEAN This boolean value indicates Whether or not the calendar supports event conflicts. That is, whether or not any of the events in the calendar can overlap. If not specified the default value is TRUE meaning that conflicts are allowed. --------------FC6F564D5C63A4CAC83C6878 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 ; Wed, 13 Feb 2002 14:58:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DJmxq29566 for ietf-calendar-bks; Wed, 13 Feb 2002 11:48:59 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJmw329562 for ; Wed, 13 Feb 2002 11:48:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA04826 for ; Wed, 13 Feb 2002 11:48:59 -0800 (PST) Message-ID: <3C6AC326.901DA58F@Royer.com> Date: Wed, 13 Feb 2002 12:48:54 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: consensus? REL-CALID is 7/8 bit & NOT globally unique. Content-Type: multipart/mixed; boundary="------------76FD22F97B83AF7E3BD57EF0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------76FD22F97B83AF7E3BD57EF0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think we have consensus and I think it was a error in cap to say that the relative CALID is globally unique. And I think we have consensus that we need to remove the 7-bit restriction from their values. Now (In 1.3): Relative Calendar Identifier (Relative CalID) An identifier for an individual calendar in a calendar store. It is unique within a calendar store. It is recommended to be globally unique. A Relative CalID consists of the portion of the "scheme part" of a Qualified CalID following the Calendar Store Identifier. This is the same as the "URL path" of the "Common Internet Scheme Syntax" portion of a URL, as defined by [URL]. Propose remove "It is recommended to be globally unique.": So that it says: Relative Calendar Identifier (Relative CalID) An identifier for an individual calendar in a calendar store. It is unique within a calendar store. A Relative CalID consists of the portion of the "scheme part" of a Qualified CalID following the Calendar Store Identifier. This is the same as the "URL path" of the "Common Internet Scheme Syntax" portion of a URL, as defined by[URL]. Now (In 2.6 Calendar Addresses): is an identifier that uniquely identifies the calendar on a particular calendar store. There is no implied structure in a Relative CALID. It is an arbitrary string of printable 7 bit ASCII characters. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store. It is recommended that the Relative CALID be globally unique. Propose remove these two sentences: "It is recommended that the Relative CALID be globally unique." "It is an arbitrary string of printable 7 bit ASCII characters. " So that it reads: is an identifier that uniquely identifies the calendar on a particular calendar store. There is no implied structure in a Relative CALID. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store. And MUST BE a valid "URL path". It is recommended that implementations allow for 8-bit Relative CALIDs in readiness for when URLs can be 8-bit. --------------76FD22F97B83AF7E3BD57EF0 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 ; Wed, 13 Feb 2002 15:06:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DJr2k29723 for ietf-calendar-bks; Wed, 13 Feb 2002 11:53:02 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJr1329718 for ; Wed, 13 Feb 2002 11:53:01 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA04832 for ; Wed, 13 Feb 2002 11:53:02 -0800 (PST) Message-ID: <3C6AC419.7A9C1A3D@Royer.com> Date: Wed, 13 Feb 2002 12:52:57 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: REL-CALID as UTF-8 or just 8-bit clean? Content-Type: multipart/mixed; boundary="------------0ED8496D18C5D059BBCDD715" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0ED8496D18C5D059BBCDD715 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George send out a list of items that must be done for last call. One of them was : "What should the format be for relcalid? Should it be utf8? " No. Not UTF-8, but 8-bit clean. Then whatever the URL working group decides is an valid 8-bit URL, we can work with that and it will not effect CAP. For example, I'll use memcmp() and not strcmp() when comparing those values. --------------0ED8496D18C5D059BBCDD715 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 ; Wed, 13 Feb 2002 15:11:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DJxHS29927 for ietf-calendar-bks; Wed, 13 Feb 2002 11:59:17 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJxF329922 for ; Wed, 13 Feb 2002 11:59:15 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: VQUERY new MATCH operator MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 15:07:06 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 03:07:19 PM, Serialize complete at 02/13/2002 03:07:19 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >But then I wouldn't have a way of only getting the VCAR >VCAR component with "GRANT:a-user@realm" explicitly set. OK, so when would that be useful? /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Life is like a metaphor. | \========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 15:12:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19533 for ; Wed, 13 Feb 2002 15:12:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DK2xi00152 for ietf-calendar-bks; Wed, 13 Feb 2002 12:02:59 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DK2w300148 for ; Wed, 13 Feb 2002 12:02:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA04852 for ; Wed, 13 Feb 2002 12:02:59 -0800 (PST) Message-ID: <3C6AC66E.55A9A18D@Royer.com> Date: Wed, 13 Feb 2002 13:02:54 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CHILD/PARENT vs RELATED-TO Content-Type: multipart/mixed; boundary="------------4FDD1DFD844455D4C31874C5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4FDD1DFD844455D4C31874C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Georges issues list is: "Use of RELATED-TO Property to express relationships between calendars. See thread: "RELATED-TO vs CHILD/PARENT." I would like to propose text like the following be added. When a calendar is deleted, the CS MUST delete any other RELATED-TO properties in the CS or any other calendar that have a RELATED-TO value of that deleted calendar. This allows those properties to be changed without the UPN that deleted the calendar from needing access to any other CS calendar and to allow them not to need to have MODIFY or DELETE permissions to those effected calendars RELATED-TO property. --------------4FDD1DFD844455D4C31874C5 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 ; Wed, 13 Feb 2002 15:15:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DK4s800229 for ietf-calendar-bks; Wed, 13 Feb 2002 12:04:54 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DK4r300225 for ; Wed, 13 Feb 2002 12:04:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA04866 for ; Wed, 13 Feb 2002 12:04:54 -0800 (PST) Message-ID: <3C6AC6E1.79635638@Royer.com> Date: Wed, 13 Feb 2002 13:04:49 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VQUERY new MATCH operator References: <3C6A87B4.2C2D9CA8@steltor.com> <3C6AB3BF.CB5ADBDB@Royer.com> <3C6ABDF6.8EF2CE4D@steltor.com> Content-Type: multipart/mixed; boundary="------------4E35CF1B6940C83D18A5AE13" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4E35CF1B6940C83D18A5AE13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > So that the following QUERY returns 'wildcard-1' and > > 'literal-1': > > > > QUERY:SELECT * FROM VCAR WHERE GRANT = 'a-user@realm' > > But then I wouldn't have a way of only getting the VCAR > VCAR component with "GRANT:a-user@realm" explicitly set. > Okay then how about: It only does wildcard matches when EXPAND:TRUE. If EXPAND:FALSE, it only matches on the explicit value Agree? --------------4E35CF1B6940C83D18A5AE13 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 ; Wed, 13 Feb 2002 15:32:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DKNv600907 for ietf-calendar-bks; Wed, 13 Feb 2002 12:23:57 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DKNt300903 for ; Wed, 13 Feb 2002 12:23:55 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: Consensus? CALMASTER - stays a MAILTO uri MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 15:31:45 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 03:31:59 PM, Serialize complete at 02/13/2002 03:31:59 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I think that the replies send indicate that it is a contact >address and a MAILTO uri makes more sense. But mailto: is not the only URI scheme for contact addresses expressed. For example, IANA's registry lists tel:, sip:, and fax:. And, once the IM protocols (SIMPLE and APEX) reach Proposed Standard, there'll probably be URI schemes for IM addresses. In practice, even http: can function as a contact address, if the URL points to a page to send a message, or if it fetches a vCard. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Know your limits, then destroy 'em. | \========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 15:44:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20224 for ; Wed, 13 Feb 2002 15:44:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DKYUW01300 for ietf-calendar-bks; Wed, 13 Feb 2002 12:34:30 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DKYT301296 for ; Wed, 13 Feb 2002 12:34:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA04926 for ; Wed, 13 Feb 2002 12:34:30 -0800 (PST) Message-ID: <3C6ACDD1.5346640A@Royer.com> Date: Wed, 13 Feb 2002 13:34:25 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------62FFA61254B9ADEA4C92F767" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------62FFA61254B9ADEA4C92F767 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > > I'll add text like: > > > > If the CUA wishes to perform more than one simultaneous > > command to the CS, then the 'cmdid' attribute must be > > added to any commands in order for the CUA and the CS > > to uniquely identify which command is being referred to > > in the abort and continue commands. > > > > I don't think that cmdid needs be a MUST when several > commands are executed. > > If not provided then we have the following problems: > > (1) The CUA cannot "abort" the command (by sending a > message from another BEEP channel). > > (2) The CUA can't unambiguously determine which command > is referred by a "timeout" message. Your right, how about: If the CUA wishes to perform more than one simultaneous command to the CS, then the 'cmdid' attribute MUST BE added to any commands if the CUA wishes to be able to abort any command in process. This has to be done in order for the CUA and the CS to uniquely identify which command is being referred to in the abort and continue commands. If no 'cmdid' attribute is supplied by the CUA in the command, then the CUA will not be able to abort a command. > For the second, I would also leave it up the the CUA, > since it doesn't impact the server. But if others see this > as a problem, then we could simply add the restriction that > id MUST be provided iff action='ask'. But only if multiple commands are in progress, because the continue and about are issued on the same channel - agree? > > Plus I did forget some of the email, so I will also add: > > > > If it is supplied at all, it MUST be in the iCalendar > > object and also supplied in the command as an attribute. > > > > Since mapping between commands and the associated responces > is no longer handled by the cmdid, is there a real need to place > it in the iCalendar object as well? I would rephrase that to say that there was never any consensus to remove it from the object so that it can be uniquely defined in a iCalendar object as define by cap requirement - old debate. I think we compromised and said that it must be in both, I would like to see it only in the object. --------------62FFA61254B9ADEA4C92F767 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 ; Wed, 13 Feb 2002 15:50:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DKb3p01386 for ietf-calendar-bks; Wed, 13 Feb 2002 12:37:03 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DKb1301382 for ; Wed, 13 Feb 2002 12:37:02 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA15464 for ; Wed, 13 Feb 2002 15:36:59 -0500 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 g1DKawQ26955 for ; Wed, 13 Feb 2002 15:36:58 -0500 (EST) Subject: CAP: Security Considerations From: Patrice Lapierre To: "ietf-calendar@imc.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Feb 2002 15:44:21 -0500 Message-Id: <1013633061.8346.45.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 A Security Considerations section must be included in CAP. The following requirement was posted on the list: Doug wrote: > I do agree that we MUST mandate at least ONE minimum authentication > level that CS/BEEP MUST support. This was dictated to us by > the area directors years ago The following proposition is based on Marshall T. Rose suggestion: see: http://www.imc.org/ietf-calendar/mail-archive/msg03765.html -------------- Section X.0 Security Considerations. Consult Section 2.4.2 for a discussion of access rights. In addition, since CAP is a profile of the BEEP, consult [BEEP]'s Section 9 for a discussion of BEEP-specific security issues. Although service provisioning is a policy matter, at a minimum, all implementations must provide the following tuning profiles: for authentication: http://iana.org/beep/SASL/DIGEST-MD5 for confidentiality: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates) -------------- Questions: - Do we want to specify a minimal encryption for CAP? If not then we should remove the last two statements. - Is DIGEST-MD5 the authentication mechanism we want to include? -- Patrice. From owner-ietf-calendar@mail.imc.org Wed Feb 13 15:54:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20458 for ; Wed, 13 Feb 2002 15:54:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DKjrQ01662 for ietf-calendar-bks; Wed, 13 Feb 2002 12:45:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DKjq301658 for ; Wed, 13 Feb 2002 12:45:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA15772 for ; Wed, 13 Feb 2002 15:45:49 -0500 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 g1DKjmQ28255 for ; Wed, 13 Feb 2002 15:45:48 -0500 (EST) Message-ID: <3C6AD0F2.6A0A2C42@steltor.com> Date: Wed, 13 Feb 2002 15:47:46 -0500 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: CAP: VQUERY new MATCH operator 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: > > >But then I wouldn't have a way of only getting the VCAR > >VCAR component with "GRANT:a-user@realm" explicitly set. > > OK, so when would that be useful? It would be useful to users and administrators to troubleshoot problems with VCAR components (e.g., why user X can do this while user Y can't?). Regards, 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 Wed Feb 13 16:00:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20590 for ; Wed, 13 Feb 2002 16:00:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DKnGs01767 for ietf-calendar-bks; Wed, 13 Feb 2002 12:49:16 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DKnD301762 for ; Wed, 13 Feb 2002 12:49:13 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA15825 for ; Wed, 13 Feb 2002 15:49:10 -0500 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 g1DKn9Q28416 for ; Wed, 13 Feb 2002 15:49:09 -0500 (EST) Subject: CAP: RELATED-TO property in VAGENDA. From: Patrice Lapierre To: "ietf-calendar@imc.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Feb 2002 15:56:32 -0500 Message-Id: <1013633792.8346.59.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 This mail summarizes the suggested changes yielded by the removal of calendar hierarchies and the introduction of the RELATED-TO property in VAGENDA. 1) Section 1.3 In definition of Calendar, replace the sentence: In addition, a calendar might be hierarchically related to other sub-calendars. with: In addition, a calendar might be related to other calendars by using the RELATED-TO calendar property. see: http://www.imc.org/ietf-calendar/mail-archive/msg02776.html 2) Section 1.3 Remove definition of Hierarchical Calendars, and add: Related Calendars A CS feature where a calendar may have relationships to other calendars. Relationships are specified in the calendar with the RELATED-TO calendar property. The relationships have no predefined meaning to CAP. They are a convenience for the CUA, CU, or CS administrator so that calendars may be organized and marked as relating to each other as specified in the implementation or administrative configuration of the CS or CUA. Any CUA with sufficient access permission may view these RELATED-TO properties. see: http://www.imc.org/ietf-calendar/mail-archive/msg02779.html 3) Section 1.3 Remove the definition of "Sub-calendars". see: http://www.imc.org/ietf-calendar/mail-archive/msg02781.html 4) Section 2.2 Calendar Store Object Model. Remove VAGENDAs nested in VAGENDA. see: http://www.imc.org/ietf-calendar/mail-archive/msg03000.html 5) Remove Section 2.4.3 Inheritance 6) Remove Section 5.1 VCAR Inheritance 7) Section 6.2.4.4 "move" Command In the section: The "move" command is used to move components within the CS's hierarchy of calendars. The access control on the VAGENDA after it has been moved to its new location in the calstore hierarchy MUST be at least as secure as it was prior to the move. One way to accomplish this is to build a list of VCARs that apply to the VAGENDA in its old hierarchy and and write them into the VAGENDA before moving it to its new location. Without VCAR inheritance, the comments about access control doesn't seem to be relevant anymore. The paragraph could probably be rewritten as: The "move" command is used to move components within the CS's containers (VCALSTORE or VAGENDAs). 8) Changes to section 10 (Properties), were already posted by George. see: http://www.imc.org/ietf-calendar/mail-archive/msg04246.html -- Patrice From owner-ietf-calendar@mail.imc.org Wed Feb 13 16:13:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20864 for ; Wed, 13 Feb 2002 16:13:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DKtuM01963 for ietf-calendar-bks; Wed, 13 Feb 2002 12:55:56 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DKtt301959 for ; Wed, 13 Feb 2002 12:55:55 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA04980 for ; Wed, 13 Feb 2002 12:55:56 -0800 (PST) Message-ID: <3C6AD2D6.A24488DA@Royer.com> Date: Wed, 13 Feb 2002 13:55:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Consensus? CALMASTER - stays a MAILTO uri References: Content-Type: multipart/mixed; boundary="------------B49D36BEA0D5EE1788138676" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B49D36BEA0D5EE1788138676 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >I think that the replies send indicate that it is a contact > >address and a MAILTO uri makes more sense. > > But mailto: is not the only URI scheme for contact addresses expressed. > For example, IANA's registry lists tel:, sip:, and fax:. And, once the IM > protocols (SIMPLE and APEX) reach Proposed Standard, there'll probably be > URI schemes for IM addresses. > > In practice, even http: can function as a contact address, if the URL > points to a page to send a message, or if it fetches a vCard. True, but how to I send a problem to an http: address? I would prefer something that can be programed into a computer and not have to manually look at a web page in order to find the contact data - if supplied at all on that web page. Would you give out your IM address or your email address to someone with an issue? And we can't use IM because it is not out yet. Perhaps we can loosen it up some in the text by changing it to something like: Is: -------------------------------------------------------------- CALMASTER N URI The e-mail address for a responsible person. MUST be a mailto URL. Propose: -------------------------------------------------------------- CALMASTER N URI The e-mail address for a responsible person. Only mailto URL is currently supported. --------------B49D36BEA0D5EE1788138676 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 ; Wed, 13 Feb 2002 16:19:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DKxU002056 for ietf-calendar-bks; Wed, 13 Feb 2002 12:59:30 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DKxT302052 for ; Wed, 13 Feb 2002 12:59:29 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA16203 for ; Wed, 13 Feb 2002 15:59:26 -0500 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 g1DKxPQ00097 for ; Wed, 13 Feb 2002 15:59:25 -0500 (EST) Message-ID: <3C6AD423.9C4651BD@steltor.com> Date: Wed, 13 Feb 2002 16:01:23 -0500 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: CAP: VQUERY new MATCH operator References: <3C6A87B4.2C2D9CA8@steltor.com> <3C6AB3BF.CB5ADBDB@Royer.com> <3C6ABDF6.8EF2CE4D@steltor.com> <3C6AC6E1.79635638@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: > > > > > > > So that the following QUERY returns 'wildcard-1' and > > > 'literal-1': > > > > > > QUERY:SELECT * FROM VCAR WHERE GRANT = 'a-user@realm' > > > > But then I wouldn't have a way of only getting the VCAR > > VCAR component with "GRANT:a-user@realm" explicitly set. > > > > Okay then how about: > > It only does wildcard matches when EXPAND:TRUE. > If EXPAND:FALSE, it only matches on the explicit value There are multiple reasons for not doing that: 1- Everything that influence the selection mechanism should be specified within the CAL-QUERY value (i.e., not as an additional property in the VQUERY component) such that VCAR components may also use them. 2- It may be acceptable (although arguable) for the EXPAND property to influence the format of the objects returned by the command, but it should not at the same time influence the selection mechanism per say. Those need to be specified separately. 3- We already have a proposal that specifies how EXPAND should influence the format of the VCAR being returned. Again, EXPAND should not at the same time influence which VCAR objects are selected AND in which format they should be returned. Regards, 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 Wed Feb 13 16:24:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21546 for ; Wed, 13 Feb 2002 16:24:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DL6S002277 for ietf-calendar-bks; Wed, 13 Feb 2002 13:06:28 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DL6R302272 for ; Wed, 13 Feb 2002 13:06:27 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA16511 for ; Wed, 13 Feb 2002 16:06:25 -0500 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 g1DL6NQ01024 for ; Wed, 13 Feb 2002 16:06:24 -0500 (EST) Message-ID: <3C6AD5C5.25ADF534@steltor.com> Date: Wed, 13 Feb 2002 16:08:21 -0500 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: CHILD/PARENT vs RELATED-TO References: <3C6AC66E.55A9A18D@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: > > On Georges issues list is: > > "Use of RELATED-TO Property to express relationships > between calendars. See thread: "RELATED-TO vs > CHILD/PARENT." > > I would like to propose text like the following be added. > > When a calendar is deleted, the CS MUST delete any other > RELATED-TO properties in the CS or any other calendar that > have a RELATED-TO value of that deleted calendar. > > This allows those properties to be changed without the UPN that > deleted the calendar from needing access to any other > CS calendar and to allow them not to need to have MODIFY > or DELETE permissions to those effected calendars > RELATED-TO property. I disagree. If the UPN is not granted the right to modify the RELATED-TO property of the other VAGENDA components, then most likely these properties were not set by him to start with. Thus, these properties should not be deleted by him (or by the CS on his behalf). It was agreed that the RELATED-TO property shall be maintained by the CUA and it shall stay that way. Regards, 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 Wed Feb 13 16:33:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21974 for ; Wed, 13 Feb 2002 16:33:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DLBZS02458 for ietf-calendar-bks; Wed, 13 Feb 2002 13:11:35 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DLBY302454 for ; Wed, 13 Feb 2002 13:11:34 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA05020 for ; Wed, 13 Feb 2002 13:11:36 -0800 (PST) Message-ID: <3C6AD682.2A4794B4@Royer.com> Date: Wed, 13 Feb 2002 14:11:30 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VQUERY new MATCH operator References: <3C6AD0F2.6A0A2C42@steltor.com> Content-Type: multipart/mixed; boundary="------------1503AEBCEF2C18019F741914" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1503AEBCEF2C18019F741914 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > John Stracke wrote: > > > > >But then I wouldn't have a way of only getting the VCAR > > >VCAR component with "GRANT:a-user@realm" explicitly set. > > > > OK, so when would that be useful? > > It would be useful to users and administrators to > troubleshoot problems with VCAR components (e.g., > why user X can do this while user Y can't?). Administration - out of scope :-) --------------1503AEBCEF2C18019F741914 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 ; Wed, 13 Feb 2002 16:33:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DLBv202477 for ietf-calendar-bks; Wed, 13 Feb 2002 13:11:57 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DLBu302473 for ; Wed, 13 Feb 2002 13:11:56 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Security Considerations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 16:19:45 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 04:20:00 PM, Serialize complete at 02/13/2002 04:20:00 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >- Do we want to specify a minimal encryption for CAP? Probably--otherwise, we wind up with clients that can't talk TLS to servers from other vendors. >- Is DIGEST-MD5 the authentication mechanism we want to > include? I'd think so. It's simple, and it doesn't send the password over the network. /==========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==========================================================| |"Where's your sense of adventure?" "Hiding under the bed."| \==========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 16:34:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22027 for ; Wed, 13 Feb 2002 16:34:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DL9Ub02386 for ietf-calendar-bks; Wed, 13 Feb 2002 13:09:30 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DL9T302382 for ; Wed, 13 Feb 2002 13:09:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA05007 for ; Wed, 13 Feb 2002 13:09:30 -0800 (PST) Message-ID: <3C6AD604.A0AE79AB@Royer.com> Date: Wed, 13 Feb 2002 14:09:24 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Security Considerations References: <1013633061.8346.45.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------CD6ED2451F9D2DB9ED5C6CA0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CD6ED2451F9D2DB9ED5C6CA0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > A Security Considerations section must be included in CAP. > > The following requirement was posted on the list: > > Doug wrote: > > I do agree that we MUST mandate at least ONE minimum authentication > > level that CS/BEEP MUST support. This was dictated to us by > > the area directors years ago > > The following proposition is based on Marshall T. Rose suggestion: > > see: http://www.imc.org/ietf-calendar/mail-archive/msg03765.html > > -------------- > > Section X.0 Security Considerations. > > Consult Section 2.4.2 for a discussion of access rights. > In addition, since CAP is a profile of the BEEP, consult > [BEEP]'s Section 9 for a discussion of BEEP-specific > security issues. > > Although service provisioning is a policy matter, at a minimum, all > implementations must provide the following tuning profiles: > > for authentication: http://iana.org/beep/SASL/DIGEST-MD5 > > for confidentiality: http://iana.org/beep/TLS (using the > TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) > > for both: http://iana.org/beep/TLS (using the > TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side > certificates) And what about VCAR and command security issues? - be careful of the GRANTs you give out ... - Use of the command ... - Anonymous login ... - ...more?... > -------------- > Questions: > > - Do we want to specify a minimal encryption for CAP? > If not then we should remove the last two statements. Yes! Otherwise any two or more implementations of TLS might not have the same encryption and that makes things break. > - Is DIGEST-MD5 the authentication mechanism we want to > include? I think so, that is what Paul had said in the past for maximum usability mixed with desired security. --------------CD6ED2451F9D2DB9ED5C6CA0 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 ; Wed, 13 Feb 2002 16:36:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DLEQ702564 for ietf-calendar-bks; Wed, 13 Feb 2002 13:14:26 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DLEO302560 for ; Wed, 13 Feb 2002 13:14:24 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: VQUERY new MATCH operator MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 16:22:14 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 04:22:29 PM, Serialize complete at 02/13/2002 04:22:29 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> >But then I wouldn't have a way of only getting the VCAR >> >VCAR component with "GRANT:a-user@realm" explicitly set. >> >> OK, so when would that be useful? > >It would be useful to users and administrators to >troubleshoot problems with VCAR components (e.g., >why user X can do this while user Y can't?). It would be a little useful, but it would hardly be necessary--you can ask for all the VCARs that apply to X, and filter out the ones you don't want. And adding a new operator to the query language is probably overkill for a rare case like this--how often are you going to be debugging your VCARs? /==========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==========================================================| |"Where's your sense of adventure?" "Hiding under the bed."| \==========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 16:54:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22344 for ; Wed, 13 Feb 2002 16:54:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DLckf03217 for ietf-calendar-bks; Wed, 13 Feb 2002 13:38:46 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DLci303213 for ; Wed, 13 Feb 2002 13:38:44 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: Consensus? CALMASTER - stays a MAILTO uri MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 16:46:34 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 04:46:49 PM, Serialize complete at 02/13/2002 04:46:49 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> In practice, even http: can function as a contact address, >True, but how to I send a problem to an http: address? The CUA can't, but the CU can. If the CS is installed in an enterprise that's invested in an intranet app for submitting and tracking help desk requests, they won't appreciate the CUA insisting on an email address. >Would you give out your IM address or your email address to >someone with an issue? Different companies have different processes for their help desks. A company that's installed an internal IM server might very well want to have an IM address for the support desk. >And we can't use IM because it is >not out yet. Red herring. We can't use it now, but we should make sure we can use it in the future. >CALMASTER N URI The e-mail address for a > responsible person. Only mailto > URL is currently supported. I would phrase it as, "A contact address for a responsible person. mailto: is recommended, so that a CUA can preformat a problem report for the calmaster; but a CUA MUST be able to accept any scheme, even if all it does is display the URI to the user". Another option would be to permit CALMASTER to be either a mailto: or a URL that points to a vCard; that would permit the CS to provide multiple contact addresses. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |If God had not given us duct tape, it would have been necessary| |to invent it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 16:55:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22369 for ; Wed, 13 Feb 2002 16:55:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DLfC103302 for ietf-calendar-bks; Wed, 13 Feb 2002 13:41:12 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DLfB303298 for ; Wed, 13 Feb 2002 13:41:11 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CHILD/PARENT vs RELATED-TO MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 13 Feb 2002 16:49:00 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/13/2002 04:49:15 PM, Serialize complete at 02/13/2002 04:49:15 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >If the UPN is not granted the right to modify the >RELATED-TO property of the other VAGENDA components, >then most likely these properties were not set by >him to start with. Thus, these properties should >not be deleted by him (or by the CS on his behalf). That doesn't automatically follow. The person who set those properties in the first place was trying to add useful information to the system. It is entirely reasonable for CAP to specify that the information should be deleted once it becomes useless. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |============================================================| |In the country of the blind, the one-eyed man is in therapy.| \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 13 17:50:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23397 for ; Wed, 13 Feb 2002 17:50:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DMamS04894 for ietf-calendar-bks; Wed, 13 Feb 2002 14:36:48 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DMak304889 for ; Wed, 13 Feb 2002 14:36:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA05168 for ; Wed, 13 Feb 2002 14:36:47 -0800 (PST) Message-ID: <3C6AEA79.40338990@Royer.com> Date: Wed, 13 Feb 2002 15:36:41 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CHILD/PARENT vs RELATED-TO References: <3C6AC66E.55A9A18D@Royer.com> <3C6AD5C5.25ADF534@steltor.com> Content-Type: multipart/mixed; boundary="------------219B9FD05E6C30215540DF52" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------219B9FD05E6C30215540DF52 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > On Georges issues list is: > > > > "Use of RELATED-TO Property to express relationships > > between calendars. See thread: "RELATED-TO vs > > CHILD/PARENT." > > > > I would like to propose text like the following be added. > > > > When a calendar is deleted, the CS MUST delete any other > > RELATED-TO properties in the CS or any other calendar that > > have a RELATED-TO value of that deleted calendar. > > > > This allows those properties to be changed without the UPN that > > deleted the calendar from needing access to any other > > CS calendar and to allow them not to need to have MODIFY > > or DELETE permissions to those effected calendars > > RELATED-TO property. > > I disagree. > > If the UPN is not granted the right to modify the > RELATED-TO property of the other VAGENDA components, > then most likely these properties were not set by > him to start with. Thus, these properties should > not be deleted by him (or by the CS on his behalf). And so how does the owner of that calendar get notified that the RELATED-TO is gone and that their calendar property is now bogus? When it was CHILD/PARENT the CS maintained that field at the CS level and now that is gone. > It was agreed that the RELATED-TO property shall be > maintained by the CUA and it shall stay that way. It was proposed :-) --------------219B9FD05E6C30215540DF52 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 ; Wed, 13 Feb 2002 18:17:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1DMxjA05503 for ietf-calendar-bks; Wed, 13 Feb 2002 14:59:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DMxi305499 for ; Wed, 13 Feb 2002 14:59:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA05211 for ; Wed, 13 Feb 2002 14:59:46 -0800 (PST) Message-ID: <3C6AEFDB.EBA6B615@Royer.com> Date: Wed, 13 Feb 2002 15:59:39 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: Consensus? BEEP commands Content-Type: multipart/mixed; boundary="------------A04EF580A513F078C7A3AA42" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A04EF580A513F078C7A3AA42 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Aside from the empty reply debate. I think we have consensus on my last proposal: (#2) Byte reduction in BEEP commands. So as it is going to change little bits all over CAP. I am going to not send out another copy of that proposal and I don't think I need to send the exact text. Just view: http://www.imc.org/ietf-calendar/mail-archive/msg04199.html So - if there are not objections, I'll add/tweak CAP to make those changes soon. --------------A04EF580A513F078C7A3AA42 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 ; Wed, 13 Feb 2002 19:32:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1E0HRO07579 for ietf-calendar-bks; Wed, 13 Feb 2002 16:17:27 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E0HQ307575 for ; Wed, 13 Feb 2002 16:17:26 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA05328 for ; Wed, 13 Feb 2002 16:17:28 -0800 (PST) Message-ID: <3C6B0210.87D1DC38@Royer.com> Date: Wed, 13 Feb 2002 17:17:20 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Proposal: METHOD REVIEWER changes Content-Type: multipart/mixed; boundary="------------036873505BF0F1D73211FF58" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------036873505BF0F1D73211FF58 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There were issues with the METHOD REVIEWER. The issue was that there was not a method to appeal when something was accepted. This is a proposal to add that text (marked with '+') and to delete text (marked with '-') to the existing text. 12.2.4 Submit the proposal for approval Once the two-week comment period has elapsed, and the proposer is convinced consensus has been reached on the proposal, the registration application should be submitted to the Method Reviewer for approval. The Method Reviewer is appointed by the Application Area Directors and can either accept or reject the proposal registration. An accepted registration should be passed on by the Method Reviewer to the IANA for inclusion in the official IANA method registry. The registration can be rejected for any of the following reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) Technical deficiencies raised on the list or elsewhere have not - been addressed. The Method Reviewers decision to reject a proposal - can be appealed by the proposer to the IESG, or the objections raised - can be addressed by the proposer and the proposal resubmitted. + been addressed. Decisions made by the reviewer may be + appealed to the IESG. --------------036873505BF0F1D73211FF58 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 ; Wed, 13 Feb 2002 22:46:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1E3SsV12284 for ietf-calendar-bks; Wed, 13 Feb 2002 19:28:54 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E3Sr312280 for ; Wed, 13 Feb 2002 19:28:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id TAA05504 for ; Wed, 13 Feb 2002 19:28:56 -0800 (PST) Message-ID: <3C6B2EEF.C265A11C@Royer.com> Date: Wed, 13 Feb 2002 20:28:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Delete section "4.1.3 Querying Experminental Properties" Content-Type: multipart/mixed; boundary="------------06125397B0E7F35427473852" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------06125397B0E7F35427473852 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I propose that the EMPTY section called: "4.1.3 Querying Experimental Properties" be deleted from CAP. CAP does not support any specific query methods for selecting experimental only properties. --------------06125397B0E7F35427473852 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 ; Thu, 14 Feb 2002 00:08:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1E4r8x14442 for ietf-calendar-bks; Wed, 13 Feb 2002 20:53:08 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E4r6314438 for ; Wed, 13 Feb 2002 20:53:06 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id UAA05539 for ; Wed, 13 Feb 2002 20:53:09 -0800 (PST) Message-ID: <3C6B42AC.6991FA0F@Royer.com> Date: Wed, 13 Feb 2002 21:53:00 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: (#1) CAP Synchronization proposal. Content-Type: multipart/mixed; boundary="------------D4CF6421636A249DA3F04020" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D4CF6421636A249DA3F04020 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Because of multiple questions raised on this list, the editors have decided that we need a "Synchronization" section in CAP. And because it is a in the CAP requirements document that a CUA be able to synchronize with a CS. Here is attempt (#1) at the text for that new section: ------------------------------------------------------------------------- X. "Synchronization between a CUA and CS" There are two major issues with synchronization (1), iTIP updates and dealing with out of order or missing iTIP components, and (2) updating booked entries. Synchronization is a two sided process. That is you need to update the CUA with any new object from the CS. And any new objects in the CUA may need to be deposited into the CS. Below the term "zombie object" will refer to any out of order ITIP object that is dead but does not yet know it. As in METHOD:CANCEL, UID:123, SEQUENCE:10 has been processed, and then you get METHOD:REQUEST, UID:123, SEQUENCE:9. So the second iTIP object is lurking around waiting to be reaped by the CUA. X.1 "iTIP and synchronization" There is no difference between the iMIP handling of iTIP objects and CAP handling of iTIP messages once the iTIP objects are in the CUA. So this section will describe some CS and CUA implementation considerations. Such as how to fetch iTIP objects from the CS, when to delete them from the CS, and when to leave them in the CS for later processing. This is not a tutorial on how to process iTIP objects. This is an outline of the problems that may be unique to an iTIP objects when a CUA is synchronizing with a CS. The section titled "Query for all Non-Booked Entries" shows examples of how to fetch for iTIP objects. It is recommended that the CUA fetch iTIP objects with EXPAND:FALSE in order to simplify the synchronization process. Fetching of all of the data booked, not booked, and marked for delete, SHOULD BE performed using one VQUERY to reduce the bandwidth by not having to keep sending commands to the CUA which can be expensive on slow networks.  The first step is to fetch all objects where the LAST-MODIFIED date is greater then the CUAs last synchronization date. The next step is to pull out any marked METHOD:CREATE (booked). These may be new or updated objects. Compare them to the METHOD:CREATE objects in the CUA with the same UID: If the CUA does not have that UID - add the new object. If the CUA does have that UID: compare the SEQUENCE values: If the object with the higher SEQUENCE value came from the CS drop the one in the CUA and have it use the new one from the CS. If the object with the higher SEQUENCE value is from the CUA, then the CUA must delete the older object from the CS and add the newer object to the CS. If the SEQUENCE numbers are the same then keep the one with the greater LAST-MODIFIED date. If the one with the older LAST-MODIFIED date is from the CS. Then that object must be deleted from the CS and it must be replaced with the newer one from the CUA. If the CUA has UIDs that have a LAST-MODIFIED time greater than the last synchronization time, and no object came back from the query with the same UID, then those new objects need to be added or updated in the CS. This will require a separate query to determine if they exist at all in the CS before deciding if they are new to the CS or need to be updated in the CS. Now examine the UIDs that you fetched for having METHOD:DELETE. The CUA should note the UID and its SEQUENCE value so that in later synchronization's the CUA can know that any out of order (zombie) iTIP objects can be deleted from the CS and otherwise ignored in the CUA. And drop these from the CUA and know to later delete them from the CS if the zombie objects later arrive. At this point the CUA has two choices: It can delete those METHOD:DELETE objects from the CS with command . Or it can keep them in the CS in case other CUAs will be synchronizing with that same calendar and will need to know that those UIDs should be deleted from the CUAs. It is up to the CUA or CU and the CS or CS administrator to decide when the METHOD:DELETE object are to be deleted from the CS. And this is not specified in CAP. Now start processing the iTIP object in the CUA just like you would as described in iTIP and iMIP. Then for each of those iTIP object that were processed, update the CS with the latest version of the object, followed by drop those processed iTIP objects from both the CUA and delete them from the CS. Any iTIP objects that can not be processed yet (example, a METHOD:COUNTER, UID:abc, SEQUENCE:1 when you have not yet have METHOD:REQUEST, UID:abc in the CUA or CS). These would be left in the CS until the CUA or CU and the CS or CS administrator decided that they were zombies or just too old to care about and then they would be deleted from the CS. And their LAST-MODIFIED time MUST BE updated in the CS so that they would continue to be fetched for the next synchronization until they were used or deleted. The CUA MUST update the LAST-MODIFIED times of any object that it updates or adds to the CS. This needs to be done by the CUA and not the CS in order for there not to be a race condition that is caused by the CUA object always being older than the same object in the CS. Some optimizations can be done. For example the CUA may just use and not followed by to update the CS. And many of the updates, deletes, and creates could be combined and processed at the end, or as they are determined, which ever works best for the implementations. --------------D4CF6421636A249DA3F04020 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 ; Thu, 14 Feb 2002 00:46:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1E5X0L15389 for ietf-calendar-bks; Wed, 13 Feb 2002 21:33:00 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E5Ww315384 for ; Wed, 13 Feb 2002 21:32:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id VAA05561 for ; Wed, 13 Feb 2002 21:33:01 -0800 (PST) Message-ID: <3C6B4C03.A4A286CD@Royer.com> Date: Wed, 13 Feb 2002 22:32:51 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: (#1) synchronization part 2, and identifying a components VALARM References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> <3BFEBEE2.2F736E3D@Royer.com> <3C221F20.D92B2355@steltor.com> <3C238743.61387D6F@Royer.com> Content-Type: multipart/mixed; boundary="------------22ECD02F128F400A66F89664" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------22ECD02F128F400A66F89664 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Outstanding CAP problems: How do you identify which VALARM is being modified in a component when the CUA wishes to a VALARM in an existing component and that components contains two or more VALARMs. (See UID vs ALARMID debate.) How do you tag VALARMS (or any component) as local so that when you do synchronization or new iTIP object arrive, the local VALARMS do not get tossed out because they were mistakenly seen as old data. How do you disable VALARMS that came in as part of a METHOD:REQUEST without deleting them. They can not be deleted because if the CUA wishes to send a METHOD:COUNTER, you need to include the entire object and only change or delete what you are proposing in the COUNTER to change or the ORGANIZER would assume that part of the COUNTER was to delete the VALARM. Proposal: (1) Add SEQUENCE as a MUST for VALARM in the CS that starts at zero (0). If the incoming object does not have any, then the CUA MUST add them before depositing them in the CS. This would make them unique per object and solve the MODIFY problem. The CUA would have to compare the contents of any updated iTIP objects that arrive without SEQUENCE to determine what changes have been made in order to synchronize and update the CS and CUA objects. (2) Create a new LOCAL parameter for the SEQUENCE property. The default value if not specified is 'false', and can be set to 'true'. Where 'true' means only visible to the calendar owners(s) and 'local' VALARMS MUST NOT be sent to non-calendar-owner(s) during queries. This would allow global (ORGANIZER originated VALARMs), and local (OWNER originated VALARMs) to have numbers starting at zero and not have to coordinate them between the OWNER and ORGANIZER. BEGIN:VALARM SEQUENCE:0 ... END:VALARM BEGIN:VALARM SEQUENCE;LOCAL=true:0 ... END:VALARM This would solve the synchronization problem by uniquely identifying the local VALARMS to the CS and CUA so local VALARMs do not get tossed when a higher SEQUENCE number arrives in an iTIP object. (3) Add a new ENABLE parameter to TRIGGER with a default value of 'true', and could be set to 'false'. If not specified it default to 'true'. And ENABLE is local to the calendar ONLY. That means the ORGANIZER MUST NOT set or specify ENABLE, and the CS MUST NOT export the ENABLE parameter to non-owners of the object during queries. This would allow local users to enable or disable both local and global VALARMS. ... BEGIN:VALARM SEQUENCE:2 TRIGGER;ENABLE=false:20020101T000000Z SUMMARY:NEW YEAR ... END:VALARM BEGIN:VALARM SEQUENCE;SCOPE=local:0 TRIGGER:20020101T000000 SUMMARY:NEW YEAR ... END:VALARM ... Now with this the ORGANIZER can modify VALARMS, and the local owner can decide the users preferences for TRIGGERS. I think this solves the MODIFY problem by uniquely identifying VALARMS in each object (by using SEQUENCE and LOCAL) and gives the local user control over VALARM TRIGGERs without breaking synchronization. --------------22ECD02F128F400A66F89664 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 ; Thu, 14 Feb 2002 00:54:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1E5h0N15602 for ietf-calendar-bks; Wed, 13 Feb 2002 21:43:00 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E5gx315598 for ; Wed, 13 Feb 2002 21:42:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id VAA05571 for ; Wed, 13 Feb 2002 21:43:02 -0800 (PST) Message-ID: <3C6B4E5C.27AE5DD9@Royer.com> Date: Wed, 13 Feb 2002 22:42:52 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Almost - text for VQUERY Content-Type: multipart/mixed; boundary="------------D661D4CE0AA5CF37CCF40552" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D661D4CE0AA5CF37CCF40552 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I was going to send out the new text for VQUERY tonight, however it needs more editing and I need more sleep. I can't remember if it was due by the 14th or on the 14th. I'll send it tomorrow afternoon (14th). There is nothing new and that has not been discussed on this list, but it needs to be re-written and the examples need to be updated and I am not yet done with that work. --------------D661D4CE0AA5CF37CCF40552 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 ; Thu, 14 Feb 2002 07:30:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1ECJhN27311 for ietf-calendar-bks; Thu, 14 Feb 2002 04:19:43 -0800 (PST) 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 g1ECJf327307 for ; Thu, 14 Feb 2002 04:19:42 -0800 (PST) Received: from jsoft.com (roo.jsoft.com [192.168.0.4]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g1ECIHj21216 for ; Thu, 14 Feb 2002 06:18:17 -0600 Message-ID: <3C6BAB57.4060704@jsoft.com> Date: Thu, 14 Feb 2002 06:19:35 -0600 From: Gary Frederick User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Security Considerations References: <1013633061.8346.45.camel@c-1241.in.steltor.com> <3C6AD604.A0AE79AB@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 Doug Royer wrote: >Patrice Lapierre wrote: > >>A Security Considerations section must be included in CAP. >> >>The following requirement was posted on the list: >> >>Doug wrote: >> >>>I do agree that we MUST mandate at least ONE minimum authentication >>>level that CS/BEEP MUST support. This was dictated to us by >>>the area directors years ago >>> Why? This prevents someone from implementing a small 'CAP' service. What if I have something in a secure area and don't need to authenticate? Then again, I can have something reasonably light weight and call it CAPLite and say it's not CAP. Mandating eliminates the need to have protocol and behavior to see what's on the other side. Gary From owner-ietf-calendar@mail.imc.org Thu Feb 14 08:33:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17573 for ; Thu, 14 Feb 2002 08:33:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EDN9k29415 for ietf-calendar-bks; Thu, 14 Feb 2002 05:23:09 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EDN7329408 for ; Thu, 14 Feb 2002 05:23:08 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id IAA24854 for ; Thu, 14 Feb 2002 08:23:03 -0500 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 g1EDN3Q23547 for ; Thu, 14 Feb 2002 08:23:03 -0500 (EST) Subject: Re: (#2) Byte reduction in BEEP commands. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C6ACDD1.5346640A@Royer.com> References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C6ACDD1.5346640A@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 08:30:24 -0500 Message-Id: <1013693424.8346.173.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 Wed, 2002-02-13 at 15:34, Doug Royer wrote: > Patrice Lapierre wrote: > > > > > > I'll add text like: > > > > > > If the CUA wishes to perform more than one simultaneous > > > command to the CS, then the 'cmdid' attribute must be > > > added to any commands in order for the CUA and the CS > > > to uniquely identify which command is being referred to > > > in the abort and continue commands. > > > > > > > I don't think that cmdid needs be a MUST when several > > commands are executed. > > > > If not provided then we have the following problems: > > > > (1) The CUA cannot "abort" the command (by sending a > > message from another BEEP channel). > > > > (2) The CUA can't unambiguously determine which command > > is referred by a "timeout" message. > > > Your right, how about: > > If the CUA wishes to perform more than one simultaneous > command to the CS, then the 'cmdid' attribute MUST BE > added to any commands if the CUA wishes to be able to > abort any command in process. This has to be done in order > for the CUA and the CS to uniquely identify which command > is being referred to in the abort and continue commands. > If no 'cmdid' attribute is supplied by the CUA in the command, > then the CUA will not be able to abort a command. > There are many ways a command can be aborted: (1) CUA sends an "abort" message at any moment from another channel. (2) CUA sends an "abort" RPY to a "timeout" MSG (when max lantency is exhausted). (3) Max latency is reached and action='abort' For (2), I agree. For (3), cmdid is not an issue, but your text seems correct since we can say that it's not the CUA that aborts the commmand. For (1), I think that the cmdid must always be present, even if only a single command is present. The motivation is that there might be delay before the CS processes the "abort" command. Without the "cmdid" the server will not be able to unambiguously determine which command to cancel (even if there is only one it could have been sent after the "abort"). > > For the second, I would also leave it up the the CUA, > > since it doesn't impact the server. But if others see this > > as a problem, then we could simply add the restriction that > > id MUST be provided iff action='ask'. > > But only if multiple commands are in progress, because the continue > and about are issued on the same channel - agree? Yes. > > > > Plus I did forget some of the email, so I will also add: > > > > > > If it is supplied at all, it MUST be in the iCalendar > > > object and also supplied in the command as an attribute. > > > > > > > Since mapping between commands and the associated responces > > is no longer handled by the cmdid, is there a real need to place > > it in the iCalendar object as well? > > I would rephrase that to say that there was never any consensus > to remove it from the object so that it can be uniquely defined > in a iCalendar object as define by cap requirement - old debate. > I think we compromised and said that it must be in both, I would > like to see it only in the object. Ok, good compromise. From owner-ietf-calendar@mail.imc.org Thu Feb 14 09:21:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18643 for ; Thu, 14 Feb 2002 09:21:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EE7am03051 for ietf-calendar-bks; Thu, 14 Feb 2002 06:07:36 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EE7Z303047 for ; Thu, 14 Feb 2002 06:07:35 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA25841 for ; Thu, 14 Feb 2002 09:07:30 -0500 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 g1EE7UQ28561 for ; Thu, 14 Feb 2002 09:07:30 -0500 (EST) Subject: Re: CAP: Security Considerations From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C6BAB57.4060704@jsoft.com> References: <1013633061.8346.45.camel@c-1241.in.steltor.com> <3C6AD604.A0AE79AB@Royer.com> <3C6BAB57.4060704@jsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 09:14:51 -0500 Message-Id: <1013696091.8346.218.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 Thu, 2002-02-14 at 07:19, Gary Frederick wrote: > > > Doug Royer wrote: > > >Patrice Lapierre wrote: > > > >>A Security Considerations section must be included in CAP. > >> > >>The following requirement was posted on the list: > >> > >>Doug wrote: > >> > >>>I do agree that we MUST mandate at least ONE minimum authentication > >>>level that CS/BEEP MUST support. This was dictated to us by > >>>the area directors years ago > >>> > Why? > I can't say, I wasn't there. > This prevents someone from implementing a small 'CAP' service. > > What if I have something in a secure area and don't need to authenticate? > > Then again, I can have something reasonably light weight and call it > CAPLite and say it's not CAP. Mandating eliminates the need to have > protocol and behavior to see what's on the other side. > CAP uses BEEP for authentication, therefore you could use another profile for authentication. And BEEP does provide a mean for a CUA to determine what authentication mechanisms are available on the other side. From owner-ietf-calendar@mail.imc.org Thu Feb 14 09:51:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23207 for ; Thu, 14 Feb 2002 09:51:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EEerZ04100 for ietf-calendar-bks; Thu, 14 Feb 2002 06:40:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEep304096 for ; Thu, 14 Feb 2002 06:40:51 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA27008; Thu, 14 Feb 2002 09:40:47 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EEekQ02765; Thu, 14 Feb 2002 09:40:46 -0500 (EST) Message-ID: <3C6BCC6E.B50E8A59@steltor.com> Date: Thu, 14 Feb 2002 09:40:46 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> <3C69AE2A.43C4FEEB@Royer.com> <3C6A95DB.A3E61921@steltor.com> <3C6AAC9E.FAA3BBB1@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: > > George Babics wrote: > > > > Doug Royer wrote: > > > > > > > And how about replace: > > > > > > If FALSE, then no two events may conflict > > > > > > With: > > > If FALSE, then no two components or their expanded > > > instances can share the same time or overlap the same > > > time periods. > > > > Is this not implied by "no two events may conflict"? > > Two points: > > (1) 'events' implied VEVENT to me. Do you mean that "Overlapped Booking" should apply to all types of components? I think that the definitions should apply to VEVENTs only and not to components as you had in your definition. We do not want VEVENTs conflicting with VTODOs. Nor do we want VTODOs conflicting with other VTODOs. > > (2) I just was not clear from reading the text if > it meant expanded or not. (You and I know what > it means, but it did not say that). I took the text as is from version 06 of CAP. If we need to explain that the components are expanded and what conflicts mean, we should do so at the beginning of the definition. The original definitions was: > Description: In a "VAGENDA", this property is used to indicate > whether events may conflict. If it has a value of TRUE, then > conflicts are allowed. If FALSE, the no two events may conflict. Then if we need to specify what conflicts mean and that the conflicts apply to expansions, we should say something like: Description: In a "VAGENDA", this property is used to indicate whether events may conflict. That is, if their expanded instances may share the same time or overlap the same time periods. If it has a value of TRUE, then conflicts are allowed. If FALSE, the no two events may conflict. George From owner-ietf-calendar@mail.imc.org Thu Feb 14 09:54:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23312 for ; Thu, 14 Feb 2002 09:54:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EEjBV04193 for ietf-calendar-bks; Thu, 14 Feb 2002 06:45:11 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEj9304189 for ; Thu, 14 Feb 2002 06:45:09 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Security Considerations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 09:52:51 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 09:53:15 AM, Serialize complete at 02/14/2002 09:53:15 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >What if I have something in a secure area and don't need to authenticate? Basic assumption of network security: there are no secure areas. If, by "secure area", you mean a military base, with a network protected by an air gap and men with guns, then you've answered your own question: someone who can afford physical security can afford to implement DIGEST-MD5. /========================================================\ |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 Thu Feb 14 10:02:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23621 for ; Thu, 14 Feb 2002 10:02:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EEmYO04251 for ietf-calendar-bks; Thu, 14 Feb 2002 06:48:34 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEmX304247 for ; Thu, 14 Feb 2002 06:48:33 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA27330 for ; Thu, 14 Feb 2002 09:48:29 -0500 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 g1EEmTQ03751 for ; Thu, 14 Feb 2002 09:48:29 -0500 (EST) Message-ID: <3C6BCEB3.2DBE5B42@steltor.com> Date: Thu, 14 Feb 2002 09:50:27 -0500 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: CHILD/PARENT vs RELATED-TO References: <3C6AC66E.55A9A18D@Royer.com> <3C6AD5C5.25ADF534@steltor.com> <3C6AEA79.40338990@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: > > > > Doug Royer wrote: > > > > > > On Georges issues list is: > > > > > > "Use of RELATED-TO Property to express relationships > > > between calendars. See thread: "RELATED-TO vs > > > CHILD/PARENT." > > > > > > I would like to propose text like the following be added. > > > > > > When a calendar is deleted, the CS MUST delete any other > > > RELATED-TO properties in the CS or any other calendar that > > > have a RELATED-TO value of that deleted calendar. > > > > > > This allows those properties to be changed without the UPN that > > > deleted the calendar from needing access to any other > > > CS calendar and to allow them not to need to have MODIFY > > > or DELETE permissions to those effected calendars > > > RELATED-TO property. > > > > I disagree. > > > > If the UPN is not granted the right to modify the > > RELATED-TO property of the other VAGENDA components, > > then most likely these properties were not set by > > him to start with. Thus, these properties should > > not be deleted by him (or by the CS on his behalf). > > And so how does the owner of that calendar get notified > that the RELATED-TO is gone and that their > calendar property is now bogus? By using the command. > When it was CHILD/PARENT the CS maintained that field > at the CS level and now that is gone. But previously the CUA was NOT allowed to modify these properties. The properties were managed by the CS ONLY. > > It was agreed that the RELATED-TO property shall be > > maintained by the CUA and it shall stay that way. > > It was proposed :-) 1- Hierarchical calendars have been removed from CAP. As such, the CS has no notion of the RELATED-TO property, the CUA does. 2- A property should either be managed by the CUA or the CS. NOT BOTH! 3- What if I delete my VAGENDA and re-create it right away with the same CALID? 4- You had mention that you wanted to add an EXTERN parameter to the RELATED-TO property to allow links outside the CS (when we do fan-out). The CS is not going to modify the VAGENDAs located in other CS, so eventually, the CUA will have to handle RELATED-TO property with CALID that no longer exists, the same way web browser needs to handle broken links (as was mentioned by John). Regards, 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 Thu Feb 14 10:05:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23683 for ; Thu, 14 Feb 2002 10:05:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EEoDM04291 for ietf-calendar-bks; Thu, 14 Feb 2002 06:50:13 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEoC304286 for ; Thu, 14 Feb 2002 06:50:12 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: (#1) synchronization part 2, and identifying a components VALARM MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 09:58:03 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 09:58:17 AM, Serialize complete at 02/14/2002 09:58:17 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Proposal: > > (1) Add SEQUENCE as a MUST for VALARM in the CS [...] I like it (ignore my .sig quote :-). /========================================================\ |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 Thu Feb 14 10:06:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23705 for ; Thu, 14 Feb 2002 10:06:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EEsnB04390 for ietf-calendar-bks; Thu, 14 Feb 2002 06:54:49 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEsm304386 for ; Thu, 14 Feb 2002 06:54:48 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA27543; Thu, 14 Feb 2002 09:54:43 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EEsgQ04879; Thu, 14 Feb 2002 09:54:42 -0500 (EST) Message-ID: <3C6BCFB2.BB716E92@steltor.com> Date: Thu, 14 Feb 2002 09:54:42 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: John Stracke CC: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > 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 If you can't get the current time from NTP, why not use the current time that is not available on the device? I still don't see the importance of getting the current time of the CS. I still think that we should remove it from CAP. However, if people really want it and see an important need for it, we can add a "get-currenttime" command. The current time on the CS is not a capability nor is it a VCALSTORE property. George John Stracke wrote: > > >> I agree. We have NTP for time synchronization; it can do a much better > >> job than anything we might build over TCP. > > > > I agree. Can we remove CURRENT-DATETIME from CAP? > >I still see no reasons why we need it. > > Well, there are times when you can't use NTP (e.g., if there's a firewall > in the way that doesn't permit it), so getting the CS's current time when > you first connect gives you at least a crude idea (to within seconds, > usually). > > /===========================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc. | > |http://www.incentivesystems.com |My opinions are my own. | > |===========================================================| > |"I only wish I had time to get married myself, as I've told| > |m'wife many's the time." | > \===========================================================/ From owner-ietf-calendar@mail.imc.org Thu Feb 14 10:15:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23909 for ; Thu, 14 Feb 2002 10:15:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EEwpu04504 for ietf-calendar-bks; Thu, 14 Feb 2002 06:58:51 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEwo304499 for ; Thu, 14 Feb 2002 06:58:50 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 10:06:42 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 10:06:55 AM, Serialize complete at 02/14/2002 10:06:55 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >If you can't get the current time from NTP, why not use the current >time that is not available on the device? Could you please rephrase that so that it makes sense? >I still don't see the >importance of getting the current time of the CS. So that, if your clock and the CS's clock disagree, you can compensate when you set a CS-side VALARM. /========================================================\ |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 Thu Feb 14 10:17:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23930 for ; Thu, 14 Feb 2002 10:17:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EEvRd04463 for ietf-calendar-bks; Thu, 14 Feb 2002 06:57:27 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEvQ304459 for ; Thu, 14 Feb 2002 06:57:26 -0800 (PST) To: "ietf-calendar@imc.org" Cc: paf@cisco.com, ned.freed@mrochek.com Subject: Re: Proposal: METHOD REVIEWER changes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 10:05:17 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 10:05:31 AM, Serialize complete at 02/14/2002 10:05:31 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >There were issues with the METHOD REVIEWER. The issue was >that there was not a method to appeal when something was accepted. If we keep the method reviewer, I support this proposal; it fixes the original problem I pointed out. , However, I still maintain that there is no room for a reviewer in a protocol spec. It's a way of short-circuiting the RFC process, and updating the protocol without having to get consensus, go through Last Call, advance on the standards track, etc. It works for MIME types only because MIME types are completely independent (defining text/foo does not have any impact on anybody who doesn't use it), and are normally defined merely as labels for existing file types. For iCalendar properties, etc., it does not work, because the properties are interdependent. Patrik and Ned, can you guys please give us an opinion here? /========================================================\ |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 Thu Feb 14 10:20:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23971 for ; Thu, 14 Feb 2002 10:20:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EEuj704443 for ietf-calendar-bks; Thu, 14 Feb 2002 06:56:45 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EEui304439 for ; Thu, 14 Feb 2002 06:56:44 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA27601 for ; Thu, 14 Feb 2002 09:56:40 -0500 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 g1EEueQ04981 for ; Thu, 14 Feb 2002 09:56:40 -0500 (EST) Message-ID: <3C6BD09E.4628C10F@steltor.com> Date: Thu, 14 Feb 2002 09:58:38 -0500 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: CHILD/PARENT vs RELATED-TO References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit John Stracke wrote: > > >If the UPN is not granted the right to modify the > >RELATED-TO property of the other VAGENDA components, > >then most likely these properties were not set by > >him to start with. Thus, these properties should > >not be deleted by him (or by the CS on his behalf). > > That doesn't automatically follow. The person who set those properties in > the first place was trying to add useful information to the system. It is > entirely reasonable for CAP to specify that the information should be > deleted once it becomes useless. I disagree. I don't think it is reasonable for the CS to decide when the information become useless. I can set the RELATED-TO property of a VAGENDA to a CALID that doesn't yet exists. As such, the CS should not delete, on its own, RELATED-TO property set to CALID that don't exists. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Recherche et développement Tél. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Feb 14 10:30:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24228 for ; Thu, 14 Feb 2002 10:30:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EFHR005799 for ietf-calendar-bks; Thu, 14 Feb 2002 07:17:27 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EFHQ305795 for ; Thu, 14 Feb 2002 07:17:26 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA28464; Thu, 14 Feb 2002 10:17:21 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EFHLQ08075; Thu, 14 Feb 2002 10:17:21 -0500 (EST) Message-ID: <3C6BD500.C87134EA@steltor.com> Date: Thu, 14 Feb 2002 10:17:20 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: John Stracke CC: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > 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: > > >If you can't get the current time from NTP, why not use the current > >time that is not available on the device? > > Could you please rephrase that so that it makes sense? I meant: "why not use the current time that is available on the device?" ^^ > > >I still don't see the > >importance of getting the current time of the CS. > > So that, if your clock and the CS's clock disagree, you can compensate > when you set a CS-side VALARM.' What is a CS-side VALARM? They are not defined in CAP. George > > /========================================================\ > |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 Thu Feb 14 10:48:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25016 for ; Thu, 14 Feb 2002 10:48:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EFYOO06860 for ietf-calendar-bks; Thu, 14 Feb 2002 07:34:24 -0800 (PST) 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 g1EFYN306853 for ; Thu, 14 Feb 2002 07:34:23 -0800 (PST) Received: from jsoft.com (IDENT:CijK45dV8GsJpCLQd53AA7aCrcGqDLO4@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g1EFWwj22185 for ; Thu, 14 Feb 2002 09:32:58 -0600 Message-ID: <3C6BD8AA.4050808@jsoft.com> Date: Thu, 14 Feb 2002 09:32:58 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020213 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: Security Considerations References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>What if I have something in a secure area and don't need to authenticate? >> > > Basic assumption of network security: there are no secure areas. Basic assumption of people working on security: it's necessary. > > If, by "secure area", you mean a military base, with a network protected > by an air gap and men with guns, then you've answered your own question: > someone who can afford physical security can afford to implement > DIGEST-MD5. I was thinking of my wife's calendar and mine. I'm secure with who she is and that her calendar and mine should talk. Forcing EVERYTHING to authenticate is simple, yet insane. But it's ok if that has to be... sigh Gary "Thanks for noticing" Eeyore to Pooh > > /========================================================\ > |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 Thu Feb 14 11:27:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26192 for ; Thu, 14 Feb 2002 11:27:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EG58T08618 for ietf-calendar-bks; Thu, 14 Feb 2002 08:05:08 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EG56308614 for ; Thu, 14 Feb 2002 08:05:06 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA06170 for ; Thu, 14 Feb 2002 08:05:07 -0800 (PST) Message-ID: <3C6BE02F.96B033C3@Royer.com> Date: Thu, 14 Feb 2002 09:05:03 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Security Considerations References: <1013633061.8346.45.camel@c-1241.in.steltor.com> <3C6AD604.A0AE79AB@Royer.com> <3C6BAB57.4060704@jsoft.com> Content-Type: multipart/mixed; boundary="------------E36B7E67DA6C0B3512660264" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E36B7E67DA6C0B3512660264 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > > Doug Royer wrote: > > >Patrice Lapierre wrote: > > > >>A Security Considerations section must be included in CAP. > >> > >>The following requirement was posted on the list: > >> > >>Doug wrote: > >> > >>>I do agree that we MUST mandate at least ONE minimum authentication > >>>level that CS/BEEP MUST support. This was dictated to us by > >>>the area directors years ago > >>> > Why? Because it is an IETF requirement and we will not be allowed to become an RFC without it. We MUST mandate at least one authentication mechanism. You can search the archives for this discussion - it took place a year or more ago on this list. If there where 10 CS implementations and each used a unique authentication mechanism - we would have NO interoperability. And what if 10 CUA implementations used another 10 unique authentication mechanisms, no one could use CAP at all. And per the IETF, we can not mandate clear text authentication. > This prevents someone from implementing a small 'CAP' service. No, it just mandates that they are CAP servers if they conform. > What if I have something in a secure area and don't need to authenticate? Your are free to turn it off. The requirement says that it is not a CAP server unless it can interoperate with any other CAP server that is compliant to the spec. BEEP allows for multiple authentication mechanisms, you must at least advertise the mandated one. You are free to advertise others. > Then again, I can have something reasonably light weight and call it > CAPLite and say it's not CAP. Mandating eliminates the need to have > protocol and behavior to see what's on the other side. If it is not CAP - then it is not CAP - what is the issue? --------------E36B7E67DA6C0B3512660264 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 ; Thu, 14 Feb 2002 11:30:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EG97h08723 for ietf-calendar-bks; Thu, 14 Feb 2002 08:09:07 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EG96308719 for ; Thu, 14 Feb 2002 08:09:06 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA06174 for ; Thu, 14 Feb 2002 08:09:07 -0800 (PST) Message-ID: <3C6BE11F.AD9482CA@Royer.com> Date: Thu, 14 Feb 2002 09:09:03 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) Byte reduction in BEEP commands. References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C6ACDD1.5346640A@Royer.com> <1013693424.8346.173.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------3F0B35D50A876AEBA0FE9E77" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3F0B35D50A876AEBA0FE9E77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > There are many ways a command can be aborted: > > (1) CUA sends an "abort" message at any moment from > another channel. > > (2) CUA sends an "abort" RPY to a "timeout" MSG > (when max lantency is exhausted). > > (3) Max latency is reached and action='abort' > > For (2), I agree. > For (3), cmdid is not an issue, but your text seems correct > since we can say that it's not the CUA that aborts the > commmand. > > For (1), I think that the cmdid must always be present, > even if only a single command is present. The motivation > is that there might be delay before the CS processes the > "abort" command. Without the "cmdid" the server will not > be able to unambiguously determine which command to cancel > (even if there is only one it could have been sent after > the "abort"). In (1) the CUA is doing more than one command at a time. So yes when the CUA sends more than one command at a time and it may wish to cancel the command, it MUST supply CMDID. But if the CUA is NEVER going to send more than one command and is not using latency, then it NEVER is needed. --------------3F0B35D50A876AEBA0FE9E77 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 ; Thu, 14 Feb 2002 11:33:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EGDoj08968 for ietf-calendar-bks; Thu, 14 Feb 2002 08:13:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EGDn308964 for ; Thu, 14 Feb 2002 08:13:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA06182 for ; Thu, 14 Feb 2002 08:13:49 -0800 (PST) Message-ID: <3C6BE23A.CE677793@Royer.com> Date: Thu, 14 Feb 2002 09:13:46 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions References: <3C699404.DAF9AE4A@steltor.com> <3C69AE2A.43C4FEEB@Royer.com> <3C6A95DB.A3E61921@steltor.com> <3C6AAC9E.FAA3BBB1@Royer.com> <3C6BCC6E.B50E8A59@steltor.com> Content-Type: multipart/mixed; boundary="------------F4602454332F511F6A96026E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F4602454332F511F6A96026E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > Doug Royer wrote: > > > > George Babics wrote: > > > > > > Doug Royer wrote: > > > > > > > > > > And how about replace: > > > > > > > > If FALSE, then no two events may conflict > > > > > > > > With: > > > > If FALSE, then no two components or their expanded > > > > instances can share the same time or overlap the same > > > > time periods. > > > > > > Is this not implied by "no two events may conflict"? > > > > Two points: > > > > (1) 'events' implied VEVENT to me. > > Do you mean that "Overlapped Booking" should apply to all > types of components? Yes that was my belief. > I think that the definitions should apply to > VEVENTs only and not to components as you had in your definition. > We do not want VEVENTs conflicting with VTODOs. Nor do we want > VTODOs conflicting with other VTODOs. I think we are agreeing. So we should change the word 'events' to components? My belief was that is was to never allow two things to book the same time in the same calendar. VEVENT - rent the snowmobile at 10:am TODO - change the oil in the snowmobile - at 10am If it applied to all components, then one of them would have never been booked. --------------F4602454332F511F6A96026E 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 ; Thu, 14 Feb 2002 12:18:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EH3HV10391 for ietf-calendar-bks; Thu, 14 Feb 2002 09:03:17 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EH3G310387 for ; Thu, 14 Feb 2002 09:03:16 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: Security Considerations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 12:11:07 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 12:11:22 PM, Serialize complete at 02/14/2002 12:11:22 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> >>>I do agree that we MUST mandate at least ONE minimum authentication >> >>>level that CS/BEEP MUST support. This was dictated to us by >> >>>the area directors years ago >> >>> >> Why? >> > I can't say, I wasn't there. It's basic IETF policy. Without that, you don't get interoperability. /========================================================\ |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 Thu Feb 14 12:29:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00543 for ; Thu, 14 Feb 2002 12:29:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EH88U10523 for ietf-calendar-bks; Thu, 14 Feb 2002 09:08:08 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EH87310519 for ; Thu, 14 Feb 2002 09:08:07 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CHILD/PARENT vs RELATED-TO MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 12:15:58 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 12:16:13 PM, Serialize complete at 02/14/2002 12:16:13 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I can set the RELATED-TO property of a VAGENDA to a >CALID that doesn't yet exists. And are you claiming this is a useful ability? /========================================================\ |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 Thu Feb 14 12:32:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00607 for ; Thu, 14 Feb 2002 12:32:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EH6mo10502 for ietf-calendar-bks; Thu, 14 Feb 2002 09:06:48 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EH6l310498 for ; Thu, 14 Feb 2002 09:06:47 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 12:14:37 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 12:14:53 PM, Serialize complete at 02/14/2002 12:14:53 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> So that, if your clock and the CS's clock disagree, you can compensate >> when you set a CS-side VALARM.' > > What is a CS-side VALARM? They are not defined in CAP. As we have been discussing, some alarms might be sent by the CS (e.g., email alarms). /========================================================\ |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 Thu Feb 14 12:33:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00631 for ; Thu, 14 Feb 2002 12:33:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EH41q10412 for ietf-calendar-bks; Thu, 14 Feb 2002 09:04:01 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EH40310407 for ; Thu, 14 Feb 2002 09:04:00 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Security Considerations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 12:11:51 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 12:12:06 PM, Serialize complete at 02/14/2002 12:12:06 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I was thinking of my wife's calendar and mine. I'm secure with who she >is and that her calendar and mine should talk. Really? And are you willing to allow anybody who cracks into your client to talk to your CS without authenticating? /========================================================\ |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 Thu Feb 14 12:37:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00752 for ; Thu, 14 Feb 2002 12:37:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EHN8k10883 for ietf-calendar-bks; Thu, 14 Feb 2002 09:23:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EHN6310879 for ; Thu, 14 Feb 2002 09:23:06 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA31869 for ; Thu, 14 Feb 2002 12:23:02 -0500 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 g1EHN2Q22978 for ; Thu, 14 Feb 2002 12:23:02 -0500 (EST) Subject: Re: (#2) Byte reduction in BEEP commands. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C6BE11F.AD9482CA@Royer.com> References: <3C68698B.6CFC51A7@Royer.com> <1013526416.24764.8.camel@c-1241.in.steltor.com> <3C694274.F894CDE4@Royer.com> <1013538474.24840.65.camel@c-1241.in.steltor.com> <3C6ACDD1.5346640A@Royer.com> <1013693424.8346.173.camel@c-1241.in.steltor.com> <3C6BE11F.AD9482CA@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 12:30:22 -0500 Message-Id: <1013707823.8346.254.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 Thu, 2002-02-14 at 11:09, Doug Royer wrote: > Patrice Lapierre wrote: > > > > > There are many ways a command can be aborted: > > > > (1) CUA sends an "abort" message at any moment from > > another channel. > > > > (2) CUA sends an "abort" RPY to a "timeout" MSG > > (when max lantency is exhausted). > > > > (3) Max latency is reached and action='abort' > > > > For (2), I agree. > > For (3), cmdid is not an issue, but your text seems correct > > since we can say that it's not the CUA that aborts the > > commmand. > > > > For (1), I think that the cmdid must always be present, > > even if only a single command is present. The motivation > > is that there might be delay before the CS processes the > > "abort" command. Without the "cmdid" the server will not > > be able to unambiguously determine which command to cancel > > (even if there is only one it could have been sent after > > the "abort"). > > In (1) the CUA is doing more than one command at a time. > So yes when the CUA sends more than one command at a time > and it may wish to cancel the command, it MUST supply CMDID. > > But if the CUA is NEVER going to send more than one command > and is not using latency, then it NEVER is needed. Yes, I agree. From owner-ietf-calendar@mail.imc.org Thu Feb 14 12:53:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01270 for ; Thu, 14 Feb 2002 12:53:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EHWDN11079 for ietf-calendar-bks; Thu, 14 Feb 2002 09:32:13 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EHWB311075 for ; Thu, 14 Feb 2002 09:32:11 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA32113 for ; Thu, 14 Feb 2002 12:32:07 -0500 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 g1EHW7Q24089 for ; Thu, 14 Feb 2002 12:32:07 -0500 (EST) Subject: Re: Consensus? BEEP commands From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C6AEFDB.EBA6B615@Royer.com> References: <3C6AEFDB.EBA6B615@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 12:39:28 -0500 Message-Id: <1013708368.7902.264.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 Wed, 2002-02-13 at 17:59, Doug Royer wrote: > > Aside from the empty reply debate. I think we have consensus > on my last proposal: (#2) Byte reduction in BEEP commands. > > So as it is going to change little bits all over CAP. > I am going to not send out another copy of that proposal > and I don't think I need to send the exact text. Just > view: > > http://www.imc.org/ietf-calendar/mail-archive/msg04199.html > > So - if there are not objections, I'll add/tweak CAP to > make those changes soon. I understand that such a change, may involve too many modifications to send every details to the list (and still reach our goal for the last call). However I'm not sure we have consensus on all aspects. Before modifying the draft could you send the new suggested XML DTD for CAP commands, and complete example of each commands and the associated response (including the "move" command), they could be the one from the draft (they'll need to be adjusted anyway). -- Patrice. From owner-ietf-calendar@mail.imc.org Thu Feb 14 13:14:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05045 for ; Thu, 14 Feb 2002 13:14:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EHv4h11674 for ietf-calendar-bks; Thu, 14 Feb 2002 09:57:04 -0800 (PST) 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 g1EHv3311669 for ; Thu, 14 Feb 2002 09:57:03 -0800 (PST) Received: from jsoft.com (IDENT:HwOGLxlGWLmvFjnfWBT6PkopnvfvOcTy@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g1EHtcj22980 for ; Thu, 14 Feb 2002 11:55:38 -0600 Message-ID: <3C6BFA1A.5000404@jsoft.com> Date: Thu, 14 Feb 2002 11:55:38 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Security Considerations References: <1013633061.8346.45.camel@c-1241.in.steltor.com> <3C6AD604.A0AE79AB@Royer.com> <3C6BAB57.4060704@jsoft.com> <3C6BE02F.96B033C3@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 Doug Royer wrote: > Gary Frederick wrote: > >>Doug Royer wrote: >> >> >>>Patrice Lapierre wrote: >>> >>> >>>>A Security Considerations section must be included in CAP. >>>> >>>>The following requirement was posted on the list: >>>> >>>>Doug wrote: >>>> >>>> >>>>>I do agree that we MUST mandate at least ONE minimum authentication >>>>>level that CS/BEEP MUST support. This was dictated to us by >>>>>the area directors years ago >>>>> >>>>> >>Why? >> > > Because it is an IETF requirement and we will not be allowed > to become an RFC without it. Good enough for me. > We MUST mandate at least > one authentication mechanism. You can search the archives > for this discussion - it took place a year or more ago > on this list. > > If there where 10 CS implementations and each used a unique > authentication mechanism - we would have NO interoperability. > And what if 10 CUA implementations used another 10 unique > authentication mechanisms, no one could use CAP at all. > > And per the IETF, we can not mandate clear text authentication. > > >>This prevents someone from implementing a small 'CAP' service. >> > > No, it just mandates that they are CAP servers if they conform. > > >>What if I have something in a secure area and don't need to authenticate? >> > > Your are free to turn it off. The requirement says that it is > not a CAP server unless it can interoperate with any other > CAP server that is compliant to the spec. > > BEEP allows for multiple authentication mechanisms, you must > at least advertise the mandated one. You are free to advertise > others. > > >>Then again, I can have something reasonably light weight and call it >>CAPLite and say it's not CAP. Mandating eliminates the need to have >>protocol and behavior to see what's on the other side. >> > > If it is not CAP - then it is not CAP - what is the issue? I was agreeing... > > Gary From owner-ietf-calendar@mail.imc.org Thu Feb 14 13:40:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05698 for ; Thu, 14 Feb 2002 13:40:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EIMBV12613 for ietf-calendar-bks; Thu, 14 Feb 2002 10:22:11 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EIMA312609 for ; Thu, 14 Feb 2002 10:22:10 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA00589; Thu, 14 Feb 2002 13:22:05 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EIM5Q29802; Thu, 14 Feb 2002 13:22:05 -0500 (EST) Message-ID: <3C6C004D.268BAFED@steltor.com> Date: Thu, 14 Feb 2002 13:22:05 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Current Date-Time Component Property > 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: > > >> So that, if your clock and the CS's clock disagree, you can compensate > >> when you set a CS-side VALARM.' > > > > What is a CS-side VALARM? They are not defined in CAP. > > As we have been discussing, some alarms might be sent by the CS (e.g., > email alarms). The CS does not send alarms. Perhaps you mean the CUA-bot that Doug has referred to? > > /========================================================\ > |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 Thu Feb 14 13:52:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06054 for ; Thu, 14 Feb 2002 13:52:25 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EIeMi13787 for ietf-calendar-bks; Thu, 14 Feb 2002 10:40:22 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EIeL313782 for ; Thu, 14 Feb 2002 10:40:21 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA01129 for ; Thu, 14 Feb 2002 13:40:17 -0500 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 g1EIeHQ02221 for ; Thu, 14 Feb 2002 13:40:17 -0500 (EST) Message-ID: <3C6C0507.749F86C9@steltor.com> Date: Thu, 14 Feb 2002 13:42:15 -0500 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: CHILD/PARENT vs RELATED-TO 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 can set the RELATED-TO property of a VAGENDA to a > >CALID that doesn't yet exists. > > And are you claiming this is a useful ability? I didn't claim anything other than the fact that I can do it. Are you suggesting that this should be illegal? Regards, 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 Thu Feb 14 14:24:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07163 for ; Thu, 14 Feb 2002 14:24:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EJAnk15861 for ietf-calendar-bks; Thu, 14 Feb 2002 11:10:49 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EJAl315857 for ; Thu, 14 Feb 2002 11:10:47 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CHILD/PARENT vs RELATED-TO MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 14:18:47 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 02:18:54 PM, Serialize complete at 02/14/2002 02:18:54 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> >I can set the RELATED-TO property of a VAGENDA to a >> >CALID that doesn't yet exists. >> >> And are you claiming this is a useful ability? > >I didn't claim anything other than the fact that I can do it. > >Are you suggesting that this should be illegal? Of course. It's not useful, it opens up opportunities for error, and it's easy to prevent. Why should it be legal? /========================================================\ |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 Thu Feb 14 14:38:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07666 for ; Thu, 14 Feb 2002 14:38:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EJR8L16958 for ietf-calendar-bks; Thu, 14 Feb 2002 11:27:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EJR6316954 for ; Thu, 14 Feb 2002 11:27:06 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA02904; Thu, 14 Feb 2002 14:27:01 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EJR1Q08310; Thu, 14 Feb 2002 14:27:01 -0500 (EST) Message-ID: <3C6C0F84.57F175FF@steltor.com> Date: Thu, 14 Feb 2002 14:27:00 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: Consensus?: Order In Which Scheduled Components Are Processed Is Specified In iTIP 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 In section 6.3.2, "Processing Scheduling Components", it is stated: The CUA MUST process the scheduled components in the order sent. iTIP already addresses the order in which scheduled components should be processed. We should remove the text. George From owner-ietf-calendar@mail.imc.org Thu Feb 14 14:51:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07957 for ; Thu, 14 Feb 2002 14:51:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EJdvW17874 for ietf-calendar-bks; Thu, 14 Feb 2002 11:39:57 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EJdt317866 for ; Thu, 14 Feb 2002 11:39:55 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA03270; Thu, 14 Feb 2002 14:39:51 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EJdlQ09927; Thu, 14 Feb 2002 14:39:47 -0500 (EST) Message-ID: <3C6C1283.13D19615@steltor.com> Date: Thu, 14 Feb 2002 14:39:47 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: Consensus?: Who Sent The Counter? 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 A while ago it was identified in CAP, that CUA is unable to identify who sent a COUNTER. Looking in the archives, this issue has already come up in iTIP and a consensus was reached. The thread: http://www.imc.org/ietf-calendar/mail-archive/msg00709.html The proposal: http://www.imc.org/ietf-calendar/mail-archive/msg00731.html The consensus: http://www.imc.org/ietf-calendar/mail-archive/msg00751.html Thus, I think it is no longer an issue for CAP. George From owner-ietf-calendar@mail.imc.org Thu Feb 14 15:11:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08522 for ; Thu, 14 Feb 2002 15:11:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EJxWN19244 for ietf-calendar-bks; Thu, 14 Feb 2002 11:59:32 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EJxT319237 for ; Thu, 14 Feb 2002 11:59:29 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA03790; Thu, 14 Feb 2002 14:59:24 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EJxNQ12212; Thu, 14 Feb 2002 14:59:23 -0500 (EST) Message-ID: <3C6C171B.10799CCC@steltor.com> Date: Thu, 14 Feb 2002 14:59:23 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP: Remove Editors Notes 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 I have will removes all the editors notes form CAP. They are: [Editors Note: TODO - get the lower port number ] Doug is handling the port number. It is already on the list of outstanding items. [EDITORS NOTE: Issues: Can one use DELETE to remove all VALARMs and VTIMEZONEs that match a certain search criteria and that belong to all components, event though VALARMs and VTIMEZONEs never exist as independent components? Or should one use MODIFY? If they can be deleted, do we return the REQUEST-STATUS of their deletion in a VEVENT or separately? I believe this one has already been answered on the list. Anyone remember the reply? [EDITORS NOTE: Issue: does write access to a VAGENDA give you the right to move a calendar into it? I think the answer is yes? [EDITORS NOTE: need to make a pass through the iTIP restriction tables to make sure that there are no problems with using them as they exist] [EDITORS NOTE: Do we want to use the same set of codes?] ?? [EDITORS NOTE: These extensions/changes to iCalendar need to be reformatted to conform to the IANA registration process defined in section 7 of [RFC2445].] This is in progress and is on our list of outstanding items. [Editor's Note: see if the above still make sense after reviewing the VCARs in ICAL-updates.html doc] VCARs are currently being discussed on the list. [EDITORS NOTE: hopefully, calid is defined somewhere...] On our list of outstanding items and is currently being discussed. [EDITORS NOTE: John Stracke to review any updates] On our list of outstanding items and is currently being discussed. George From owner-ietf-calendar@mail.imc.org Thu Feb 14 15:39:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09116 for ; Thu, 14 Feb 2002 15:39:25 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EKQ4s21326 for ietf-calendar-bks; Thu, 14 Feb 2002 12:26:04 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EKQ3321321 for ; Thu, 14 Feb 2002 12:26:03 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA04734 for ; Thu, 14 Feb 2002 15:26:00 -0500 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 g1EKPxQ15551 for ; Thu, 14 Feb 2002 15:25:59 -0500 (EST) Message-ID: <3C6C1DCE.E5EB255D@steltor.com> Date: Thu, 14 Feb 2002 15:27:58 -0500 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: CHILD/PARENT vs RELATED-TO 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 can set the RELATED-TO property of a VAGENDA to a > >> >CALID that doesn't yet exists. > >> > >> And are you claiming this is a useful ability? > > > >I didn't claim anything other than the fact that I can do it. > > > >Are you suggesting that this should be illegal? > > Of course. It's not useful, it opens up opportunities for error, and it's > easy to prevent. Why should it be legal? Am I talking to the same guy? http://www.imc.org/ietf-calendar/mail-archive/msg02855.html John Stracke wrote: > > >When linkages are between entities whose control is not under a > >single or common UPN (ie: CU) then its just not possible to guarantee > >that going "top down" will result in the same view of the links as > >going "bottom up". > > Just like in hypertext. Most pre-Web hypertext systems attempted to > enforce link consistency, which required either a single server or a > complicated distribution model. When the hypertext community saw the > early Web, they asked, "So how do you prevent broken links?". Answer: "We > don't. It usually works, though." "Usually" turned out to be good enough > to live with, and the simplicity made Web servers easy enough to become > common. Regards, 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 Thu Feb 14 16:00:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09515 for ; Thu, 14 Feb 2002 16:00:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EKmQs23011 for ietf-calendar-bks; Thu, 14 Feb 2002 12:48:26 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EKmN323002 for ; Thu, 14 Feb 2002 12:48:23 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA05255 for ; Thu, 14 Feb 2002 15:48:19 -0500 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 g1EKmJQ17824 for ; Thu, 14 Feb 2002 15:48:19 -0500 (EST) Subject: Re: CAP: Security Considerations From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C6AD604.A0AE79AB@Royer.com> References: <1013633061.8346.45.camel@c-1241.in.steltor.com> <3C6AD604.A0AE79AB@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Feb 2002 15:55:40 -0500 Message-Id: <1013720140.8346.351.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 Wed, 2002-02-13 at 16:09, Doug Royer wrote: > Patrice Lapierre wrote: > > ... > > Section X.0 Security Considerations. > > > > Consult Section 2.4.2 for a discussion of access rights. > > In addition, since CAP is a profile of the BEEP, consult > > [BEEP]'s Section 9 for a discussion of BEEP-specific > > security issues. > > > > Although service provisioning is a policy matter, at a minimum, > > all implementations must provide the following tuning profiles: > > > > for authentication: http://iana.org/beep/SASL/DIGEST-MD5 > > > > for confidentiality: http://iana.org/beep/TLS (using the > > TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) > > > > for both: http://iana.org/beep/TLS (using the > > TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side > > certificates) > > And what about VCAR and command security issues? > > - be careful of the GRANTs you give out ... How about rewriting the first sentence to: Access rights should be granted cautiously, consult Section 2.4.2 for a discussion of the subject. > > - Use of the command ... Good point. Section 6.1.3 mentions the following: The CS determines through an internal mechanism if the credentials supplied at authentication permit the assumption of the selected identity. If they do, the session assumes the new identity, otherwise a security error is returned. Would it be sufficient to add the following: The "identify" command should be carefully implemented as discussed in Section 6.1.3. > > - Anonymous login ... > I think it's supported by the profile: 'http://iana.org/beep/SASL/ANONYMOUS' I don't understand your intent, are you suggesting that it should be added as must, or proposing to add some text to explain issues related to anonymous authentication? From owner-ietf-calendar@mail.imc.org Thu Feb 14 17:03:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11135 for ; Thu, 14 Feb 2002 17:03:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1ELof226878 for ietf-calendar-bks; Thu, 14 Feb 2002 13:50:41 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ELoe326874 for ; Thu, 14 Feb 2002 13:50:40 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CHILD/PARENT vs RELATED-TO MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Feb 2002 16:58:34 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/14/2002 04:58:48 PM, Serialize complete at 02/14/2002 04:58:48 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Of course. It's not useful, it opens up opportunities for error, and it's >> easy to prevent. Why should it be legal? > >Am I talking to the same guy? Am I not allowed to change my mind? (If not, then any attempt to achieve consensus is kind of pointless...) What I said previously was too simplistic; it made a false analogy between cross-server links and cross-user links. It should be easy to ensure consistency in cross-user links. /========================================================\ |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 Thu Feb 14 17:45:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12005 for ; Thu, 14 Feb 2002 17:45:26 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EMZpX29213 for ietf-calendar-bks; Thu, 14 Feb 2002 14:35:51 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EMZo329209 for ; Thu, 14 Feb 2002 14:35:50 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA08698 for ; Thu, 14 Feb 2002 17:35:47 -0500 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 g1EMZkQ02050 for ; Thu, 14 Feb 2002 17:35:47 -0500 (EST) Message-ID: <3C6C3C39.19D3A21@steltor.com> Date: Thu, 14 Feb 2002 17:37:45 -0500 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: CAP: Searching iTIP objects 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 Assuming Mary submits the following iCalendar object in Bob's calendar: BEGIN:VCALENDAR * METHOD:ADD PRODID:-//ACME/CAPserver//EN VERSION:2.0 BEGIN:VEVENT DTSTART:20000218T160000Z DTEND:20000218T170000Z SUMMARY:Press Conference UID:123 SEQUENCE:1 ORGANIZER:cap://cal.example.com/mary-relcalid ATTENDEE;RSVP=FALSE:cap://cal.example.com/bob-relcalid END:VEVENT END:VCALENDAR a) Which VQUERY component will allow Bob to find this iCalendar object in his calendar? My guess: BEGIN:VQUERY QUERYNAME:Query-01 QUERY:SELECT * FROM VEVENT WHERE METHOD = 'ADD' END:VQUERY Without EXPAND:TRUE that is. b) How will the returned VEVENT component look like? My guess: BEGIN:VCALENDAR PRODID:-//ACME/CAPserver//EN VERSION:2.0 BEGIN:VEVENT * METHOD:ADD DTSTART:20000218T160000Z DTEND:20000218T170000Z SUMMARY:Press Conference UID:123 SEQUENCE:1 ORGANIZER:cap://cal.example.com/mary-relcalid ATTENDEE;RSVP=FALSE:cap://cal.example.com/bob-relcalid END:VEVENT END:VCALENDAR c) Does the EXPAND property influence the selection mechanism of iTIP objects? Regards, 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 Thu Feb 14 21:21:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14920 for ; Thu, 14 Feb 2002 21:21:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1F27eq04992 for ietf-calendar-bks; Thu, 14 Feb 2002 18:07:40 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1F27d304987 for ; Thu, 14 Feb 2002 18:07:39 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g1F27YO06061 for ; Thu, 14 Feb 2002 18:07:34 -0800 (PST) Received: from netscape.com ([10.169.59.204]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GRJXWP00.54H for ; Thu, 14 Feb 2002 18:07:37 -0800 Message-ID: <3C6C6D39.1B137AD9@netscape.com> Date: Thu, 14 Feb 2002 18:06:49 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP Consensus: relativeCALID Content-Type: multipart/mixed; boundary="------------A60764A82EE33DBCAC6B97DF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A60764A82EE33DBCAC6B97DF Content-Type: multipart/alternative; boundary="------------70D5FF9304C0442161846CE7" --------------70D5FF9304C0442161846CE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, There still some open issues on relativeCALID . The current definition of a calendar address is: [[]://[:]/] And relativeCALID is defined in CAP 2.6 as: is an identifier that uniquely identifies the calendar on a particular calendar store. There is no implied structure in a Relative CALID. It is an arbitrary string of printable 7 bit ASCII characters. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store. It is recommended that the Relative CALID be globally unique. There are two issues here. First, "an arbitrary string of printable 7 bit ASCII characters" is probably not what we want. Second, is the recommendation to make relativeCALIDs globally unique. For the latter issue, I propose we just remove the last sentence. For the first issue, I'll start the recommendations with the following: is an identifier that uniquely identifies the calendar on a particular calendar store. There is no implied structure in a Relative CALID. It is an arbitrary string of ASCII characters as defined by relcalid below. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store. lowalpha = ( "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" ) upalpha = ( "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" ) alpha = ( lowalpha / upalpha ) digit = ( "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" ) alphanum = ( alpha / digit ) other = ( "-" / "_" / "." / "!" / "~" / "*" / "@" / "(" / ")" / "{" / "}" / "/" / "\" / "^" / "[" / "]" ) relcalid = *( alphanum / other ) Comments are welcome. -Steve --------------70D5FF9304C0442161846CE7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Folks,

There still some open issues on relativeCALID .

The current definition of a calendar address is:

[[<scheme>]://<csid>[:<port>]/]<relativeCALID>
And relativeCALID is defined in CAP 2.6 as:
<relativeCALID> is an identifier that uniquely identifies the calendar on a particular calendar store. There is no implied structure in a Relative CALID. It is an arbitrary string of printable 7 bit ASCII characters. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store. It is recommended that the Relative CALID be globally unique.
There are two issues here.  First, "an arbitrary string of printable 7 bit ASCII characters" is probably not what we want.  Second, is the recommendation to make relativeCALIDs globally unique.

For the latter issue, I propose we just remove the last sentence.

For the first issue, I'll start the recommendations with the following:

<relativeCALID> is an identifier that uniquely identifies the calendar on a particular calendar store. There is no implied structure in a Relative CALID. It is an arbitrary string of ASCII characters as defined by relcalid below. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store.

  lowalpha = ( "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i"
           /   "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r"
           /   "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" )

  upalpha  = ( "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I"
           /   "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R"
           /   "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" )

  alpha    = ( lowalpha / upalpha )

  digit    = ( "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
           /   "8" / "9" )

  alphanum = ( alpha / digit )

  other    = ( "-" / "_" / "." / "!" / "~" / "*" / "@" / "(" / ")"
           /   "{" / "}" / "/" / "\" / "^" / "[" / "]" )

  relcalid = *( alphanum / other )

Comments are welcome.

-Steve --------------70D5FF9304C0442161846CE7-- --------------A60764A82EE33DBCAC6B97DF Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650.937.3351 x-mozilla-html:FALSE org:Netscape adr:;;;;;; version:2.1 title:Director of Engineering fn:Steve Mansour end:vcard --------------A60764A82EE33DBCAC6B97DF-- From owner-ietf-calendar@mail.imc.org Thu Feb 14 22:20:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16528 for ; Thu, 14 Feb 2002 22:20:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1F39l406604 for ietf-calendar-bks; Thu, 14 Feb 2002 19:09:47 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1F39k306600 for ; Thu, 14 Feb 2002 19:09:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id TAA06670 for ; Thu, 14 Feb 2002 19:09:49 -0800 (PST) Message-ID: <3C6C7BF4.CDB0FE86@Royer.com> Date: Thu, 14 Feb 2002 20:09:40 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: Consensus? BEEP commands References: <3C6AEFDB.EBA6B615@Royer.com> <1013708368.7902.264.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------830A26C1EE34D67BDE4B7323" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------830A26C1EE34D67BDE4B7323 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [FYI - do to a local router down, I have been offline all day] Patrice Lapierre wrote: > > On Wed, 2002-02-13 at 17:59, Doug Royer wrote: > > > > Aside from the empty reply debate. I think we have consensus > > on my last proposal: (#2) Byte reduction in BEEP commands. > > > > So as it is going to change little bits all over CAP. > > I am going to not send out another copy of that proposal > > and I don't think I need to send the exact text. Just > > view: > > > > http://www.imc.org/ietf-calendar/mail-archive/msg04199.html > > > > So - if there are not objections, I'll add/tweak CAP to > > make those changes soon. > > I understand that such a change, may involve too many > modifications to send every details to the list (and > still reach our goal for the last call). Thanks! > However I'm not sure we have consensus on all aspects. I agree but I think we are close. - it won't be too late to change, but at this point I think we all need everything in the draft before blasting me :-) > Before modifying the draft could you send the new suggested > XML DTD for CAP commands, and complete example of each > commands and the associated response (including the "move" > command), they could be the one from the draft (they'll > need to be adjusted anyway). The examples of the new commands were in the text I sent. For them most part they are one line With the optional latency and cmdid and when sending iCalendar data followed by CDATA CDATA DTD - I am not a DTD expert - I was hoping to get the text close then get some help with DTD's. --------------830A26C1EE34D67BDE4B7323 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 ; Thu, 14 Feb 2002 22:22:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1F3CFh06674 for ietf-calendar-bks; Thu, 14 Feb 2002 19:12:15 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1F3CE306670 for ; Thu, 14 Feb 2002 19:12:14 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id TAA06682 for ; Thu, 14 Feb 2002 19:12:16 -0800 (PST) Message-ID: <3C6C7C88.914C4D3A@Royer.com> Date: Thu, 14 Feb 2002 20:12:08 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Who Sent The Counter? References: <3C6C1283.13D19615@steltor.com> Content-Type: multipart/mixed; boundary="------------97B1CBC24E873278E57B0517" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------97B1CBC24E873278E57B0517 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > A while ago it was identified in CAP, that CUA is unable to > identify who sent a COUNTER. > > Looking in the archives, this issue has already come up in iTIP > and a consensus was reached. > > The thread: http://www.imc.org/ietf-calendar/mail-archive/msg00709.html > The proposal: http://www.imc.org/ietf-calendar/mail-archive/msg00731.html > The consensus: http://www.imc.org/ietf-calendar/mail-archive/msg00751.html > > Thus, I think it is no longer an issue for CAP. GREAT - I agree that we should adopt this this proposal. It makes more sense that SEND-BY I proposed. --------------97B1CBC24E873278E57B0517 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 ; Thu, 14 Feb 2002 22:28:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1F3ITa06793 for ietf-calendar-bks; Thu, 14 Feb 2002 19:18:29 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1F3IR306789 for ; Thu, 14 Feb 2002 19:18:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id TAA06696 for ; Thu, 14 Feb 2002 19:18:30 -0800 (PST) Message-ID: <3C6C7DFD.3C6F15F@Royer.com> Date: Thu, 14 Feb 2002 20:18:21 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Remove Editors Notes References: <3C6C171B.10799CCC@steltor.com> Content-Type: multipart/mixed; boundary="------------D802F4EC90D206D0198E99B6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D802F4EC90D206D0198E99B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > I have will removes all the editors notes form CAP. > > They are: > > [Editors Note: TODO - get the lower port number ] > > Doug is handling the port number. It is already on the list > of outstanding items. Hearing no objections - I start work on this tomorrow. > [EDITORS NOTE: Issues: > Can one use DELETE to remove all VALARMs and VTIMEZONEs that > match a certain search criteria and that belong to all > components, event though VALARMs and VTIMEZONEs never exist as > independent components? Or should one use MODIFY? If they can > be deleted, do we return the REQUEST-STATUS of their deletion > in a VEVENT or separately? I think you can delete or modify anything in the CS. So yes. Which one will depend on the CUA - I think there is no prefered method. I would think that it would be the same as when deleting or modifying any other set of data. > I believe this one has already been answered on the list. > Anyone remember the reply? > > [EDITORS NOTE: Issue: does write access to a VAGENDA give you > the right to move a calendar into it? > > I think the answer is yes? MOVE of calendars is dead - as there is no more requirement for PARENT/CHILD. --------------D802F4EC90D206D0198E99B6 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 ; Thu, 14 Feb 2002 22:31:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1F3AjL06631 for ietf-calendar-bks; Thu, 14 Feb 2002 19:10:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1F3Ai306627 for ; Thu, 14 Feb 2002 19:10:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id TAA06674 for ; Thu, 14 Feb 2002 19:10:47 -0800 (PST) Message-ID: <3C6C7C2E.E84172D9@Royer.com> Date: Thu, 14 Feb 2002 20:10:38 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are Processed Is Specified In iTIP References: <3C6C0F84.57F175FF@steltor.com> Content-Type: multipart/mixed; boundary="------------51B61CC0B457CABC0336C0B2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------51B61CC0B457CABC0336C0B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > In section 6.3.2, "Processing Scheduling Components", it is > stated: > > The CUA MUST process the scheduled components in the order sent. > > iTIP already addresses the order in which scheduled components > should be processed. We should remove the text. I agree. --------------51B61CC0B457CABC0336C0B2 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 ; Thu, 14 Feb 2002 22:36:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1F3OWB06924 for ietf-calendar-bks; Thu, 14 Feb 2002 19:24:32 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1F3OV306918 for ; Thu, 14 Feb 2002 19:24:31 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id TAA06705 for ; Thu, 14 Feb 2002 19:24:34 -0800 (PST) Message-ID: <3C6C7F69.4DC66585@Royer.com> Date: Thu, 14 Feb 2002 20:24:25 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Security Considerations References: <1013633061.8346.45.camel@c-1241.in.steltor.com> <3C6AD604.A0AE79AB@Royer.com> <1013720140.8346.351.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------E423095E2D0C4F0E53A2DC92" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E423095E2D0C4F0E53A2DC92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > I don't understand your intent, are you suggesting that > it should be added as must, or proposing to add some text > to explain issues related to anonymous authentication? My experience tells me that the security IETF folks are going to read this section and use it to determine if we know what we are talking about. Pointing to BEEP is not sufficient. We will need to say something like: BEEP allows xxx authentication and we do (or do not) see that CAP opens up any additional security .... or Or in addition to BEEP security ... if the CS does this xxxx then bad yyy can happen. So it is not just an index of where to look. It its a section where we can point out security issues for implementers and administrators. I don't recall that we have had this debate. And I think the reason is that we depend on PAUL to be our expert. I am not an expert in security. --------------E423095E2D0C4F0E53A2DC92 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 ; Fri, 15 Feb 2002 09:40:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FEUkN01018 for ietf-calendar-bks; Fri, 15 Feb 2002 06:30:46 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FEUi301014 for ; Fri, 15 Feb 2002 06:30:44 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA16348 for ; Fri, 15 Feb 2002 09:30:40 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1FEUaQ22085 for ; Fri, 15 Feb 2002 09:30:36 -0500 (EST) Message-Id: <5.1.0.14.0.20020215092245.03617df8@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Feb 2002 09:27:09 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: (#1) synchronization part 2, and identifying a components VALARM In-Reply-To: <3C6B4C03.A4A286CD@Royer.com> References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> <3BFEBEE2.2F736E3D@Royer.com> <3C221F20.D92B2355@steltor.com> <3C238743.61387D6F@Royer.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:32 PM 2/13/2002 -0700, you wrote:

Outstanding CAP problems:

     How do you identify which VALARM is being modified
     in a component when the CUA wishes to <modify> a VALARM
     in an existing component and that components contains two
     or more VALARMs. (See UID vs ALARMID debate.)

     How do you tag VALARMS (or any component) as local so that
     when you do synchronization or new iTIP object arrive,
     the local VALARMS do not get tossed out because they
     were mistakenly seen as old data.

     How do you disable VALARMS that came in as part of a
     METHOD:REQUEST without deleting them. They can not be deleted
     because if the CUA wishes to send a METHOD:COUNTER, you need
     to include the entire object and only change or delete what
     you are proposing in the COUNTER to change or the ORGANIZER
     would assume that part of the COUNTER was to delete the VALARM.

 Proposal:
 
         (1) Add SEQUENCE as a MUST for VALARM in the CS
             that starts at zero (0). If the incoming object does
             not have any, then the CUA MUST add them before depositing
             them in the CS.
 
             This would make them unique per object and solve the
             MODIFY problem.

             The CUA would have to compare the contents of any
             updated iTIP objects that arrive without SEQUENCE
             to determine what changes have been made in order
             to synchronize and update the CS and CUA objects.
             
         (2) Create a new LOCAL parameter for the SEQUENCE property.
 
             The default value if not specified is 'false', and
             can be set to 'true'. Where 'true' means only visible
             to the calendar owners(s) and 'local' VALARMS MUST NOT
             be sent to non-calendar-owner(s) during queries.
 
             This would allow global (ORGANIZER originated VALARMs),
             and local (OWNER originated VALARMs) to have numbers
             starting at zero and not have to coordinate them between
             the OWNER and ORGANIZER.
 
                 BEGIN:VALARM
                 SEQUENCE:0
                 ...
                 END:VALARM
                 BEGIN:VALARM
                 SEQUENCE;LOCAL=true:0
                 ...
                 END:VALARM
 
             This would solve the synchronization problem by
             uniquely identifying the local VALARMS to the CS
             and CUA so local VALARMs do not get tossed when a
             higher SEQUENCE number arrives in an iTIP object.
 
         (3) Add a new ENABLE parameter to TRIGGER with a default
             value of 'true', and could be set to 'false'. If
             not specified it default to 'true'.
 
             And ENABLE is local to the calendar ONLY. That means
             the ORGANIZER MUST NOT set or specify ENABLE, and the
             CS MUST NOT export the ENABLE parameter to non-owners
             of the object during queries.
 
             This would allow local users to enable or disable
             both local and global VALARMS.
 
                 ...
                 BEGIN:VALARM
                 SEQUENCE:2
                 TRIGGER;ENABLE=false:20020101T000000Z
                 SUMMARY:NEW YEAR
                 ...
                 END:VALARM
                 BEGIN:VALARM
                 SEQUENCE;SCOPE=local:0

Shouldn't that be SEQUENCE;LOCAL=true;0 like you did above ?

                 TRIGGER:20020101T000000
                 SUMMARY:NEW YEAR
                 ...
                 END:VALARM
                 ...
 
 
 Now with this the ORGANIZER can modify VALARMS, and the local
 owner can decide the users preferences for TRIGGERS.  I think this
 solves the MODIFY problem by uniquely identifying VALARMS in each
 object (by using SEQUENCE and LOCAL) and gives the local user control
 over VALARM TRIGGERs without breaking synchronization.

Agree. Your alarms are yours and shouldn't interfere with the actual ITIP workflow. These provisions should allow a CUA to let an attendee set up their own alarms and keep them up-to-date without messing with the rest of the works.

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@steltor.com
http://www.steltor.com



 From owner-ietf-calendar@mail.imc.org Fri Feb 15 09:46:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06883 for ; Fri, 15 Feb 2002 09:46:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FESUi00771 for ietf-calendar-bks; Fri, 15 Feb 2002 06:28:30 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FESS300767 for ; Fri, 15 Feb 2002 06:28:28 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA16269 for ; Fri, 15 Feb 2002 09:28:24 -0500 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 g1FESNQ21620 for ; Fri, 15 Feb 2002 09:28:23 -0500 (EST) Subject: Re: Consensus? BEEP commands From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C6C7BF4.CDB0FE86@Royer.com> References: <3C6AEFDB.EBA6B615@Royer.com> <1013708368.7902.264.camel@c-1241.in.steltor.com> <3C6C7BF4.CDB0FE86@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 09:35:42 -0500 Message-Id: <1013783742.21001.46.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 Thu, 2002-02-14 at 22:09, Doug Royer wrote: > > [FYI - do to a local router down, I have been offline all day] > > Patrice Lapierre wrote: > > > > On Wed, 2002-02-13 at 17:59, Doug Royer wrote: > > > > > > Aside from the empty reply debate. I think we have consensus > > > on my last proposal: (#2) Byte reduction in BEEP commands. > > > > > > So as it is going to change little bits all over CAP. > > > I am going to not send out another copy of that proposal > > > and I don't think I need to send the exact text. Just > > > view: > > > > > > http://www.imc.org/ietf-calendar/mail-archive/msg04199.html > > > > > > So - if there are not objections, I'll add/tweak CAP to > > > make those changes soon. > > > > I understand that such a change, may involve too many > > modifications to send every details to the list (and > > still reach our goal for the last call). > > Thanks! > > > However I'm not sure we have consensus on all aspects. > > I agree but I think we are close. > - it won't be too late to change, but at this point I think we > all need everything in the draft before blasting me :-) > > > Before modifying the draft could you send the new suggested > > XML DTD for CAP commands, and complete example of each > > commands and the associated response (including the "move" > > command), they could be the one from the draft (they'll > > need to be adjusted anyway). > > The examples of the new commands were in the text I sent. > For them most part they are one line > With the optional latency and cmdid and when sending > iCalendar data followed by CDATA > > > CDATA > The samples in the text were skeletons and didn't include the move command or the responses. If we are really so close to a consensus it shouldn't be a problem. Coming up with examples doesn't require additional work, the ones from the draft would need to be updated anyway. > > DTD - I am not a DTD expert - I was hoping to get the text > close then get some help with DTD's. From owner-ietf-calendar@mail.imc.org Fri Feb 15 09:52:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06995 for ; Fri, 15 Feb 2002 09:52:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FEhEu01453 for ietf-calendar-bks; Fri, 15 Feb 2002 06:43:14 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FEhC301449 for ; Fri, 15 Feb 2002 06:43:12 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP Consensus: relativeCALID MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 15 Feb 2002 09:51:10 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/15/2002 09:51:21 AM, Serialize complete at 02/15/2002 09:51:21 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >It is an arbitrary string of ASCII characters as defined by relcalid below. Since a calid is a URI, it might be better to define the syntax in terms of characters that are permitted in URI--the uric production (or perhaps the unreserved production, which is safer) from RFC-2396. /========================================================\ |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 Feb 15 11:18:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09817 for ; Fri, 15 Feb 2002 11:18:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FG6Ju05464 for ietf-calendar-bks; Fri, 15 Feb 2002 08:06:19 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FG6H305456 for ; Fri, 15 Feb 2002 08:06:17 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA20116 for ; Fri, 15 Feb 2002 11:06:13 -0500 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 g1FG6DQ05783 for ; Fri, 15 Feb 2002 11:06:13 -0500 (EST) Subject: CAP: Ordering of the components returned by the search command. From: Patrice Lapierre To: "ietf-calendar@imc.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 11:13:31 -0500 Message-Id: <1013789612.21000.79.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 The latest proposal for CAP-QL states the following for the ordering of components returned by the search command: 4.1.2 CAP-QL notes (1) There is no ORDERBY. Sorting will take place in the order the columns are supplied in the command. ... (2) The CS MUST sort at least the first column. The CS MAY sort additional columns. (3) If the cap-cols is only "*" and nothing else, then: If EXPAND=FALSE sorting will be by the DTSTART value ascending. If EXPAND=TRUE sorting will be by the RECURRENCE-ID value ascending. I see some problems/limitations with this approach: (1) Often a CUA is not interested in any particular ordering. Yet for VEVENTs an ordering is always defined. This causes unnecessary processing on the server side. (2) When selecting everything (SELECT *) from a VEVENT. The CUA might be interested in another ordering than DTSTART (or RECURRENCE-ID). (3) When selecting everything (SELECT *) from a component that doesn't include a DTSTART, no ordering can be specified. (4) If the first property in the a select clause occurs more than once, the ordering is not defined. (5) If the first property in the select clause is not present, the ordering is not defined. To address these issues, I propose the addition of an optional "ORDER BY" clause (as in SQL). When not present no ordering is specified (this solves (1)). The "ORDER BY" clause could be limited to a finite (no *) subset of the properties included directly or indirectly (i.e., *) in the SELECT clause. This would take care of (2) and (3), and shouldn't introduce additional complexity. Examples: 1. BEGIN:VQUERY QUERY:SELECT * FROM VEVENT END:VQUERY Here no ordering is specified. 2. BEGIN:VQUERY QUERY: SELECT * FROM VTODO ORDER BY SUMMARY END:VQUERY Order the returned VTODO by SUMMARY. For (4) and (5) additional rules are required: - Properties that are not present (or not visible due to insufficient access rights), should come first. - For properties that occurs more than once, the ordering should be based on the value of the property instance that comes first within each component. -- Patrice. From owner-ietf-calendar@mail.imc.org Fri Feb 15 11:33:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10310 for ; Fri, 15 Feb 2002 11:33:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FGO5T06597 for ietf-calendar-bks; Fri, 15 Feb 2002 08:24:05 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FGO4306593 for ; Fri, 15 Feb 2002 08:24:04 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29186 for ; Fri, 15 Feb 2002 11:24:05 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA26216 for ; Fri, 15 Feb 2002 11:24:04 -0500 (EST) Received: from [66.92.67.187] (wingnut.bobmah.com [66.92.67.187]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08869; Fri, 15 Feb 2002 11:24:04 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <3C6C7F69.4DC66585@Royer.com> References: <1013633061.8346.45.camel@c-1241.in.steltor.com> <3C6AD604.A0AE79AB@Royer.com> <1013720140.8346.351.camel@c-1241.in.steltor.com> <3C6C7F69.4DC66585@Royer.com> Date: Fri, 15 Feb 2002 11:25:18 -0500 To: "ietf-calendar@imc.org" From: Bob Mahoney Subject: Re: CAP: Security Considerations Cc: "ietf-calendar@imc.org" 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 8:24 PM -0700 2/14/02, Doug Royer wrote: > >My experience tells me that the security IETF folks are >going to read this section and use it to determine >if we know what we are talking about. Good assumption... :-) >So it is not just an index of where to look. It its >a section where we can point out security issues for >implementers and administrators. Yes- we need to show that we have considered all the questions, and detail what we have done (or refrained from doing) that will address them. This section will be closely scrutinized, and you can expect that some conclusions will be drawn from it as to whether we have our act together. Even if the document as a whole is a thing of Wonder and Beauty, if we attempt to hand-wave away the hard security questions, the document will simply not advance. -Bob From owner-ietf-calendar@mail.imc.org Fri Feb 15 12:12:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12016 for ; Fri, 15 Feb 2002 12:12:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FGuwL07606 for ietf-calendar-bks; Fri, 15 Feb 2002 08:56:58 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FGuv307602 for ; Fri, 15 Feb 2002 08:56:57 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA21806 for ; Fri, 15 Feb 2002 11:56:54 -0500 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 g1FGurQ12389 for ; Fri, 15 Feb 2002 11:56:53 -0500 (EST) Message-ID: <3C6D3E4C.551F17C6@steltor.com> Date: Fri, 15 Feb 2002 11:58:52 -0500 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: CAP Consensus: relativeCALID References: <3C6C6D39.1B137AD9@netscape.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 Steve Mansour wrote: > > Folks, > > There still some open issues on relativeCALID . How about replacing section 2.6 by the following two sections? It think this proposal reflects what had been previously agreed on the list. See: http://www.imc.org/ietf-calendar/mail-archive/msg02574.html Let me know if you feel it should be more verbose. 2.x CAP URL The CAP URL scheme is used to designate calendar stores, and calendars accessible using the CAP protocol. The CAP URL scheme conform to the generic URL syntax, defined in RFC 2396, and follows the Guidelines for URL Schemes, set forth in RFC 2718. A CAP URL begins with the protocol prefix "cap" and is defined by the following grammar. capurl = scheme ":" [ "//" [ csid ] ] [ "/" relcalid ] scheme = "cap" csid = hostport ; As defined in Section 3.2.2 of RFC 2396 relcalid = *uric ; As defined in Section 2 of RFC 2396 'relcalid' is an identifier that uniquely identifies a calendar on a particular calendar store. There is no implied structure in a Relative CALID. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store. Examples: cap://cal.example.com cap://cal.example.com/abcd1234QWER cap:///abcd1234QWER cap:/abcd1234QWER Relative CAP URLs are permitted and are resolved according to the rules defined in Section 5 of RFC 2396. Example of a relative CAP URL: abcd1234QWER 2.x Calendar Addresses Calendar addresses can be described as absolute or relative CAP URLs. Examples: cap://cal.example.com/abcd1234QWER cap:///abcd1234QWER cap:/abcd1234QWER abcd1234QWER For a user currently authenticated to the CAP server on cal.example.com, all four addresses refer to the same calendar. Regards, 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 Feb 15 12:49:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13796 for ; Fri, 15 Feb 2002 12:49:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FHZ0g08734 for ietf-calendar-bks; Fri, 15 Feb 2002 09:35:00 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FHYw308730 for ; Fri, 15 Feb 2002 09:34:58 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP Consensus: relativeCALID MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 15 Feb 2002 12:42:55 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/15/2002 12:43:08 PM, Serialize complete at 02/15/2002 12:43:08 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > cap://cal.example.com/abcd1234QWER > cap:///abcd1234QWER > cap:/abcd1234QWER > abcd1234QWER > > For a user currently authenticated to the CAP server on > cal.example.com, all four addresses refer to the same > calendar. Why would you use anything except the first or fourth? The middle two are just longer versions of the fourth; and supporting them takes extra complexity. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |But this one goes to 11x. | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 15 13:19:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14736 for ; Fri, 15 Feb 2002 13:19:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FI8uQ09599 for ietf-calendar-bks; Fri, 15 Feb 2002 10:08:56 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FI8t309594 for ; Fri, 15 Feb 2002 10:08:55 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA23638 for ; Fri, 15 Feb 2002 13:08:51 -0500 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 g1FI8pQ20675 for ; Fri, 15 Feb 2002 13:08:51 -0500 (EST) Subject: CAP: Scope of stored VQUERY. From: Patrice Lapierre To: "ietf-calendar@imc.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 13:16:09 -0500 Message-Id: <1013796969.21000.170.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 The "search", "modify", "move" and "delete" commands can refer to a stored VQUERY by providing only the QUERYNAME. e.g., BEGIN:VQUERY QUERYNAME:MyQueryName END:VQUERY I see some issues with this: (1) For localization and consistency with VCAR and VAGENDA, it seems that a QUERYID should be used to identify the VQUERY, and a property NAME should by used for a localizable display name. (2) QUERYNAME (or QUERYID in this proposition) is overloaded. i. In a stored VQUERY it is used as an identifier for the current query. ii. When referring to a stored VQUERY it is used as a search criteria (or pointer) to identify a stored VQUERY. For (ii) it seems that a distinct property should be used (e.g., QUERYREF). This would also allow stored VQUERY to refer to another stored VQUERY. (3) It is not specified where the server should search for the stored VQUERY. It seems that a TARGET property (or a parameter to QUERYREF) should be added to VQUERY to indicate the location of a stored VQUERY, the omission of the property would mean the VCALSTORE. Examples of stored VQUERYs: BEGIN:VQUERY QUERYID:query-01 NAME:All VEVENTs. QUERY:SELECT * FROM VEVENT END:VQUERY BEGIN:VQUERY NAME:A stored query that makes reference to query-01 NAME;LANGUAGE=fr-CA:Requete faisant reference a query-01 QUERYID:query-foo QUERYREF:query-01 TARGET:relcalid-1 END:VQUERY To use a stored VQUERY with the QUERYID set to query-01, and located in the VAGENDA with the CALID relcalid-01, the following VQUERY should be passed to the command: BEGIN:VQUERY QUERYREF:query-01 TARGET:relcalid-01 END:VQUERY -- Patrice. From owner-ietf-calendar@mail.imc.org Fri Feb 15 13:41:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15144 for ; Fri, 15 Feb 2002 13:41:08 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FIQOG10256 for ietf-calendar-bks; Fri, 15 Feb 2002 10:26:24 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FIQN310252 for ; Fri, 15 Feb 2002 10:26:23 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA24037 for ; Fri, 15 Feb 2002 13:26:20 -0500 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 g1FIQJQ22804 for ; Fri, 15 Feb 2002 13:26:19 -0500 (EST) Message-ID: <3C6D5343.E83BCE5F@steltor.com> Date: Fri, 15 Feb 2002 13:28:19 -0500 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: CAP Consensus: relativeCALID 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: > > > cap://cal.example.com/abcd1234QWER > > cap:///abcd1234QWER > > cap:/abcd1234QWER > > abcd1234QWER > > > > For a user currently authenticated to the CAP server on > > cal.example.com, all four addresses refer to the same > > calendar. > > Why would you use anything except the first or fourth? The middle two are > just longer versions of the fourth; and supporting them takes extra > complexity. I didn't claim the 2nd and 3rd forms were useful. Per RFC 2396, these forms should simply be legal. That's all. Now, to address your complexity concerns, I know that widely used applications have not had much trouble supporting the following equivalent forms of file URL. file:/etc/passwd file:///etc/passwd file://localhost/etc/passwd There are no reasons for CAP URL to be any different. Regards, 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 Feb 15 13:46:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15240 for ; Fri, 15 Feb 2002 13:46:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FIYLt10504 for ietf-calendar-bks; Fri, 15 Feb 2002 10:34:21 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FIYK310500 for ; Fri, 15 Feb 2002 10:34:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA07776 for ; Fri, 15 Feb 2002 10:34:21 -0800 (PST) Message-ID: <3C6D54A7.9F9CB98C@Royer.com> Date: Fri, 15 Feb 2002 11:34:15 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Consensus: relativeCALID References: Content-Type: multipart/mixed; boundary="------------19F29CC5A1916DA531BAF65E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------19F29CC5A1916DA531BAF65E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > > cap://cal.example.com/abcd1234QWER > > cap:///abcd1234QWER > > cap:/abcd1234QWER > > abcd1234QWER > > > > For a user currently authenticated to the CAP server on > > cal.example.com, all four addresses refer to the same > > calendar. > > Why would you use anything except the first or fourth? The middle two are > just longer versions of the fourth; and supporting them takes extra > complexity. I agree with John. The first is a full CALID. The last is a relative CALID But why would you use the 2nd and 3rd? The only time you can use a rel-CALID is when you are already connected to a CAP server and authenticated. So 'cap:' is not needed. --------------19F29CC5A1916DA531BAF65E 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 ; Fri, 15 Feb 2002 14:05:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FIlXV10803 for ietf-calendar-bks; Fri, 15 Feb 2002 10:47:33 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FIlV310799 for ; Fri, 15 Feb 2002 10:47:31 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA24665 for ; Fri, 15 Feb 2002 13:47:28 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1FIlRQ25436 for ; Fri, 15 Feb 2002 13:47:27 -0500 (EST) Message-Id: <5.1.0.14.0.20020215093259.00a73058@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Feb 2002 13:44:00 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: (#1) CAP Synchronization proposal. In-Reply-To: <3C6B42AC.6991FA0F@Royer.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:53 PM 2/13/2002 -0700, Doug Royer wrote:

Because of multiple questions raised on this list, the editors
have decided that we need a "Synchronization" section in CAP.
And because it is a in the CAP requirements document that
a CUA be able to synchronize with a CS.

Here is attempt (#1) at the text for that new section:

I think that the idea of this section is good but it should concentrate simply on showing that it is possible to query for all changes since the last time such a query was done. It should not get into assuming how a sync solution should work. That is for the sync solution implementors of the world to decide and beyond the scope of CAP. We need to be careful not to lecture as to how a sync solution should work and I believe that this version does tread into this area. For example what if a sync solution implementor decides to only sync booked entries? This is perfectly valid but this section makes it sound like you MUST worry about unprocessed ITIP objects. You may want your sync solution to process them, you might not. It is not for CAP to decide. If it does then it is really no different then any other CUA.

I had started my own proposal and I will try and make sure it gets posted before the end of the day (I know that today is a cutoff day for proposals). It actually covers a lot of the same stuff but focus's more on how you get changes as opposed to how you do sync.

I have more comments interspersed below...

-------------------------------------------------------------------------
X. "Synchronization between a CUA and CS"

There are two major issues with synchronization (1), iTIP
updates and dealing with out of order or missing iTIP components,
and (2) updating booked entries.

There are hundreds of major issues with sync and they are all beyond the scope of CAP. With respect to CAP however the main decision you need to make when you query for changes is however, whether you only care about booked entries or whether you also are worried about unprocessed ITIP objects.


Synchronization is a two sided process. That is you need to update
the CUA with any new object from the CS. And any new objects in the
CUA may need to be deposited into the CS.

Synchronization can be a three sided, four sided, n sided process. Being clear on what we mean by Synchronization is important but we should be careful about how we define it.


Below the term "zombie object" will refer to any out of order ITIP
object that is dead but does not yet know it. As in METHOD:CANCEL,
UID:123, SEQUENCE:10 has been processed, and then you get
METHOD:REQUEST, UID:123, SEQUENCE:9. So the second iTIP object is
lurking around
waiting to be reaped by the CUA.

X.1 "iTIP and synchronization"

Only concern if you plan to sync more than just booked entries.


There is no difference between the iMIP handling of iTIP objects
and CAP handling of iTIP messages once the iTIP objects are in the
CUA. So this section will describe some CS and CUA implementation
considerations. Such as how to fetch iTIP objects from the CS, when
to delete them from the CS, and when to leave them in the CS for
later processing.

When to leave them in the CS for later processing??? If it's been processed then that's that. Where in CAP does it describe when a CUA should decide to leave them and when should it scrap them? Perhaps there is such a heuristic defined somewhere but I don't remember it.



This is not a tutorial on how to process iTIP objects. This is
an outline of the problems that may be unique to an iTIP objects
when a CUA is synchronizing with a CS.

The section titled "Query for all Non-Booked Entries" shows examples
of how to fetch for iTIP objects. It is recommended that the CUA
fetch iTIP objects with EXPAND:FALSE in order to simplify the
synchronization process.

Fetching of all of the data booked, not booked, and marked for
delete, SHOULD BE performed using one VQUERY to reduce the
bandwidth by not having to keep sending commands to the
CUA which can be expensive on slow networks.

Perhaps but you just downloaded essentially an entire CU's calendar it's going to be a heavy operation no matter what.

The first step is to fetch all objects where the LAST-MODIFIED
date is greater then the CUAs last synchronization date.

The next step is to pull out any marked METHOD:CREATE (booked).
These may be new or updated objects. Compare them to the
METHOD:CREATE objects in the CUA with the same UID:

    If the CUA does not have that UID - add the new object.

    If the CUA does have that UID:

        compare the SEQUENCE values:

                If the object with the higher SEQUENCE value
                came from the CS drop the one in the CUA
                and have it use the new one from the CS.

                If the object with the higher SEQUENCE value
                is from the CUA, then the CUA must delete the
                older object from the CS and add the newer
                object to the CS.

We need to be much more careful with out wording. Sync solution's have their own policies for conflict resolution when a change has occurred both client side and server side. We are trying to convey that the server sequence is out of date so it isn't meaningful and no change has really occurred on the server so the client change can take precedence but we are not interfering with any policy the sync solution itself may have. This isn't really a sync issue though. Any CUA processing ITIP objects needs to worry about this. This isn't unique to a Sync CUA.


                If the SEQUENCE numbers are the same then keep
                the one with the greater LAST-MODIFIED date.

                        If the one with the older LAST-MODIFIED
                        date is from the CS. Then that object
                        must be deleted from the CS and it
                        must be replaced with the newer one
                        from the CUA.

Absolutely not.  If they have both been changed since the last sync and the sequences show that they are both up-to-date then the sync solution's conflict resolution policy will decide and it is none of CAP's business.


    If the CUA has UIDs that have a LAST-MODIFIED time greater
    than the last synchronization time, and no object came back
    from the query with the same UID, then those new objects
    need to be added or updated in the CS. This will require
    a separate query to determine if they exist at all in the CS
    before deciding if they are new to the CS or need to be
    updated in the CS.

How a sync solution determines if a new object exists or not is none of CAP's business. A typical sync solution keeps some sort of database linking device side ID's with server side ones so entries on the device not yet in the database are new. There is no query required.  Some vendors may decide they do want to make a query with their solution but that is out of scope.


    Now examine the UIDs that you fetched for having METHOD:DELETE.

        The CUA should note the UID and its SEQUENCE value so that
        in later synchronization's the CUA can know that any out of
        order (zombie) iTIP objects can be deleted from the CS and
        otherwise ignored in the CUA. And drop these from the CUA
        and know to later delete them from the CS if the zombie
        objects later arrive.

        At this point the CUA has two choices:

                It can delete those METHOD:DELETE objects from
                the CS with command <delete>.

Do you mean the ITIP object or the booked entry? The ITIP object can be deleted and the booked entry modified and marked METHOD:DELETE.


                Or it can keep them in the CS in case other CUAs
                will be synchronizing with that same calendar and
                will need to know that those UIDs should be deleted
                from the CUAs.

The ITIP object has been processed and therefore should be zapped. The booked entry is now marked method DELETE so other CUAs can see this.


                It is up to the CUA or CU and the CS or CS
                administrator to decide when the METHOD:DELETE
                object are to be deleted from the CS. And this
                is not specified in CAP.

It should be. A CUA which processes an ITP cancel should mark the booked entry as METHOD:DELETE. 


    Now start processing the iTIP object in the CUA just like
    you would as described in iTIP and iMIP. Then for each of
    those iTIP object that were processed, update the CS with
    the latest version of the object, followed by drop those
    processed iTIP objects from both the CUA and delete them
    from the CS.

    Any iTIP objects that can not be processed yet (example, a
    METHOD:COUNTER, UID:abc, SEQUENCE:1 when you have not yet have
    METHOD:REQUEST, UID:abc in the CUA or CS). These would be left
    in the CS until the CUA or CU and the CS or CS administrator
    decided that they were zombies or just too old to care about
    and then they would be deleted from the CS. And their LAST-MODIFIED
    time MUST BE updated in the CS so that they would continue to
    be fetched for the next synchronization until they were used
    or deleted.

The CUA MUST update the LAST-MODIFIED times of any object that
it updates or adds to the CS. This needs to be done by the
CUA and not the CS in order for there not to be a race condition
that is caused by the CUA object always being older than
the same object in the CS.

Out of scope. All Sync solution implementors know they have to do something to ensure that the changes they initiated don't come back the next time they ask for changes. How they do  so is implentation specific. There are hundreds of other things you should be aware of when doing a sync but just like this one it is out of scope for CAP.


Some optimizations can be done. For example the CUA may
just use <modify> and not <delete> followed by <create> to
update the CS. And many of the updates, deletes, and creates
could be combined and processed at the end, or as they are
determined, which ever works best for the implementations.

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@steltor.com
http://www.steltor.com



 From owner-ietf-calendar@mail.imc.org Fri Feb 15 14:06:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15860 for ; Fri, 15 Feb 2002 14:06:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FIqY010911 for ietf-calendar-bks; Fri, 15 Feb 2002 10:52:34 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FIqX310907 for ; Fri, 15 Feb 2002 10:52:33 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Scope of stored VQUERY. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 15 Feb 2002 14:00:30 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/15/2002 02:00:44 PM, Serialize complete at 02/15/2002 02:00:44 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >(1) For localization and consistency with VCAR and VAGENDA, > it seems that a QUERYID should be used to identify the VQUERY, > and a property NAME should by used for a localizable > display name. That might be worthwhile, yeah. It should probably be possible to provide multiple localized variants of the display name. For queries submitted by a CUA for the same user to use later, it wouldn't matter; but, if the CS provides convenient predefined searches, then it may need to provide the name in multiple languages. >(2) QUERYNAME (or QUERYID in this proposition) is overloaded. Perhaps, but it's not ambiguous. "Search by name" and "My name is" are clearly distinct. Having to say "Search by reference" and "My name is" is less clear, because it's not obvious that "reference" corresponds to "name". /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 15 14:20:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16411 for ; Fri, 15 Feb 2002 14:20:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FJA6l11390 for ietf-calendar-bks; Fri, 15 Feb 2002 11:10:06 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FJA5311386 for ; Fri, 15 Feb 2002 11:10:05 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP Consensus: relativeCALID MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 15 Feb 2002 14:18:02 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/15/2002 02:18:15 PM, Serialize complete at 02/15/2002 02:18:15 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I didn't claim the 2nd and 3rd forms were useful. >Per RFC 2396, these forms should simply be legal. I disagree. Remember, the syntaxes in RFC-2396 are examples, rather than normative. (For example, see the Abstract, which says, "This document does not define a generative grammar for URI".) In particular, section 3 ("URI Syntactic Components"), opens with the sentence: "The URI syntax is dependent upon the scheme." My reading of the rest of the section is that a URI such as cap:///relcalid would be primarily for schemes which have heirarchical paths, but no server component. (The file: URL scheme is old, strange, and confusing--it is a terrible idea, UI-wise, for file:/foo and file:///foo to be equivalent.) And the distinction between scheme:/id and scheme:id is for schemes which have heirarchical paths; calids are not. I say we should support only "cap://server/id" and "id". /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |Go not to the Vorlons for advice, for they will say both no and| |sherbert. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 15 15:58:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19367 for ; Fri, 15 Feb 2002 15:58:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FKcaK13710 for ietf-calendar-bks; Fri, 15 Feb 2002 12:38:36 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FKcY313706 for ; Fri, 15 Feb 2002 12:38:34 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA27633 for ; Fri, 15 Feb 2002 15:38:31 -0500 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 g1FKcLQ08037 for ; Fri, 15 Feb 2002 15:38:21 -0500 (EST) Subject: Re: CAP: Scope of stored VQUERY. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 15:45:39 -0500 Message-Id: <1013805940.21001.278.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 Fri, 2002-02-15 at 14:00, John Stracke wrote: ... > >(2) QUERYNAME (or QUERYID in this proposition) is overloaded. > > Perhaps, but it's not ambiguous. "Search by name" and "My name is" are > clearly distinct. True they are distinct. But I dislike having the semantic of a property being dependent of the presence of other properties. e.g., if the "search" command receives: BEGIN:VQUERY QUERYNAME:MyQuery END:VQUERY the meaning is: find and use a stored VQUERY named MyQuery. However if the "search" command receives: BEGIN:VQUERY QUERYNAME:MyQuery QUERY:SELECT * FROM VEVENT END:VQUERY the meaning is: use the given VQUERY which happens to be named MyQuery. > Having to say "Search by reference" and "My name is" is > less clear, because it's not obvious that "reference" corresponds to > "name". I don't understand, the proposal is: - All stored VQUERYs must have a unique QUERYID within its scope (VQUERYs that are not stored don't need a QUERYID). - The NAME property is only for display name (not to be used by QUERYREF). - QUERYREF and TARGET are used to uniquely identify a stored VQUERY within a CS. To use a stored VQUERY the only thing that must be provided is the location (TARGET) and the id (QUERYREF) of the query. So you would not have to say "Search by reference" and "My name (or id) is", unless your intent is to create a new stored VQUERY that refers to another stored VQUERY (which was not be possible with the previous proposal). -- Patrice. From owner-ietf-calendar@mail.imc.org Fri Feb 15 16:33:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20301 for ; Fri, 15 Feb 2002 16:33:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FLD2014538 for ietf-calendar-bks; Fri, 15 Feb 2002 13:13:02 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FLD1314534 for ; Fri, 15 Feb 2002 13:13:01 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA28880 for ; Fri, 15 Feb 2002 16:12:58 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1FLCvQ12535 for ; Fri, 15 Feb 2002 16:12:58 -0500 (EST) Message-Id: <5.1.0.14.0.20020215134429.00a73058@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Feb 2002 16:00:57 -0500 To: ietf-calendar@imc.org From: Mark Paterson Subject: Alternative CAP Sync Proposal Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable
X. Synchronisation and CAP

The need for data synchronisation exists today.  Due to the exponential growth of mobile devices and user=92s needs for instant access the potential for =93islands of communication=94 exists. The continued expansion of data on devices and applications is accelerating the need for Data Synchronisation to manage these =93islands=94.  Recognizing this reality it is important that CAP not inhibit the ability for data synchronisation solutions to be implemented.

Synchronisation from the perspective of CAP is seen as=85

=93the process of exchanging information between multiple physical or virtual locations for the purpose of ensuring that each location's copy of that information reflects the same information content=94  WAP-234-SYNC-20010207-draft

[Editor=92s NOTE: I need to hunt down the exact WAP Spec #]

Based on this perspective it is therefore important that data synchronisation solutions be able to query a CAP compliant CS for all changes within a range of time, meaning at a minimum that the CUA is able to find and retrieve new, modified or deleted entries for a given time period. This section will attempt through explanation and example to show that this is possible however it is not meant to be exhaustive. It will do its best not make any assumptions about how a data synchronisation solution should work and stick to the topic of querying for changes.

The most important concept for data synchronisation solutions to understand is that all objects within a CAP CS have a LAST-MODIFIED property that is updated whenever the object is changed. By saving the last time a synchronisation was performed a data synchronisation solution can use this value in any VQUERY it builds up in comparison with the LAST-MODIFIED property to determine changes since the last time a synchronisation was performed.

The example below looks for changes to booked (METHOD =3D =91CREATE=92) VEVE= NT entries that occur within a given range (using DTSTART).

BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT WHERE
DTSTART < upper range AND
DTSTART > lower range AND
METHOD =3D 'CREATE' AND LAST-MODIFIED > last time asked
END:VQUERY

As all booked entries will have a unique UID (as specified in [ICAL]), data synchronisation solutions that save these UIDs can then process through the results of the query above and determine all newly booked entries (those objects returned with UIDs that are not recognized) and all modified pre-existing booked entries (those objects returned with UIDs that are recognized). For deleted entries it must be understood that booked entries will NOT actually be removed but rather will be modified and marked with METHOD:DELETE so they will be reported as modifications and can be picked out by looking for METHOD:DELETE.
 
This simple example would therefore seem to provide data synchronisation solutions with what they need however there are some limitations that should be understood.

The above example allows data synchronisation solutions to determine what has been deleted by recognizing objects with METHOD:DELETE within the modifications. Although this works nicely for non-recurring booked entries it will not catch instances of a recurring booked entry that may no longer exist as the recurrence, upon expansion, will no longer lead to an instance that falls within the range that the query is covering. Depending on a data synchronisation solution=92s approach therefore it may be necessary to also query to see if any recurring entry that should have caused an instance to fall within range in the past has changed and if so whether this change is actually something that should be considered as a delete to the data synchronisation solution.

It is also very important to note that the example given above has only looked for changes to booked entries. It has not taken into consideration possible unprocessed ITIP objects. Booked entries cannot be considered up-to-date until all ITIP objects have been processed. If data synchronisation solutions want to ensure that the booked entries are completely up-to-date then it must first process the changed non-booked entries (unprocessed ITIP objects). In such a case data synchronisation solutions are no different then any other CUA and must process the ITIP objects as specified in section XX, =93XXXXX=94.

[Editor=92s NOTE: I need put the right section reference]

At a minimum a CUA is able to find and retrieve new, modified or deleted entries for a given time period therefore data synchronisation solutions should be possible.

--
Mark Paterson
Director, Client R&D
Steltor
mailto:markp@steltor.com
http://www.steltor.com



 From owner-ietf-calendar@mail.imc.org Fri Feb 15 16:33:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20313 for ; Fri, 15 Feb 2002 16:33:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FLLnw14750 for ietf-calendar-bks; Fri, 15 Feb 2002 13:21:49 -0800 (PST) Received: from postman.incentivesystems.com ([66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FLLm314745 for ; Fri, 15 Feb 2002 13:21:48 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Scope of stored VQUERY. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 15 Feb 2002 16:29:44 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/15/2002 04:29:59 PM, Serialize complete at 02/15/2002 04:29:59 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > True they are distinct. But I dislike having the semantic >of a property being dependent of the presence of other >properties. A problem, but not a big one--and one that we already have to deal with, since iCalendar itself is full of properties with interdependent semantics. >> Having to say "Search by reference" and "My name is" is >> less clear, because it's not obvious that "reference" corresponds to >> "name". > To use a stored VQUERY the only thing that must be provided >is the location (TARGET) and the id (QUERYREF) of the query. The point is that it is nonobvious that REF means NAME. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |"All gateways lose information. Some do it more efficiently than| |others." -- Einar Stefferud | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 15 17:45:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22263 for ; Fri, 15 Feb 2002 17:45:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FMOiF16316 for ietf-calendar-bks; Fri, 15 Feb 2002 14:24:44 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FMOg316312 for ; Fri, 15 Feb 2002 14:24:42 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA30255 for ; Fri, 15 Feb 2002 17:24:40 -0500 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 g1FMOdQ20148 for ; Fri, 15 Feb 2002 17:24:40 -0500 (EST) Subject: Re: CAP: Scope of stored VQUERY. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 17:31:57 -0500 Message-Id: <1013812318.21000.336.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 Fri, 2002-02-15 at 16:29, John Stracke wrote: ... > > > To use a stored VQUERY the only thing that must be provided > >is the location (TARGET) and the id (QUERYREF) of the query. > > The point is that it is nonobvious that REF means NAME. > REF does not mean name but id, however the confusion proves your point. How about using a less ambiguous name such as "QUERYIDREF" or "STOREDQUERYIDREF" instead? From owner-ietf-calendar@mail.imc.org Fri Feb 15 18:02:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22697 for ; Fri, 15 Feb 2002 18:02:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FMqMl16713 for ietf-calendar-bks; Fri, 15 Feb 2002 14:52:22 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FMqL316709 for ; Fri, 15 Feb 2002 14:52:21 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA30513 for ; Fri, 15 Feb 2002 17:52:19 -0500 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 g1FMqIQ22504 for ; Fri, 15 Feb 2002 17:52:18 -0500 (EST) Message-ID: <3C6D919A.1C84D7C4@steltor.com> Date: Fri, 15 Feb 2002 17:54:18 -0500 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: CAP Consensus: relativeCALID 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 didn't claim the 2nd and 3rd forms were useful. > >Per RFC 2396, these forms should simply be legal. > > I disagree. Remember, the syntaxes in RFC-2396 are examples, rather than > normative. (For example, see the Abstract, which says, "This document does not define a generative grammar for URI".) In particular, section 3 ("URI Syntactic Components"), opens with the sentence: "The URI syntax is dependent upon the scheme." My reading of the rest of the section is that a URI such as > cap:///relcalid would be primarily for schemes which have heirarchical > paths, but no server component. (The file: URL scheme is old, strange, > and confusing--it is a terrible idea, UI-wise, for file:/foo and > file:///foo to be equivalent.) And the distinction between scheme:/id and > scheme:id is for schemes which have heirarchical paths; calids are not. I tell you what. I don't care. All URL schemes that I know of allow this, but if this WG insists in doing things differently, so be it. Don't worry about me. I'll manage the added complexity: if (!csid.empty()) { capurlstr << "cap://" << csid << "/" << relcalid << ends; } else { capurlstr << relcalid << ends; } versus capurlstr << "cap://" << csid << "/" << relcalid << ends; Sigh! Regards, 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 Feb 15 18:11:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22908 for ; Fri, 15 Feb 2002 18:11:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FN26V16905 for ietf-calendar-bks; Fri, 15 Feb 2002 15:02:06 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FN24316901 for ; Fri, 15 Feb 2002 15:02:04 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA30618 for ; Fri, 15 Feb 2002 18:02:02 -0500 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 g1FN22Q23403 for ; Fri, 15 Feb 2002 18:02:02 -0500 (EST) Subject: CAP: Functions to manipulate time in CAP-QL From: Patrice Lapierre To: "ietf-calendar@imc.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Feb 2002 18:09:19 -0500 Message-Id: <1013814560.21001.375.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 The CAP-QL seems to be missing operations to manipulate values of type DATE, TIME and DATE-TIME. The operations currently supported are: (1) =, !=, <, <=, >, >= which seems required. (2) LIKE operator. Which does add some functionality, but was designed for TEXT and doesn't seem adequate for DATE-TIME operations. i.e., - As shown in the proposed text, it can be used to test for exact match on a portion of a DATE-TIME, but is not well suited for other operations (e.g. search for all VEVENTs that starts before 8h30). - Cannot extract information that is not directly visible from a DATE-TIME (e.g., WEEKDAY, timezone conversion, ...). I propose to add new functions to CAP-QL to extract information from a DATE-TIME value. Each function would have the following format: FUNCTIONNAME( VALUE, TIMEZONE ) Where VALUE must be of type DATE, TIME or DATE-TIME. And TIMEZONE of type TZID or NULL to indicate UTC. The type of the returned value is dependent on the function, but NULL is returned when the information is not available (e.g, when trying to extract the hour of a value of type DATE). Here the proposed functions: Function name: TIME Returned type: TIME Function description: When available returns the TIME portion of VALUE in the given TIMEZONE, returns NULL if not available. Function name: WEEKDAY Returned type: TEXT Function description: When available returns the weekday ("SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA") of VALUE in the given TIMEZONE. Returns NULL if the information if not available. Function name: WEEKNO Type of returned value: INTEGER Function description: When available returns the WEEKNO (1 to 51) of VALUE in the given TIMEZONE, returns NULL otherwise. Function name: MONTH Returned type: INTEGER Function description: When available returns the month (1 to 12) of VALUE in the given TIMEZONE, returns NULL otherwise. Function name: YEAR Return type: INTEGER Function description: Function description: When available returns the year (0 to 9999) of VALUE in the given TIMEZONE, returns NULL otherwise. Function name: HOUR Return type: INTEGER Function description: When available returns the hour (0 to 23) of VALUE in the given TIMEZONE, returns NULL otherwise. Function name: MINUTE Return type: INTEGER Function description: When available returns the minute (0 to 59) of VALUE in the given TIMEZONE, returns NULL otherwise. Function name: SECONDS Return type: INTEGER Function description: When available returns the second (0 to 59) of VALUE in the given TIMEZONE, returns NULL otherwise. Function name: MONTHDAY Return type: INTEGER Function description: When available returns the day of the month (1 to 31) of VALUE in the given TIMEZONE. Returns NULL if the information is not available. Function name: NEGMONTHDAY Return type: INTEGER Function description: When available returns the day of the month (1 to 31) starting from the end. Returns NULL if not available. Examples: Query for VEVENTs starting outside office hours. SELECT * FROM VEVENT WHERE WEEKDAY(DTSTART,'US-Eastern') = 'SA' OR WEEKDAY(DTSTART,'US-Eastern') = 'SU' OR TIME(DTSTART,'US-Eastern') > '170000' OR TIME(DTSTART,'US-Eastern') < '080000' Query all VEVENTs that intersect with lunch time (say 12h-13h) in the timezone of the starttime of the event: SELECT * FROM VEVENT WHERE HOUR(DTSTART, PARAM(DTSTART,TZID)) <= '13' AND HOUR(DTEND, PARAM(DSTART,TZID)) >= '12' -- Patrice. From owner-ietf-calendar@mail.imc.org Fri Feb 15 18:28:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23132 for ; Fri, 15 Feb 2002 18:28:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1FNFXK17092 for ietf-calendar-bks; Fri, 15 Feb 2002 15:15:33 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FNFW317088 for ; Fri, 15 Feb 2002 15:15:32 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA30697 for ; Fri, 15 Feb 2002 18:15:29 -0500 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 g1FNFTQ24631 for ; Fri, 15 Feb 2002 18:15:29 -0500 (EST) Message-ID: <3C6D9709.D75F6D4@steltor.com> Date: Fri, 15 Feb 2002 18:17:29 -0500 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: Consensus? BEEP commands References: <3C6AEFDB.EBA6B615@Royer.com> <1013708368.7902.264.camel@c-1241.in.steltor.com> <3C6C7BF4.CDB0FE86@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: > > Patrice Lapierre wrote: > > > > Before modifying the draft could you send the new suggested > > XML DTD for CAP commands, and complete example of each > > commands and the associated response (including the "move" > > command), they could be the one from the draft (they'll > > need to be adjusted anyway). > > The examples of the new commands were in the text I sent. > For them most part they are one line > With the optional latency and cmdid and when sending > iCalendar data followed by CDATA > > > CDATA > Send the examples on the list before adding them to the draft. What was sent is not sufficient for us to agree. > DTD - I am not a DTD expert - I was hoping to get the text > close then get some help with DTD's. Sure. Regards, 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 Feb 15 22:07:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26534 for ; Fri, 15 Feb 2002 22:07:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1G2eCR25880 for ietf-calendar-bks; Fri, 15 Feb 2002 18:40:12 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1G2eB325876 for ; Fri, 15 Feb 2002 18:40:11 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA08287 for ; Fri, 15 Feb 2002 18:40:14 -0800 (PST) Message-ID: <3C6DC67C.51A6BB61@Royer.com> Date: Fri, 15 Feb 2002 19:39:56 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Functions to manipulate time in CAP-QL References: <1013814560.21001.375.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------A18D6B5FC525388F983657B6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A18D6B5FC525388F983657B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > The CAP-QL seems to be missing operations to manipulate > values of type DATE, TIME and DATE-TIME. Sounds like a great post-CAP is RFC add on, but we don't NEED it to get CAP out the door. --------------A18D6B5FC525388F983657B6 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 ; Fri, 15 Feb 2002 22:09:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1G2ich25996 for ietf-calendar-bks; Fri, 15 Feb 2002 18:44:38 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1G2ia325992 for ; Fri, 15 Feb 2002 18:44:36 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA08295 for ; Fri, 15 Feb 2002 18:44:39 -0800 (PST) Message-ID: <3C6DC785.FFFBD93B@Royer.com> Date: Fri, 15 Feb 2002 19:44:21 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Scope of stored VQUERY. References: <1013796969.21000.170.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------C483CAA75520C0039274B333" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C483CAA75520C0039274B333 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > The "search", "modify", "move" and "delete" commands can > refer to a stored VQUERY by providing only the QUERYNAME. > > e.g., > > BEGIN:VQUERY > QUERYNAME:MyQueryName > END:VQUERY > > > I see some issues with this: > > (1) For localization and consistency with VCAR and VAGENDA, > it seems that a QUERYID should be used to identify the VQUERY, > and a property NAME should by used for a localizable > display name. > > (2) QUERYNAME (or QUERYID in this proposition) is overloaded. > > i. In a stored VQUERY it is used as an identifier for the > current query. It is used as the ID for the current query. > ii. When referring to a stored VQUERY it is used as a > search criteria (or pointer) to identify a stored > VQUERY. In both cases it is an ID. You can give it an ID and you can fetch it by ID. I could agree that we change it to QUERYID as it is an "ID" and not a "NAME" , and add and optional NAME property to VQUERY. Other than that I don't see that it is overloaded. --------------C483CAA75520C0039274B333 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 ; Fri, 15 Feb 2002 22:14:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1G2mic26121 for ietf-calendar-bks; Fri, 15 Feb 2002 18:48:44 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1G2mg326117 for ; Fri, 15 Feb 2002 18:48:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA08305 for ; Fri, 15 Feb 2002 18:48:45 -0800 (PST) Message-ID: <3C6DC87A.CA361A22@Royer.com> Date: Fri, 15 Feb 2002 19:48:26 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Ordering of the components returned by the search command. References: <1013789612.21000.79.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------25629E4ED3E3EEFE7003A855" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------25629E4ED3E3EEFE7003A855 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > The latest proposal for CAP-QL states the following for the ordering > of components returned by the search command: > > I see some problems/limitations with this approach: > > (1) Often a CUA is not interested in any particular ordering. > Yet for VEVENTs an ordering is always defined. This causes > unnecessary processing on the server side. The (old) debate was that the default fetch should be by DATE or RECURRANCE-ID in UTC. That evolved into what it is now. > (2) When selecting everything (SELECT *) from a VEVENT. The > CUA might be interested in another ordering than DTSTART > (or RECURRENCE-ID). > (3) When selecting everything (SELECT *) from a component > that doesn't include a DTSTART, no ordering can be specified. Not true, it is on the 1st item in the SELECT clause. > (4) If the first property in the a select clause occurs more than > once, the ordering is not defined. Yes it is, it is by the first item in the SELECT clause. > (5) If the first property in the select clause is not present, > the ordering is not defined. It has to have at least one item in the SELECT clause or it is not a valid QUERY: QUERY:SELECT FROM VEVENT ; Is not valid. > To address these issues, I propose the addition of an optional > "ORDER BY" clause (as in SQL). When not present no ordering is specified > (this solves (1)). We already beat this down and decided it could be an add on. --------------25629E4ED3E3EEFE7003A855 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 ; Fri, 15 Feb 2002 22:27:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1G2x1R26325 for ietf-calendar-bks; Fri, 15 Feb 2002 18:59:01 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1G2x0326321 for ; Fri, 15 Feb 2002 18:59:00 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA08309 for ; Fri, 15 Feb 2002 18:59:02 -0800 (PST) Message-ID: <3C6DCAE4.46E7E14B@Royer.com> Date: Fri, 15 Feb 2002 19:58:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alternative CAP Sync Proposal References: <5.1.0.14.0.20020215134429.00a73058@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------CF9F0735DC02472B9D054873" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CF9F0735DC02472B9D054873 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > Based on this perspective it is therefore important that data > synchronisation solutions be able to query a CAP compliant CS for all > changes within a range of time, meaning at a minimum that the CUA is > able to find and retrieve new, modified or deleted entries for a given > time period. This section will attempt through explanation and example > to show that this is possible however it is not meant to be > exhaustive. It will do its best not make any assumptions about how a > data synchronisation solution should work and stick to the topic of > querying for changes. The text above would have been great for the requirement document, but not for CAP. If you are SURE that NO other CUA will access the same calendar, your proposal is worth considering. But that is just not true in all cases. You have to get all BOOKED, iTIP, and DELETE objects in one query. You have to process any updated BOOKED and DELETE objects before the iTIP entries. If you don't another CUA could have changed the state of the objects and you are synching with phantom data. If more that one CUA is going to be doing a sync. You MUST sync both directions. This proposal did not have any specific methods that would allow N number CUAs to all be in sync. (or CUA-bots) It is NOT up to the CUA to worry about sync. If all CUA do not sync the same way or in the same order - then you can be chasing updates all day long. --------------CF9F0735DC02472B9D054873 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 ; Sat, 16 Feb 2002 12:57:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1GHeEs26011 for ietf-calendar-bks; Sat, 16 Feb 2002 09:40:14 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GHeC326007 for ; Sat, 16 Feb 2002 09:40:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA08997 for ; Sat, 16 Feb 2002 09:40:13 -0800 (PST) Message-ID: <3C6E9979.61B01976@Royer.com> Date: Sat, 16 Feb 2002 10:40:09 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#1) synchronization part 2, and identifying a componentsVALARM References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> <3BFEBEE2.2F736E3D@Royer.com> <3C221F20.D92B2355@steltor.com> <3C238743.61387D6F@Royer.com> <5.1.0.14.0.20020215092245.03617df8@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------1C6A6625B00AF18AA869D6C4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1C6A6625B00AF18AA869D6C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > > ... > > BEGIN:VALARM > > SEQUENCE:2 > > TRIGGER;ENABLE=false:20020101T000000Z > > SUMMARY:NEW YEAR > > ... > > END:VALARM > > BEGIN:VALARM > > SEQUENCE;SCOPE=local:0 > > Shouldn't that be SEQUENCE;LOCAL=true;0 like you did above ? They are independent. You can ENABLE or disable a GLOBAL VALARM trigger. That allows a CU to ignore any VALARMs in their calendar if needed that were added as part of a REQUEST, PUBLISH, or whatever. --------------1C6A6625B00AF18AA869D6C4 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 ; Sat, 16 Feb 2002 16:20:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1GL7s901473 for ietf-calendar-bks; Sat, 16 Feb 2002 13:07:54 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GL7p301467 for ; Sat, 16 Feb 2002 13:07:51 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA09132 for ; Sat, 16 Feb 2002 13:07:52 -0800 (PST) Message-ID: <3C6ECA22.7CCA6AD5@Royer.com> Date: Sat, 16 Feb 2002 14:07:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAL-QUERY value type Content-Type: multipart/mixed; boundary="------------2EE5658D33ADB513BD7E4BFF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2EE5658D33ADB513BD7E4BFF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is the CAL-QUERY value type to be included into CAP. The CAL-QL section will be submitted separately. -------------------------------------------------------------------- x.x.1 Property Value Data Types x.x.1.2 CAP-QUERY Value Type To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property value type. Value Name: CAP-QUERY Value Type Purpose: To define a selection language for identifying the contents of iCalendar objects. This was based on [SQL92] and [SQLCOM]. NOTE: This grammar is NOT SQL92. (1) All components look like tables for the purpose of a QUERY including VALARM. And their contained properties looked like columns in those tables. (2) All VAGENDAs and CS's look like tables for the purpose of a QUERY. And all of their properties look like columns in those tables. (3) You CAN NOT do any cross component-type joins. And that means you can ONLY have one component, OR one VAGENDA OR one CALSTORE in the the FROM clause. (4) Everything in the SELECT and WHERE clauses MUST be from the component type, or VAGENDA OR CALSTORE in the FROM clause. This includes the values from the USING_PROPERTIES and USING_COMPONENT clauses. (5) The '.' means . when needed for contained properties or their associated contained components. As long as all were contained (as defined by iCalendar or CAP) in the SINGLE component type named in the FROM clause OR its contained component. (6) A contained component without a '.' it is the same as .* with the result being a properly formatted (s) in the data stream, and correctly formatted in the contained component(s) in iCalendar (RFC2445) format. VALID: (a) SELECT VEVENT. FROM VEVENT (b) SELECT VEVENT.VALARM FROM VEVENT (c) SELECT VALARM FROM VEVENT (d) SELECT VEVENT.* FROM VEVENT (e) SELECT * FROM VEVENT (f) SELECT * FROM VEVENT USING_COMPONENTS VALARM alarm WHERE alarm.TRIGGER < '20020201T000000Z' AND alarm.TRIGGER > '20020101T000000Z' Note: (a) Selects all instances of from all VEVENTs. That (b), and (c) yield the same results. And that is select all VALARMS from all VEVENTS. Note that (d) does not enclose them in BEGIN/END VALARM because you selected the properties from the VALARM and not the VALARM. (e) Selects every property and every component that is in any VEVENTs. (f) Selects all properties and all contained components in all VEVENTS that have a VALARM with a TRIGGER property value between the provided dates and times. NOT VALID: (g) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT (h) SELECT DTSTART,UID FROM VEVENT WHERE VTODO.SUMMARY = "Fix typo in CAP" Note: (g) Is NOT valid because it contains two '.' characters in the SELECT clause. (h) Is NOT valid because it mixes VEVENT and VTODO properties in the same QUERY. (7) When multiple QUERY properties are supplied in a single component that contains a QUERY, the results are the same as a logical 'OR'. That is all conditions that match any of the QUERY property values returned. Formal Definition: The value type is defined by the following notation: comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VAGENDA" / "VCAR" / "CALSTORE" / "VQUERY" / iana-name / x-comp querycomp = queries / ( queryname queries) / queryname queryname = "QUERYNAME" *(";" xparam) ":" text CRLF queries = query / queries query query = "QUERY" *(";" xparam) ":" capselect CRLF ; NOTE: There is exactly one space separating ; the various parts of capselect ; capselect = "SELECT" SP cap-cols SP "FROM" SP comp-name SP *(cauprops SP / capcprops SP) "WHERE" SP cap-expr / "SELECT" SP cap-cols SP "FROM" SP comp-name capuprops = "USING_PROPERTIES" SP uprop-list uprop-list = (cap-col SP cap-local) / uprop-list SP cap-col SP cap-local capcprops = "USING_COMPONENTS" SP cprop-list cprop-list = (cap-comp cap-local) / cprop-list SP cap-col SP cap-local cap-col = ; Any property name found in the component ; named in the comp-tbl used in the FROM clause. ; ; SELECT ORGANIZER FROM VEVENT ... ; ; OR ; ; A component name of an existing component contained ; inside of the cmp-tbl used in the FROM clause. ; ; SELECT VALARM FROM VEVENT ... ; NOTE: there is NO space around the "," on ; the next line cap-cols = cap-col / ( cap-cols "," cap-col) / "*" / cap-param = ; Any parameter that may be contained in the cap-col ; in the supplied PARAM() function cap-local = ; Any string that is composed of the characters ; that could be a cap-col name, but is not any ; cap-col name. It is suggested that the ; string start with "x-" to ensure it does not ; conflict with any existing or future cap-col name. ; This name MUST BE defined in the cap-using and ; can only be used in cap-expr of the same query. ; And this name is only known and valid for the ; provided query and only for the lifetime of ; the query. If multiple QUERY properties exist ; in the same component, it is only valid and usable ; in the same QUERY property where it was supplied. col-value = col-literal / "SELF()" / "CAL-OWNERS(" cal-address ")" / "CURRENT-CALID()" cal-address = ; A CALID as define by CAP col-literal = "'" literal-data "'" literal-data = ; Any data that matches the value type of the ; column that is being compared. That is you can ; not compare PRIORITY to "some string" because ; PRIORITY has a value type of integer. If it is ; not preceded by the LIKE element, any '%' and '_' ; characters in the literal data are not treated as ; wildcard characters and do not have to be backslash ; escaped. ; ; OR ; ; If the literal-data is preceded by the LIKE ; element it may also contain the '%' and '_' ; wildcard characters. And if the literal data ; that is comparing contains any '%' or '_' ; characters, they MUST BE backslash escaped as ; described in the notes below in order for them not ; to be treated as wildcard characters. cap-ucol = cap-col / cap-local cap-expr = "(" cap-expr ")" / cap-term cap-term = cap-expr SP cap-logical SP cap-expr / cap-factor cap-factor = cap-colval SP cap-oper SP col-value / cap-colval SP "NOT LIKE" SP col-value / cap-colval SP "LIKE" SP col-value / cap-colval SP "IS NULL" / cap-colval SP "IS NOT NULL" / col-value SP "NOT IN" cap-colval" / col-value SP "IN" cap-colval" cap-colval = cap-ucol / "PARAM(" cap-ucol "," cap-param ")" cap-oper = "=" / "!=" / "<" / ">" / "<=" / ">=" cap-logical = "AND" / "OR" SP = ; A single white space ascii character ; (value in HEX %x20). CRLF = ; As defined in RFC 2445. xparam = ; As defined in RFC 2445. x-prop = ; As defined in RFC 2445. x-comp = ; As defined in RFC 2445. (1) There is no ORDERBY. Sorting will take place in the order the columns are supplied in the command. Float and integer values MUST BE sorted by their numeric value. This means the result of a sort on an integer value type will be: 1, 2, 100, 1000 and not 1, 100, 1000, 2 This means the result of a sort on an float value type will be: 1.1, 2.23, 100.332, 1000.12 and not 1.1, 100.332, 1000.12, 2.23 Date and date time values will be sorted by their equivalent value in UTC. No matter what the returned time zone in the result set returns. This is so that if multiple components are returned each in a unique time zone, the results will be sorted in UTC. This does not mean the values must be converted to UTC in the data returned to the CUA. It means the CS must do the sort in UTC. All other values are sorted according to the locale sorting order as specified in the calendar. Or the CS locale if the calendar does not have any locale set, or the host operating system locale if the CS does not specify a locale. And the locale to use for the sort is determined in that order. (2) The CS MUST sort at least the first column. The CS MAY sort additional columns. (3) If the cap-cols is only "*" and nothing else, then: If EXPAND=FALSE sorting will be by the DTSTART value ascending. If EXPAND=TRUE sorting will be by the RECURRENCE-ID value ascending. If one or more DTSTART or RECURRENCE-ID components have exactly the same value, the order for those matching components is unspecified. (4) All literal values are surrounded by single quotes ('), not double quotes ("), and not without any quotes. If the value contains quotes or any other ESCAPED-CHAR, they must be backslash escaped as described in section "4.3.11 Text" of RFC2445. Any LIKE wildcard characters that are part of any literal data that is preceded by a LIKE clause and is not intended to mean wildcard search, MUST BE escaped as described in note (7) below. (5) When comparing DATE-TIME to DATE value types and when comparing DATE to DATE-TIME value types, the result will be true if the DATE value is on the same day as the DATE-TIME value. And they are compared in UTC no matter what time zone the data may actual have been stored in. VALUE-1 VALUE-2 Compare Results 20020304 20020304T123456 TRUE (in UTC-3) (in UTC-3) 20020304 20020304T003456 FALSE (in UTC-4) (in UTC-4) 20020304T003456Z 20020205T003456 FALSE (in UTC-0) (in UTC-7) When comparing DATE and DATE-TIME values with the LIKE clause the comparison will be done as if the value is a RFC2445 DATE or DATE-TIME string value. LIKE '2002%' will match anything in the year 2002. LIKE '200201%' will match anything in January 2002. LIKE '%T000000' will match anything at midnight. LIKE '____01__T%' will match anything for any year or time that is in January. (Four '_', '01', two '_' 'T%'). Again all comparisons will be done in UTC. Using a LIKE value of "%00%, would return any value that contained two consecutive zeros. (6) DTEND and DURATION. When a QUERY contains a DTEND value, then the CS MUST also evaluate any existing DURATION property value and determine if it has an effective end time that matches the QUERY supplied DTEND value or any range of values supplied by the QUERY. When a QUERY contains a DURATION value, then the CS MUST also evaluate any existing DTEND property value and determine if it has an effective duration that matches the QUERY supplied DURATION value or any range of values supplied by the QUERY. As DTEND is the first time that is excluded from a components time range, any DURATION supplied by the QUERY that is exactly one second less than DTEND MUST match the QUERY. And if the DURATION ends exactly at the computed DTEND it MUST NOT match. Any DTEND supplied by the QUERY that is exactly one second more than an end time computed from a DURATION MUST match the QUERY. Any end time that is computed from a DURATION that exactly matches the supplied DTEND MUST NOT match. (6.1) Given a meeting room reserved with a component that contains: DTSTART:20020127T000000Z DTEND:20020127T010000Z The reservation is really from: January 27th, 2002 00:00:00 To: January 27th, 2002,00:59:59 (6.2) Given another meeting room reserved with a component that contains: DTSTART:20020127T000000Z DURATION:P59M59S The reservation is really from: January 27th, 2002 00:00:00 To: January 27th, 2002,00:59:59 (6.3) A QUERY that contains: ... VEVENT.DTSTART = '20020127T00000Z' AND VEVENT.DTEND = '20020127T010000Z' MUST match both (6.1) and (6.2). (6.4) A QUERY that contains: ... VEVENT.DTSTART = '20020127T00000Z' AND DURATION = 'P59M59S' MUST match both (6.1) and (6.2). (7) [NOT] LIKE notes: The pattern matching characters is the '%' that matches zero or more characters, and '_' that matches exactly one character (where character does not always mean octet). LIKE pattern matches always cover the entire string. To match a pattern anywhere within a string, the pattern must start and end with a percent sign. To match a '%' or '_' in the data and not have it interpreted as a wildcard character, they must be backslash escaped. That is to search for a '%' or '_' in the string: LIKE '%\%%' Matches any string with a '%' in it. LIKE '%\_%' Matches any string with a '_' in it. Strings compared using the LIKE clause MUST BE performed using case in-sensitive comparisons. ('a' = 'A'). If LIKE is preceded by 'NOT' then there is a match when the string compare fails. (8) 'col-value SP "NOT IN" cap-colval" This is similar to the LIKE element, except it does value matching and not string comparison matches. property:value1,value2 property:value1,value2 property:value3 paramater="1,2,3" 'value1' IN property would match 'value3' IN property would match 'value' IN property would NOT match '2' IN paramater would match LIKE(property, 'value%') would match LIKE(paramater, '2%') would match The CS must understand the objects being compared and understand how to determine how any multi valued or multi instances properties or parameter values are separated, quoted, and backslash escaped and perform the comparisons as if each value existed by itself and not quoted or backslash escaped when comparing using the CONTAINS() element. If IN is preceded by 'NOT' then there is a match when the value does not exist in the property or parameter value. (9) DATE-TIME and TIME values in a WHEN clause. All DATE-TIME and TIME literal values supplied as in a WHEN clause MUST BE terminated with 'Z'. That means that the CUA MUST supply the values in UTC. Valid: WHERE alarm.TRIGGER < '20020201T000000Z' AND alarm.TRIGGER > '20020101T000000Z' Not valid: WHERE alarm.TRIGGER < '20020201T000000' AND alarm.TRIGGER > '20020101T000000' It is a syntax error and the CS MUST reject the QUERY. --------------2EE5658D33ADB513BD7E4BFF 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 ; Sat, 16 Feb 2002 18:13:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1GN1UZ04482 for ietf-calendar-bks; Sat, 16 Feb 2002 15:01:30 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GN1S304468 for ; Sat, 16 Feb 2002 15:01:28 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA09283 for ; Sat, 16 Feb 2002 15:01:30 -0800 (PST) Message-ID: <3C6EE4C4.18201D91@Royer.com> Date: Sat, 16 Feb 2002 16:01:24 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VQUERY - registration only Content-Type: multipart/mixed; boundary="------------C6DC857F26C92EBF63C2913C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C6DC857F26C92EBF63C2913C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As both the CAP BEEP commands and the VQUERY examples are mixed together. I am going to send them out together. Here is the proposed text for the VQUERY component. (Examples in separate email). ------------------------------------------------------------------------- x.x.x.1 "VQUERY component type" To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME component - VQUERY Component name: VQUERY Property purpose: A component used to contain query information. Conformance: Can be specified in an iCalendar object. Description: This component is used as the container that can hold a query designed to be used by a CUA or a CS. Format definition: NOTE: Properties in iCalendar objects can be in any order. This ABNF below specifies the valid contents of a BEGIN/END VQUERY. The ordering of the properties is not important. Any two VQUERY components that contain exactly the same properties in any random order are equivalent. The same is true for parameters, that is any two properties that contain exactly the same parameters in any random order are equivalent. search = "BEGIN:VQUERY" CRLF 0*1expand *(x-prop) query "END:VQUERY" CRLF ; If not provided, EXPAND defaults to FALSE expand = "EXPAND" *(";" xparam) ":" ( "TRUE" / "FALSE") CRLF --------------C6DC857F26C92EBF63C2913C 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 ; Sat, 16 Feb 2002 18:24:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1GNDco04867 for ietf-calendar-bks; Sat, 16 Feb 2002 15:13:38 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GNDa304862 for ; Sat, 16 Feb 2002 15:13:36 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA09292 for ; Sat, 16 Feb 2002 15:13:38 -0800 (PST) Message-ID: <3C6EE79C.F73F0DDA@Royer.com> Date: Sat, 16 Feb 2002 16:13:32 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: BEEP - new: 3.2 Use of XML, MIME and iCalendar Content-Type: multipart/mixed; boundary="------------5133D9226995B2D82BE96622" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5133D9226995B2D82BE96622 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am proposing that section "3.2 Use of XML, MIME and iCalendar" be replaced with: C: MSG 1 2 . 432 62 C: Content-Type: application/cap+xml C: C: C: END Otherwise, arbitrary MIME content is included in the BEEP payload by using CDATA. C: MSG 1 3 . 1023 489 C: Content-Type: application/cap+xml C: C: C: ]]> C: --------------5133D9226995B2D82BE96622 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 ; Sat, 16 Feb 2002 18:41:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1GNShK05332 for ietf-calendar-bks; Sat, 16 Feb 2002 15:28:43 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GNSf305328 for ; Sat, 16 Feb 2002 15:28:41 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA09304 for ; Sat, 16 Feb 2002 15:28:43 -0800 (PST) Message-ID: <3C6EEB25.2231C507@Royer.com> Date: Sat, 16 Feb 2002 16:28:37 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: BEEP new : "3.3 Bounded Latency" Content-Type: multipart/mixed; boundary="------------EB62961A83C2A94153E831AD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EB62961A83C2A94153E831AD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I propose the example in "3.3 Bounded Latency", be replaced with (Note, in the *original* examples the beep 'msgsize' values were often not correct.) They will be counted exactly in the last call version. --------------------------------------------------------------------- C: MSG 1 4 . 2043 284 C: Content-Type: application/cap+xml C: C: C: = '19990714T080000Z' C: AND DTSTART <= '19990715T080000Z' C: END:VQUERY C: END:VCALENDAR C: END # After 3 seconds S: MSG 1 2 . 102 64 S: Content-Type: application/cap+xml S: S: S: END If Bill wants to continue and give the server more time he would issue a "continue" reply: C: RPY 1 2 . 166 86 C: Content-Type: application/cap+xml C: C: C: END If Bill wants to abort the command and not wait any further he would issue an "abort" reply: C: RPY 1 2 . 166 62 C: Content-Type: application/cap+xml C: C: C: END S: RPY 1 4 . 2723 112 S: S: S: Request Aborted by the CUA. S: S: END --------------EB62961A83C2A94153E831AD 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 ; Sat, 16 Feb 2002 18:43:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1GNXBc05509 for ietf-calendar-bks; Sat, 16 Feb 2002 15:33:11 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GNX9305504 for ; Sat, 16 Feb 2002 15:33:09 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA09310 for ; Sat, 16 Feb 2002 15:33:11 -0800 (PST) Message-ID: <3C6EEC31.379B2C35@Royer.com> Date: Sat, 16 Feb 2002 16:33:05 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New "4.1.4 Example, Query by UID" Content-Type: multipart/mixed; boundary="------------78272E95687816D8E0C13AFF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------78272E95687816D8E0C13AFF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 4.1.4 Example, Query by UID The following example would match the entire content of the VEVENT or VTODO with the UID property equal to "uid123" and not expand any multiple instances of the component. If the CUA does not know if "uid123" was a VEVENT, VTODO, VJOURNAL, or any other component, then all components that the CUA supports MUST be supplied in a QUERY property. This example assumes the CUA only supports VTODO and VEVENT. If the results were empty it could also mean that "uid123" was a property in a component other than a VTODO or VEVENT. BEGIN:VQUERY QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' END:VQUERY The following example would match the entire content of the component with the UID property equal to "uid123" and would expand any instances of the component after applying any recurrence rules. This query could select multiple instances of components each with the same UID. Each instance would have a unique RECURRENCE-ID of the expanded component. BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' END:VQUERY --------------78272E95687816D8E0C13AFF 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 ; Sat, 16 Feb 2002 18:44:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1GNY4205544 for ietf-calendar-bks; Sat, 16 Feb 2002 15:34:04 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GNY3305539 for ; Sat, 16 Feb 2002 15:34:03 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA09319 for ; Sat, 16 Feb 2002 15:34:05 -0800 (PST) Message-ID: <3C6EEC67.8A791A43@Royer.com> Date: Sat, 16 Feb 2002 16:33:59 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New "4.1.5 Query by Date-Time range" Content-Type: multipart/mixed; boundary="------------24879C616AFFF6F8CE2A30F6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------24879C616AFFF6F8CE2A30F6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 4.1.5 Query by Date-Time range This query selects the entire content of every booked VEVENT that has an instance greater than or equal to July 1st, 2000 00:00:00 UTC and less than or equal to July 31st, 2000 23:59:59 UTC BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE RECURRENCE-ID >= '20000801T000000Z' AND RECURRENCE-ID <= '20000831T235959Z' AND METHOD = 'CREATE' END:VQUERY --------------24879C616AFFF6F8CE2A30F6 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 ; Sat, 16 Feb 2002 19:04:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1GNrC706372 for ietf-calendar-bks; Sat, 16 Feb 2002 15:53:12 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GNrA306367 for ; Sat, 16 Feb 2002 15:53:10 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA09333 for ; Sat, 16 Feb 2002 15:53:12 -0800 (PST) Message-ID: <3C6EF0E2.BC64ED36@Royer.com> Date: Sat, 16 Feb 2002 16:53:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New "4.1.6 Query for all Non-Booked Entries" Content-Type: multipart/mixed; boundary="------------02C1D89908D2969A727DBB48" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------02C1D89908D2969A727DBB48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 4.1.6 Query for all Non-Booked Entries The following example selects the entire contents of all [ITIP] non-booked VTODOs and VEVENTs with their METHOD set to one of the [ITIP] METHODs. The default for EXPAND is FALSE, so the recurrence rules will not be expanded. BEGIN:VQUERY QUERYID:Fetch VEVENT and VTODO iTIP components QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' OR METHOD = 'ADD' OR METHOD = 'PUBLISH' OR METHOD = 'CANCEL' OR METHOD = 'REPLY' OR METHOD = 'COUNTER' OR METHOD = 'REFRESH' OR METHOD = 'DECLINECOUNTER' QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' OR METHOD = 'ADD' OR METHOD = 'PUBLISH' OR METHOD = 'CANCEL' OR METHOD = 'REPLY' OR METHOD = 'COUNTER' OR METHOD = 'REFRESH' OR METHOD = 'DECLINECOUNTER' END:VQUERY The following example fetches all VEVENT and VTODO booked entries from the CS. BEGIN:VQUERY QUERYID:Fetch All Booked VEVENT and VTODO components QUERY:SELECT * FROM VEVENT WHERE METHOD = 'CREATE' QUERY:SELECT * FROM VTODO WHERE METHOD = 'CREATE' END:VQUERY The following fetches the UID for all VEVENT and VTODO components that have been marked for delete (METHOD:DELETE). BEGIN:VQUERY QUERYID:Fetch UIDs of marked for delete VEVENTs and VTODOs QUERY:SELECT UID FROM VEVENT WHERE METHOD = 'DELETE' QUERY:SELECT UID FROM VTODO WHERE METHOD = 'DELETE' END:VQUERY In the examples above they were bunched into groups of similar queries. They could be performed all at once by having all of the QUERY property in one BEGIN/END VQUERY component. --------------02C1D89908D2969A727DBB48 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 ; Sat, 16 Feb 2002 19:13:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1H02js06814 for ietf-calendar-bks; Sat, 16 Feb 2002 16:02:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H02i306809 for ; Sat, 16 Feb 2002 16:02:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA09363 for ; Sat, 16 Feb 2002 16:02:46 -0800 (PST) Message-ID: <3C6EF320.CF034A75@Royer.com> Date: Sat, 16 Feb 2002 17:02:40 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New "4.1.8 Components With Alarms In A Range" Content-Type: multipart/mixed; boundary="------------0A568EBCBBFC4E882F315B06" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0A568EBCBBFC4E882F315B06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 4.1.8 Components With Alarms In A Range This example fetches all VEVENTs with an alarm that triggers within the specified time range. In this case only the UID, SUMMARY, and DESCRIPTION will be selected for all booked VEVENTS that have an alarm between the two date-times. BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT USING_COMPONENT VALARM x-alarm WHERE x-alarm.TRIGGER >= '20000101T030405Z' AND x-alarm.TRIGGER <= '20001231T235959Z' AND METHOD = 'CREATE' END:VQUERY --------------0A568EBCBBFC4E882F315B06 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 ; Sat, 16 Feb 2002 19:24:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1H0BZo07212 for ietf-calendar-bks; Sat, 16 Feb 2002 16:11:35 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H0BX307202 for ; Sat, 16 Feb 2002 16:11:33 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA09371 for ; Sat, 16 Feb 2002 16:11:35 -0800 (PST) Message-ID: <3C6EF530.4D9CB47D@Royer.com> Date: Sat, 16 Feb 2002 17:11:28 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New "6.1.1 "generate-uid" Command" Content-Type: multipart/mixed; boundary="------------5AEB8358D78182E119D5F2F0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5AEB8358D78182E119D5F2F0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 6.1.1 "generate-uid" Command Attributes: num: Number of UIDs to generate (1 if omitted). cmdid: A unique id that identifies this command to the CUA and CS. latency: How long before CS asks you to continue. (optional) action: How to handle latencty - MUST BE suppled but only when the 'latency' command is supplied. Response: "uid-list" The "generate-uid" command returns one or more unique identifiers which MUST BE globaly unique. Example: C: MSG 1 5 . 2837 60 C: Content-Type: application/beep+xml C: C: C: END S: RPY 1 5 . 2897 328 S: Content-Type: application/beep+xml S: S: S: 20011121T120000Z-12340@cal.example.com S: 20011121T120000Z-12341@cal.example.com S: 20011121T120000Z-12342@cal.example.com S: 20011121T120000Z-12343@cal.example.com S: 20011121T120000Z-12344@cal.example.com S: S: END --------------5AEB8358D78182E119D5F2F0 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 ; Sat, 16 Feb 2002 19:56:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1H0iNG08444 for ietf-calendar-bks; Sat, 16 Feb 2002 16:44:23 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H0iM308440 for ; Sat, 16 Feb 2002 16:44:22 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA09404 for ; Sat, 16 Feb 2002 16:44:24 -0800 (PST) Message-ID: <3C6EFCE0.491DA758@Royer.com> Date: Sat, 16 Feb 2002 17:44:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New: "6.1.2 "get-capability" Command" Content-Type: multipart/mixed; boundary="------------5F1AF50C3A064803AB0E6CB6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5F1AF50C3A064803AB0E6CB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NOTE: The changes to 'car' and 'query-level' are to accommodate the CRISP draft. However we can not mention that in this draft because CRISP is not yet an RFC. So when query-level AND car support are BOTH set to NONE, then it is an iTIP only CS (CRISP CS). This will be in the CRISP draft (John? correct?) AND - We are moving some of the CS properties into capabilities. So this may need to be updated again. AND - It has been talked about on this list, so I added a capability of 'components' to be the names of components that the CS supports - blast me for adding it without explicit debate - it can be easily removed as it is not yet committed. ----------------------------------------------------------------------- 6.1.2 "get-capability" Command Attributes: None Elements: None Response: "capability" The "get-capability" command returns information about the Calendar Server given the current state of the connection with the client. The values returned may differ depending on current user identify and the security level of the connection. Client implementations SHOULD NOT require any capability element beyond those defined in this specification, and MAY ignore any non- standard, experimental capability elements. Non-standard experimental capability elements MUST be prefixed with the text "x-". The prefix SHOULD also include a vendor identifier. For example, "x- foo-barcapability", for the non-standard "barcapability" capability of the vendor "foo". It may return different results depending on the UPN. Capability Occurs Description ------------------------------------------------------- cap 1 Container for CAP related elements. cap-version 1+ Version of CAP. MUST include at least "1.0" for this version of CAP. prodid 0 or 1 The product id of the CS. query-level 1+ Indicates level of SQL support. CAP-QL or NONE. (NONE is for CS's that allow ITIP methods only to be deposited and nothing else). If set to NONE, then the 'car' capability MUST BE set to NONE. car 1+ Indicates level of CAR support. CAR-NONE, CAR-MIN or CAR-FULL-1. If CAR-FUL-1 is supplied then CAR-MIN MUST BE supplied. CAR = NONE MUST BE used when query-level of NONE is supplied. If date-max 0 or 1 The datetime value in UTC beyond which the server cannot accept. If not specified the default is 99991231T235959Z. date-min 0 or 1 The datetime value prior to which the server cannot accept. If not specified the default is 00000101T000000Z. max-component-size 0 or 1 A positive integer value that specifies the size of the largest iCalendar object that the server will accept in octets. Objects larger than this will be rejected. The absence of this attribute indicates no limit. This is also the maximum value of any BEEP MSG payload the CS will accept. components 1 A comma seperated list of the names of components that this CS supports. This includes any components inside of other components (VALARM and VEVENT for example). MUST include at least VCALSTORE, VCALENDAR, and VAGENDA and at least one of VEVENT, VTODO, or VJORNAL. version 1+ Version of iCalendar support. MUST BE at least "2.0". supported. itip-version 1+ Version(s) of ITIP, MUST include at least "1.0". Example: C: MSG 1 6 . 3225 57 C: Content-Type: application/beep+xml C: C: C: END S: RPY 1 6 . 3282 423 S: Content-Type: application/beep+xml S: S: S: S: 2.0 S: 65536 S: 1.0 S: 1.0 S: CAR-FULL-1CAR-MINCAP-QL S: 00000101T000000Z S: 99991231T235959Z S: S: VCALSTORE,VAGENDA,VCALENDAR,VEVENT,X-my-vcomp,VALARM S: S: S: END --------------5F1AF50C3A064803AB0E6CB6 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 ; Sat, 16 Feb 2002 19:58:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1H0nEA08567 for ietf-calendar-bks; Sat, 16 Feb 2002 16:49:14 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H0nD308563 for ; Sat, 16 Feb 2002 16:49:13 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA09412 for ; Sat, 16 Feb 2002 16:49:16 -0800 (PST) Message-ID: <3C6EFE04.A79B9DF4@Royer.com> Date: Sat, 16 Feb 2002 17:49:08 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New: 6.1.3 "identify" Command" Content-Type: multipart/mixed; boundary="------------8A665E5C78C387571C28AF05" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8A665E5C78C387571C28AF05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 6.1.3 "identify" Command Attribute: upn: The UPN of the new identify to assume. Element: None Response: "result" with one of the following request-status codes: 2.0 Successful. 6.4 Identity not permitted. The "identify" command allows the CUA to set a new identity to be used for calendar access. The CS determines through an internal mechanism if the credentials supplied at authentication permit the assumption of the selected identity. If they do, the session assumes the new identity, otherwise a security error is returned. If Example: C: MSG 1 7 . 3705 47 C: Content-Type: application/cap+xml C: C: C: END S: RPY 1 7 . 3752 91 S: Content-Type: application/cap+xml S: S: S: END --------------8A665E5C78C387571C28AF05 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 ; Sat, 16 Feb 2002 20:03:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1H0pD208634 for ietf-calendar-bks; Sat, 16 Feb 2002 16:51:13 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H0pC308630 for ; Sat, 16 Feb 2002 16:51:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA09416 for ; Sat, 16 Feb 2002 16:51:15 -0800 (PST) Message-ID: <3C6EFE7C.BE975F3D@Royer.com> Date: Sat, 16 Feb 2002 17:51:08 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New: "6.1.4 "noop" Command" Content-Type: multipart/mixed; boundary="------------8CC86186AD0B2A15AF2365E0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8CC86186AD0B2A15AF2365E0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 6.1.4 "noop" Command Arguments: None Element: None Response: 2.0 successful This command does nothing. It can be sent to the server periodically to request that the CS does not time out the session. Example: C: MSG 1 7 . 3705 47 C: Content-Type: application/cap+xml C: C: C: END S: RPY 1 7 . 3752 91 S: Content-Type: application/cap+xml S: S: S: END --------------8CC86186AD0B2A15AF2365E0 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 ; Sat, 16 Feb 2002 20:06:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1H0uI008772 for ietf-calendar-bks; Sat, 16 Feb 2002 16:56:18 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H0uH308767 for ; Sat, 16 Feb 2002 16:56:17 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA09420 for ; Sat, 16 Feb 2002 16:56:19 -0800 (PST) Message-ID: <3C6EFFAC.81E12BF6@Royer.com> Date: Sat, 16 Feb 2002 17:56:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New (name change): 6.2.2.1 "cmdid" Attribute Content-Type: multipart/mixed; boundary="------------CAE2DF4919A6592FACA8942B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CAE2DF4919A6592FACA8942B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (was id) 6.2.2.1 "cmdid" Attribute The "cmdid" attribute is an optional identifier for the command. When specified, the CS will include this attribute in all the related messages it returns to the client. The "cmdid" attribute is mainly useful for the "timeout" message (see Section 3.3). The CAP server imposes no restriction on the value. If uniqueness is required, then it is the responsibility of the CUA to generate unique values. If supplied then the property CMDID MUST BE supplied and with the same value in any iCalendar object sent in the same command. If the CUA wishes to abort a command at any time, an abort command may be sent on a separate BEEP channel with the 'cmdid' to be aborted supplied in the abort command: --------------CAE2DF4919A6592FACA8942B 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 ; Sat, 16 Feb 2002 20:08:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1H0wst08867 for ietf-calendar-bks; Sat, 16 Feb 2002 16:58:54 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H0wr308862 for ; Sat, 16 Feb 2002 16:58:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA09424 for ; Sat, 16 Feb 2002 16:58:55 -0800 (PST) Message-ID: <3C6F0048.4959752B@Royer.com> Date: Sat, 16 Feb 2002 17:58:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: DELETE Content-Type: multipart/mixed; boundary="------------F052AA30CCA15F38BDEE2625" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F052AA30CCA15F38BDEE2625 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The iCalendar data is now in a CDATA section, so this section would be deleted. ---------------------------------------------------------------------- 6.2.3.1 "data" Element The role of the "data" element is to join an iCalendar document to an XML document forming a CAP command or response. The "data" element is composed of a single attribute ("content") that MUST be set to a "cid" URL that refers to an iCalendar document. See Section 3.2 for more information. Depending of the context, the content of the referred iCalendar object is subject to restrictions. See Section 6.2.1 for more details. --------------F052AA30CCA15F38BDEE2625 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 ; Sat, 16 Feb 2002 20:12:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1H12SY09025 for ietf-calendar-bks; Sat, 16 Feb 2002 17:02:28 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H12R309021 for ; Sat, 16 Feb 2002 17:02:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA09433 for ; Sat, 16 Feb 2002 17:02:29 -0800 (PST) Message-ID: <3C6F011E.72CC9842@Royer.com> Date: Sat, 16 Feb 2002 18:02:22 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New (renamed) 6.2.3.2 "target" Element Content-Type: multipart/mixed; boundary="------------D170C9DE11AC5D47F639E5D6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D170C9DE11AC5D47F639E5D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 6.2.3.2 "target" Element Many calendaring commands can target several components stored on the CS (e.g., "search", "delete", "modify" and "move"). The "select" element is used to identify the targeted components. When the 'target' element is supplied, then there MUST BE a TARGET property with the same value(s) supplied in any iCalendar object that is contained in the CDATA section of the command. --------------D170C9DE11AC5D47F639E5D6 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 ; Sat, 16 Feb 2002 20:13:08 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1H14Aq09107 for ietf-calendar-bks; Sat, 16 Feb 2002 17:04:10 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H149309102 for ; Sat, 16 Feb 2002 17:04:09 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA09437 for ; Sat, 16 Feb 2002 17:04:11 -0800 (PST) Message-ID: <3C6F0184.13D8E8B8@Royer.com> Date: Sat, 16 Feb 2002 18:04:04 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: DELETE 6.2.3.3 "source" Element Content-Type: multipart/mixed; boundary="------------302397A703BBEB5CA1884319" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------302397A703BBEB5CA1884319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is not needed and was an add-on that was not agreed to on the WG-list. ------------------------------------------------------------------ 6.2.3.3 "source" Element The "source" element is used to specify container(s) that will be examined during the execution of a CAP command. The "source" element is similar to the "target" element (see Section 6.2.3.4, but can refer to several containers (e.g., a calendar hierarchy or all the calendar owned by a given CU). Attributes: csid: when specified MUST point to a CSID. When omitted the CSID of the current server is assumed. relcalid: when specified MUST point to a RELCALID. The value is relative the value of the "csid" attribute. depth: specifies the maximal depth of the calendar hierarchy to explore. When omitted the value "0" is assumed. The accepted values are positives integers and "*". owner: if present MUST be set to a UPN. When specified only the VAGENDA owned by the given UPN are considered. --------------302397A703BBEB5CA1884319 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 ; Sat, 16 Feb 2002 20:17:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1H169Q09181 for ietf-calendar-bks; Sat, 16 Feb 2002 17:06:09 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H168309177 for ; Sat, 16 Feb 2002 17:06:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA09441 for ; Sat, 16 Feb 2002 17:06:11 -0800 (PST) Message-ID: <3C6F01FB.5B951963@Royer.com> Date: Sat, 16 Feb 2002 18:06:03 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: DELETE OLD - 6.2.3.4 "target" Element Content-Type: multipart/mixed; boundary="------------754BEA525C425E80413E383B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------754BEA525C425E80413E383B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Two messages ago I changed
The IESG <iesg-secretary@ietf.org>
Sent by: owner-ietf-calendar@mail.imc.org

02/20/02 17:34

       
        To:        IETF-Announce: ;
        cc:        RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.edu>, ietf-calendar@imc.org
        Subject:        Document Action: Guide to Internet Calendaring to Informational






The IESG has approved the Internet-Draft 'Guide to Internet
Calendaring' <draft-ietf-calsch-inetcal-guide-02.txt> as an
Informational RFC.  This document is the product of the Calendaring and
Scheduling Working Group.  The IESG contact persons are Ned Freed and
Patrik Faltstrom.
--=_alternative 007F75E885256B66_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 10:54:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21533 for ; Thu, 21 Feb 2002 10:54:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LFbri20832 for ietf-calendar-bks; Thu, 21 Feb 2002 07:37:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LFbq320828 for ; Thu, 21 Feb 2002 07:37:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA10465; Thu, 21 Feb 2002 10:37:47 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LFbkQ10660; Thu, 21 Feb 2002 10:37:46 -0500 (EST) Message-ID: <3C751449.CCED9EE4@steltor.com> Date: Thu, 21 Feb 2002 10:37:45 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Consensus? Default TRANSP for CAP is allow overlapped References: <3C6AC031.250159FF@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 Agreed. Doug Royer wrote: > > Some email that was sent raised the issue about the > default for this property. The issue died without a > specific proposal. > > CAP currently has the following defaut and I think there > is consensus to keep this as tthe default. > > ALLOW-CONFLICT N BOOLEAN This boolean value indicates > Whether or not the calendar > supports event conflicts. That > is, whether or not any of the > events in the calendar can > overlap. If not specified the > default value is TRUE meaning > that conflicts are allowed. From owner-ietf-calendar@mail.imc.org Thu Feb 21 10:56:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21663 for ; Thu, 21 Feb 2002 10:56:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LFYNG20757 for ietf-calendar-bks; Thu, 21 Feb 2002 07:34:23 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LFYL320752 for ; Thu, 21 Feb 2002 07:34:22 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA10278; Thu, 21 Feb 2002 10:34:17 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LFYGQ09964; Thu, 21 Feb 2002 10:34:17 -0500 (EST) Message-ID: <3C751378.822C63EA@steltor.com> Date: Thu, 21 Feb 2002 10:34:16 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Who Sent The Counter? References: <3C6C1283.13D19615@steltor.com> <3C6C7C88.914C4D3A@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 Given that this is no longer an issue for scheduling in CAP, since the problem was solved in iTIP, can we close this issue? George Doug Royer wrote: > > George Babics wrote: > > > > A while ago it was identified in CAP, that CUA is unable to > > identify who sent a COUNTER. > > > > Looking in the archives, this issue has already come up in iTIP > > and a consensus was reached. > > > > The thread: http://www.imc.org/ietf-calendar/mail-archive/msg00709.html > > The proposal: http://www.imc.org/ietf-calendar/mail-archive/msg00731.html > > The consensus: http://www.imc.org/ietf-calendar/mail-archive/msg00751.html > > > > Thus, I think it is no longer an issue for CAP. > > GREAT - I agree that we should adopt this this proposal. > It makes more sense that SEND-BY I proposed. From owner-ietf-calendar@mail.imc.org Thu Feb 21 10:57:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21760 for ; Thu, 21 Feb 2002 10:57:42 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LFVsg20695 for ietf-calendar-bks; Thu, 21 Feb 2002 07:31:54 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LFVr320691 for ; Thu, 21 Feb 2002 07:31:53 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA10211; Thu, 21 Feb 2002 10:31:48 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LFVmQ09842; Thu, 21 Feb 2002 10:31:48 -0500 (EST) Message-ID: <3C7512E3.E8F966D7@steltor.com> Date: Thu, 21 Feb 2002 10:31:47 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Delete old secheduling text. References: <3C704E8A.64DB461C@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 I agree. Doug Royer wrote: > > All of these and their contents should be deleted. > To process iTIP commands - read iTIP. > > 6.3 Scheduling Commands . . . . . . . . . . . . . . . . . . 71 > 6.3.1 "schedule" Command . . . . . . . . . . . . . . . . . . . 72 > 6.3.2 Processing Scheduling Components . . . . . . . . . . . . 73 > 6.3.2.1 REQUEST Method . . . . . . . . . . . . . . . . . . . . . 75 > 6.3.3 iTIP Examples . . . . . . . . . . . . . . . . . . . . . 75 > 6.3.3.1 Sending and Receiving an iTIP request . . . . . . . . . 75 > 6.3.3.2 Handling an iTIP refresh . . . . . . . . . . . . . . . . 82 > 6.3.3.3 Sending and accepting an iTIP counter . . . . . . . . . 84 > 6.3.3.4 Declining an iTIP counter . . . . . . . . . . . . . . . 87 From owner-ietf-calendar@mail.imc.org Thu Feb 21 12:20:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25241 for ; Thu, 21 Feb 2002 12:20:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LH2OF25078 for ietf-calendar-bks; Thu, 21 Feb 2002 09:02:24 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LH2N325074 for ; Thu, 21 Feb 2002 09:02:23 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA16862 for ; Thu, 21 Feb 2002 09:02:23 -0800 (PST) Message-ID: <3C75281A.598FA8D4@Royer.com> Date: Thu, 21 Feb 2002 10:02:18 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Who Sent The Counter? References: <3C6C1283.13D19615@steltor.com> <3C6C7C88.914C4D3A@Royer.com> <3C751378.822C63EA@steltor.com> Content-Type: multipart/mixed; boundary="------------E4040EF10665F6F495C7FFE6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E4040EF10665F6F495C7FFE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > Given that this is no longer an issue for scheduling in CAP, > since the problem was solved in iTIP, can we close this issue? 's not solved by iTIP at all. Frank made a proposal and no one adopted it, no draft was written, no property registered, that I can find. I'll take what Frank said and send a 'registration' to this list. It seems simple. It will be a 2445 registration with a note on how it applies to iTIP. PAT - BOB - Per 2445, We just register a new 2445 property this way - correct? Or does it have to also be an accepted draft? If no, then we will have to include this in CAP. > George > > Doug Royer wrote: > > > > George Babics wrote: > > > > > > A while ago it was identified in CAP, that CUA is unable to > > > identify who sent a COUNTER. > > > > > > Looking in the archives, this issue has already come up in iTIP > > > and a consensus was reached. > > > > > > The thread: http://www.imc.org/ietf-calendar/mail-archive/msg00709.html > > > The proposal: http://www.imc.org/ietf-calendar/mail-archive/msg00731.html > > > The consensus: http://www.imc.org/ietf-calendar/mail-archive/msg00751.html > > > > > > Thus, I think it is no longer an issue for CAP. > > > > GREAT - I agree that we should adopt this this proposal. > > It makes more sense that SEND-BY I proposed. --------------E4040EF10665F6F495C7FFE6 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------E4040EF10665F6F495C7FFE6-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 12:21:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25259 for ; Thu, 21 Feb 2002 12:21:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LH52l25164 for ietf-calendar-bks; Thu, 21 Feb 2002 09:05:02 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LH51325160 for ; Thu, 21 Feb 2002 09:05:01 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA13245 for ; Thu, 21 Feb 2002 12:04:57 -0500 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 g1LH4mQ21148 for ; Thu, 21 Feb 2002 12:04:48 -0500 (EST) Message-ID: <3C75292E.F3530E33@steltor.com> Date: Thu, 21 Feb 2002 12:06:54 -0500 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: CAL-QUERY value type References: <3C6ECA22.7CCA6AD5@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: > > Here is the CAL-QUERY value type to be included into CAP. > The CAL-QL section will be submitted separately. > > -------------------------------------------------------------------- > > x.x.1 Property Value Data Types > > x.x.1.2 CAP-QUERY Value Type > > To: ietf-calendar@imc.org > > Subject: Registration of text/calendar MIME property value type. Subject: Registration of text/calendar MIME value type CAP-QUERY > > Value Name: CAP-QUERY > > Value Type Purpose: To define a selection language for identifying > the contents of iCalendar objects. That's the purpose of this section, not of the value type per say. Based on the description of other "value type purposes", I think it would be more appropriate to write the following: This value type is used to identify values that contain query statements targeted to a calendar store (CS). The following information does not belong in the registration of the value type CAL-QUERY. This section should focus on the syntax only. The semantic should be defined elsewhere in the draft. > This was based on [SQL92] and [SQLCOM]. > NOTE: This grammar is NOT SQL92. > > (1) All components look like tables for the purpose of > a QUERY including VALARM. And their contained properties > looked like columns in those tables. > > (2) All VAGENDAs and CS's look like tables for the purpose of a > QUERY. And all of their properties look like columns in > those tables. As VAGENDA, VCALSTORE, and VALARM are all components, how about merging (1) and (2) together and simply state the following: (1) For the purpose of a query, all components should be handled as SQL tables, and the properties of these components, should be handled as SQL columns. > (3) You CAN NOT do any cross component-type joins. And that means > you can ONLY have one component, OR one VAGENDA OR one CALSTORE > in the the FROM clause. We should rephrase this paragraph to avoid using "You" in the draft. Also, "CAN NOT", "ONLY" and "OR" are not defined in RFC 2119. Furthermore, change CALSTORE to VCALSTORE (as well as everywhere else in the text). > > (4) Everything in the SELECT and WHERE clauses MUST be from the > component type, or VAGENDA OR CALSTORE in the FROM clause. > This includes the values from the USING_PROPERTIES and > USING_COMPONENT clauses. We should rephrase this paragraph. Perhaps splitting it in two paragraphs would help (for SELECT and WHERE). (It's USING_COMPONENTS with an 'S'). > > (5) The '.' means . when needed for contained > properties or their associated contained components. > As long as all were contained (as defined by iCalendar or CAP) > in the SINGLE component type named in the FROM clause OR > its contained component. This paragraph will be hard to understand for the first time readers. Perhaps we could rephrase it? > (6) A contained component without a '.' it is the same as > .* with the result being a properly formatted > (s) in the data stream, and correctly formatted > in the contained component(s) in iCalendar (RFC2445) format. We should clarify what is "a contained component". This paragraph should specify to which part of CAL-QUERY it applies (SELECT clause only?). > > VALID: > > (a) SELECT VEVENT. FROM VEVENT This is not valid according to the rule part cal-col of the ABNF specified below (per the calendar store model a VEVENT cannot contain another VEVENT). Perhaps we could change this example to: (a) SELECT VEVENT. FROM VAGENDA > (b) SELECT VEVENT.VALARM FROM VEVENT Same problem as (a). How about: (b) SELECT VEVENT.VALARM FROM VAGENDA > (c) SELECT VALARM FROM VEVENT > > (d) SELECT VEVENT.* FROM VEVENT Same problem as (a), and this is not valid according to the rule part 'cal-cols' of the ABNF specified below. > > (e) SELECT * FROM VEVENT > > (f) SELECT * FROM VEVENT > USING_COMPONENTS VALARM alarm > WHERE alarm.TRIGGER < '20020201T000000Z' > AND alarm.TRIGGER > '20020101T000000Z' > > Note: (a) Selects all instances of > from all VEVENTs. > > That (b), and (c) yield the same results. > And that is select all VALARMS from all VEVENTS. Change VALARMS to VALARMs, or even better: "VALARM components". Same for VEVENTS. > > Note that (d) does not enclose them in BEGIN/END > VALARM because you selected the properties from the > VALARM and not the VALARM. Sorry, I don't understand this paragraph at all. > > (e) Selects every property and every component > that is in any VEVENTs. If (d) was valid, what would be the difference between (d) and (e)? > > (f) Selects all properties and all contained > components in all VEVENTS that have a VALARM > with a TRIGGER property value between the provided > dates and times. > > NOT VALID: > > (g) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT > > (h) SELECT DTSTART,UID FROM VEVENT WHERE > VTODO.SUMMARY = "Fix typo in CAP" > > Note: (g) Is NOT valid because it contains > two '.' characters in the SELECT clause. It's not valid because a VEVENT cannot contain VEVENT. Change to: SELECT VEVENT.VALARM.TRIGGER FROM VAGENDA But then, I don't see any problem allowing more than one '.' character in the SELECT clause. > > (h) Is NOT valid because it mixes VEVENT > and VTODO properties in the same QUERY. (h) is not valid because of the limitation specified in (4). Not because it mixes VEVENT and VTODO "properties (?)". > > (7) When multiple QUERY properties are supplied in a single component > that contains a QUERY, the results are the same as a logical 'OR'. > That is all conditions that match any of the QUERY property > values returned. This needs to be rephrase. How about: (7) When multiple QUERY properties are supplied in a single VQUERY component, the results returned are the same as the results returned for multipled VQUERY components having each a single QUERY property. > > Formal Definition: The value type is defined by the following > notation: > > comp-name = "VEVENT" / "VTODO" / "VJOURNAL" > / "VTIMEZONE" / "VALARM" / "VFREEBUSY" > / "VAGENDA" / "VCAR" / "CALSTORE" > / "VQUERY" / iana-name / x-comp > > querycomp = queries / ( queryname queries) / queryname > > queryname = "QUERYNAME" *(";" xparam) ":" text CRLF > > queries = query > / queries query > > query = "QUERY" *(";" xparam) ":" capselect CRLF > > ; NOTE: There is exactly one space separating > ; the various parts of capselect > ; These rule parts don't belong in this section. We need separate sections to register these. That is, Subject: Registration of text/calendar MIME component VQUERY Subject: Registration of text/calendar MIME property QUERYNAME Subject: Registration of text/calendar MIME property QUERY > capselect = "SELECT" SP cap-cols SP > "FROM" SP comp-name SP > *(cauprops SP / capcprops SP) Typo: *( capuprops SP / capcprops SP ) ^ > "WHERE" SP cap-expr > > / "SELECT" SP cap-cols SP > "FROM" SP comp-name For the sake of simplicity we should rename "capselect" to "cal-query" to match the name of the value type. That will make referencing to this value type easier. > > capuprops = "USING_PROPERTIES" SP uprop-list > > uprop-list = (cap-col SP cap-local) > / uprop-list SP cap-col SP cap-local > > capcprops = "USING_COMPONENTS" SP cprop-list > > cprop-list = (cap-comp cap-local) Add missing SP rule part: (cap-comp SP cap-local) ^^ > / cprop-list SP cap-col SP cap-local > > cap-col = ; Any property name found in the component > ; named in the comp-tbl used in the FROM clause. > ; > ; SELECT ORGANIZER FROM VEVENT ... > ; > ; OR > ; > ; A component name of an existing component contained > ; inside of the cmp-tbl used in the FROM clause. > ; > ; SELECT VALARM FROM VEVENT ... > > ; NOTE: there is NO space around the "," on > ; the next line We can't define a rule part only with comments. > cap-cols = cap-col / ( cap-cols "," cap-col) > / "*" > / Remove trailing '/'. > cap-param = ; Any parameter that may be contained in the cap-col > ; in the supplied PARAM() function Define. > > cap-local = ; Any string that is composed of the characters > ; that could be a cap-col name, but is not any > ; cap-col name. It is suggested that the > ; string start with "x-" to ensure it does not > ; conflict with any existing or future cap-col name. > ; This name MUST BE defined in the cap-using and > ; can only be used in cap-expr of the same query. > ; And this name is only known and valid for the > ; provided query and only for the lifetime of > ; the query. If multiple QUERY properties exist > ; in the same component, it is only valid and usable > ; in the same QUERY property where it was supplied. As was discussed on the list, there is no "conflict" here. http://www.imc.org/ietf-calendar/mail-archive/msg03622.html On the other hand, I totally agree that a bad choice of variable names can bring "confusion". In any case, prefixing variables with "my" (e.g., "myAlarm") should be sufficient to avoid any confusion (beside, the odds of having to deal with a property called "x-alarm" is probably higher than "myAlarm"). > col-value = col-literal > / "SELF()" > / "CAL-OWNERS(" cal-address ")" > / "CURRENT-CALID()" > > cal-address = ; A CALID as define by CAP Define. > > col-literal = "'" literal-data "'" > > literal-data = ; Any data that matches the value type of the > ; column that is being compared. That is you can > ; not compare PRIORITY to "some string" because > ; PRIORITY has a value type of integer. If it is > ; not preceded by the LIKE element, any '%' and '_' > ; characters in the literal data are not treated as > ; wildcard characters and do not have to be backslash > ; escaped. > ; > ; OR > ; > ; If the literal-data is preceded by the LIKE > ; element it may also contain the '%' and '_' > ; wildcard characters. And if the literal data > ; that is comparing contains any '%' or '_' > ; characters, they MUST BE backslash escaped as > ; described in the notes below in order for them not > ; to be treated as wildcard characters. > > cap-ucol = cap-col / cap-local > > cap-expr = "(" cap-expr ")" > / cap-term > > cap-term = cap-expr SP cap-logical SP cap-expr > / cap-factor > > cap-factor = cap-colval SP cap-oper SP col-value > / cap-colval SP "NOT LIKE" SP col-value > / cap-colval SP "LIKE" SP col-value > / cap-colval SP "IS NULL" > / cap-colval SP "IS NOT NULL" > / col-value SP "NOT IN" cap-colval" > / col-value SP "IN" cap-colval" > > cap-colval = cap-ucol > / "PARAM(" cap-ucol "," cap-param ")" > > cap-oper = "=" > / "!=" > / "<" > / ">" > / "<=" > / ">=" > > cap-logical = "AND" / "OR" > > SP = ; A single white space ascii character > ; (value in HEX %x20). > > CRLF = ; As defined in RFC 2445. > > xparam = ; As defined in RFC 2445. > > x-prop = ; As defined in RFC 2445. > > x-comp = ; As defined in RFC 2445. > > (1) There is no ORDERBY. Sorting will take place in the order the > columns are supplied in the command. > > Float and integer values MUST BE sorted by their numeric value. > > This means the result of a sort on an integer value type will be: > > 1, 2, 100, 1000 > > and not > > 1, 100, 1000, 2 > > This means the result of a sort on an float value type will be: > > 1.1, 2.23, 100.332, 1000.12 > > and not > > 1.1, 100.332, 1000.12, 2.23 > > Date and date time values will be sorted by their equivalent > value in UTC. No matter what the returned time zone in the result > set returns. This is so that if multiple components are returned > each in a unique time zone, the results will be sorted in UTC. > This does not mean the values must be converted to UTC in the > data returned to the CUA. It means the CS must do the sort in UTC. > > All other values are sorted according to the locale sorting order > as specified in the calendar. Or the CS locale if the calendar > does not have any locale set, or the host operating system > locale if the CS does not specify a locale. And the locale to > use for the sort is determined in that order. > > (2) The CS MUST sort at least the first column. > The CS MAY sort additional columns. > > (3) If the cap-cols is only "*" and nothing else, then: > > If EXPAND=FALSE sorting will be by the DTSTART value > ascending. > > If EXPAND=TRUE sorting will be by the RECURRENCE-ID value > ascending. > > If one or more DTSTART or RECURRENCE-ID components have > exactly the same value, the order for those matching > components is unspecified. > > (4) All literal values are surrounded by single quotes ('), not > double quotes ("), and not without any quotes. If the value > contains quotes or any other ESCAPED-CHAR, they must be > backslash escaped as described in section "4.3.11 Text" > of RFC2445. Any LIKE wildcard characters that are part > of any literal data that is preceded by a LIKE clause and > is not intended to mean wildcard search, MUST BE escaped as > described in note (7) below. > > (5) When comparing DATE-TIME to DATE value types and when > comparing DATE to DATE-TIME value types, the result will > be true if the DATE value is on the same day as the DATE-TIME > value. And they are compared in UTC no matter what time zone > the data may actual have been stored in. > > VALUE-1 VALUE-2 Compare Results > > 20020304 20020304T123456 TRUE > (in UTC-3) (in UTC-3) > > 20020304 20020304T003456 FALSE > (in UTC-4) (in UTC-4) > > 20020304T003456Z 20020205T003456 FALSE > (in UTC-0) (in UTC-7) > > When comparing DATE and DATE-TIME values with the LIKE > clause the comparison will be done as if the value is > a RFC2445 DATE or DATE-TIME string value. > > LIKE '2002%' will match anything in the year 2002. > > LIKE '200201%' will match anything in January 2002. > > LIKE '%T000000' will match anything at midnight. > Add missing 'Z' (i.e., LIKE '%T000000Z'). See (9) below. > LIKE '____01__T%' will match anything for any year or > time that is in January. > (Four '_', '01', two '_' 'T%'). > > Again all comparisons will be done in UTC. > > Using a LIKE value of "%00%, would return any value that > contained two consecutive zeros. > > (6) DTEND and DURATION. > > When a QUERY contains a DTEND value, then the CS MUST also > evaluate any existing DURATION property value and determine > if it has an effective end time that matches the QUERY > supplied DTEND value or any range of values supplied by > the QUERY. > > When a QUERY contains a DURATION value, then the CS MUST > also evaluate any existing DTEND property value and determine > if it has an effective duration that matches the QUERY > supplied DURATION value or any range of values supplied by > the QUERY. > > As DTEND is the first time that is excluded from a components > time range, any DURATION supplied by the QUERY that is > exactly one second less than DTEND MUST match the QUERY. > And if the DURATION ends exactly at the computed DTEND it > MUST NOT match. > > Any DTEND supplied by the QUERY that is exactly one second > more than an end time computed from a DURATION MUST match the > QUERY. Any end time that is computed from a DURATION that > exactly matches the supplied DTEND MUST NOT match. > > (6.1) Given a meeting room reserved with a component > that contains: > DTSTART:20020127T000000Z > DTEND:20020127T010000Z > > The reservation is really from: > > January 27th, 2002 00:00:00 > To: > > January 27th, 2002,00:59:59 > > (6.2) Given another meeting room reserved with a component > that contains: > > DTSTART:20020127T000000Z > DURATION:P59M59S > > The reservation is really from: > > January 27th, 2002 00:00:00 > To: > > January 27th, 2002,00:59:59 > > (6.3) A QUERY that contains: > > ... VEVENT.DTSTART = '20020127T00000Z' > AND VEVENT.DTEND = '20020127T010000Z' > > MUST match both (6.1) and (6.2). > > (6.4) A QUERY that contains: > > ... VEVENT.DTSTART = '20020127T00000Z' > AND DURATION = 'P59M59S' > > MUST match both (6.1) and (6.2). > > (7) [NOT] LIKE notes: > > The pattern matching characters is the '%' that matches > zero or more characters, and '_' that matches exactly one > character (where character does not always mean octet). > > LIKE pattern matches always cover the entire string. To match > a pattern anywhere within a string, the pattern must start and > end with a percent sign. > > To match a '%' or '_' in the data and not have it interpreted > as a wildcard character, they must be backslash escaped. > That is to search for a '%' or '_' in the string: > > LIKE '%\%%' Matches any string with a '%' in it. > LIKE '%\_%' Matches any string with a '_' in it. We should add another example to show how to match '\': LIKE '%\\%' Matches any string with a '\' in it. > > Strings compared using the LIKE clause MUST BE performed > using case in-sensitive comparisons. ('a' = 'A'). > > If LIKE is preceded by 'NOT' then there is a match when > the string compare fails. > > (8) 'col-value SP "NOT IN" cap-colval" > > This is similar to the LIKE element, except it does value > matching and not string comparison matches. > > property:value1,value2 > property:value1,value2 > property:value3 We should use a specific property in our example, since the comma (",") is not defined as a value delimitor for all properties (e.g., SUMMARY:Hello, world!). > > paramater="1,2,3" Should probably be: parameter=1,2,3 else, '2' IN parameter would NOT match. (parameter is spelled paramAter in many places here) Again, use a specific parameter for which the comma is defined as a value delimiter. > > 'value1' IN property would match > 'value3' IN property would match > 'value' IN property would NOT match > '2' IN paramater would match > > LIKE(property, 'value%') would match > LIKE(paramater, '2%') would match LIKE(parameter, '2%') would NOT match since the value doesn't start with '2'. > > The CS must understand the objects being compared and > understand how to determine how any multi valued or multi > instances properties or parameter values are separated, > quoted, and backslash escaped and perform the comparisons as > if each value existed by itself and not quoted or backslash > escaped when comparing using the CONTAINS() element. CONTAINS() no longer exists. > > If IN is preceded by 'NOT' then there is a match when > the value does not exist in the property or parameter value. > > (9) DATE-TIME and TIME values in a WHEN clause. There is no WHEN clause. > > All DATE-TIME and TIME literal values supplied as in > a WHEN clause MUST BE terminated with 'Z'. That means > that the CUA MUST supply the values in UTC. > > Valid: > > WHERE alarm.TRIGGER < '20020201T000000Z' > AND alarm.TRIGGER > '20020101T000000Z' > > Not valid: > > WHERE alarm.TRIGGER < '20020201T000000' > AND alarm.TRIGGER > '20020101T000000' > > It is a syntax error and the CS MUST reject the QUERY. Regards, 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 Thu Feb 21 12:58:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26692 for ; Thu, 21 Feb 2002 12:58:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LHjTV25968 for ietf-calendar-bks; Thu, 21 Feb 2002 09:45:29 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LHjS325964 for ; Thu, 21 Feb 2002 09:45:28 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA16960 for ; Thu, 21 Feb 2002 09:45:29 -0800 (PST) Message-ID: <3C753234.980DF821@Royer.com> Date: Thu, 21 Feb 2002 10:45:24 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: CAL-QUERY value type - description References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------46A6114A91099106F42878EF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------46A6114A91099106F42878EF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Value Name: CAP-QUERY > > > > Value Type Purpose: To define a selection language for identifying > > the contents of iCalendar objects. > > That's the purpose of this section, not of the value type > per say. Based on the description of other "value type > purposes", I think it would be more appropriate to write > the following: > > This value type is used to identify values that contain > query statements targeted to a calendar store (CS). For the most part - yes. But it is a general 2445 property value type we are registering. So, I'll replace "calendar store (cs)" with something generic. One of the goals we had in 2445 was that we tried not to define which draft or objects the properties were used in so that we could re-use them at a later time and not have to retrofit an existing RFC. --------------46A6114A91099106F42878EF 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------46A6114A91099106F42878EF-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:02:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26898 for ; Thu, 21 Feb 2002 13:02:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LHnqZ26069 for ietf-calendar-bks; Thu, 21 Feb 2002 09:49:52 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LHnp326065 for ; Thu, 21 Feb 2002 09:49:51 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA16970 for ; Thu, 21 Feb 2002 09:49:52 -0800 (PST) Message-ID: <3C75333C.E5FC3A3C@Royer.com> Date: Thu, 21 Feb 2002 10:49:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type - SQL note References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------2B15B862DB9186305E90E0F2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2B15B862DB9186305E90E0F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The following information does not belong in the registration > of the value type CAL-QUERY. This section should focus on the > syntax only. The semantic should be defined elsewhere in the > draft. Did you mean only the next two lines? > > This was based on [SQL92] and [SQLCOM]. > > NOTE: This grammar is NOT SQL92. If so, then I disagree. Knowing that it is SQL like is very important. --------------2B15B862DB9186305E90E0F2 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------2B15B862DB9186305E90E0F2-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:07:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27129 for ; Thu, 21 Feb 2002 13:07:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LHquH26142 for ietf-calendar-bks; Thu, 21 Feb 2002 09:52:56 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LHqt326138 for ; Thu, 21 Feb 2002 09:52:55 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA16983 for ; Thu, 21 Feb 2002 09:52:55 -0800 (PST) Message-ID: <3C7533F3.49EC81D1@Royer.com> Date: Thu, 21 Feb 2002 10:52:51 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type - tables/columns References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------3F1B0E1D95B5E4FB35A17A1C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3F1B0E1D95B5E4FB35A17A1C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > (1) All components look like tables for the purpose of > > a QUERY including VALARM. And their contained properties > > looked like columns in those tables. > > > > (2) All VAGENDAs and CS's look like tables for the purpose of a > > QUERY. And all of their properties look like columns in > > those tables. > > As VAGENDA, VCALSTORE, and VALARM are all components, how about > merging (1) and (2) together and simply state the following: > > (1) For the purpose of a query, all components should be > handled as SQL tables, and the properties of these > components, should be handled as SQL columns. I think there will be an objection to using phrase 'SQL'. Which is why the note I about 'like' SQL needs to stay. I agree - otherwise: (1) For the purpose of a query, all components should be handled as tables, and the properties of these components, should be handled as columns. --------------3F1B0E1D95B5E4FB35A17A1C 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------3F1B0E1D95B5E4FB35A17A1C-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:12:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27418 for ; Thu, 21 Feb 2002 13:12:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LHw5l26256 for ietf-calendar-bks; Thu, 21 Feb 2002 09:58:05 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LHw4326251 for ; Thu, 21 Feb 2002 09:58:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA16992 for ; Thu, 21 Feb 2002 09:58:05 -0800 (PST) Message-ID: <3C753528.E88AA03F@Royer.com> Date: Thu, 21 Feb 2002 10:58:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Consesus? VCALSTORE vs CALSTORE References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------D289E43CC518C318CF4A13AC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D289E43CC518C318CF4A13AC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Furthermore, change CALSTORE to VCALSTORE > (as well as everywhere else in the text). Yes - some of the text was written before the proposal to change it from CALSTORE to VCALSTORE. These I think fall into clean up work and we do have a lot of cleanup to do. There was some email - and I don't think that anyone has a problem with this.  --------------D289E43CC518C318CF4A13AC 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------D289E43CC518C318CF4A13AC-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:15:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27530 for ; Thu, 21 Feb 2002 13:15:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LHxrV26287 for ietf-calendar-bks; Thu, 21 Feb 2002 09:59:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LHxq326283 for ; Thu, 21 Feb 2002 09:59:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA17001 for ; Thu, 21 Feb 2002 09:59:52 -0800 (PST) Message-ID: <3C753594.8E21B461@Royer.com> Date: Thu, 21 Feb 2002 10:59:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------465EFD4F1FBBED08570A838A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------465EFD4F1FBBED08570A838A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > (4) Everything in the SELECT and WHERE clauses MUST be from the > > component type, or VAGENDA OR CALSTORE in the FROM clause. > > This includes the values from the USING_PROPERTIES and > > USING_COMPONENTS clauses. > > We should rephrase this paragraph. Perhaps splitting > it in two paragraphs would help (for SELECT and WHERE). > (It's USING_COMPONENTS with an 'S'). Can do - agreed. --------------465EFD4F1FBBED08570A838A 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------465EFD4F1FBBED08570A838A-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:21:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27807 for ; Thu, 21 Feb 2002 13:21:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LI62p26437 for ietf-calendar-bks; Thu, 21 Feb 2002 10:06:02 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LI61326432 for ; Thu, 21 Feb 2002 10:06:01 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA14894 for ; Thu, 21 Feb 2002 13:05:58 -0500 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LI5vQ28645 for ; Thu, 21 Feb 2002 13:05:57 -0500 (EST) Message-Id: <5.1.0.14.0.20020221130812.01b056a0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 13:09:54 -0500 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: CAL-QUERY value type - tables/columns In-Reply-To: <3C7533F3.49EC81D1@Royer.com> References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:52 AM 21/02/2002 -0700, Doug Royer wrote: > (1) For the purpose of a query, all components should be > handled as tables, and the properties of these > components, should be handled as columns. sub-components can also be used as columns though, so the analogy might not be useful (or perhaps should be expanded a little), e.g. : SELECT VALARM FROM VEVENT where [...] --Alan From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:26:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28053 for ; Thu, 21 Feb 2002 13:26:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LICbY26722 for ietf-calendar-bks; Thu, 21 Feb 2002 10:12:37 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LICa326718 for ; Thu, 21 Feb 2002 10:12:36 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17044 for ; Thu, 21 Feb 2002 10:12:36 -0800 (PST) Message-ID: <3C753890.25354F76@Royer.com> Date: Thu, 21 Feb 2002 11:12:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type - contained component References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------EB90C4B298DFB50F9F9C91A7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EB90C4B298DFB50F9F9C91A7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > (6) A contained component without a '.' it is the same as > > .* with the result being a properly formatted > > (s) in the data stream, and correctly formatted > > in the contained component(s) in iCalendar (RFC2445) format. > > We should clarify what is "a contained component". I'll a definitions in the definitions section, like: "contained component" - A component that is contained inside of another component. VALARM for example may be contained inside of a VEVENT. --------------EB90C4B298DFB50F9F9C91A7 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------EB90C4B298DFB50F9F9C91A7-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:26:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28094 for ; Thu, 21 Feb 2002 13:26:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LI9La26517 for ietf-calendar-bks; Thu, 21 Feb 2002 10:09:21 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LI9K326513 for ; Thu, 21 Feb 2002 10:09:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17027 for ; Thu, 21 Feb 2002 10:09:20 -0800 (PST) Message-ID: <3C7537CB.3F4CBA15@Royer.com> Date: Thu, 21 Feb 2002 11:09:15 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type - clearing up '.' References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------249AD38171ABF47A384D4045" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------249AD38171ABF47A384D4045 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > (5) The '.' means
. when needed for contained > > properties or their associated contained components. > > As long as all were contained (as defined by iCalendar or CAP) > > in the SINGLE component type named in the FROM clause OR > > its contained component. > > This paragraph will be hard to understand for the > first time readers. Perhaps we could rephrase it? Yes. How about: (5) The '.' is used to separate the table name (component) and column name (property) when selecting a property that is contained inside of a component that is targeted in the TARGET property. In this example the '.' is used to separate the TRIGGER property from its contained component (VALARM) which is contained in any VEVENT in the selected TARGET (relcalid). All TRIGGER values in any VEVENT in relcalid would be returned. TARGET:relcalid QUERY: SELECT VALARM.TRIGGER FROM VEVENT --------------249AD38171ABF47A384D4045 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------249AD38171ABF47A384D4045-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:31:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28281 for ; Thu, 21 Feb 2002 13:31:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LIIYm26817 for ietf-calendar-bks; Thu, 21 Feb 2002 10:18:34 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LIIX326812 for ; Thu, 21 Feb 2002 10:18:33 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17058 for ; Thu, 21 Feb 2002 10:18:34 -0800 (PST) Message-ID: <3C7539F5.C4FD4120@Royer.com> Date: Thu, 21 Feb 2002 11:18:29 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: CAL-QUERY value type References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------61A507BC46D341B0E8450343" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------61A507BC46D341B0E8450343 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > This paragraph should specify to which part of > CAL-QUERY it applies (SELECT clause only?). > > > > > VALID: > > > > (a) SELECT VEVENT. FROM VEVENT > > This is not valid according to the rule part cal-col > of the ABNF specified below (per the calendar store > model a VEVENT cannot contain another VEVENT). It should say (as the text below in the original post states it selects ALL properties with that name from all VEVENTs): SELECT FROM VEVENT > Perhaps we could change this example to: > > (a) SELECT VEVENT. FROM VAGENDA > > > > (b) SELECT VEVENT.VALARM FROM VEVENT > > Same problem as (a). How about: It should say (similar - it was intended to say how to get all VALARMs from all VEVENTs): SELECT VALARM FROM VEVENT > (b) SELECT VEVENT.VALARM FROM VAGENDA > > > (c) SELECT VALARM FROM VEVENT > > > > (d) SELECT VEVENT.* FROM VEVENT > > Same problem as (a), and this is not valid according to > the rule part 'cal-cols' of the ABNF specified below. It should say: SELECT * FROM VEVENT And (e) should be dropped. > > > > (e) SELECT * FROM VEVENT --------------61A507BC46D341B0E8450343 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------61A507BC46D341B0E8450343-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:38:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28635 for ; Thu, 21 Feb 2002 13:38:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LINnJ26955 for ietf-calendar-bks; Thu, 21 Feb 2002 10:23:49 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LINm326951 for ; Thu, 21 Feb 2002 10:23:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17071 for ; Thu, 21 Feb 2002 10:23:49 -0800 (PST) Message-ID: <3C753B30.4760682E@Royer.com> Date: Thu, 21 Feb 2002 11:23:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type (d) VALARM and not the VALARM References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------37A3DC181A2520C1DBFD0A68" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------37A3DC181A2520C1DBFD0A68 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Note that (d) does not enclose them in BEGIN/END > > VALARM because you selected the properties from the > > VALARM and not the VALARM. > > Sorry, I don't understand this paragraph at all. :-) It must be one of those read my mind statements. Change the last VALARM to VEVENT. --------------37A3DC181A2520C1DBFD0A68 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------37A3DC181A2520C1DBFD0A68-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:39:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28669 for ; Thu, 21 Feb 2002 13:39:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LILEn26890 for ietf-calendar-bks; Thu, 21 Feb 2002 10:21:14 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LILD326886 for ; Thu, 21 Feb 2002 10:21:13 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17062 for ; Thu, 21 Feb 2002 10:21:14 -0800 (PST) Message-ID: <3C753A95.90ED26C5@Royer.com> Date: Thu, 21 Feb 2002 11:21:09 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: CAL-QUERY value type - (b) and (c) note References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------F34461DA3FE6CA30F6AED14D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F34461DA3FE6CA30F6AED14D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > That (b), and (c) yield the same results. > > And that is select all VALARMS from all VEVENTS. > > Change VALARMS to VALARMs, or even better: "VALARM components". > Same for VEVENTS. Yes. --------------F34461DA3FE6CA30F6AED14D 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------F34461DA3FE6CA30F6AED14D-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:41:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28758 for ; Thu, 21 Feb 2002 13:41:40 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LIQQu26990 for ietf-calendar-bks; Thu, 21 Feb 2002 10:26:26 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LIQP326986 for ; Thu, 21 Feb 2002 10:26:25 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17084 for ; Thu, 21 Feb 2002 10:26:26 -0800 (PST) Message-ID: <3C753BCD.316B34CD@Royer.com> Date: Thu, 21 Feb 2002 11:26:21 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------D70229D3C03140E606688FC2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D70229D3C03140E606688FC2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > (7) When multiple QUERY properties are supplied in a single component > > that contains a QUERY, the results are the same as a logical 'OR'. > > That is all conditions that match any of the QUERY property > > values returned. > > This needs to be rephrase. How about: > > (7) When multiple QUERY properties are supplied in a single VQUERY > component, the results returned are the same as the results > returned for multipled VQUERY components having each a single > QUERY property. Yes. --------------D70229D3C03140E606688FC2 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------D70229D3C03140E606688FC2-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:42:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28786 for ; Thu, 21 Feb 2002 13:42:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LIUTl27102 for ietf-calendar-bks; Thu, 21 Feb 2002 10:30:29 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LIUR327098 for ; Thu, 21 Feb 2002 10:30:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17088 for ; Thu, 21 Feb 2002 10:30:28 -0800 (PST) Message-ID: <3C753CBF.EF50A8B2@Royer.com> Date: Thu, 21 Feb 2002 11:30:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type - change to registration References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------486BFC84831E49C1EC6C97A6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------486BFC84831E49C1EC6C97A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Formal Definition: The value type is defined by the following > > notation: > > > > comp-name = "VEVENT" / "VTODO" / "VJOURNAL" > > / "VTIMEZONE" / "VALARM" / "VFREEBUSY" > > / "VAGENDA" / "VCAR" / "CALSTORE" > > / "VQUERY" / iana-name / x-comp > > > > > querycomp = queries / ( queryname queries) / queryname > > > > queryname = "QUERYNAME" *(";" xparam) ":" text CRLF > > > > queries = query > > / queries query > > > > query = "QUERY" *(";" xparam) ":" capselect CRLF > > > > ; NOTE: There is exactly one space separating > > ; the various parts of capselect > > ; > > These rule parts don't belong in this section. We need separate > sections to register these. That is, > > Subject: Registration of text/calendar MIME component VQUERY Yes - and I don't see that I defined VQUERY here. > Subject: Registration of text/calendar MIME property QUERYNAME Yes - and I thought we were going to call id QUERYID and and an optional NAME to VQUERY? > Subject: Registration of text/calendar MIME property QUERY Yes. --------------486BFC84831E49C1EC6C97A6 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------486BFC84831E49C1EC6C97A6-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 13:54:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29332 for ; Thu, 21 Feb 2002 13:54:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LIfaV27377 for ietf-calendar-bks; Thu, 21 Feb 2002 10:41:36 -0800 (PST) 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 g1LIfY327373 for ; Thu, 21 Feb 2002 10:41:34 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Who Sent The Counter? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 21 Feb 2002 13:49:47 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/21/2002 01:50:06 PM, Serialize complete at 02/21/2002 01:50:06 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >PAT - BOB - Per 2445, We just register a new 2445 property >this way - correct? Or does it have to also be an accepted draft? If you want to update the iTIP protocol, you probably need a new RFC that updates the iTIP RFC. In any case, it's purely an iTIP thing, so it's independent of CAP; it can run on a separate track. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |"A dog will eat pretty much anything; one major reason why there| |are no restaurants for dogs is that the customers would eat the | |menus." -- Dave Barry | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Feb 21 14:06:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29848 for ; Thu, 21 Feb 2002 14:06:58 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LInPc27603 for ietf-calendar-bks; Thu, 21 Feb 2002 10:49:25 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LInO327599 for ; Thu, 21 Feb 2002 10:49:24 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17147 for ; Thu, 21 Feb 2002 10:49:25 -0800 (PST) Message-ID: <3C754130.CF8443E9@Royer.com> Date: Thu, 21 Feb 2002 11:49:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type - capselect -> cal-query References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------BB071991636380B673DF4CB5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BB071991636380B673DF4CB5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > "WHERE" SP cap-expr > > > > / "SELECT" SP cap-cols SP > > "FROM" SP comp-name > > For the sake of simplicity we should rename "capselect" > to "cal-query" to match the name of the value type. > That will make referencing to this value type easier. yes. --------------BB071991636380B673DF4CB5 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------BB071991636380B673DF4CB5-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 14:07:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29893 for ; Thu, 21 Feb 2002 14:07:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LIpwk27683 for ietf-calendar-bks; Thu, 21 Feb 2002 10:51:58 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LIpv327679 for ; Thu, 21 Feb 2002 10:51:57 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA17156 for ; Thu, 21 Feb 2002 10:51:58 -0800 (PST) Message-ID: <3C7541C9.7AC2F2F0@Royer.com> Date: Thu, 21 Feb 2002 11:51:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type X- vs MY References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------4EBEE1BA21553F1F5A15B558" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4EBEE1BA21553F1F5A15B558 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > In any case, prefixing variables with "my" (e.g., "myAlarm") > should be sufficient to avoid any confusion (beside, the odds > of having to deal with a property called "x-alarm" is probably > higher than "myAlarm"). I'll change it to: "my-" Agree? --------------4EBEE1BA21553F1F5A15B558 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------4EBEE1BA21553F1F5A15B558-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 14:23:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00540 for ; Thu, 21 Feb 2002 14:23:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LJ9tK28102 for ietf-calendar-bks; Thu, 21 Feb 2002 11:09:55 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJ9s328096 for ; Thu, 21 Feb 2002 11:09:54 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA16326; Thu, 21 Feb 2002 14:09:50 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LJ9oQ05502; Thu, 21 Feb 2002 14:09:50 -0500 (EST) Message-ID: <3C7545FD.E638E65A@steltor.com> Date: Thu, 21 Feb 2002 14:09:49 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: Consensus?: CAP URL definition [WAS: Re: CAP URL definition] References: <3C6D919A.1C84D7C4@steltor.com> <3C716653.F03814BA@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 This is the latest proposal for the definition of CAP URLs: http://www.imc.org/ietf-calendar/mail-archive/msg04578.html People agree, disagree? Please state you opinions. George Bernard Desruisseaux wrote: > > [ I'm cross posting this message to ietf-urn in the hope that people > from this working group might help us with our CAP URL definition. ] > > As requested by members of ietf-calendar I've changed my proposal > (see http://www.imc.org/ietf-calendar/mail-archive/msg04439.html) > to forbid CAP URLs of the following forms: > > cap:///abcd1234QWER > cap:/abcd1234QWER > > Comments anyone? > > -------------------------------------------------------------------- > > 2.x CAP URL > > The CAP URL scheme is used to designate calendar stores, > and calendars accessible using the CAP protocol. > > The CAP URL scheme conform to the generic URL syntax, > defined in RFC 2396, and follows the Guidelines for URL > Schemes, set forth in RFC 2718. > > A CAP URL begins with the protocol prefix "cap" and is > defined by the following grammar. > > capurl = scheme ":" [ "//" csid ] [ "/" relcalid ] > scheme = "cap" > csid = hostport ; As defined in Section 3.2.2 of RFC 2396 > relcalid = *uric ; As defined in Section 2 of RFC 2396 > > 'relcalid' is an identifier that uniquely identifies a calendar > on a particular calendar store. There is no implied structure in > a Relative CALID. It may refer to the calendar of a user or of a > resource such as a conference room. It MUST be unique within the > calendar store. > > Examples: > > cap://cal.example.com > cap://cal.example.com/abcd1234QWER > > Relative CAP URLs are permitted and are resolved according > to the rules defined in Section 5 of RFC 2396. > > Example of a relative CAP URL: > > abcd1234QWER > > 2.x Calendar Addresses > > Calendar addresses can be described as absolute or relative > CAP URLs. > > Examples: > > cap://cal.example.com/abcd1234QWER > abcd1234QWER > > For a user currently authenticated to the CAP server on > cal.example.com, all four addresses refer to the same > calendar. > > -------------------------------------------------------------------- > > Regards, > 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 Thu Feb 21 14:25:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00629 for ; Thu, 21 Feb 2002 14:25:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LJC8028190 for ietf-calendar-bks; Thu, 21 Feb 2002 11:12:08 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJC6328181 for ; Thu, 21 Feb 2002 11:12:06 -0800 (PST) To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: CAP: Consensus?: Who Sent The Counter? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 21 Feb 2002 14:12:02 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 02/21/2002 02:12:09 PM Content-Type: multipart/mixed; boundary="=_mixed 00697AE785256B67_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 00697AE785256B67_= Content-Type: multipart/alternative; boundary="=_alternative 00697AE785256B67_=" --=_alternative 00697AE785256B67_= Content-Type: text/plain; charset="us-ascii" Doug/George, it is our understanding we can not register anything until it is an official draft. Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 02/21/02 12:02 Please respond to "ietf-calendar@imc.org" To: "ietf-calendar@imc.org" cc: Subject: Re: CAP: Consensus?: Who Sent The Counter? George Babics wrote: > > Given that this is no longer an issue for scheduling in CAP, > since the problem was solved in iTIP, can we close this issue? 's not solved by iTIP at all. Frank made a proposal and no one adopted it, no draft was written, no property registered, that I can find. I'll take what Frank said and send a 'registration' to this list. It seems simple. It will be a 2445 registration with a note on how it applies to iTIP. PAT - BOB - Per 2445, We just register a new 2445 property this way - correct? Or does it have to also be an accepted draft? If no, then we will have to include this in CAP. > George > > Doug Royer wrote: > > > > George Babics wrote: > > > > > > A while ago it was identified in CAP, that CUA is unable to > > > identify who sent a COUNTER. > > > > > > Looking in the archives, this issue has already come up in iTIP > > > and a consensus was reached. > > > > > > The thread: http://www.imc.org/ietf-calendar/mail-archive/msg00709.html > > > The proposal: http://www.imc.org/ietf-calendar/mail-archive/msg00731.html > > > The consensus: http://www.imc.org/ietf-calendar/mail-archive/msg00751.html > > > > > > Thus, I think it is no longer an issue for CAP. > > > > GREAT - I agree that we should adopt this this proposal. > > It makes more sense that SEND-BY I proposed. --=_alternative 00697AE785256B67_= Content-Type: text/html; charset="us-ascii"
Doug/George, it is our understanding we can not register anything until it is an official draft.


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

02/21/02 12:02
Please respond to "ietf-calendar@imc.org"

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: CAP: Consensus?: Who Sent The Counter?



George Babics wrote:
>
> Given that this is no longer an issue for scheduling in CAP,
> since the problem was solved in iTIP, can we close this issue?



's not solved by iTIP at all. Frank made a proposal and
no one adopted it, no draft was written, no property registered,
that I can find.

I'll take what Frank said and send a 'registration' to this list.
It seems simple. It will be a 2445 registration with a note
on how it applies to iTIP.

PAT - BOB - Per 2445, We just register a new 2445 property
this way - correct? Or does it have to also be an accepted draft?
If no, then we will have to include this in CAP.

> George
>
> Doug Royer wrote:
> >
> > George Babics wrote:
> > >
> > >   A while ago it was identified in CAP, that CUA is unable to
> > > identify who sent a COUNTER.
> > >
> > > Looking in the archives, this issue has already come up in iTIP
> > > and a consensus was reached.
> > >
> > >   The thread: http://www.imc.org/ietf-calendar/mail-archive/msg00709.html
> > >   The proposal: http://www.imc.org/ietf-calendar/mail-archive/msg00731.html
> > >   The consensus: http://www.imc.org/ietf-calendar/mail-archive/msg00751.html
> > >
> > >   Thus, I think it is no longer an issue for CAP.
> >
> > GREAT - I agree that we should adopt this this proposal.
> > It makes more sense that SEND-BY I proposed.

--=_alternative 00697AE785256B67_=-- --=_mixed 00697AE785256B67_= Content-Type: application/octet-stream; name="Doug.vcf" Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOlJveWVyO0RvdWcNCnRlbDtwYWdlcjpwYWdlckByb3llci5jb20NCnRl bDtjZWxsOjIwOC01MjAtNDA0NA0KdGVsO2ZheDo4NjYtNTk0LTg1NzQNCnRlbDt3b3JrOjg2Ni01 OTQtODU3NA0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vUm95ZXIuY29tL1Blb3Bs ZS9Eb3VnDQpvcmc6SU5FVC1Db25zdWx0aW5nIExMQyA8aHR0cDovL0lORVQtQ29uc3VsdGluZy5j b20+DQphZHI6Ozs7Ozs7DQp2ZXJzaW9uOjIuMQ0KZW1haWw7aW50ZXJuZXQ6RG91Z0BSb3llci5j b20NCnRpdGxlOkNoaWVmIEV4ZWN1dGl2ZSBNYW5hZ2VyDQp4LW1vemlsbGEtY3B0OjstODgzMg0K Zm46RG91ZyBSb3llcg0KZW5kOnZjYXJkDQo= --=_mixed 00697AE785256B67_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 14:25:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00646 for ; Thu, 21 Feb 2002 14:25:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LJDkx28254 for ietf-calendar-bks; Thu, 21 Feb 2002 11:13:46 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJDj328250 for ; Thu, 21 Feb 2002 11:13:45 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA16451 for ; Thu, 21 Feb 2002 14:13:42 -0500 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 g1LJDfQ06048 for ; Thu, 21 Feb 2002 14:13:41 -0500 (EST) Message-ID: <3C754764.87D1C264@steltor.com> Date: Thu, 21 Feb 2002 14:15:48 -0500 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: VQUERY - registration only References: <3C6EE4C4.18201D91@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: > > As both the CAP BEEP commands and the VQUERY examples are mixed > together. I am going to send them out together. > > Here is the proposed text for the VQUERY component. > > (Examples in separate email). > > ------------------------------------------------------------------------- > > x.x.x.1 "VQUERY component type" > > To: ietf-calendar@imc.org > > Subject: Registration of text/calendar MIME component - VQUERY > > Component name: VQUERY > > Property purpose: A component used to contain query information. Based on the description of other "component purposes", I think it would be more appropriate to write the following: Component purpose: Provide a grouping of component properties ^^^^^^^^^ that describe a query. > > Conformance: Can be specified in an iCalendar object. RFC 2445 doesn't use a "Conformance" field for components. > Description: This component is used as the container that can > hold a query designed to be used by a CUA or a CS. RFC 2445 talks of "grouping" and not of "container". > > Format definition: > > NOTE: Properties in iCalendar objects can be in any order. This > ABNF > below specifies the valid contents of a BEGIN/END VQUERY. The > ordering of the properties is not important. Any two VQUERY > components that contain exactly the same properties in any > random order are equivalent. The same is true for parameters, > that is any two properties that contain exactly the same > parameters in any random order are equivalent. With the ABNF written properly (see below) we can delete this note. All of this is already specified in RFC 2445. > search = "BEGIN:VQUERY" CRLF > 0*1expand *(x-prop) query > "END:VQUERY" CRLF > > ; If not provided, EXPAND defaults to FALSE > > expand = "EXPAND" *(";" xparam) ":" ( "TRUE" / "FALSE") CRLF For consistency with RFC 2445, we should rewite this ABNF as follows: queryc = "BEGIN" ":" "VQUERY" CRLF queryprop "END" ":" "VQUERY" CRLF queryprop = *( ; the following are optional, ; but MUST NOT occur more than once expand / queryid / ; the following are optional, ; and MAY occur more than once query / name / x-prop ) *** NOTE: I've added the missing rule parts 'queryid' and 'name' for the QUERYID and NAME properties. The registration for the NAME property is already part of the VCAR proposal. If the WG wants to use QUERYNAME instead of NAME, we'll have to register this property in another section as well. > expand = "EXPAND" *(";" xparam) ":" ( "TRUE" / "FALSE") CRLF We need a separate sections to register the EXPAND property. Subject: Registration of text/calendar MIME property EXPAND EXPAND is of value type BOOLEAN, and we should use the rule part 'boolean' defined in RFC 2445 in its formal definition. Regards, 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 Thu Feb 21 14:46:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01258 for ; Thu, 21 Feb 2002 14:46:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LJOdN28542 for ietf-calendar-bks; Thu, 21 Feb 2002 11:24:39 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJOc328536 for ; Thu, 21 Feb 2002 11:24:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA17210 for ; Thu, 21 Feb 2002 11:24:38 -0800 (PST) Message-ID: <3C754971.B0C581F4@Royer.com> Date: Thu, 21 Feb 2002 12:24:33 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type - description Content-Type: multipart/mixed; boundary="------------F9543E55182355273C00F1C9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F9543E55182355273C00F1C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Value Name: CAP-QUERY > > > > Value Type Purpose: To define a selection language for identifying > > the contents of iCalendar objects. > > That's the purpose of this section, not of the value type > per say. Based on the description of other "value type > purposes", I think it would be more appropriate to write > the following: > > This value type is used to identify values that contain > query statements targeted to a calendar store (CS). For the most part - yes. But it is a general 2445 property value type we are registering. So, I'll replace "calendar store (cs)" with something generic. One of the goals we had in 2445 was that we tried not to define which draft or objects the properties were used in so that we could re-use them at a later time and not have to retrofit an existing RFC. --------------F9543E55182355273C00F1C9 Content-Type: text/plain; charset=us-ascii; name="nsmail3C75491012640CF" Content-Disposition: inline; filename="nsmail3C75491012640CF" Content-Transfer-Encoding: 7bit Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from plexus.cst.ca (IDENT:root@plexus.CST.CA [207.139.176.42]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LHm8Q26479; Thu, 21 Feb 2002 12:48:08 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA14500; Thu, 21 Feb 2002 12:48:03 -0500 Received: by above.proper.com (8.11.6/8.11.3) id g1LHjTV25968 for ietf-calendar-bks; Thu, 21 Feb 2002 09:45:29 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LHjS325964 for ; Thu, 21 Feb 2002 09:45:28 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA16960 for ; Thu, 21 Feb 2002 09:45:29 -0800 (PST) Message-ID: <3C753234.980DF821@Royer.com> Date: Thu, 21 Feb 2002 10:45:24 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: CAL-QUERY value type - description References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------46A6114A91099106F42878EF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------46A6114A91099106F42878EF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Value Name: CAP-QUERY > > > > Value Type Purpose: To define a selection language for identifying > > the contents of iCalendar objects. > > That's the purpose of this section, not of the value type > per say. Based on the description of other "value type > purposes", I think it would be more appropriate to write > the following: > > This value type is used to identify values that contain > query statements targeted to a calendar store (CS). For the most part - yes. But it is a general 2445 property value type we are registering. So, I'll replace "calendar store (cs)" with something generic. One of the goals we had in 2445 was that we tried not to define which draft or objects the properties were used in so that we could re-use them at a later time and not have to retrofit an existing RFC. --------------46A6114A91099106F42878EF Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------46A6114A91099106F42878EF-- --------------F9543E55182355273C00F1C9 Content-Type: text/plain; charset=us-ascii; name="nsmail3C75491012740CF" Content-Disposition: inline; filename="nsmail3C75491012740CF" Content-Transfer-Encoding: 7bit Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from plexus.cst.ca (IDENT:root@plexus.CST.CA [207.139.176.42]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LHsNQ27104 for ; Thu, 21 Feb 2002 12:54:23 -0500 (EST) Received: from royer.com (royer.com [4.23.9.161]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA14625 for ; Thu, 21 Feb 2002 12:54:22 -0500 Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA16987; Thu, 21 Feb 2002 09:54:17 -0800 (PST) Sender: doug@royer.com Message-ID: <3C753445.2BEBB642@Royer.com> Date: Thu, 21 Feb 2002 10:54:13 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: CAL-QUERY value type (YOU,OR) References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------DA616DCE534CAE1709339829" This is a multi-part message in MIME format. --------------DA616DCE534CAE1709339829 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > (3) You CAN NOT do any cross component-type joins. And that means > > you can ONLY have one component, OR one VAGENDA OR one CALSTORE > > in the the FROM clause. > > We should rephrase this paragraph to avoid using > "You" in the draft. Also, "CAN NOT", "ONLY" and > "OR" are not defined in RFC 2119. Agree. --------------DA616DCE534CAE1709339829 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------DA616DCE534CAE1709339829-- --------------F9543E55182355273C00F1C9 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------F9543E55182355273C00F1C9-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 14:59:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01665 for ; Thu, 21 Feb 2002 14:59:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LJhFh28955 for ietf-calendar-bks; Thu, 21 Feb 2002 11:43:15 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJhE328951 for ; Thu, 21 Feb 2002 11:43:14 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA17015 for ; Thu, 21 Feb 2002 14:43:11 -0500 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 g1LJhBQ09139 for ; Thu, 21 Feb 2002 14:43:11 -0500 (EST) Message-ID: <3C754E4D.4E7CAD7E@steltor.com> Date: Thu, 21 Feb 2002 14:45:17 -0500 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: BEEP - new: 3.2 Use of XML, MIME and iCalendar References: <3C6EE79C.F73F0DDA@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: > > C: MSG 1 3 . 1023 489 > C: Content-Type: application/cap+xml > C: > C: > C: ... > C: />]]> > C: CDATA is not used properly. C: Regards, 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 Thu Feb 21 15:08:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01952 for ; Thu, 21 Feb 2002 15:08:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LJrfo29191 for ietf-calendar-bks; Thu, 21 Feb 2002 11:53:41 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJrd329186 for ; Thu, 21 Feb 2002 11:53:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA17270; Thu, 21 Feb 2002 11:53:30 -0800 (PST) Message-ID: <3C755034.6BA44190@Royer.com> Date: Thu, 21 Feb 2002 12:53:24 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAL-QUERY value type References: <3C6ECA22.7CCA6AD5@Royer.com> <3C75292E.F3530E33@steltor.com> Content-Type: multipart/mixed; boundary="------------AEC9987529CF0ACDB7FCCED0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AEC9987529CF0ACDB7FCCED0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > We should use a specific property in our example, since > the comma (",") is not defined as a value delimitor for > all properties (e.g., SUMMARY:Hello, world!). > > > > > paramater="1,2,3" > > Should probably be: > > parameter=1,2,3 I'll change the example to be a mixture of possible iCalendar multiple instance and multiple valued properties and parameters and I add this text before the example: Some iCalendar objects can be multi instance and multi valued. The IN operator will return a match if the literal value supplied as part of the 'IN' clause is contained in the value of any instance of the named property or parameter, or is in any of the multiple values in the named property or parameter. BEGIN:A-COMPONENT a property:value1,value2 One property, two values. b property:"value1,value2" One property, one value. c FOO:paramater=1,2:x One parameter, two values. d FOO:paramater="1,2",3:y One parameter, two value. END:A-COMPONENT 'value1' IN property would match (a) only. 'value1,value2' IN property would match (b) only. 'value%' IN property would NOT match any. '2' IN parameter would match (c) only. '1,2' IN parameter would match (d) only. LIKE(property, "value1%" would match (a) and (b) LIKE(property, 'value%') would match (a) and (b) LIKE(paramater, '1%') would match (c) and (d) LIKE(paramater, '%2%') would match (c) and (d) And I'll add this text to the start of the paragraph that follows the example: Some property values (such as the 'recur' value type), contain commas and are not multi valued. The CS must understand the objects being compared and ... --------------AEC9987529CF0ACDB7FCCED0 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------AEC9987529CF0ACDB7FCCED0-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 15:14:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02112 for ; Thu, 21 Feb 2002 15:14:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LK0tx29329 for ietf-calendar-bks; Thu, 21 Feb 2002 12:00:55 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LK0s329325 for ; Thu, 21 Feb 2002 12:00:54 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA17288 for ; Thu, 21 Feb 2002 12:00:55 -0800 (PST) Message-ID: <3C7551F1.F44E0FEA@Royer.com> Date: Thu, 21 Feb 2002 13:00:49 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VQUERY - registration only References: <3C6EE4C4.18201D91@Royer.com> <3C754764.87D1C264@steltor.com> Content-Type: multipart/mixed; boundary="------------F94C814EECFA0B3919BB5BED" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F94C814EECFA0B3919BB5BED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > > Format definition: > > > > NOTE: Properties in iCalendar objects can be in any order. This > > ABNF > > below specifies the valid contents of a BEGIN/END VQUERY. The > > ordering of the properties is not important. Any two VQUERY > > components that contain exactly the same properties in any > > random order are equivalent. The same is true for parameters, > > that is any two properties that contain exactly the same > > parameters in any random order are equivalent. > > With the ABNF written properly (see below) we can delete > this note. All of this is already specified in RFC 2445. I assume your comment was for the text above, and not the text below you comment. No - In fact that is one of the bugs in 2445. It did not specify it in the grammar and we got complaints about that. The 2445 grammar implies that there is a specific order. The above text is used to amplify the issue so that someone that reads 2445 can understand that is a 2445 bug an that we are not replicating that bug. --------------F94C814EECFA0B3919BB5BED 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------F94C814EECFA0B3919BB5BED-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 15:33:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02796 for ; Thu, 21 Feb 2002 15:33:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LKKZa29939 for ietf-calendar-bks; Thu, 21 Feb 2002 12:20:35 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LKKY329935 for ; Thu, 21 Feb 2002 12:20:34 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA17340 for ; Thu, 21 Feb 2002 12:20:35 -0800 (PST) Message-ID: <3C75568D.4C54CEAE@Royer.com> Date: Thu, 21 Feb 2002 13:20:29 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: BEEP - new: 3.2 Use of XML, MIME and iCalendar References: <3C6EE79C.F73F0DDA@Royer.com> <3C754E4D.4E7CAD7E@steltor.com> Content-Type: multipart/mixed; boundary="------------DE5498D68660BB8C17317A76" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DE5498D68660BB8C17317A76 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > CDATA is not used properly. > > C: C: ... > C: ]]> Yep - cut/paste error. I made a temporary file with sample CDATA in it, they may all have that error. --------------DE5498D68660BB8C17317A76 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------DE5498D68660BB8C17317A76-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 16:15:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04550 for ; Thu, 21 Feb 2002 16:15:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LKsjg00756 for ietf-calendar-bks; Thu, 21 Feb 2002 12:54:45 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LKsi300752 for ; Thu, 21 Feb 2002 12:54:44 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA18747 for ; Thu, 21 Feb 2002 15:54:41 -0500 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 g1LKsfQ17323 for ; Thu, 21 Feb 2002 15:54:41 -0500 (EST) Message-ID: <3C755F0F.2A175BE0@steltor.com> Date: Thu, 21 Feb 2002 15:56:47 -0500 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: BEEP new : "3.3 Bounded Latency" References: <3C6EEB25.2231C507@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: > > C: MSG 1 4 . 2043 284 > C: Content-Type: application/cap+xml > C: > C: Per your proposal: http://www.imc.org/ietf-calendar/mail-archive/msg04538.html The search command is missing the target attribute. C: > C: C: BEGIN:VCALENDAR > C: METHOD:SEARCH > C: CMDID:xyz12346 > C: TARGET:opaqueid101 > C: BEGIN:VQUERY > C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT > C: WHERE DTEND >= '19990714T080000Z' > C: AND DTSTART <= '19990715T080000Z' > C: END:VQUERY > C: END:VCALENDAR Missing: C: ]]> C: > C: END Regards, 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 Thu Feb 21 16:42:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05237 for ; Thu, 21 Feb 2002 16:42:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LLLq601367 for ietf-calendar-bks; Thu, 21 Feb 2002 13:21:52 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LLLp301363 for ; Thu, 21 Feb 2002 13:21:51 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA19521 for ; Thu, 21 Feb 2002 16:21:48 -0500 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 g1LLLmQ20674 for ; Thu, 21 Feb 2002 16:21:48 -0500 (EST) Message-ID: <3C75656A.7C95A8D5@steltor.com> Date: Thu, 21 Feb 2002 16:23:54 -0500 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: New: 6.2.4.5 "search" Command (TARGET) References: <3C704DA3.76F1E8D1@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: > > C: MSG 1 13 . 12507 378 > C: Content-Type: application/cap+xml > C: > C: > C: C: BEGIN:VCALENDAR > C: VERSION:2.0 > C: METHOD:SEARCH > C: CMDID:search01 > C: TARGET:relcal2,relcal3 Change to: C: TARGET:relcal2 C: TARGET:relcal3 In draft-05, the TARGET property was only multi-instance NOT multi-valued. A multi-valued TARGET would make it difficult to write restriction tables with "TARGET 1". Regards, 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 Thu Feb 21 16:46:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05298 for ; Thu, 21 Feb 2002 16:46:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LLQP201484 for ietf-calendar-bks; Thu, 21 Feb 2002 13:26:25 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LLQO301478 for ; Thu, 21 Feb 2002 13:26:24 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA19642 for ; Thu, 21 Feb 2002 16:26:22 -0500 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 g1LLQLQ21232 for ; Thu, 21 Feb 2002 16:26:21 -0500 (EST) Message-ID: <3C75667C.91734936@steltor.com> Date: Thu, 21 Feb 2002 16:28:28 -0500 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: BEEP new : "3.3 Bounded Latency" (cmdid) References: <3C6EEB25.2231C507@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: > > C: RPY 1 2 . 166 62 > C: Content-Type: application/cap+xml > C: > C: Change to: C: > S: RPY 1 4 . 2723 112 > S: > S: > S: Request Aborted by the CUA. > S: > S: END The reply should also contain the "cmdid". How about: S: RPY 1 4 . 2723 112 S: S: S: S: Request Aborted by the CUA. S: S: S: END Regards, 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 Thu Feb 21 16:55:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05539 for ; Thu, 21 Feb 2002 16:55:08 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LLa0D01696 for ietf-calendar-bks; Thu, 21 Feb 2002 13:36:00 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LLZx301692 for ; Thu, 21 Feb 2002 13:35:59 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA19989 for ; Thu, 21 Feb 2002 16:35:56 -0500 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 g1LLZuQ22580 for ; Thu, 21 Feb 2002 16:35:56 -0500 (EST) Message-ID: <3C7568BB.556BC7C7@steltor.com> Date: Thu, 21 Feb 2002 16:38:03 -0500 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: New: "6.1.2 "get-capability" Command" (Using XML for list of components) References: <3C6EFCE0.491DA758@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: > > S: > S: VCALSTORE,VAGENDA,VCALENDAR,VEVENT,X-my-vcomp,VALARM > S: Since the capabilities are returned in XML, let's use XML: S: S: S: S: S: S: S: S: Agree? Regards, 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 Thu Feb 21 17:24:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06076 for ; Thu, 21 Feb 2002 17:24:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LM2Xl02331 for ietf-calendar-bks; Thu, 21 Feb 2002 14:02:33 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LM2V302327 for ; Thu, 21 Feb 2002 14:02:31 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA20762 for ; Thu, 21 Feb 2002 17:02:28 -0500 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 g1LM2SQ25634 for ; Thu, 21 Feb 2002 17:02:28 -0500 (EST) Message-ID: <3C756EF2.2C1339A6@steltor.com> Date: Thu, 21 Feb 2002 17:04:34 -0500 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: New: 6.2.4.3 "modify" Command () References: <3C6FE7F2.6C29C120@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: > > 6.2.4.3 "modify" Command > > If multiple components are selected, then the UID for each selected > component MUST BE returned: > > S: RPY 1 7 . 3752 156 > S: Content-Type: application/cap+xml > S: > S: > S: > S: UID:1 > S: > S: > S: UID:2 > S: > S: > S: END 1- The element is used to specify an error message. See: http://www.imc.org/ietf-calendar/mail-archive/msg04490.html ; 2- Not all components have a UID property. This WG insisted in using ALARMID, QUERYID, and CARID. Furthermore, UID does not uniquely identify components within a TARGET (e.g., there may be multiple iTIP objects with the same UID); 3- It should be clearly specified in the reply whether the returned information is specified in XML or iCalendar format ("UID:1" by itself is not iCalendar); 4- The target is missing in the reply; 5- The format of the reply for the modify command should be similar to the format of the reply of the delete command. Regards, 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 Thu Feb 21 17:28:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06165 for ; Thu, 21 Feb 2002 17:28:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LM7hH02428 for ietf-calendar-bks; Thu, 21 Feb 2002 14:07:43 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LM7g302424 for ; Thu, 21 Feb 2002 14:07:43 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA20833 for ; Thu, 21 Feb 2002 17:07:40 -0500 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 g1LM7dQ26109 for ; Thu, 21 Feb 2002 17:07:39 -0500 (EST) Message-ID: <3C75702A.DE7419E5@steltor.com> Date: Thu, 21 Feb 2002 17:09:46 -0500 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: New: 6.2.4.2 "delete" Command (rewrite example) References: <3C6F16E7.F2F1BDF3@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: > > Example to delete a VEVENT with VEVENT UID 'abcd12345' from > the calendar "user@cal.example.com" from the current CS: > > C: MSG 1 10 . 7016 235 > C: Content-Type: application/cap+xml > C: > C: > C: C: BEGIN:VQUERY > C: CMDID:delete01 > C: TARGET:user@cal.example.com > C: QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' > C: END:VQUERY > C: />]]> > C: > C: END This one needs to be rewritten: C: C: C: C: END Regards, 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 Thu Feb 21 17:28:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06192 for ; Thu, 21 Feb 2002 17:28:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LMCkS02669 for ietf-calendar-bks; Thu, 21 Feb 2002 14:12:46 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMCi302665 for ; Thu, 21 Feb 2002 14:12:44 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA20949 for ; Thu, 21 Feb 2002 17:12:42 -0500 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 g1LMCfQ26672 for ; Thu, 21 Feb 2002 17:12:41 -0500 (EST) Message-ID: <3C757158.D73727B1@steltor.com> Date: Thu, 21 Feb 2002 17:14:48 -0500 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: New: 6.2.4.1 "create" Command (No METHOD in restriction table?) References: <3C6F110C.E051E6D7@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: > > 6.2.4.1 "create" Command > > Restriction table for the "create" command: > > Component/Property Presence Comment > ------------------- -------- ----------------------------- > VCALENDAR 1 > . VERSION 1 MUST be at least 2.0 > . TARGET 1+ > . CMDID 0+ METHOD is not allowed? Regards, 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 Thu Feb 21 17:33:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06261 for ; Thu, 21 Feb 2002 17:32:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LMFFQ02775 for ietf-calendar-bks; Thu, 21 Feb 2002 14:15:15 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMFE302769 for ; Thu, 21 Feb 2002 14:15:14 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA21006 for ; Thu, 21 Feb 2002 17:15:11 -0500 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 g1LMFAQ26819 for ; Thu, 21 Feb 2002 17:15:11 -0500 (EST) Message-ID: <3C7571ED.488DBAEC@steltor.com> Date: Thu, 21 Feb 2002 17:17:17 -0500 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: New: 6.2.4.1 "create" Command References: <3C6F110C.E051E6D7@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: > > Example: > > In the following example, two new top level VAGENDAs are created. > Note that the CSID of the server is cal.example.com. > > C: MSG 1 8 . 3843 480 > C: Content-Type: application/cap+xml > C: > C: > C: C: BEGIN:VCALENDAR > C: VERSION:2.0 > C: CMDID:creation01 > C: TARGET:cal.example.com > C: BEGIN:VAGENDA > C: RELCALID:relcalz1 > C: NAME;LANGUAGE=EN-us:Bill's Soccer Team > C: OWNER:bill > C: CALMASTER:mailto:bill@example.com > C: TZID:US/Pacific > C: END:VAGENDA > C: BEGIN:VAGENDA > C: RELCALID:relcalz2 > C: NAME;LANGUAGE=EN-us:Mary's personal calendar > C: OWNER:mary > C: CALMASTER:mailto:mary@example.com > C: TZID:US/Pacific > C: END:VAGENDA > C: END:VCALENDAR > C: />]]> > C: END Missing METHOD:CREATE ? Regards, 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 Thu Feb 21 17:36:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06329 for ; Thu, 21 Feb 2002 17:36:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LMEML02739 for ietf-calendar-bks; Thu, 21 Feb 2002 14:14:22 -0800 (PST) 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 g1LMEL302735 for ; Thu, 21 Feb 2002 14:14:21 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: New: "6.1.2 "get-capability" Command" (Using XML for list of components) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 21 Feb 2002 17:22:33 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/21/2002 05:22:54 PM, Serialize complete at 02/21/2002 05:22:54 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Since the capabilities are returned in XML, >let's use XML: I think this is a good idea. No point making us write code to parse the comma-separated list (admittedly, it'd be trivial) when we can just use the XML parser that's already running. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Never do card tricks for your poker buddies. | \========================================================/ From owner-ietf-calendar@mail.imc.org Thu Feb 21 17:36:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06343 for ; Thu, 21 Feb 2002 17:36:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LMHVf02809 for ietf-calendar-bks; Thu, 21 Feb 2002 14:17:31 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMHU302803 for ; Thu, 21 Feb 2002 14:17:30 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA21040 for ; Thu, 21 Feb 2002 17:17:28 -0500 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 g1LMHRQ27191 for ; Thu, 21 Feb 2002 17:17:27 -0500 (EST) Message-ID: <3C757276.8F45AF6F@steltor.com> Date: Thu, 21 Feb 2002 17:19:34 -0500 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: New: 6.2.4.1 "create" Command (Missing CMDID, XML error) References: <3C6F110C.E051E6D7@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: > > S: RPY 1 8 . 4621 294 > S: Content-Type: application/cap+xml > S: > S: > S: S: BEGIN:VCALENDAR > S: VERSION:2.0 Add: S: CMDID:creation01 > S: TARGET:cal.example.com > S: BEGIN:VAGENDA > S: RELCALID:relcalz1 > S: REQUEST-STATUS:2.0 > S: END:VAGENDA > S: BEGIN:VAGENDA > S: RELCALID:relcalz2 > S: REQUEST-STATUS:2.0 > S: END:VAGENDA > S: END:VCALENDAR > S: />]]> > S: Change to: S: ]]> S: > S: END Regards, 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 Thu Feb 21 17:49:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06594 for ; Thu, 21 Feb 2002 17:49:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LMOvi02952 for ietf-calendar-bks; Thu, 21 Feb 2002 14:24:57 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMOu302948 for ; Thu, 21 Feb 2002 14:24:56 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA21166 for ; Thu, 21 Feb 2002 17:24:53 -0500 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 g1LMOqQ27790 for ; Thu, 21 Feb 2002 17:24:52 -0500 (EST) Message-ID: <3C757433.A4220A5@steltor.com> Date: Thu, 21 Feb 2002 17:26:59 -0500 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: New: 6.2.4.1 "create" Command References: <3C6F110C.E051E6D7@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: > > Example to create a new component in multiple containers. > > C: MSG 1 9 . 5268 285 > C: Content-Type: application/cap+xml > C: > C: > C: C: BEGIN:VCALENDAR > C: VERSION:2.0 > C: TARGET:relcalz1,relcalz2 > C: BEGIN:VEVENT > C: DTSTART:99990307T180000Z > C: UID:abcd12345 > C: DTEND:99990307T190000Z > C: SUMMARY:Important Meeting > C: END:VEVENT > C: END:VCALENDAR > C: />]]> > C: > C: END Add missing CMDID:creation02 > S: ANS 1 9 . 6453 230 1 > S: Content-Type: application/cap+xml > S: > S: Add: S: S: BEGIN:VCALENDAR > S: VERSION:2.0 > S: CMDID:creation02 > S: TARGET:relcalz2 > S: BEGIN:VEVENT > S: UID:abcd12345 > S: REQUEST-STATUS:6.0 > S: END:VEVENT > S: END:VCALENDAR > S: />]]> > S: > S: END Regards, 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 Thu Feb 21 17:49:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06595 for ; Thu, 21 Feb 2002 17:49:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LMTxB03023 for ietf-calendar-bks; Thu, 21 Feb 2002 14:29:59 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMTw303019 for ; Thu, 21 Feb 2002 14:29:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA21215 for ; Thu, 21 Feb 2002 17:29:56 -0500 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 g1LMTtQ28244 for ; Thu, 21 Feb 2002 17:29:55 -0500 (EST) Message-ID: <3C757562.9D203C72@steltor.com> Date: Thu, 21 Feb 2002 17:32:02 -0500 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: CAP: Inconsistency in reply format 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 The format of the reply should be consistent for all the commands. In Doug's proposal, the following formats are used: 1- 2- ... 3- ... In the end it does not really matter what is used, but it should be consistent. Regards, 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 Thu Feb 21 17:57:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06733 for ; Thu, 21 Feb 2002 17:57:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LMa6B03135 for ietf-calendar-bks; Thu, 21 Feb 2002 14:36:06 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMa5303131 for ; Thu, 21 Feb 2002 14:36:05 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA21292 for ; Thu, 21 Feb 2002 17:36:02 -0500 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 g1LMa1Q29032 for ; Thu, 21 Feb 2002 17:36:02 -0500 (EST) Message-ID: <3C7576D0.E4D915D4@steltor.com> Date: Thu, 21 Feb 2002 17:38:08 -0500 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: New: 6.2.4.5 "search" Command (Using XML for list of targets) References: <3C704DA3.76F1E8D1@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: > > 6.2.4.5 "search" Command > C: MSG 1 13 . 12507 378 > C: Content-Type: application/cap+xml > C: > C: The list of targets should be specified in XML i.e., not as a comma separated list. What about: C: C: C: Regards, 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 Thu Feb 21 17:59:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06783 for ; Thu, 21 Feb 2002 17:59:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LMeRF03234 for ietf-calendar-bks; Thu, 21 Feb 2002 14:40:27 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMeQ303230 for ; Thu, 21 Feb 2002 14:40:26 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA21364 for ; Thu, 21 Feb 2002 17:40:24 -0500 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 g1LMeNQ29302 for ; Thu, 21 Feb 2002 17:40:23 -0500 (EST) Message-ID: <3C7577D6.80FE79EB@steltor.com> Date: Thu, 21 Feb 2002 17:42:30 -0500 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: New "6.1.1 "generate-uid" Command" References: <3C6EF530.4D9CB47D@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: > > 6.1.1 "generate-uid" Command > > C: Content-Type: application/beep+xml Change to application/cap+xml Regards, 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 Thu Feb 21 18:01:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06882 for ; Thu, 21 Feb 2002 18:01:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LMcmi03174 for ietf-calendar-bks; Thu, 21 Feb 2002 14:38:48 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMcl303170 for ; Thu, 21 Feb 2002 14:38:47 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA17544 for ; Thu, 21 Feb 2002 14:38:48 -0800 (PST) Message-ID: <3C7576F1.3A98A6EF@Royer.com> Date: Thu, 21 Feb 2002 15:38:41 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: New: 6.2.4.5 "search" Command (TARGET) References: <3C704DA3.76F1E8D1@Royer.com> <3C75656A.7C95A8D5@steltor.com> Content-Type: multipart/mixed; boundary="------------45A7181823A36E6A08EA5B7A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------45A7181823A36E6A08EA5B7A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Change to: > > C: TARGET:relcal2 > C: TARGET:relcal3 > > In draft-05, the TARGET property was only multi-instance > NOT multi-valued. A multi-valued TARGET would make it > difficult to write restriction tables with "TARGET 1". Agreed. --------------45A7181823A36E6A08EA5B7A 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------45A7181823A36E6A08EA5B7A-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 18:02:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06923 for ; Thu, 21 Feb 2002 18:02:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LMdSM03195 for ietf-calendar-bks; Thu, 21 Feb 2002 14:39:28 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMdR303191 for ; Thu, 21 Feb 2002 14:39:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA17548 for ; Thu, 21 Feb 2002 14:39:29 -0800 (PST) Message-ID: <3C75771A.5937FA9E@Royer.com> Date: Thu, 21 Feb 2002 15:39:22 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: New: "6.1.2 "get-capability" Command" (Using XML for list of components) References: <3C6EFCE0.491DA758@Royer.com> <3C7568BB.556BC7C7@steltor.com> Content-Type: multipart/mixed; boundary="------------4D2BFAA2804395DAB95562C6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4D2BFAA2804395DAB95562C6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > S: > S: > S: > S: > S: > S: > S: > S: > > Agree? Yes! --------------4D2BFAA2804395DAB95562C6 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------4D2BFAA2804395DAB95562C6-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 18:03:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06939 for ; Thu, 21 Feb 2002 18:03:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LMdlG03208 for ietf-calendar-bks; Thu, 21 Feb 2002 14:39:47 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMdk303204 for ; Thu, 21 Feb 2002 14:39:46 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA21353 for ; Thu, 21 Feb 2002 17:39:44 -0500 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 g1LMdeQ29156 for ; Thu, 21 Feb 2002 17:39:40 -0500 (EST) Message-ID: <3C7577AB.7ACC2464@steltor.com> Date: Thu, 21 Feb 2002 17:41:47 -0500 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: New "4.1.6 Query for all Non-Booked Entries" References: <3C6EF0E2.BC64ED36@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: > > BEGIN:VQUERY > QUERYID:Fetch VEVENT and VTODO iTIP components > ... > END:VQUERY Change QUERYID to NAME and add a random QUERYID. Same for examples of VQUERY. Regards, 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 Thu Feb 21 18:09:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07023 for ; Thu, 21 Feb 2002 18:09:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LMjCR03389 for ietf-calendar-bks; Thu, 21 Feb 2002 14:45:12 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMjB303385 for ; Thu, 21 Feb 2002 14:45:11 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA21433 for ; Thu, 21 Feb 2002 17:45:08 -0500 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 g1LMj7Q29716 for ; Thu, 21 Feb 2002 17:45:07 -0500 (EST) Message-ID: <3C7578F2.1BCC1254@steltor.com> Date: Thu, 21 Feb 2002 17:47:14 -0500 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: CAP: Registration of new MIME media type application/cap+xml 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 We will need to write a registration form for a new MIME media type application/cap+xml. This wasn't required for application/beep+xml, since this media is already registered in BEEP. Regards, 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 Thu Feb 21 19:09:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07760 for ; Thu, 21 Feb 2002 19:09:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LNkck04726 for ietf-calendar-bks; Thu, 21 Feb 2002 15:46:38 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LNkb304722 for ; Thu, 21 Feb 2002 15:46:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA17665 for ; Thu, 21 Feb 2002 15:46:39 -0800 (PST) Message-ID: <3C7586D8.5350A742@Royer.com> Date: Thu, 21 Feb 2002 16:46:32 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: New: 6.2.4.1 "create" Command (No METHOD in restriction table?) References: <3C6F110C.E051E6D7@Royer.com> <3C757158.D73727B1@steltor.com> Content-Type: multipart/mixed; boundary="------------CDA59FEBE269C672737C3040" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CDA59FEBE269C672737C3040 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > 6.2.4.1 "create" Command > > > > Restriction table for the "create" command: > > > > Component/Property Presence Comment > > ------------------- -------- ----------------------------- > > VCALENDAR 1 > > . VERSION 1 MUST be at least 2.0 > > . TARGET 1+ > > . CMDID 0+ > > METHOD is not allowed? METHOD 1+ CMDID 0 or 1 Missed it - thanks. --------------CDA59FEBE269C672737C3040 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------CDA59FEBE269C672737C3040-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 19:09:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07761 for ; Thu, 21 Feb 2002 19:09:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LNpko04835 for ietf-calendar-bks; Thu, 21 Feb 2002 15:51:46 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LNpi304830 for ; Thu, 21 Feb 2002 15:51:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA17673 for ; Thu, 21 Feb 2002 15:51:45 -0800 (PST) Message-ID: <3C758809.200A0AAC@Royer.com> Date: Thu, 21 Feb 2002 16:51:37 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: New: 6.2.4.5 "search" Command (Using XML for list of targets) References: <3C704DA3.76F1E8D1@Royer.com> <3C7576D0.E4D915D4@steltor.com> Content-Type: multipart/mixed; boundary="------------98F4C9FA83004280C7CAED08" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------98F4C9FA83004280C7CAED08 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > 6.2.4.5 "search" Command > > C: MSG 1 13 . 12507 378 > > C: Content-Type: application/cap+xml > > C: > > C: > > The list of targets should be specified in XML > i.e., not as a comma separated list. Why not just eliminate them from the transport command :-) I was trying to keep the command down to wireless packet size for wireless devices. They don't have a fixed size, but it is always small. --------------98F4C9FA83004280C7CAED08 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------98F4C9FA83004280C7CAED08-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 19:10:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07809 for ; Thu, 21 Feb 2002 19:10:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LNnS804768 for ietf-calendar-bks; Thu, 21 Feb 2002 15:49:28 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LNnQ304763 for ; Thu, 21 Feb 2002 15:49:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA17669 for ; Thu, 21 Feb 2002 15:49:22 -0800 (PST) Message-ID: <3C758776.35D438AA@Royer.com> Date: Thu, 21 Feb 2002 16:49:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Inconsistency in reply format References: <3C757562.9D203C72@steltor.com> Content-Type: multipart/mixed; boundary="------------C66A99056EDD2882415EFC3E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C66A99056EDD2882415EFC3E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The format of the reply should be consistent for all > the commands. In Doug's proposal, the following > formats are used: > > 1- > > 2- ... > > 3- ... > > In the end it does not really matter what is used, > but it should be consistent. There are two issues (3rd one was an error). And they are iCalendar 'result-status' and command replies. is the 2445 REQUEST-STATUS is the command reply. They had been separated in the past. I have no problem with all over the place. --------------C66A99056EDD2882415EFC3E 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------C66A99056EDD2882415EFC3E-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 19:11:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07832 for ; Thu, 21 Feb 2002 19:11:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LNrWO04892 for ietf-calendar-bks; Thu, 21 Feb 2002 15:53:32 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LNrV304888 for ; Thu, 21 Feb 2002 15:53:31 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA17677 for ; Thu, 21 Feb 2002 15:53:32 -0800 (PST) Message-ID: <3C758875.8963FF18@Royer.com> Date: Thu, 21 Feb 2002 16:53:25 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: New "4.1.6 Query for all Non-Booked Entries" References: <3C6EF0E2.BC64ED36@Royer.com> <3C7577AB.7ACC2464@steltor.com> Content-Type: multipart/mixed; boundary="------------9997131076CCF7EC94374587" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9997131076CCF7EC94374587 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > BEGIN:VQUERY > > QUERYID:Fetch VEVENT and VTODO iTIP components > > ... > > END:VQUERY > > Change QUERYID to NAME and add a random QUERYID. > > Same for examples of VQUERY. That string is a valid QUERYID. I will add a NAME property. --------------9997131076CCF7EC94374587 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------9997131076CCF7EC94374587-- From owner-ietf-calendar@mail.imc.org Thu Feb 21 19:14:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07854 for ; Thu, 21 Feb 2002 19:14:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1LNw0W05062 for ietf-calendar-bks; Thu, 21 Feb 2002 15:58:00 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LNvx305058 for ; Thu, 21 Feb 2002 15:57:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA17681 for ; Thu, 21 Feb 2002 15:58:01 -0800 (PST) Message-ID: <3C758982.42A947D7@Royer.com> Date: Thu, 21 Feb 2002 16:57:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Registration of new MIME media type application/cap+xml References: <3C7578F2.1BCC1254@steltor.com> Content-Type: multipart/mixed; boundary="------------B2427FEDFC637BADEDCDE75E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B2427FEDFC637BADEDCDE75E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > We will need to write a registration form for a new > MIME media type application/cap+xml. This wasn't > required for application/beep+xml, since this media > is already registered in BEEP. Thanks. I still want to re-bring up the point that there is NO beep requirement that we have a content type of XML. In fact I still think we should just use the already registered type if text/calendar in the BEEP transport of CAP and include everything in the iCalendar object. Then the xcal draft can send out the XML stuff and describe the BEEP profile. MSG .... Content-Type: text/calendar END MSG ... Content-Type: text/calendar And for non-iTIP objects. BEGIN:VCALENDAR CMD:CREATE CMDID:... ... END:VCALENDAR END Then the xcal draft can send out the XML stuff and describe the BEEP + CAP + XML profile. --------------B2427FEDFC637BADEDCDE75E 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------B2427FEDFC637BADEDCDE75E-- From owner-ietf-calendar@mail.imc.org Fri Feb 22 09:50:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04129 for ; Fri, 22 Feb 2002 09:50:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MEWqN29677 for ietf-calendar-bks; Fri, 22 Feb 2002 06:32:52 -0800 (PST) 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 g1MEWp329673 for ; Fri, 22 Feb 2002 06:32:51 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Registration of new MIME media type application/cap+xml MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 22 Feb 2002 09:41:08 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/22/2002 09:41:25 AM, Serialize complete at 02/22/2002 09:41:25 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >In fact I still think we should just use the already >registered type if text/calendar in the BEEP transport >of CAP and include everything in the iCalendar object. This would have the advantage of better layer separation. Makes it easier to build systems that run CAP over protocols other than BEEP. For example, Nokia could build a cellphone that does CAP by sending and receiving iCalendars over SMS. Then just build an SMS-to-BEEP proxy, and Bjorn Stronginthearm's your uncle. Plus, if, in 2012, someone wants to build CAP-NG over some newer substrate (BEEP-NG?), they just have to send the same text/calendar messages. Makes for a better transition plan. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Stock up and save! Limit one. | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 22 11:30:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09007 for ; Fri, 22 Feb 2002 11:30:58 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1MGLGf06004 for ietf-calendar-bks; Fri, 22 Feb 2002 08:21:16 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MGLF306000 for ; Fri, 22 Feb 2002 08:21:15 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA32663 for ; Fri, 22 Feb 2002 11:21:11 -0500 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 g1MGLAQ03682 for ; Fri, 22 Feb 2002 11:21:10 -0500 (EST) Message-ID: <3C767076.777CBA90@steltor.com> Date: Fri, 22 Feb 2002 11:23:18 -0500 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: CAP: BEEP / better layer separation (Was: Re: CAP: Registration of new MIME media type application/cap+xml) 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: > > >In fact I still think we should just use the already > >registered type if text/calendar in the BEEP transport > >of CAP and include everything in the iCalendar object. > > This would have the advantage of better layer separation. Makes it easier > to build systems that run CAP over protocols other than BEEP. For > example, Nokia could build a cellphone that does CAP by sending and > receiving iCalendars over SMS. Then just build an SMS-to-BEEP proxy, and > Bjorn Stronginthearm's your uncle. > > Plus, if, in 2012, someone wants to build CAP-NG over some newer substrate > (BEEP-NG?), they just have to send the same text/calendar messages. Makes > for a better transition plan. Hi John! I'm sorry, I don't understand what you mean by "better layer separation". CAP is a connection-oriented protocol. As such, it is not clear to me how one could run CAP onto a store and forward service such as SMS, or provide a mapping of BEEP onto SMS for that matter. CAP is defined as a BEEP [RFC 3080] profile, and rely on the mapping of BEEP onto TCP [RFC 3081]. To run CAP over another protocol, one simply needs to rely on a different mapping of BEEP. 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 Feb 22 12:06:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11188 for ; Fri, 22 Feb 2002 12:06:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MGuhG07826 for ietf-calendar-bks; Fri, 22 Feb 2002 08:56:43 -0800 (PST) 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 g1MGuf307822 for ; Fri, 22 Feb 2002 08:56:42 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: BEEP / better layer separation (Was: Re: CAP: Registration of new MIME media type application/cap+xml) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 22 Feb 2002 12:04:57 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/22/2002 12:05:16 PM, Serialize complete at 02/22/2002 12:05:16 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I'm sorry, I don't understand what you mean by "better >layer separation". If CAP is defined as exchanging iCalendar messages, like iTIP, then it becomes easier to move onto different substrates. >CAP is defined as a BEEP [RFC 3080] profile, and rely on >the mapping of BEEP onto TCP [RFC 3081]. To run CAP over >another protocol, one simply needs to rely on a different >mapping of BEEP. Oh, there is that; that would be more useful. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |============================================================| |In the country of the blind, the one-eyed man is in therapy.| \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 22 12:10:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11439 for ; Fri, 22 Feb 2002 12:10:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1MGxoA07863 for ietf-calendar-bks; Fri, 22 Feb 2002 08:59:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MGxn307859 for ; Fri, 22 Feb 2002 08:59:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA19107 for ; Fri, 22 Feb 2002 08:59:49 -0800 (PST) Message-ID: <3C767901.58E6E0E6@Royer.com> Date: Fri, 22 Feb 2002 09:59:45 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: BEEP / better layer separation (Was: Re: CAP: Registration of new MIME media type application/cap+xml) References: <3C767076.777CBA90@steltor.com> Content-Type: multipart/mixed; boundary="------------183CE9C33707E1EFDC5C34CC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------183CE9C33707E1EFDC5C34CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi John! > > I'm sorry, I don't understand what you mean by "better > layer separation". > > CAP is a connection-oriented protocol. As such, it is > not clear to me how one could run CAP onto a store and > forward service such as SMS, or provide a mapping of > BEEP onto SMS for that matter. CAP is also composed of iCalendar objects that are independant of transport. I think that was John's point. > CAP is defined as a BEEP [RFC 3080] profile, and rely on > the mapping of BEEP onto TCP [RFC 3081]. To run CAP over > another protocol, one simply needs to rely on a different > mapping of BEEP. Or one could take the CAP objects and use them in another transport. Like SMS or even iMIP them. --------------183CE9C33707E1EFDC5C34CC 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------183CE9C33707E1EFDC5C34CC-- From owner-ietf-calendar@mail.imc.org Fri Feb 22 12:26:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12508 for ; Fri, 22 Feb 2002 12:26:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MHEZ908129 for ietf-calendar-bks; Fri, 22 Feb 2002 09:14:35 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MHEY308125 for ; Fri, 22 Feb 2002 09:14:35 -0800 (PST) To: Bernard Desruisseaux Cc: ietf-calendar@imc.org Subject: Re: CAP: Searching iTIP objects MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02062002 February 06, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 22 Feb 2002 12:09:45 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/22/2002 12:09:33 PM, Serialize complete at 02/22/2002 12:09:33 PM Content-Type: multipart/alternative; boundary="=_alternative 005E5B6285256B68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E5B6285256B68_= Content-Type: text/plain; charset="US-ASCII" Bernard wrote: > Assuming Mary submits the following iCalendar object > in Bob's calendar: > Well, you use iTIP in your subject line but your (snipped) example is CAP, NOT iTIP so the rest this may not be exactly what you want to hear... > a) Which VQUERY component will allow Bob to find > this iCalendar object in his calendar? > > My guess: would be incorrect since you are searching for any VEVENTs that have METHOD:ADD in them but your CAP example had NO METHOD property in the VEVENT so your search would NOT find it. Had the original entry been in iTIP format instead of CAP then it would still be wrong. That is, no METHOD:ADD in the VCALENDAR and _certainly_ NOT a METHOD:ADD inside the VEVENT as that is adding an instance to the repeat set; presumably you would search for METHOD:REQUEST inside the VEVENT. > b) How will the returned VEVENT component look like? > > My guess: is again incorrect because someone (presumably the CS??) added a METHOD:ADD to the VEVENT and as stated before that would be defintely wrong for 2 reasons. The first is that ADD is for changing repeat sets (not in your example) and secondly that the CS is modifying the data that it was given for some unknown reason... I suggest you need rework your example and then we can see what the answer will be... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005E5B6285256B68_= Content-Type: text/html; charset="US-ASCII"
Bernard wrote:
> Assuming Mary submits the following iCalendar object
> in Bob's calendar:
>

Well, you use iTIP in your subject line but your (snipped) example is CAP, NOT iTIP so the rest this may not be exactly what you want to hear...

> a) Which VQUERY component will allow Bob to find
>    this iCalendar object in his calendar?
>
>    My guess:
would be incorrect since you are searching for any VEVENTs that have METHOD:ADD in them but your CAP example had NO METHOD property in the VEVENT so your search would NOT find it.  

Had the original entry been in iTIP format instead of CAP then it would still be wrong.  That is, no METHOD:ADD in the VCALENDAR and _certainly_ NOT a METHOD:ADD inside the VEVENT as that is adding an instance to the repeat set; presumably you would search for METHOD:REQUEST inside the VEVENT.

> b) How will the returned VEVENT component look like?
>
>    My guess:
is again incorrect because someone (presumably the CS??) added a METHOD:ADD to the VEVENT and as stated before that would be defintely wrong for 2 reasons.  The first is that ADD is for changing repeat sets (not in your example) and secondly that the CS is modifying the data that it was given for some unknown reason...

I suggest you need rework your example and then we can see what the answer will be...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 005E5B6285256B68_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 22 13:00:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13919 for ; Fri, 22 Feb 2002 13:00:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1MHosS08912 for ietf-calendar-bks; Fri, 22 Feb 2002 09:50:54 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MHor308908 for ; Fri, 22 Feb 2002 09:50:53 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA02210 for ; Fri, 22 Feb 2002 12:50:49 -0500 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 g1MHonQ13918 for ; Fri, 22 Feb 2002 12:50:49 -0500 (EST) Message-ID: <3C768578.7F7C09CE@steltor.com> Date: Fri, 22 Feb 2002 12:52:56 -0500 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: CAP: BEEP / better layer separation (Was: Re: CAP: Registration of newMIME media type application/cap+xml) 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'm sorry, I don't understand what you mean by "better > >layer separation". > > If CAP is defined as exchanging iCalendar messages, like iTIP, then it > becomes easier to move onto different substrates. Thanks for the clarification. You should note though that CAP, unlike iTIP, is not defined as exchanging iCalendar messages. CAP is simply a protocol that permits CUA to access an iCalendar based Calendar Store. CAP is an access protocol, iTIP is not. 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 Feb 22 14:05:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17144 for ; Fri, 22 Feb 2002 14:05:30 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1MIrw410405 for ietf-calendar-bks; Fri, 22 Feb 2002 10:53:58 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MIru310400 for ; Fri, 22 Feb 2002 10:53:56 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA03337 for ; Fri, 22 Feb 2002 13:53:53 -0500 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 g1MIrqQ20134 for ; Fri, 22 Feb 2002 13:53:52 -0500 (EST) Message-ID: <3C769440.EA69E762@steltor.com> Date: Fri, 22 Feb 2002 13:56:00 -0500 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: CAP: Registration of new MIME media type application/cap+xml References: <3C7578F2.1BCC1254@steltor.com> <3C758982.42A947D7@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: > > > > We will need to write a registration form for a new > > MIME media type application/cap+xml. This wasn't > > required for application/beep+xml, since this media > > is already registered in BEEP. > > Thanks. I still want to re-bring up the point that there > is NO beep requirement that we have a content type > of XML. > > In fact I still think we should just use the already > registered type if text/calendar in the BEEP transport > of CAP and include everything in the iCalendar object. Here's what I think are the options: a) Use application/beep+xml. No registration required. b) Use application/cap+xml. Registration required. c) Use text/calendar. No registration required, but will require us to change and review all the examples. I favor (a) as I believe it will help us get a last call sooner, but I understand that consensus should drive the schedule and not the other way around. 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 Feb 22 15:20:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21659 for ; Fri, 22 Feb 2002 15:20:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MJukp11566 for ietf-calendar-bks; Fri, 22 Feb 2002 11:56:46 -0800 (PST) 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 g1MJui311562 for ; Fri, 22 Feb 2002 11:56:45 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Registration of new MIME media type application/cap+xml MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 22 Feb 2002 15:04:56 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/22/2002 03:05:20 PM, Serialize complete at 02/22/2002 03:05:20 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >c) Use text/calendar. No registration required, but will > require us to change and review all the examples. That review wouldn't take much work, though; it should be straightforward to compare them visually. IIRC, in most cases the XML is just a container, with no extra data at all; so you'd just be comparing the contained iCalendar in the XML version to the top-level iCalendar in the text/calendar version. Now that I think of it, I think the burden is really on Bernard to establish that we should change from text/calendar to XML. The WG had always agreed on CAP commands being carried as text/calendar objects; when Bernard did -06, there was no consensus to change to wrapping it in XML. So using text/calendar isn't changing the consensus, it's fixing -06's failure to not reflect the existing consensus. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |Q: What goes "Pieces of 7! Pieces of 7!"? A: A parroty error.| \=============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 22 15:34:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22422 for ; Fri, 22 Feb 2002 15:34:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MKPNC12311 for ietf-calendar-bks; Fri, 22 Feb 2002 12:25:23 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MKPM312307 for ; Fri, 22 Feb 2002 12:25:22 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Who Sent The Counter? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02062002 February 06, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 22 Feb 2002 15:25:20 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/22/2002 03:20:20 PM, Serialize complete at 02/22/2002 03:20:20 PM Content-Type: multipart/alternative; boundary="=_alternative 00701F7585256B68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00701F7585256B68_= Content-Type: text/plain; charset="US-ASCII" Doug replied: > PAT - BOB - Per 2445, We just register a new 2445 property > this way - correct? Or does it have to also be an accepted draft? > If no, then we will have to include this in CAP. The steps in Section 7.2 of RFC 2445 are a bit wrong on how to do this. The actions for Section 7.2.1 shoud only occur after the other 7.2.x steps have been taken. The order of progress should be nearly identical to that outlined in Section 7.3 Property Change Control. Basically: 1. Define the change 2. Post the change 3. Allow a comment period 4. Submit the property for approval (Section 7.2 essentially goes 4,1,2,3). Frank had accepted the task of writing up some text but I dont think we'll see it any time soon. Perhaps Doug or I can get something out to take care of this. In response to Georges: >since the problem was solved in iTIP, can we close this issue? I would agree w/Doug that its still an issue (for iCalendar & iTIP as well as CAP) so it we shouldnt just remove it from the issues list until we have some text and discussion on it. Otherwise we may forget it for another ~2 years... Given the lack of disent to the the pseudo-proposal Frank posted I think it will be one of our less contenscious topics. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00701F7585256B68_= Content-Type: text/html; charset="US-ASCII"
Doug replied:
> PAT - BOB - Per 2445, We just register a new 2445 property
> this way - correct? Or does it have to also be an accepted draft?
> If no, then we will have to include this in CAP.

The steps in Section 7.2 of  RFC 2445 are a bit wrong on how to do this.  The actions for Section 7.2.1 shoud only occur after the other 7.2.x steps have been taken.  The order of progress should be nearly identical to that outlined in Section 7.3 Property Change Control.  Basically:

        1.           Define the change
       2.           Post the change
       3.           Allow a comment period
       4.           Submit the property for approval
(Section 7.2 essentially goes 4,1,2,3).  Frank had accepted the task of writing up some text but I dont think we'll see it any time soon.  Perhaps Doug or I can get something out to take care of this.

In response to Georges:
>since the problem was solved in iTIP, can we close this issue?

I would agree w/Doug that its still an issue (for iCalendar & iTIP as well as CAP) so it we shouldnt just remove it from the issues list until we have some text and discussion on it.  Otherwise we may forget it for another ~2 years...  Given the lack of disent to the the pseudo-proposal Frank posted I think it will be one of our less contenscious topics.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00701F7585256B68_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 22 15:43:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22913 for ; Fri, 22 Feb 2002 15:43:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1MKUsP12459 for ietf-calendar-bks; Fri, 22 Feb 2002 12:30:54 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MKUs312455 for ; Fri, 22 Feb 2002 12:30:54 -0800 (PST) To: ietf-calendar@imc.org Subject: Updating drafts on WG web site MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02062002 February 06, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 22 Feb 2002 15:30:50 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/22/2002 03:25:52 PM, Serialize complete at 02/22/2002 03:25:52 PM Content-Type: multipart/alternative; boundary="=_alternative 0070A09285256B68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070A09285256B68_= Content-Type: text/plain; charset="US-ASCII" I just noticed that while the web page at our WG web site lists the latest posted version as -06, updated on 3-Jan-02, the actual page that gets loaded claims to be posted "November 20, 2001" so can the Editors please make sure they update this date as well when new drafts are posted. This will prevent accidents like our other 'rev by date' policy. Thanks. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0070A09285256B68_= Content-Type: text/html; charset="US-ASCII"
  I just noticed that while the web page at our WG web site lists the latest posted version as -06, updated on 3-Jan-02, the actual page that gets loaded claims to be posted "November 20, 2001" so can the Editors please make sure they update this date as well when new drafts are posted.  This will prevent accidents like our other 'rev by date' policy.  Thanks.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0070A09285256B68_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 22 15:54:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23621 for ; Fri, 22 Feb 2002 15:54:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MKhon12796 for ietf-calendar-bks; Fri, 22 Feb 2002 12:43:50 -0800 (PST) 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 g1MKhn312792 for ; Fri, 22 Feb 2002 12:43:49 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Registration of new MIME media type application/cap+xml MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 22 Feb 2002 15:52:03 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/22/2002 03:52:24 PM, Serialize complete at 02/22/2002 03:52:24 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >So using text/calendar isn't changing the consensus, it's fixing -06's >failure to not reflect the existing consensus. Correction: "failure to not reflect the existing consensus"--no "not". /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Speak softly and carry an Illudium Q-32 Explosive Space | |Disintegrator. | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 22 15:56:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24256 for ; Fri, 22 Feb 2002 15:56:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MKlWr12892 for ietf-calendar-bks; Fri, 22 Feb 2002 12:47:32 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MKlR312888 for ; Fri, 22 Feb 2002 12:47:27 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are Processed Is Specified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02062002 February 06, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 22 Feb 2002 15:47:23 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/22/2002 03:42:25 PM, Serialize complete at 02/22/2002 03:42:25 PM Content-Type: multipart/alternative; boundary="=_alternative 0072245185256B68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072245185256B68_= Content-Type: text/plain; charset="US-ASCII" Doug replied: > > iTIP already addresses the order in which scheduled components > > should be processed. We should remove the text. > > I agree. Not to rain on anyones parade but I think some text may still be in order. iTIP has to deal with the possibility that messages will arrive out of order due to its mulitple bindings (ie: iMIP). However since CAP is NOT a binding of iTIP you are going to need to have some text in CAP that is the CAP equivalent of Section 2.1.5 Message Sequencing of iTIP. Since I strongly doubt that you implicitly expect a scheduling CUA to be able to remove 'older' entries (right!?), the receiving CUA MUST have some guidance on how it should sort out multiple instances of the same CAP request. This is even more critical if CUAs are going to be allowed to do 'partial' processing of the scheduled entries (as the text near the bottom of 6.3.2 seems to imply)! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072245185256B68_= Content-Type: text/html; charset="US-ASCII"
Doug replied:
> >    iTIP already addresses the order in which scheduled components
> > should be processed. We should remove the text.
>
> I agree.

Not to rain on anyones parade but I think some text may still be in order.  

iTIP has to deal with the possibility that messages will arrive out of order due to its mulitple bindings (ie: iMIP).  However since CAP is NOT a binding of iTIP you are going to need to have some text in CAP that is the CAP equivalent of Section 2.1.5 Message Sequencing of iTIP.

Since I strongly doubt that you implicitly expect a scheduling CUA to be able to remove 'older' entries (right!?),  the receiving CUA MUST have some guidance on how it should sort out multiple instances of the same CAP request.

This is even more critical if CUAs are going to be allowed to do 'partial' processing of the scheduled entries (as the text near the bottom of 6.3.2 seems to imply)!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0072245185256B68_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 22 16:45:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26821 for ; Fri, 22 Feb 2002 16:45:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1MLY1p13766 for ietf-calendar-bks; Fri, 22 Feb 2002 13:34:01 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MLXx313762 for ; Fri, 22 Feb 2002 13:33:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA19550 for ; Fri, 22 Feb 2002 13:34:01 -0800 (PST) Message-ID: <3C76B942.C72CF4C5@Royer.com> Date: Fri, 22 Feb 2002 14:33:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are Processed IsSpecified In iTIP References: Content-Type: multipart/mixed; boundary="------------3757F4AE0065515B32925AEE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3757F4AE0065515B32925AEE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied: > > > iTIP already addresses the order in which scheduled components > > > should be processed. We should remove the text. > > > > I agree. > > Not to rain on anyones parade but I think some text may still be in > order. Yes. But not of the magnitude that was in the draft. I think is all we have to do is say something like that the CS may have iTIP messages that the CUA will have to process, refer to iTIP for how to process them. PLUS o Take the result and store/modify it as METHOD:CREATE in the CS. o And the CUA MUST preserve any un-processable objects in the CS so when the rest of any out of order objects arrive, the CUA can process them using iTIP rules. > iTIP has to deal with the possibility that messages will arrive out > of order due to its mulitple bindings (ie: iMIP). However since CAP > is NOT a binding of iTIP you are going to need to have some text in > CAP that is the CAP equivalent of Section 2.1.5 Message Sequencing > of iTIP. The CS should care less about message sequencing. The CUA that fetches the un-processed iTIP messages is going to care, and at that point - they can be treated exactly like iTIP from iMIP. > Since I strongly doubt that you implicitly expect a scheduling CUA > to be able to remove 'older' entries (right!?), ... I don't follow "'older' entries". > ... the receiving CUA MUST have some guidance on how it should sort > out multiple instances of the same CAP request. > This is even more critical if CUAs are going to be allowed to > do 'partial' processing of the scheduled entries (as the text near > the bottom of 6.3.2 seems to imply)! Yes - more like a bad example. We need to go over the examples more closely. --------------3757F4AE0065515B32925AEE 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------3757F4AE0065515B32925AEE-- From owner-ietf-calendar@mail.imc.org Fri Feb 22 17:59:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00114 for ; Fri, 22 Feb 2002 17:59:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MMmTq15006 for ietf-calendar-bks; Fri, 22 Feb 2002 14:48:29 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MMmS315002 for ; Fri, 22 Feb 2002 14:48:28 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA23772 for ; Fri, 22 Feb 2002 17:48:31 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA24863 for ; Fri, 22 Feb 2002 17:48:30 -0500 (EST) Received: from [18.18.1.170] (BOB.MIT.EDU [18.18.1.170]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA22377 for ; Fri, 22 Feb 2002 17:48:29 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Fri, 22 Feb 2002 17:50:00 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Last Call & Consensus Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All- Pat and I have been observing the list traffic, and following the various threads. It is our conclusion that the WG has not yet reached consensus on some key points, and so the draft is not yet ready for last call. Considering the significant movement and change in the last few months, our hope for a last-call by Minneapolis was probably too optimistic. Our goal now is to gather what consensus changes we have together for an -07 version of the draft, so that we can get it submitted by the deadline next Friday (3/1/02), and available for discussion in Minneapolis. To refresh for those who may not be familiar, the end point of this process looks like: 1) The WG enters a (somewhat informal) last-call period, which serves as a second-to-last review before this document will be considered by the IESG. If the chairs can detect sufficient consensus on the issues, and the document is as mature and correct as we can make it, it is forwarded to the Area Directors with our request that it advance. 2) The ADs/IESG announce the formal last-call period on the ietf-announce list, and the document gets a "final review by the general Internet community". Be aware that significant feedback/objections are not unknown. 3) Only after the IESG feels that any objections raised in last-call have been satisfied, can the document be considered for review as a Proposed Standard. (For details of the whole process, see: http://www.ietf.org/rfc/rfc2026.txt ) The point to take away from this reminder is that our work will have serious review by the entire community. We need to be confident we have done a complete and correct design before we expose our work to judgement. We are close, and have come far, but we're not yet finished. We hope that the recent energetic review on the list will continue, and that the document will continue to mature rapidly. -Bob & Pat From owner-ietf-calendar@mail.imc.org Fri Feb 22 18:56:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01591 for ; Fri, 22 Feb 2002 18:56:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MNl3T15935 for ietf-calendar-bks; Fri, 22 Feb 2002 15:47:03 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MNl2315931 for ; Fri, 22 Feb 2002 15:47:02 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA19849 for ; Fri, 22 Feb 2002 15:47:04 -0800 (PST) Message-ID: <3C76D870.F19F2BD7@Royer.com> Date: Fri, 22 Feb 2002 16:46:56 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Last Call & Consensus References: Content-Type: multipart/mixed; boundary="------------95D85B85479CFBC1887F281B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------95D85B85479CFBC1887F281B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think we have reached consensus on (not that the proposed text is bug free or needs tweaking) - but I think we agree on: o VCAR - latest proposal o VQUERY - latest proposal o shorter commands - latest proposal w/tweaks from WG. o Using SEQUENCE, LOCAL, and ENABLE to tag local only VALARMS. See thread: (#1) synchronization part 2, and identifying a components VALARM o CALID url - latest proposal. o Review process. - latest proposal o Overlap booking - no change - latest proposal. o How to identify who sent the COUNTER - use Franks proposal. o CALMASTER - change "MUST BE" to "SHOULD BE" a mailto url. o TRANSP - no change. o Synchronization - omit this from CAP - to complex for now. o RELCALID - globally unique - no. o RELATED-TO to replace CHILD/PARENT And I think that covers the major issues. Open: Do we use text/calendar or application/???-xml And the draft needs cleaned up as Bruce has pointed out with the examples and the various proposals were sent by N people and there will need to be an editing session to clean it up. --------------95D85B85479CFBC1887F281B 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------95D85B85479CFBC1887F281B-- From owner-ietf-calendar@mail.imc.org Sat Feb 23 11:50:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21545 for ; Sat, 23 Feb 2002 11:50:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1NGc5q15165 for ietf-calendar-bks; Sat, 23 Feb 2002 08:38:05 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1NGc3315161 for ; Sat, 23 Feb 2002 08:38:03 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g1NGc2O19953 for ; Sat, 23 Feb 2002 08:38:02 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GRZVJG00.9WJ for ; Sat, 23 Feb 2002 08:38:04 -0800 Message-ID: <3C77C52E.C6EE53B1@netscape.com> Date: Sat, 23 Feb 2002 08:37:02 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP Concensus: BEEP issues References: <3C72D9B2.6010100@netscape.com> <3C75B392.B9B8CBF4@steltor.com> Content-Type: multipart/mixed; boundary="------------CB3619394B4338EA35C23FE9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CB3619394B4338EA35C23FE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I'm a pretty strong believer in completely separating calendar data from the transport wrappers. If we put calendar data in the transport wrappers -- it's a slippery slope and it will come back to bite us. I thought we had consensus here from the last ietf meeting. George brought up a few messages where there may still be some concerns. I re-read these messages: > CAP data into the XML section: > > http://www.imc.org/ietf-calendar/mail-archive/msg02798.html > http://www.imc.org/ietf-calendar/mail-archive/msg02810.html > http://www.imc.org/ietf-calendar/mail-archive/msg02818.html I found nothing that requires CAP data in the BEEP wrappers. YOUR INPUT NEEDED HERE: Is there anyone on the list who believes that we should keep calendar information in any of the beep headers? This is an important point on which we need to close. Please respond either way so we know whether we have consensus or an issue. -Steve --------------CB3619394B4338EA35C23FE9 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650.937.3351 x-mozilla-html:FALSE org:Netscape adr:;;;;;; version:2.1 title:Director of Engineering fn:Steve Mansour end:vcard --------------CB3619394B4338EA35C23FE9-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 03:08:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02095 for ; Mon, 25 Feb 2002 03:08:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1P7sU915529 for ietf-calendar-bks; Sun, 24 Feb 2002 23:54:30 -0800 (PST) Received: from mail.lan-aces.com ([63.219.237.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1P7sS315525 for ; Sun, 24 Feb 2002 23:54:29 -0800 (PST) Message-Id: <200202250754.g1P7sS315525@above.proper.com> Received: from [63.219.237.99] (Ralph.Patterson@LAN-ACES.COM) by mail.lan-aces.com; Mon, 25 Feb 2002 01:53:07 -0600 X-WM-Posted-At: mail.lan-aces.com; Mon, 25 Feb 02 01:53:07 -0600 Received: from [63.219.237.99] (Ralph.Patterson@LAN-ACES.COM) by WebClean; Mon, 25 Feb 2002 01:53:06 -0600 Date: Mon, 25 Feb 2002 01:53:06 -0600 From: Ralph.Patterson@lan-aces.com To: sman@netscape.com (Steve Mansour) cc: CalSched IETF Subject: cc: re: CAP Concensus: BEEP issues X-Mailer: Office-Logic/Win32 7.00.10 MIME-Version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1P7sT315526 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Steve, Isn't this the same issue that came up when we originally did the iCalendar object and decided that calendar information shouldn't be in MIME headers? Is this a different issue? I still believe that calendar information should be independent of the transport so put me down on that side of the issue. Regards, Ralph Patterson *** End of comment *** On Saturday, February 23, 2002 10:37 AM, Steve Mansour wrote: > >Date: Sat, 23 Feb 2002 08:37:02 -0800 >From: Steve Mansour >To: CalSched IETF >Subject: CAP Concensus: BEEP issues > >All, > >I'm a pretty strong believer in completely separating calendar data from the transport wrappers. If we >put calendar data in the transport wrappers -- it's a slippery slope and it will come back to bite us. >I thought we had consensus here from the last ietf meeting. George brought up a few messages where >there may still be some concerns. I re-read these messages: > >> CAP data into the XML section: >> >> http://www.imc.org/ietf-calendar/mail-archive/msg02798.html >> http://www.imc.org/ietf-calendar/mail-archive/msg02810.html >> http://www.imc.org/ietf-calendar/mail-archive/msg02818.html > >I found nothing that requires CAP data in the BEEP wrappers. > >YOUR INPUT NEEDED HERE: Is there anyone on the list who believes that we should keep calendar >information in any of the beep headers? This is an important point on which we need to close. Please >respond either way so we know whether we have consensus or an issue. > >-Steve > > > From owner-ietf-calendar@mail.imc.org Mon Feb 25 09:50:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12396 for ; Mon, 25 Feb 2002 09:50:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PEa7S20046 for ietf-calendar-bks; Mon, 25 Feb 2002 06:36:07 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PEa5320039 for ; Mon, 25 Feb 2002 06:36:06 -0800 (PST) To: ietf-calendar@imc.org Subject: CalConnect III MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Mon, 25 Feb 2002 09:35:54 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 02/25/2002 09:36:07 AM, Serialize complete at 02/25/2002 09:36:07 AM Content-Type: multipart/alternative; boundary="=_alternative 0050310085256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0050310085256B6B_= Content-Type: text/plain; charset="us-ascii" Time is fast approaching for the next Interoperability testing. I've updated the interop information on www.calsch.org. You can find a welcome letter from our hosts, Novell. It includes information on great Novell rates at local hotels (http://www.calsch.org/CalConnect3/calconn3-welcome.html). If you are planning on attending, please contact me as soon as possible. I am in the process of making arrangements. This should be a great event. We look forward to seeing great participation. --=_alternative 0050310085256B6B_= Content-Type: text/html; charset="us-ascii"
Time is fast approaching for the next Interoperability testing.  I've updated the interop information on www.calsch.org.  You can find a welcome letter from our hosts, Novell.  It includes information on great Novell rates at local hotels (http://www.calsch.org/CalConnect3/calconn3-welcome.html).

If you are planning on attending, please contact me as soon as possible. I am in the process of making arrangements.  This should be a great event.  We look forward to seeing great participation. --=_alternative 0050310085256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 10:25:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13564 for ; Mon, 25 Feb 2002 10:25:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PF6rn23186 for ietf-calendar-bks; Mon, 25 Feb 2002 07:06:53 -0800 (PST) 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 g1PF6q323182 for ; Mon, 25 Feb 2002 07:06:52 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: cc: re: CAP Concensus: BEEP issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Feb 2002 10:15:28 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/25/2002 10:15:37 AM, Serialize complete at 02/25/2002 10:15:37 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Isn't this the same issue that came up when we originally did the >iCalendar object and decided that calendar information shouldn't be in >MIME headers? Ooh, good point. The MIME headers that we had in -05 are exactly analogous to data in the BEEP envelope. If there was consensus not to put calendar data into the MIME headers, then there was consensus not to put it into the BEEP envelope when transliterating CAP to be BEEP-based. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |============================================================| |"Never interrupt your enemy when he is making a mistake." --| |Napoleon | \============================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 25 11:08:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15539 for ; Mon, 25 Feb 2002 11:08:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1PFnuS24875 for ietf-calendar-bks; Mon, 25 Feb 2002 07:49:56 -0800 (PST) Received: from esmtp.starfish.com (esmtp.starfish.com [66.35.205.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PFnt324869 for ; Mon, 25 Feb 2002 07:49:55 -0800 (PST) Received: from pthompson509 ([63.249.68.175]) by esmtp.starfish.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 07:34:48 -0800 From: "Peter Thompson" To: "CalSched IETF" Subject: RE: re: CAP Concensus: BEEP issues Date: Mon, 25 Feb 2002 07:48:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200202250754.g1P7sS315525@above.proper.com> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 25 Feb 2002 15:34:48.0555 (UTC) FILETIME=[F57F0BB0:01C1BE11] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Folks, I also am on the side of keeping the calendar info completely seperate from transport. This way the calendar info can be sent using ANY transport (including SyncML). Cheers, Peter Thompson > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of > Ralph.Patterson@lan-aces.com > Sent: Sunday, February 24, 2002 11:53 PM > To: sman@netscape.com > Cc: CalSched IETF > Subject: cc: re: CAP Concensus: BEEP issues > > > > Steve, > Isn't this the same issue that came up when we originally did the > iCalendar object and decided that calendar information shouldn't be in > MIME headers? Is this a different issue? I still believe that calendar > information should be independent of the transport so put me down on that > side of the issue. > Regards, > Ralph Patterson > *** End of comment *** > > On Saturday, February 23, 2002 10:37 AM, Steve Mansour wrote: > > > >Date: Sat, 23 Feb 2002 08:37:02 -0800 > >From: Steve Mansour > >To: CalSched IETF > >Subject: CAP Concensus: BEEP issues > > > >All, > > > >I'm a pretty strong believer in completely separating calendar data from the > transport wrappers. If we > >put calendar data in the transport wrappers -- it's a slippery slope and it > will come back to bite us. > >I thought we had consensus here from the last ietf meeting. George brought up > a few messages where > >there may still be some concerns. I re-read these messages: > > > >> CAP data into the XML section: > >> > >> http://www.imc.org/ietf-calendar/mail-archive/msg02798.html > >> http://www.imc.org/ietf-calendar/mail-archive/msg02810.html > >> http://www.imc.org/ietf-calendar/mail-archive/msg02818.html > > > >I found nothing that requires CAP data in the BEEP wrappers. > > > >YOUR INPUT NEEDED HERE: Is there anyone on the list who believes that we > should keep calendar > >information in any of the beep headers? This is an important point on which > we need to close. Please > >respond either way so we know whether we have consensus or an issue. > > > >-Steve > > > > > > > > From owner-ietf-calendar@mail.imc.org Mon Feb 25 11:38:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17135 for ; Mon, 25 Feb 2002 11:38:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1PGTKt00498 for ietf-calendar-bks; Mon, 25 Feb 2002 08:29:20 -0800 (PST) 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 g1PGTJ300489 for ; Mon, 25 Feb 2002 08:29:19 -0800 (PST) To: ietf-calendar@imc.org Subject: RE: re: CAP Concensus: BEEP issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Feb 2002 11:37:57 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/25/2002 11:38:04 AM, Serialize complete at 02/25/2002 11:38:04 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >This way the calendar info can be >sent using ANY transport (including SyncML). ? I thought SyncML was transport-independent. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |Rope is rope, and string is string, and never the twine shall| |meet. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 25 12:08:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19025 for ; Mon, 25 Feb 2002 12:08:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PGxHs02702 for ietf-calendar-bks; Mon, 25 Feb 2002 08:59:17 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PGxB302690 for ; Mon, 25 Feb 2002 08:59:11 -0800 (PST) MIME-Version: 1.0 To: Doug@royer.com Cc: ietf-calendar@imc.org Subject: Re: Last Call & Consensus X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 11:57:18 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 11:54:51 AM, Serialize complete at 02/25/2002 11:54:51 AM Content-Type: multipart/alternative; boundary="=_alternative 005D28AB85256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005D28AB85256B6B_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/22/2002 06:46:56 PM: > I think we have reached consensus on (not that the proposed > text is bug free or needs tweaking) - but I think we agree on: Im not sure that we have concensus on that entire list. I for one am still behind on the massive backlog from the past couple weeks. I have yet to really be able to absorb it all and make comments (let alone agree) on everything. I know I need to focus on the query proposal and I need to dive more on BEEP and the separation of CAP and BEEP info... Then again maybe Im just the only one that feels this way. I know some folks really want to get thru WG last call on CAP by this meeting but given the info overload we've had lately Im not sure that we can do that safely. I for one do not want to repeat the Recurrence Grammar kind of confusion/obscurity we had for iCalendar in CAP; Id rather take another deep breath and a little more time to make sure we cover all the bases fully and clearly. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005D28AB85256B6B_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/22/2002 06:46:56 PM:
> I think we have reached consensus on (not that the proposed
> text is bug free or needs tweaking) - but I think we agree on:

Im not sure that we have concensus on that entire list.  I for one am still behind on the massive backlog from the past couple weeks.  I have yet to really be able to absorb it all and make comments (let alone agree) on everything.   I know I need to focus on the query proposal and I need to dive more on BEEP and the separation of CAP and BEEP info...

Then again maybe Im just the only one that feels this way.  I know some folks really want to get thru WG last call on CAP by this meeting but given the info overload we've had lately Im not sure that we can do that safely.  I for one do not want to repeat the Recurrence Grammar kind of confusion/obscurity we had for iCalendar in CAP; Id rather take another deep breath and a little more time to make sure we cover all the bases fully and clearly.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005D28AB85256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 12:33:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20295 for ; Mon, 25 Feb 2002 12:32:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PHNsU03342 for ietf-calendar-bks; Mon, 25 Feb 2002 09:23:54 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PHNr303338 for ; Mon, 25 Feb 2002 09:23:53 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are Processed IsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 11:37:27 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 12:19:29 PM, Serialize complete at 02/25/2002 12:19:29 PM Content-Type: multipart/alternative; boundary="=_alternative 005B34C685256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B34C685256B6B_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/22/2002 04:33:54 PM: > > > > iTIP already addresses the order in which scheduled components > > > > should be processed. We should remove the text. > > > > > > I agree. > > > > Not to rain on anyones parade but I think some text may still be in > > order. > > Yes. But not of the magnitude that was in the draft. I guess I misread your "I agree" to mean that you also wanted to remove the text as Bernard had proposed. Glad to see that I was wrong. I think we should not rely on just saying "Go read Section x.x.x of iTIP on sequencing AND then also do...". I would suggest that we directly include the full text we want in CAP so that its centralized and easily found. It also allows us to make sure we have no disjoins between what appears in iTIP and what may change for CAP. > The CS should care less about message sequencing. The CUA that > fetches the un-processed iTIP messages is going to care, and > at that point - they can be treated exactly like iTIP from iMIP. Its NOT just unprocessed iTIP messages, there can also be multiple unprocessed CAP scheduled requests waiting for the CUA. Its not illogical to expect that between the time I re/check my CS that someone may send more than 1 CAP request for the same event. For example, Im out sick for 1 day and in the mean time the AA for my boss has had to reschedule a team meeting 4 times. When I come back in the next day, my CUA is going to have to have some consistant way of dealing w/the scheduled requests (preferably it would 'know' to ignore all but the "most recenty" or some other such stuff). Right? Or are you implicitly assuming that the CS will filter out 'less than current' requests so they never show up?? > > Since I strongly doubt that you implicitly expect a scheduling CUA > > to be able to remove 'older' entries (right!?), ... > > I don't follow "'older' entries". 'Older' entries are entries that created prior to the 'latest' one. That is, they have a DTSTAMP prior to the "most recent" copy of the same event. (Thats not just reving SEQUENCE, its also DTSTAMP.) Perhaps I should have used the term "older instance" or "previously sent entries". Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005B34C685256B6B_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/22/2002 04:33:54 PM:
> > > >    iTIP already addresses the order in which scheduled components
> > > > should be processed. We should remove the text.
> > >
> > > I agree.
> >
> > Not to rain on anyones parade but I think some text may still be in
> > order.
>
> Yes. But not of the magnitude that was in the draft.

I guess I misread your "I agree" to mean that you also wanted to remove the text as Bernard had proposed.  Glad to see that I was wrong.

I think we should not rely on just saying "Go read Section x.x.x of iTIP on sequencing AND then also do...".  I would suggest that we directly include the full text we want in CAP so that its centralized and easily found.  It also allows us to make sure we have no disjoins between what appears in iTIP and what may change for CAP.

> The CS should care less about message sequencing. The CUA that
> fetches the un-processed iTIP messages is going to care, and
> at that point - they can be treated exactly like iTIP from iMIP.
Its NOT just unprocessed iTIP messages, there can also be multiple unprocessed CAP scheduled requests waiting for the CUA.  Its not illogical to expect that between the time I re/check my CS that someone may send more than 1 CAP request for the same event.  For example, Im out sick for 1 day and in the mean time the AA for my boss has had to reschedule a team meeting 4 times.  When I come back in the next day, my CUA is going to have to have some consistant way of dealing w/the scheduled requests (preferably it would 'know' to ignore all but the "most recenty" or some other such stuff).  Right?

Or are you implicitly assuming that the CS will filter out 'less than current' requests so they never show up??

> > Since I strongly doubt that you implicitly expect a scheduling CUA
> > to be able to remove 'older' entries (right!?), ...
>
> I don't follow "'older' entries".

'Older' entries are entries that created prior to the 'latest' one.  That is, they have a DTSTAMP prior to the "most recent" copy of the same event.  (Thats not just reving SEQUENCE, its also DTSTAMP.)  Perhaps I should have used the term "older instance" or "previously sent entries".

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

--=_alternative 005B34C685256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 12:39:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21234 for ; Mon, 25 Feb 2002 12:39:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1PHUAo03524 for ietf-calendar-bks; Mon, 25 Feb 2002 09:30:10 -0800 (PST) Received: from ismtp.starfish.com (ismtp.starfish.com.209.120.66.in-addr.arpa [66.120.209.21] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PHU9303520 for ; Mon, 25 Feb 2002 09:30:09 -0800 (PST) Received: from pthompson509 ([10.79.194.27]) by ismtp.starfish.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 25 Feb 2002 09:30:02 -0800 From: "Peter Thompson" To: Subject: RE: re: CAP Concensus: BEEP issues Date: Mon, 25 Feb 2002 09:30:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 25 Feb 2002 17:30:02.0618 (UTC) FILETIME=[0E9955A0:01C1BE22] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes, SyncML IS transport independant, as well as media format independant. However, we do use both vCalendar and iCalendar for the calendar information. I would like to see those formats remain transport independant as well. However it is possible that I have not read the email as carefully as I should, so I may not have to worry about this issue. Cheers, Peter Thompson > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke > Sent: Monday, February 25, 2002 8:38 AM > To: ietf-calendar@imc.org > Subject: RE: re: CAP Concensus: BEEP issues > > > > >This way the calendar info can be > >sent using ANY transport (including SyncML). > > ? I thought SyncML was transport-independent. > > /=============================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc. | > |http://www.incentivesystems.com |My opinions are my own. | > |=============================================================| > |Rope is rope, and string is string, and never the twine shall| > |meet. | > \=============================================================/ > From owner-ietf-calendar@mail.imc.org Mon Feb 25 13:06:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22301 for ; Mon, 25 Feb 2002 13:06:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PHtFQ04090 for ietf-calendar-bks; Mon, 25 Feb 2002 09:55:15 -0800 (PST) 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 g1PHtD304086 for ; Mon, 25 Feb 2002 09:55:13 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are Processed IsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Feb 2002 13:03:50 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/25/2002 01:03:59 PM, Serialize complete at 02/25/2002 01:03:59 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I think we should not rely on just saying "Go read Section x.x.x of >iTIP on sequencing AND then also do...". I would suggest that we >directly include the full text we want in CAP so that its centralized >and easily found. It also allows us to make sure we have no disjoins >between what appears in iTIP and what may change for CAP. But that would imply that an iTIP conversation with a CAP server might require different behavior than with another version of iTIP. That would break the "transport-independent" part of the iTIP design (and name), forcing us to add "quasi-" before the "Independent" part...and I don't want to have to pronounce "iTQIP". ;-) Even if we don't want to change anything for CAP, we should use iTIP by reference, rather than copying text, because someday we may need to change iTIP; we don't want to have to rev both RFCs at the same time. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |"How can one conceive of a one party system in a country that has| |over 200 varieties of cheese?" --Charles de Gaulle | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 25 13:59:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25007 for ; Mon, 25 Feb 2002 13:59:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PIjji05540 for ietf-calendar-bks; Mon, 25 Feb 2002 10:45:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PIji305536 for ; Mon, 25 Feb 2002 10:45:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA24413 for ; Mon, 25 Feb 2002 10:45:44 -0800 (PST) Message-ID: <3C7A8653.8F84E70A@Royer.com> Date: Mon, 25 Feb 2002 11:45:39 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are ProcessedIsSpecified In iTIP References: Content-Type: multipart/mixed; boundary="------------4E347412D6655E72817E0705" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4E347412D6655E72817E0705 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > I think we should not rely on just saying "Go read Section x.x.x of > iTIP on sequencing AND then also do...". I would suggest that we > directly include the full text we want in CAP so that its centralized > and easily found. It also allows us to make sure we have no disjoins > between what appears in iTIP and what may change for CAP. The text that explains how to do that is multiple pages long. In fact it is most of iTIP. As no one paragraph or section in iTIP explains how you do that. Do you have suggested text? Understanding iTIP is a MUST for a person reading CAP. Just point to the section(s). > > The CS should care less about message sequencing. The CUA that > > fetches the un-processed iTIP messages is going to care, and > > at that point - they can be treated exactly like iTIP from iMIP. > > Its NOT just unprocessed iTIP messages, there can also be multiple > unprocessed CAP scheduled requests waiting for the CUA. Its not > illogical to expect that between the time I re/check my CS that > someone may send more than 1 CAP request for the same event. For > example, Im out sick for 1 day and in the mean time the AA for my boss > has had to reschedule a team meeting 4 times. When I come back in the > next day, my CUA is going to have to have some consistant way of > dealing w/the scheduled requests (preferably it would 'know' to ignore > all but the "most recenty" or some other such stuff). Right? I guess I don't understand. It seems your example is 100% iTIP scheduling requests or if your AA did the iTIP processing for you - then you just have to re-sync. We are separating iTIP processing from synchronization. First you have to get *all* updated objects where LAST-MODIFIED time > CUA's last sync time. Then update older booked entries with the newer ones in both the CS and CUA. Then you can process any iTIP requests. If you don't do it in that order you have a mess that might not be fixable without asking for a REFRESH. > Or are you implicitly assuming that the CS will filter out 'less than > current' requests so they never show up?? No. I call anything that does that for you a 'CUA-bot' and it would have to follow the same rules as any other CUA. > > > Since I strongly doubt that you implicitly expect a scheduling CUA > > > to be able to remove 'older' entries (right!?), ... > > > > I don't follow "'older' entries". > > 'Older' entries are entries that created prior to the 'latest' one. > That is, they have a DTSTAMP prior to the "most recent" copy of the > same event. (Thats not just reving SEQUENCE, its also DTSTAMP.) > Perhaps I should have used the term "older instance" or "previously > sent entries". Your talking synchronization - not iTIP processing - correct? So I think we agree. --------------4E347412D6655E72817E0705 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------4E347412D6655E72817E0705-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 14:39:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26700 for ; Mon, 25 Feb 2002 14:39:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PJUU806483 for ietf-calendar-bks; Mon, 25 Feb 2002 11:30:30 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PJUT306479 for ; Mon, 25 Feb 2002 11:30:29 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are ProcessedIsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 14:30:24 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 02:26:05 PM, Serialize complete at 02/25/2002 02:26:05 PM Content-Type: multipart/alternative; boundary="=_alternative 006B0A8585256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B0A8585256B6B_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/25/2002 01:45:39 PM: > The text that explains how to do that is multiple pages long. In > fact it is most of iTIP. As no one paragraph or section in iTIP > explains how you do that. Do you have suggested text? Not sure what verison of iTIP you are reading but my copy just has a ~1 page text for Section 2.1.5 Message Sequencing. If I take into account the text above it (p. 11) and the amount of text that flows onto p. 12 then its just 1 page long... In any case (praticing my self focusing) the point is that we do need some text to describe how a CAP CUA has to deal with sequencing; the proposal to omit _all_ the text is a bad idea. > Understanding iTIP is a MUST for a person reading CAP. > Just point to the section(s). This implicit requirement is not always adhered to judging by some of the discussions we've had round here. Perhaps it should become part of the introduction along the lines of "It is assumed that the reader has some degree of familiarity with the iCalendar and iTIP RFCs (2445 and 2446 respectively) in order for all design concepts to make sense." > I guess I don't understand. It seems your example is 100% > iTIP scheduling requests or if your AA did the iTIP processing > for you - then you just have to re-sync. NO IT IS NOT. My AA uses CAP to "schedule" the entrys everyones calendar. She is NOT using iTIP to mail me the requests; she is using CAP. She does NOT "book" them, I dont allow her to! As such, this is different from using iTIP (ie: iMIP really) in that CAP is used to put the entry where my CUA finds it, NOT iTIP/iMIP. From my perspective as a CU they _SHOULD_ look the same but since only iTIP has any text to describe how my CUA should separate the latest from the rest the behaviour for CAP originating entries is unclear. There is a distinction between booking and scheduling entrys. Since its not valid design to say that all CUs who use CAP MUST be able to direct "book" me (ie: Actually put the entry on my calendar so that it blocks time, requires NO action on my part, etc) is not what we have; CAP MUST deal with sequencing of multiple scheduled entries that are awaiting my attention. In any case, we are in agreement that text _is_ necessary still; we just dont agree on the text or where it should be... > First you have to get *all* updated objects where LAST-MODIFIED > time > CUA's last sync time. LAST-MODIFIED is the wrong property to use. It should be DTSTAMP. See RFC 2446, Section 2.1.5. > > 'Older' entries are entries that created prior to the 'latest' one. > > That is, they have a DTSTAMP prior to the "most recent" copy of the > > same event. (Thats not just reving SEQUENCE, its also DTSTAMP.) > > Perhaps I should have used the term "older instance" or "previously > > sent entries". > > Your talking synchronization - not iTIP processing - correct? > > So I think we agree. Im NOT talking sync of any kind. I just summarized and paraphrased part of RFC 2446, Section 2.1.5. In any case, we agree that some sequencing text is appropriate for CAP and Bernards propsal to omit it is NOT good. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B0A8585256B6B_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/25/2002 01:45:39 PM:

> The text that explains how to do that is multiple pages long. In
> fact it is most of iTIP. As no one paragraph or section in iTIP
> explains how you do that. Do you have suggested text?
Not sure what verison of iTIP you are reading but my copy just has a ~1 page text for Section 2.1.5 Message Sequencing.  If I take into account the text above it (p. 11) and the amount of text that flows onto p. 12 then its just 1 page long...

In any case (praticing my self focusing) the point is that we do need some text to describe how a CAP CUA has to deal with sequencing; the proposal to omit _all_ the text is a bad idea.

<DIGRESSION>
> Understanding iTIP is a MUST for a person reading CAP.
> Just point to the section(s).
This implicit requirement is not always adhered to judging by some of the discussions we've had round here.  Perhaps it should become part of the introduction along the lines of "It is assumed that the reader has some degree of familiarity with the iCalendar and iTIP RFCs (2445 and 2446 respectively) in order for all design concepts to make sense."
</DIGRESSON>

> I guess I don't understand. It seems your example is 100%
> iTIP scheduling requests or if your AA did the iTIP processing
> for you - then you just have to re-sync.
NO IT IS NOT.  My AA uses CAP to "schedule" the entrys everyones calendar.  She is NOT using iTIP to mail me the requests; she is using CAP.  She does NOT "book" them, I dont allow her to!  As such, this is different from using iTIP (ie: iMIP really) in that CAP is used to put the entry where my CUA finds it, NOT iTIP/iMIP.  

From my perspective as a CU they _SHOULD_ look the same but since only iTIP has any text to describe how my CUA should separate the latest from the rest the behaviour for CAP originating entries is unclear.

There is a distinction between booking and scheduling entrys.  Since its not valid design to say that all CUs who use CAP MUST be able to direct "book" me (ie: Actually put the entry on my calendar so that it blocks time, requires NO action on my part, etc) is not what we have; CAP MUST deal with sequencing of multiple scheduled entries that are awaiting my attention.

In any case, we are in agreement that text  _is_ necessary still; we just dont agree on the text or where it should be...

<DIGRESSION>
> First you have to get *all* updated objects where LAST-MODIFIED
> time > CUA's last sync time.
LAST-MODIFIED is the wrong property to use.  It should be DTSTAMP.  See RFC 2446, Section 2.1.5.

> > 'Older' entries are entries that created prior to the 'latest' one.
> >  That is, they have a DTSTAMP prior to the "most recent" copy of the
> > same event.  (Thats not just reving SEQUENCE, its also DTSTAMP.)
> >  Perhaps I should have used the term "older instance" or "previously
> > sent entries".
>
> Your talking synchronization - not iTIP processing - correct?
>
> So I think we agree.

Im NOT talking sync of any kind.  I just summarized and paraphrased part of RFC 2446, Section 2.1.5.  In any case, we agree that some sequencing text is appropriate for CAP and Bernards propsal to omit it is NOT good.
</DIGRESSION>

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

--=_alternative 006B0A8585256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 14:45:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26907 for ; Mon, 25 Feb 2002 14:45:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PJbRB06678 for ietf-calendar-bks; Mon, 25 Feb 2002 11:37:27 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PJbP306674 for ; Mon, 25 Feb 2002 11:37:25 -0800 (PST) To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are Processed IsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 14:36:15 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 02:33:01 PM, Serialize complete at 02/25/2002 02:33:01 PM Content-Type: multipart/alternative; boundary="=_alternative 006B939685256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B939685256B6B_= Content-Type: text/plain; charset="US-ASCII" John digressed on 02/25/2002 01:03:50 PM: > But that would imply that an iTIP conversation with a CAP server might > require different behavior than with another version of iTIP. That would > break the "transport-independent" part of the iTIP design [Snip, snip] Not sure where you got that from. If my CUA speaks CAP and iTIP and the rules for ordering entries received via iTIP changes, how is that a problem w/CAP?? I think you are treating CAP as a binding of iTIP (ala iRIP) and thats not a valid comparison. Since Section 2.1.5 of iTIP is ~1 page, I dont see why explicit inclusion of it (w/the proper updates/changes for CAP) is a bad thing. Its not like Im saying that we need to include all the restriction tables of iTIP or anything... Its logical to include it in CAP since the sequencing rules are for CAP and may (or may not) require some tweaking to deal w/the CAP design. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B939685256B6B_= Content-Type: text/html; charset="US-ASCII"
John digressed on 02/25/2002 01:03:50 PM:
> But that would imply that an iTIP conversation with a CAP server might
> require different behavior than with another version of iTIP.  That would
> break the "transport-independent" part of the iTIP design [Snip, snip]
Not sure where you got that from.  If my CUA speaks CAP and iTIP and the rules for ordering entries received via iTIP changes, how is that a problem w/CAP??  I think you are treating CAP as a binding of iTIP (ala iRIP) and thats not a valid comparison.

Since Section 2.1.5 of iTIP is ~1 page, I dont see why explicit inclusion of it (w/the proper updates/changes for CAP) is a bad thing.  Its not like Im saying that we need to include all the restriction tables of iTIP or anything...  Its logical to include it in CAP since the sequencing rules are for CAP and may (or may not) require some tweaking to deal w/the CAP design.

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


--=_alternative 006B939685256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 14:55:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27320 for ; Mon, 25 Feb 2002 14:55:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PJkgQ06937 for ietf-calendar-bks; Mon, 25 Feb 2002 11:46:42 -0800 (PST) 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 g1PJkf306933 for ; Mon, 25 Feb 2002 11:46:41 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are Processed IsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Feb 2002 14:55:18 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/25/2002 02:55:27 PM, Serialize complete at 02/25/2002 02:55:27 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> But that would imply that an iTIP conversation with a CAP server might >> require different behavior than with another version of iTIP. That would >> break the "transport-independent" part of the iTIP design [Snip, snip] > >Not sure where you got that from. Either the ordering rules are meant to be the same either way (in which case copying the text is a Bad Thing--just like copying code, it increases the maintenance costs), or iTIP over CAP is different from, say, iMIP. >I think you are treating CAP as a binding of iTIP (ala iRIP) and thats not a valid comparison. On the contrary; we've agreed ever since the Oslo meeting that CAP can be used as an iTIP binding: it can carry iTIP messages from CU A's CUA to CU B's CS, where CU B's CUA will pick them up. That's why we've got CRISP, instead of resurrecting iRIP. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |Rope is rope, and string is string, and never the twine shall| |meet. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 25 15:21:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28405 for ; Mon, 25 Feb 2002 15:21:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PK0nT07364 for ietf-calendar-bks; Mon, 25 Feb 2002 12:00:49 -0800 (PST) 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 g1PK0m307360 for ; Mon, 25 Feb 2002 12:00:48 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are ProcessedIsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Feb 2002 15:09:19 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/25/2002 03:09:34 PM, Serialize complete at 02/25/2002 03:09:34 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >My AA uses CAP to "schedule" the entrys everyones calendar. She is >NOT using iTIP to mail me the requests; she is using CAP. She does >NOT "book" them, I dont allow her to! As such, this is different >from using iTIP (ie: iMIP really) in that CAP is used to put the >entry where my CUA finds it, NOT iTIP/iMIP. Wrong. When your AA puts an iTIP message into your CS, she is putting that message where your CUA will see it--in effect, she is sending it to your CUA. This is *exactly* like sending you an iMIP message, and your CUA should react to it *exactly* the same way. The message is still an iTIP message, Independent of the Transport Protocol that was used to get it to you. If it's not an iTIP message, then it's just a VEVENT booked into your calendar. Those are the only options. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |I used to belong to a solipsism club, but I got bored & voted| |everybody else out. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 25 15:26:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28624 for ; Mon, 25 Feb 2002 15:26:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PKICQ08046 for ietf-calendar-bks; Mon, 25 Feb 2002 12:18:12 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PKIB308042 for ; Mon, 25 Feb 2002 12:18:11 -0800 (PST) To: BEEPwg@lists.beepcore.org, ietf-calendar@imc.org Subject: BEEP header & ABNF Question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 15:18:09 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 03:13:46 PM, Serialize complete at 02/25/2002 03:13:46 PM Content-Type: multipart/alternative; boundary="=_alternative 006F768985256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F768985256B6B_= Content-Type: text/plain; charset="US-ASCII" [Crossposting this to BEEP and CalSched WGs to insure proper coverage] In my attempt to be come more BEEP savy and dealing with the CAP issues I was rereading the BEEP RFC and I think there is a small disjoin between the text and the ABNF that folks should be aware of (or they can point out where the corrective text is). The text in Section 2.2.1.1 Frame Header says: The frame header consists of a three-character keyword (one of: "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more parameters. A single space character (decimal code 32, " ") separates each component. (my emphasis) but the ABNF in Section 2.2.1 Frame Syntax defines each of the parameters as mandatory: data = header payload trailer header = msg / rpy / err / ans / nul msg = "MSG" SP common CR LF rpy = "RPY" SP common CR LF ans = "ANS" SP common SP ansno CR LF err = "ERR" SP common CR LF nul = "NUL" SP common CR LF common = channel SP msgno SP more SP seqno SP size So is it just poor text in Section 2.2.1.1 or is there a case where the parameters are really optional? I ask because it makes the ABNF different if any parameter is truely optional and it makes the parser need a few more checks for 'skipped' parameters (assuming one could 'leave off', say' more as the text seemingly implys). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F768985256B6B_= Content-Type: text/html; charset="US-ASCII"
[Crossposting this to BEEP and CalSched WGs to insure proper coverage]

In my attempt to be come more BEEP savy and dealing with the CAP issues I was rereading the BEEP RFC and I think there is a small disjoin between the text and the ABNF that folks should be aware of (or they can point out where the corrective text is).  The text in Section 2.2.1.1 Frame Header says:

   The frame header consists of a three-character keyword (one of:
  "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more
  parameters.  A single space character (decimal code 32, " ")
  separates each component.

(my emphasis) but the ABNF in Section 2.2.1 Frame Syntax defines each of the parameters as mandatory:

   data       = header payload trailer

  header     = msg / rpy / err / ans / nul
   msg        = "MSG" SP common          CR LF
  rpy        = "RPY" SP common          CR LF
  ans        = "ANS" SP common SP ansno CR LF
  err        = "ERR" SP common          CR LF
  nul        = "NUL" SP common          CR LF
   common     = channel SP msgno SP more SP seqno SP size

So is it just poor text in Section 2.2.1.1 or is there a case where the parameters are really optional?  

I ask because it makes the ABNF different if any parameter is truely optional and it makes the parser need a few more checks for 'skipped' parameters (assuming one could 'leave off', say' more as the text seemingly implys).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006F768985256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 16:50:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01181 for ; Mon, 25 Feb 2002 16:50:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1PLZEg09950 for ietf-calendar-bks; Mon, 25 Feb 2002 13:35:14 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PLZD309946 for ; Mon, 25 Feb 2002 13:35:13 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA24626 for ; Mon, 25 Feb 2002 13:35:14 -0800 (PST) Message-ID: <3C7AAE0C.BC724400@Royer.com> Date: Mon, 25 Feb 2002 14:35:08 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Order In Which Scheduled Components AreProcessedIsSpecified In iTIP References: Content-Type: multipart/mixed; boundary="------------A613F3DDEE0D24499CBC36AA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A613F3DDEE0D24499CBC36AA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > I guess I don't understand. It seems your example is 100% > > iTIP scheduling requests or if your AA did the iTIP processing > > for you - then you just have to re-sync. > > NO IT IS NOT. My AA uses CAP to "schedule" the entrys everyones > calendar. She is NOT using iTIP to mail me the requests; she is using > CAP. She does NOT "book" them, I dont allow her to! As such, this is > different from using iTIP (ie: iMIP really) in that CAP is used to put > the entry where my CUA finds it, NOT iTIP/iMIP. I never said iMIP (She is NOT using iTIP to mail me the requests;), I said iTIP. She is doing iTIP, its just that the transport is CAP and not iMIP. Her CUA would deposit the METHOD:REQUEST (or whatever) into your CS to be processed by an OWNER CUA later - just as any other iTIP object. Your CUA should never care if the iTIP object came via iMIP, CAP, or whatever. And if she has the VCARs for it, then she could do the iTIP processing and deposit or modify any entries and book them. If not, then she leaves iTIP objects in your CS for an OWNER CUA to do the processing. > From my perspective as a CU they _SHOULD_ look the same but since only > iTIP has any text to describe how my CUA should separate the latest > from the rest the behaviour for CAP originating entries is unclear. I think the that examples show how to get iTIP objects out of your CS. And we should say, once the CUA gets those iTIP methods, process them just the same as if you got them from any other iTIP source. If it were not, we broke iTIP. --------------A613F3DDEE0D24499CBC36AA 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------A613F3DDEE0D24499CBC36AA-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 16:50:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01210 for ; Mon, 25 Feb 2002 16:50:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1PLdG510075 for ietf-calendar-bks; Mon, 25 Feb 2002 13:39:16 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PLdF310071 for ; Mon, 25 Feb 2002 13:39:15 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA24637 for ; Mon, 25 Feb 2002 13:39:16 -0800 (PST) Message-ID: <3C7AAEFE.EF253958@Royer.com> Date: Mon, 25 Feb 2002 14:39:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are ProcessedIsSpecified In iTIP References: Content-Type: multipart/mixed; boundary="------------E39FEE95190D7212CC2C0D77" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E39FEE95190D7212CC2C0D77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > But that would imply that an iTIP conversation with a CAP server > > might require different behavior than with another version of iTIP. > > That would break the "transport-independent" part of the iTIP design > > [Snip, snip] > > Not sure where you got that from. If my CUA speaks CAP and iTIP and > the rules for ordering entries received via iTIP changes, how is that > a problem w/CAP?? I think you are treating CAP as a binding of iTIP > (ala iRIP) and thats not a valid comparison. If you recall - we dropped iRIP and added the iRIP iTIP processing into CAP. Part of CAP is iTIP. All iTIP objects are valid in CAP and mean the same thing. CAP is a transport for iTIP. Your CUA can deposit iTIP objects into CAP. My CUA gets the iTIP objects out. And processes them the same as any other iTIP objects. --------------E39FEE95190D7212CC2C0D77 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------E39FEE95190D7212CC2C0D77-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 17:13:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01794 for ; Mon, 25 Feb 2002 17:13:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PM5dQ11012 for ietf-calendar-bks; Mon, 25 Feb 2002 14:05:39 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PM5b311008 for ; Mon, 25 Feb 2002 14:05:37 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components AreProcessedIsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 17:05:37 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 05:01:13 PM, Serialize complete at 02/25/2002 05:01:13 PM Content-Type: multipart/alternative; boundary="=_alternative 00794D7085256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00794D7085256B6B_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/25/2002 04:35:08 PM: > I never said iMIP (She is NOT using iTIP to mail me the requests;), I > said iTIP. > > She is doing iTIP, its just that the transport is CAP and not iMIP. So CAP is a binding of iTIP?? I haven't seen that in any specs/talks and we abandoned iRIP to replace it with CAP. CAP does more than iRIP (or iTIP) so I find this an interesting revelation... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00794D7085256B6B_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/25/2002 04:35:08 PM:

> I never said iMIP (She is NOT using iTIP to mail me the requests;), I
> said iTIP.
>
> She is doing iTIP, its just that the transport is CAP and not iMIP.
So CAP is a binding of iTIP??  I haven't seen that in any specs/talks and we abandoned iRIP to replace it with CAP.  CAP does more than iRIP (or iTIP) so I find this an interesting revelation...

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

--=_alternative 00794D7085256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 17:27:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02199 for ; Mon, 25 Feb 2002 17:27:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PMImH11493 for ietf-calendar-bks; Mon, 25 Feb 2002 14:18:48 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PMIm311489 for ; Mon, 25 Feb 2002 14:18:48 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are ProcessedIsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 17:18:46 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 05:14:23 PM, Serialize complete at 02/25/2002 05:14:23 PM Content-Type: multipart/alternative; boundary="=_alternative 007A81B685256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A81B685256B6B_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/25/2002 04:39:10 PM: > If you recall - we dropped iRIP and added the iRIP iTIP processing > into CAP. Part of CAP is iTIP. All iTIP objects are valid in CAP > and mean the same thing. I grok that we need this for iTIP compatability for several reasons but its never been expressly said in any text/drafts. I think it MUST be expressly written so that motivations for why something is or is not allowable is crystal clear. Otherwise we revert to "Well I see it as..." kinds of discussions instead of having clear cut guidelines for making decisions. The reason Im more than a bit skeptical is that some CAP commands use "deltas" instead of "full snapshots" and thats why I want to be 100% clear. An example of this "delta" use is the "add" element in Section 6.2.4.3 where only the 'changes' get sent. This is 100% NOT iTIP legal because the 'delta' is just that; its not a complete snapshot that iTIP expects or that an iMIP CUA would need. The same goes for much of the "modify" command. To make sure Im clear, when I say 'delta' I mean that the sender sends only the information that is to be changed and not ALL of the information relevant to that entity (or a "full snapshot" of the entry according to the sender). The example in Section 6.2.4.3 simply adds an attachment and thats NOT legal in iTIP. I am 110% behind the "CAP must not break iTIP" mantra but we have some work to do to make this correct in all cases (where appropriate). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007A81B685256B6B_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/25/2002 04:39:10 PM:
> If you recall - we dropped iRIP and added the iRIP iTIP processing
> into CAP. Part of CAP is iTIP. All iTIP objects are valid in CAP
> and mean the same thing.

I grok that we need this for iTIP compatability for several reasons but its never been expressly said in any text/drafts.  I think it MUST be expressly written so that motivations for why something is or is not allowable is crystal clear.  Otherwise we revert to "Well I see it as..." kinds of discussions instead of having clear cut guidelines for making decisions.

The reason Im more than a bit skeptical is that some CAP commands use "deltas" instead of "full snapshots" and thats why I want to be 100% clear.  An example of this "delta" use is the "add" element in Section 6.2.4.3 where only the 'changes' get sent.  This is 100% NOT iTIP legal because the 'delta' is just that; its not a complete snapshot that iTIP expects or that an iMIP CUA would need.  The same goes for much of the "modify" command.

To make sure Im clear, when I say 'delta' I mean that the sender sends only the information that is to be changed and not ALL of the information relevant to that entity (or a "full snapshot" of the entry according to the sender).  The example in Section 6.2.4.3 simply adds an attachment and thats NOT legal in iTIP.

I am 110% behind the "CAP must not break iTIP" mantra but we have some work to do to make this correct in all cases (where appropriate).

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

--=_alternative 007A81B685256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 17:53:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02893 for ; Mon, 25 Feb 2002 17:53:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PMgvb12188 for ietf-calendar-bks; Mon, 25 Feb 2002 14:42:57 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PMgu312184 for ; Mon, 25 Feb 2002 14:42:56 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are ProcessedIsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 17:41:29 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 05:38:31 PM, Serialize complete at 02/25/2002 05:38:31 PM Content-Type: multipart/alternative; boundary="=_alternative 007C95F585256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007C95F585256B6B_= Content-Type: text/plain; charset="US-ASCII" I wrote on 02/25/2002 05:18:46 PM: > The reason Im more than a bit skeptical is that some CAP commands > use "deltas" instead of "full snapshots" and thats why I want to be > 100% clear. Argh, Im blurring the lines between the CAP funtionality (ie: modifying the entry in my calendar) and any subsumed iTIP functionality (ie: The scheduling stuff under Section 6.3 Scheduling Commands). Mea culpa for that. Let me try to take a step back and restate what I wanted to say... Any action that does not directly or indirectly cause a workflow (ie: iTIP) message to be sent out does not need to be "valid in iTIP". However any action that directly or indirectly causes a workflow message to be sent MUST be "valid in iTIP". However its not clear to me still how any address provided in the "target" property of a "schedule" command can be considered valid in iTIP. For example, just what kind of "target" value would be used in the missing sample under Section 6.2.3.1 REQUEST method if I need to send an reply to an iTIP user (ie: ORGANIZER;CN="Bruce The Curious":mailto:Bruce_Kahn@ibm.com )?? According to 6.2.3.4 the value of "target" is either a CSID or a RelCalID; neither of which match the mailto URI that is needed... Bruce Just trying to keep the pieces straight in my head... =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007C95F585256B6B_= Content-Type: text/html; charset="US-ASCII"
I wrote on 02/25/2002 05:18:46 PM:
> The reason Im more than a bit skeptical is that some CAP commands
> use "deltas" instead of "full snapshots" and thats why I want to be
> 100% clear.  

Argh, Im blurring the lines between the CAP funtionality (ie: modifying the entry in my calendar) and any subsumed iTIP functionality (ie: The scheduling stuff under Section 6.3 Scheduling Commands).  Mea culpa for that.  Let me try to take a step back and restate what I wanted to say...

Any action that does not directly or indirectly cause a workflow (ie: iTIP) message to be sent out does not need to be "valid in iTIP".  However any action that directly or indirectly causes a workflow message to be sent MUST be "valid in iTIP".

However its not clear to me still how any address provided in the "target" property of a "schedule" command can be considered valid in iTIP.  For example, just what kind of "target" value would be used in the missing sample under Section 6.2.3.1 REQUEST method if I need to send an reply to an iTIP user (ie: ORGANIZER;CN="Bruce The Curious":mailto:Bruce_Kahn@ibm.com )??  According to 6.2.3.4 the value of "target" is either a CSID or a RelCalID; neither of which match the mailto URI that is needed...

Bruce
Just trying to keep the pieces straight in my head...
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007C95F585256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 17:56:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03011 for ; Mon, 25 Feb 2002 17:56:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PMmfe12336 for ietf-calendar-bks; Mon, 25 Feb 2002 14:48:41 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PMme312332 for ; Mon, 25 Feb 2002 14:48:40 -0800 (PST) To: Bernard Desruisseaux Cc: ietf-calendar@imc.org Subject: Re: CAP: Registration of new MIME media type application/cap+xml MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 17:48:32 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 05:44:16 PM, Serialize complete at 02/25/2002 05:44:16 PM Content-Type: multipart/alternative; boundary="=_alternative 007D3B3385256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007D3B3385256B6B_= Content-Type: text/plain; charset="US-ASCII" Bernard wrote: > > Thanks. I still want to re-bring up the point that there > > is NO beep requirement that we have a content type > > of XML. > > > > In fact I still think we should just use the already > > registered type if text/calendar in the BEEP transport > > of CAP and include everything in the iCalendar object. > > Here's what I think are the options: The options are irrelvant since the WG never discussed changing to use XML AND as Doug correctly notes we have a registered MIME type already. I suspect that the motivation for doing a sweeping change is due to the change to BEEP which likes XML for its commands. However thats not a justification for making such a change in CAP w/o WG discussion (and clearly there is no concensus for it and never has been). We should stick w/our text/calendar MIME type and focus on the technical challenges of CAP so we can get it baked quicker. (And folks probalby thought that Doug & I never agree... John is another matter. ;^) ) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007D3B3385256B6B_= Content-Type: text/html; charset="US-ASCII"
Bernard wrote:
> > Thanks. I still want to re-bring up the point that there
> > is NO beep requirement that we have a content type
> > of XML.
> >
> > In fact I still think we should just use the already
> > registered type if text/calendar in the BEEP transport
> > of CAP and include everything in the iCalendar object.
>
> Here's what I think are the options:

The options are irrelvant since the WG never discussed changing to use XML AND as Doug correctly notes we have a registered MIME type already.  I suspect that the motivation for doing a sweeping change is due to the change to BEEP which likes XML for its commands.  However thats not a justification for making such a change in CAP w/o WG discussion (and clearly there is no concensus for it and never has been).

We should stick w/our text/calendar MIME type and focus on the technical challenges of CAP so we can get it baked quicker.

(And folks probalby thought that Doug & I never agree... John is another matter. ;^) )

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 007D3B3385256B6B_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 18:22:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03782 for ; Mon, 25 Feb 2002 18:22:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PNEhs12850 for ietf-calendar-bks; Mon, 25 Feb 2002 15:14:43 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PNEg312846 for ; Mon, 25 Feb 2002 15:14:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA24759 for ; Mon, 25 Feb 2002 15:14:43 -0800 (PST) Message-ID: <3C7AC55C.638B044A@Royer.com> Date: Mon, 25 Feb 2002 16:14:36 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components AreProcessedIsSpecified In iTIP References: Content-Type: multipart/mixed; boundary="------------EFB1984FE2454EF3B4AB3AB7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EFB1984FE2454EF3B4AB3AB7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > To make sure Im clear, when I say 'delta' I mean that the sender sends > only the information that is to be changed and not ALL of the > information relevant to that entity (or a "full snapshot" of the entry > according to the sender). The example in Section 6.2.4.3 simply adds > an attachment and thats NOT legal in iTIP. True - but CAP is MORE than iTIP. The CU could add an attachment, increment the SEQUENCE using MODIFY. Not an iTIP process. Then the CUA could send out the updated object using iMIP. A CUA could also modify an iTIP object. Consider iTIP processing. The CUA could do some optimizing in its calendar and modify an existing iTIP object into a merged result of any iTIP processing done by the CUA. Until that object is sent over the wire, it does not matter what the CUA does with it as long as the end result is that over the wire objects (NON-local data) is the same as the ORGANIZERs given the same UID, SEQUENCE, ... . Another example, I get a REQUEST and accept it. The CUA could MODIFY the METHOD from REQUEST to CREATE in the CS to mark it as booked. Not an iTIP process on an iTIP object, but still valid CAP. > I am 110% behind the "CAP must not break iTIP" mantra but we have some > work to do to make this correct in all cases (where appropriate). Yes, many of the examples suck! Until we get the document ready for pushing the next revision, the examples should be considered flaky. We need to somehow say that a the ORGANIZER's object is the correct object (minus data marked local only). And a CUA MUST NOT modify non-local data to objects where OWNER != ORGANIZER, even in their own calendar - else it breaks iTIP. --------------EFB1984FE2454EF3B4AB3AB7 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------EFB1984FE2454EF3B4AB3AB7-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 18:38:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04136 for ; Mon, 25 Feb 2002 18:38:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PNUji13158 for ietf-calendar-bks; Mon, 25 Feb 2002 15:30:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PNUi313154 for ; Mon, 25 Feb 2002 15:30:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA24788 for ; Mon, 25 Feb 2002 15:30:46 -0800 (PST) Message-ID: <3C7AC91F.6DB1A4B@Royer.com> Date: Mon, 25 Feb 2002 16:30:39 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Consensus?: Order In Which Scheduled Components AreProcessedIsSpecified In iTIP References: Content-Type: multipart/mixed; boundary="------------511825498FD0F6C359D0C127" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------511825498FD0F6C359D0C127 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > However its not clear to me still how any address provided in the > "target" property of a "schedule" command can be considered valid in > iTIP. .... Toss the 06 meaning of 'target' and use the 05 version of 'TARGET'. As John and I keep saying, there was never any consensus to change that, the 06 meaning is an error. Take the 06 doc, rip out the XML commands, add in BEEP, and add it a single tag for command. That is the current state. I still want to rip out the remaining single xml command and make the CAP BEEP profile text/calendar only. The xml-Cal draft can then make a profile for xml-iCalendar objects and beep, and that will be 'the' xml profile for CSs that support XML-iCal --------------511825498FD0F6C359D0C127 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------511825498FD0F6C359D0C127-- From owner-ietf-calendar@mail.imc.org Mon Feb 25 19:08:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04716 for ; Mon, 25 Feb 2002 19:08:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PNxbK13708 for ietf-calendar-bks; Mon, 25 Feb 2002 15:59:37 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PNxY313704 for ; Mon, 25 Feb 2002 15:59:34 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: Consensus?: Order In Which Scheduled Components AreProcessedIsSpecified In iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 25 Feb 2002 18:59:28 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 06:55:09 PM, Serialize complete at 02/25/2002 06:55:09 PM Content-Type: multipart/alternative; boundary="=_alternative 0083B94D85256B6B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0083B94D85256B6B_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 02/25/2002 06:30:39 PM: > Toss the 06 meaning of 'target' and use the 05 version of 'TARGET'. > As John and I keep saying, there was never any consensus to > change that, the 06 meaning is an error. Too bad I dont keep archive copies of the drafts. Also making it hard to do this is that we apparently have SEVERAL -06 drafts up on the WG site. We do not have any -05 copies to be had. (I assume you mean that the -06 submitted for the last IETF is suspect and not just the interim drafts of the same name SANS dates as we should expect) CAP Editors: Can you put up a copy of the -05 Draft for those of us w/o complete archives of very interim draft ever written?? If need be Im sure John or Doug can provide a copy. > I still want to rip out the remaining single xml command > and make the CAP BEEP profile text/calendar only. I would concur since there has been no WG discussion of a change of this magnitude AND we have consistantly said NO to adopting XML. Until I can get a clearer picture of the -05 + BEEP Ill hold my tongue on this bit and go and get some eats w/the family... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0083B94D85256B6B_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 02/25/2002 06:30:39 PM:
<BIG TIME DIGRESSION>
> Toss the 06 meaning of 'target' and use the 05 version of 'TARGET'.
> As John and I keep saying, there was never any consensus to
> change that, the 06 meaning is an error.
Too bad I dont keep archive copies of the drafts.  Also making it hard to do this is that we apparently have SEVERAL -06 drafts up on the WG site.  We do not have any -05 copies to be had.   (I assume you mean that the -06 submitted for the last IETF is suspect and not just the interim drafts of the same name SANS dates as we should expect)

CAP Editors: Can you put up a copy of the -05 Draft for those of us w/o complete archives of very interim draft ever written??  If need be Im sure John or Doug can provide a copy.

> I still want to rip out the remaining single xml command
> and make the CAP BEEP profile text/calendar only.
I would concur since there has been no WG discussion of a change of this magnitude AND we have consistantly said NO to adopting XML.  

Until I can get a clearer picture of the -05 + BEEP Ill hold my tongue on this bit and go and get some eats w/the family...
</BIG TIME DIGRESSION>
Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0083B94D85256B6B_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 26 13:26:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14695 for ; Tue, 26 Feb 2002 13:26:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1QIB0718848 for ietf-calendar-bks; Tue, 26 Feb 2002 10:11:00 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QIAv318844 for ; Tue, 26 Feb 2002 10:10:58 -0800 (PST) To: ietf-calendar@imc.org Subject: To CalConnect or Not - that is the question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Feb 2002 13:10:53 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 02/26/2002 01:11:00 PM, Serialize complete at 02/26/2002 01:11:00 PM Content-Type: multipart/alternative; boundary="=_alternative 0063DFCF85256B6C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063DFCF85256B6C_= Content-Type: text/plain; charset="us-ascii" We are about 30 days away from CalConnect III. After tomorrow, flights get more expensive. At this time, we've heard from no company about signing up for this event. I don't want to get paranoid - but that's my nature. If you are planning on attending, please let me know as soon as possible. If this is not going to happen, I want to let Novell know quickly. This note is not meant to pressure people - it's get to get an idea of who will be attending. Thanks for your support. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0063DFCF85256B6C_= Content-Type: text/html; charset="us-ascii"
We are about 30 days away from CalConnect III.  After tomorrow, flights get more expensive.  At this time, we've heard from no company about signing up for this event.  I don't want to get paranoid - but that's my nature.  If you are planning on attending, please let me know as soon as possible.  If this is not going to happen, I want to let Novell know quickly.  This note is not meant to pressure people - it's get to get an idea of who will be attending.  Thanks for your support.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0063DFCF85256B6C_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 27 14:57:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14112 for ; Wed, 27 Feb 2002 14:57:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RJgCI04134 for ietf-calendar-bks; Wed, 27 Feb 2002 11:42:12 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RJgB304130 for ; Wed, 27 Feb 2002 11:42:11 -0800 (PST) To: ietf-calendar@imc.org Subject: RFC 2445 Big ABNF fauxpau MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 27 Feb 2002 14:45:10 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/27/2002 02:42:14 PM, Serialize complete at 02/27/2002 02:42:14 PM Content-Type: multipart/alternative; boundary="=_alternative 006C218185256B6D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C218185256B6D_= Content-Type: text/plain; charset="US-ASCII" I wonder how the heck this got past EVERYONE but it seems we reused a name in 2 places in the ABNF and they are not interchangable. Anyone got any guesses what property parameter defintions Im talking about?... We accidentally used attparam for both ATTACH and ATTENDEE to be the their respective property parameter definitions: attach = "ATTACH" attparam ":" uri CRLF attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64" ";" "VALUE" "=" "BINARY" ":" binary attparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" fmttypeparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) and attendee = "ATTENDEE" attparam ":" cal-address CRLF attparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" cutypeparam) / (";"memberparam) / (";" roleparam) / (";" partstatparam) / (";" rsvpparam) / (";" deltoparam) / (";" delfromparam) / (";" sentbyparam) / (";"cnparam) / (";" dirparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) This MUST get fixed when we update 2445! %^| I propose that we change attparam on ATTACH to be attachparam and we leave attparam on ATTENDEE as is. If there is any sentiment to change that to attendeeparam then that works for me too. Thoughts?? Shannon: Can you please chalk this one up on the To Do list for 2445 so we dont forget it?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006C218185256B6D_= Content-Type: text/html; charset="US-ASCII"
I wonder how the heck this got past EVERYONE but it seems we reused a name in 2 places in the ABNF and they are not interchangable.  Anyone got any guesses what property parameter defintions Im talking about?...

We accidentally used attparam for both ATTACH and ATTENDEE to be the their respective property parameter definitions:

     attach     = "ATTACH" attparam ":" uri  CRLF

    attach     =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64"
                  ";" "VALUE" "=" "BINARY" ":" binary

    attparam   = *(

               ; the following is optional,
               ; but MUST NOT occur more than once

               (";" fmttypeparam) /

               ; the following is optional,
               ; and MAY occur more than once

               (";" xparam)

               )

and

     attendee   = "ATTENDEE" attparam ":" cal-address CRLF

    attparam   = *(

               ; the following are optional,
               ; but MUST NOT occur more than once

               (";" cutypeparam) / (";"memberparam) /
               (";" roleparam) / (";" partstatparam) /
               (";" rsvpparam) / (";" deltoparam) /
               (";" delfromparam) / (";" sentbyparam) /
               (";"cnparam) / (";" dirparam) /
               (";" languageparam) /

               ; the following is optional,
               ; and MAY occur more than once

               (";" xparam)

               )

This MUST get fixed when we update 2445!  %^|

I propose that we change attparam on ATTACH to be attachparam and we leave attparam on ATTENDEE as is.  If there is any sentiment to change that to attendeeparam then that works for me too.  

Thoughts??

Shannon:  Can you please chalk this one up on the To Do list for 2445 so we dont forget it??  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006C218185256B6D_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 27 15:06:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14683 for ; Wed, 27 Feb 2002 15:06:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RJv0g04430 for ietf-calendar-bks; Wed, 27 Feb 2002 11:57:00 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RJux304425 for ; Wed, 27 Feb 2002 11:57:00 -0800 (PST) To: ietf-calendar@imc.org Subject: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 27 Feb 2002 14:59:51 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/27/2002 02:57:03 PM, Serialize complete at 02/27/2002 02:57:03 PM Content-Type: multipart/alternative; boundary="=_alternative 006D79A185256B6D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D79A185256B6D_= Content-Type: text/plain; charset="US-ASCII" Here is my proposal to resolve how an Organizer is able to tell who is actually sending the COUNTER method. This text is a proposal that updates RFC 2445 itself. The updates RFC 2446 are after the proposal. ------------------------------------------------------------ 4.8.4.x Countering Attendee Property Name: ATTCOUNTER Purpose: The property defines an "Attendee" within a calendar component who is counter proposing the definition or content of the component. Value Type: CAL-ADDRESS Property Parameters: Non-standard, language, common name, and sent by property parameters can be specified on this property. Conformance: This property MUST be specified in an iCalendar object that specifies a counter proposal to a group scheduled calendar entity. This property MUST NOT be specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but are entities only on a single user's calendar. This property MUST NOT be specified on an iCalendar object that does not involve counter proposing a new definition or content for a group scheduled calendar entity. Description: The property is specified within the "VEVENT", "VTODO", "VJOURNAL calendar components to specify the sender of a counter proposal to a group scheduled calendar entity. The value of the property MUST match one of the ATTENDEE properties specified on the group scheduled entity that it is being counter proposed. The value of the property MAY NOT match one of the ATTENDEE properties specified on the counter proposed group scheduled calendar entity; the ATTENDEE could be counter proposing an ATTENDEE list that does not include themselves. The property has the property parameters CN, for specifying the common or display name associated with the countering user, SENT-BY, for specifying another calendar user that is acting on behalf of the countering ATTENDEE. The non-standard parameters may also be specified on this property. If the LANGUAGE property parameter is specified, the identified language applies to the CN parameter value. Format Definition: The property is defined by the following notation: attcounter = "ATTCOUNTER" attcounterparam ":" cal-address CRLF attcounterparam = *( ; The following are optional, ; but MUST NOT occur more than once ( ";" cnparam ) / ( ";" sentbyparam ) / ( ";" languageparam ) / ; The following are optional, ; and MAY occur more than once ( ";" xparam ) / ( ";" iana-param ) ) Example: The following is an example of this property: ATTCOUNTER;CN=John Smith:MAILTO:jsmith@host1.com The following is an example of this property used by another calendar user who is counter proposing on behalf of an ATTENDEE: ATTCOUNTER;SENT-BY="MAILTO:jane_doe@host.com": MAILTO:jsmith@host1.com ------------------------------------------------------------------------ The changes to RFC 2446 involve inserting a: ATTCOUNTER 0 into ALL restriction tables _except_ the ones in Sections 3.2.7 COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO). For those 2 cases it would be: ATTCOUNTER 0 or 1 for the obvious reasons. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D79A185256B6D_= Content-Type: text/html; charset="US-ASCII"
Here is my proposal to resolve how an Organizer is able to tell who is actually sending the COUNTER method.

This text is a proposal that updates RFC 2445 itself.  The updates RFC 2446 are after the proposal.

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

4.8.4.x Countering Attendee

  Property Name: ATTCOUNTER

  Purpose: The property defines an "Attendee" within a calendar
  component who is counter proposing the definition or content
   of the component.

  Value Type: CAL-ADDRESS

  Property Parameters: Non-standard, language, common name, and sent by
   property parameters can be specified on this property.

  Conformance: This property MUST be specified in an iCalendar object
  that specifies a counter proposal to a group scheduled calendar entity.
   This property MUST NOT be specified in an iCalendar object that
   specifies only a time zone definition or that defines calendar
   entities that are not group scheduled entities, but are entities
   only on a single user's calendar.  This property MUST NOT be specified
   on an iCalendar object that does not involve counter proposing a
   new definition or content for a group scheduled calendar entity.

  Description: The property is specified within the "VEVENT", "VTODO",
  "VJOURNAL calendar components to specify the sender of a counter
   proposal to a group scheduled calendar entity.  The value of the
   property MUST match one of the ATTENDEE properties specified on the
   group scheduled entity that it is being counter proposed.  The value
   of the property MAY NOT match one of the ATTENDEE properties specified
   on the counter proposed group scheduled calendar entity; the ATTENDEE
   could be counter proposing an ATTENDEE list that does not include
   themselves.

  The property has the property parameters CN, for specifying the
  common or display name associated with the countering user, SENT-BY,
   for specifying another calendar user that is acting on behalf of
   the countering ATTENDEE. The non-standard parameters may also be specified
   on this property. If the LANGUAGE property parameter is specified,
   the identified language applies to the CN parameter value.

  Format Definition: The property is defined by the following notation:

    attcounter = "ATTCOUNTER" attcounterparam ":" cal-address CRLF

    attcounterparam = *(

               ; The following are optional,
               ; but MUST NOT occur more than once

               ( ";" cnparam ) / ( ";" sentbyparam ) /
                ( ";" languageparam ) /

               ; The following are optional,
               ; and MAY occur more than once

               ( ";" xparam ) / ( ";" iana-param )

               )

  Example: The following is an example of this property:

    ATTCOUNTER;CN=John Smith:MAILTO:jsmith@host1.com

  The following is an example of this property used by another calendar
  user who is counter proposing on behalf of an ATTENDEE:

    ATTCOUNTER;SENT-BY="MAILTO:jane_doe@host.com":
     MAILTO:jsmith@host1.com

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

The changes to RFC 2446 involve inserting a:

     ATTCOUNTER     0

into ALL restriction tables _except_ the ones in Sections 3.2.7 COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO).  For those 2 cases it would be:

     ATTCOUNTER     0 or 1

for the obvious reasons.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006D79A185256B6D_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 27 15:07:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14721 for ; Wed, 27 Feb 2002 15:07:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RJxWF04504 for ietf-calendar-bks; Wed, 27 Feb 2002 11:59:32 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RJxV304500 for ; Wed, 27 Feb 2002 11:59:31 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA09067; Wed, 27 Feb 2002 14:59:26 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RJxPQ26512; Wed, 27 Feb 2002 14:59:25 -0500 (EST) Message-ID: <3C7D3A9D.831E9504@steltor.com> Date: Wed, 27 Feb 2002 14:59:25 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: Bruce_Kahn@notesdev.ibm.com CC: ietf-calendar@imc.org Subject: Re: RFC 2445 Big ABNF fauxpau References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > I wonder how the heck this got past EVERYONE but it seems we reused a name in 2 places in the ABNF and they are not interchangable. Anyone got any guesses what property parameter defintions Im > talking about?... > > We accidentally used attparam for both ATTACH and ATTENDEE to be the their respective property parameter definitions: > > attach = "ATTACH" attparam ":" uri CRLF > > attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64" > ";" "VALUE" "=" "BINARY" ":" binary > > attparam = *( > > ; the following is optional, > ; but MUST NOT occur more than once > > (";" fmttypeparam) / > > ; the following is optional, > ; and MAY occur more than once > > (";" xparam) > > ) > > and > > attendee = "ATTENDEE" attparam ":" cal-address CRLF > > attparam = *( > > ; the following are optional, > ; but MUST NOT occur more than once > > (";" cutypeparam) / (";"memberparam) / > (";" roleparam) / (";" partstatparam) / > (";" rsvpparam) / (";" deltoparam) / > (";" delfromparam) / (";" sentbyparam) / > (";"cnparam) / (";" dirparam) / > (";" languageparam) / > > ; the following is optional, > ; and MAY occur more than once > > (";" xparam) > > ) > > This MUST get fixed when we update 2445! %^| > > I propose that we change attparam on ATTACH to be attachparam and we leave attparam on ATTENDEE as is. If there is any sentiment to change that to attendeeparam then that works for me too. I agree. Furthermore, either attparam or attendeeparam on ATTENDEE are fine with me. > > Thoughts?? > > Shannon: Can you please chalk this one up on the To Do list for 2445 so we dont forget it?? > > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... George From owner-ietf-calendar@mail.imc.org Wed Feb 27 15:32:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16262 for ; Wed, 27 Feb 2002 15:32:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1RKO1x05214 for ietf-calendar-bks; Wed, 27 Feb 2002 12:24:01 -0800 (PST) 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 g1RKNx305208 for ; Wed, 27 Feb 2002 12:23:59 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2445 Big ABNF fauxpau MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 27 Feb 2002 15:32:36 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/27/2002 03:32:52 PM, Serialize complete at 02/27/2002 03:32:52 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I propose that we change attparam on ATTACH to be attachparam I agree. >leave attparam on ATTENDEE as is. If there is any sentiment to >change that to attendeeparam then that works for me too. Enh. It wouldn't hurt; and it could make things a bit clearer for someone who winds up reading both versions (say, if they're partway through implementing when the new RFC comes out). It's not something I'd fight for, though. :-) /=========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=========================================================| |NT's lack of reliability is only surpassed by its lack of| |scalability. --John Kirch | \=========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 27 15:39:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16647 for ; Wed, 27 Feb 2002 15:39:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1RKQ7C05259 for ietf-calendar-bks; Wed, 27 Feb 2002 12:26:07 -0800 (PST) Received: from twelve-monkeys.ximian.com (show-me-your-papers.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RKQ6305255 for ; Wed, 27 Feb 2002 12:26:06 -0800 (PST) Received: (from danw@localhost) by twelve-monkeys.ximian.com (8.11.6/8.9.3) id g1RKQ1621190; Wed, 27 Feb 2002 15:26:01 -0500 (EST) Subject: Re: RFC 2445 Big ABNF fauxpau From: Dan Winship To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2.99 Preview Release Date: 27 Feb 2002 15:26:01 -0500 Message-Id: <1014841561.21091.4.camel@twelve-monkeys.ximian.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 Wed, 2002-02-27 at 14:45, Bruce_Kahn@notesdev.ibm.com wrote: > I wonder how the heck this got past EVERYONE but it seems we reused a name > in 2 places in the ABNF and they are not interchangable. Someone on the IMAP list mentioned an ABNF validator a while back: http://www.washington.edu/imap/listarch/2001/msg00875.html (The link to the validator from that message doesn't work right now, but it might be a temporary problem, or you could try emailing him.) -- Dan From owner-ietf-calendar@mail.imc.org Wed Feb 27 15:46:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16891 for ; Wed, 27 Feb 2002 15:46:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1RKYpi05497 for ietf-calendar-bks; Wed, 27 Feb 2002 12:34:51 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RKYo305493 for ; Wed, 27 Feb 2002 12:34:50 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA28301 for ; Wed, 27 Feb 2002 12:34:51 -0800 (PST) Message-ID: <3C7D42E6.53C9747C@Royer.com> Date: Wed, 27 Feb 2002 13:34:46 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER References: Content-Type: multipart/mixed; boundary="------------2839E4201EC4B9C47F567757" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2839E4201EC4B9C47F567757 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > ------------------------------------------------------------------------ > > The changes to RFC 2446 involve inserting a: > > ATTCOUNTER 0 > > into ALL restriction tables _except_ the ones in Sections 3.2.7 > COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO). For those > 2 cases it would be: > > ATTCOUNTER 0 or 1 > > for the obvious reasons. Also in DECLINE-COUNTER? So the CUA knows how/who to send it back to. What if you AND your AA do a COUNTER. If I then do a DECLINE-COUNTER, I would return two objects that could look identical. If we add the ATTCOUNTER to DECLINE-COUNTER one object would have you as the ATTCOUNTER, the other would have you as the ATTCOUNTER plus have SENT-BY set to your AA. If I then DECLINET-COUNTER, then you get two unique DECLINE-COUNTER objects, one for each received and processed. --------------2839E4201EC4B9C47F567757 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------2839E4201EC4B9C47F567757-- From owner-ietf-calendar@mail.imc.org Wed Feb 27 15:47:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16944 for ; Wed, 27 Feb 2002 15:47:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RKWUC05435 for ietf-calendar-bks; Wed, 27 Feb 2002 12:32:30 -0800 (PST) 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 g1RKWT305422 for ; Wed, 27 Feb 2002 12:32:29 -0800 (PST) To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 27 Feb 2002 15:41:07 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/27/2002 03:41:22 PM, Serialize complete at 02/27/2002 03:41:22 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Conformance: This property MUST be specified in an iCalendar object > that specifies a counter proposal to a group scheduled calendar entity. Looks good. However, that "MUST be specified" clause is a bit problematic, since then someone who implements to the updated RFC won't accept messages from existing implementations. How about this: An iCalendar object which does not have a METHOD:COUNTER property MUST NOT include an ATTCOUNTER property. An implementation creating an iCalendar object which has a METHOD:COUNTER property MUST include an ATTCOUNTER property. However, an implementation which receives an iCalendar object with a METHOD:COUNTER property and no ATTCOUNTER property SHOULD accept it, for compatibility with an earlier version of this specification. /=========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=========================================================| |NT's lack of reliability is only surpassed by its lack of| |scalability. --John Kirch | \=========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 27 16:19:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19036 for ; Wed, 27 Feb 2002 16:19:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RL6Ka06260 for ietf-calendar-bks; Wed, 27 Feb 2002 13:06:20 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RL6J306252 for ; Wed, 27 Feb 2002 13:06:19 -0800 (PST) To: Doug Royer Cc: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 27 Feb 2002 16:09:18 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/27/2002 04:06:23 PM, Serialize complete at 02/27/2002 04:06:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0073D55585256B6D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073D55585256B6D_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 02/27/2002 03:34:46 PM: > Also in DECLINE-COUNTER? Not necessary. A DECLINECOUNTER (no hyphen) is _only_ sent from the Organizer to the countering user to tell them "No thanks". If you check the restriction tables in iTIP for DECLINECOUNTER you find that it has "ATTENDEE 0" since the only intent is to tell the countering user the proposal was rejected. No additional info is necessary for that method. > So the CUA knows how/who to > send it back to. What if you AND your AA do a COUNTER. > If I then do a DECLINE-COUNTER, I would return two objects > that could look identical. The DECLINECOUNTER should go to the users in the ATTCOUNTER value. It should not go to the SENT-BY user as well. After all, all the workflow went thru the ATTENDEE and not thru the SENT-BY user(s). All future workflow (ie: other reschedules, updates, etc ) will go thru the ATTENDEE and none of their SENT-BY(s) so to KISS Id opt for NOT adding the SENT-BY into the decline process. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0073D55585256B6D_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 02/27/2002 03:34:46 PM:
> Also in DECLINE-COUNTER?

Not necessary.  A DECLINECOUNTER (no hyphen) is _only_ sent from the Organizer to the countering user to tell them "No thanks".  If you check the restriction tables in iTIP for DECLINECOUNTER you find that it has "ATTENDEE 0" since the only intent is to tell the countering user the proposal was rejected.  No additional info is necessary for that method.

>                            So the CUA knows how/who to
> send it back to. What if you AND your AA do a COUNTER.
> If I then do a DECLINE-COUNTER, I would return two objects
> that could look identical.
The DECLINECOUNTER should go to the users in the ATTCOUNTER value.  It should not go to the SENT-BY user as well.  After all, all the workflow went thru the ATTENDEE and not thru the SENT-BY user(s).  All future workflow (ie: other reschedules, updates, etc ) will go thru the ATTENDEE and none of their SENT-BY(s) so to KISS Id opt for NOT adding the SENT-BY into the decline process.

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

--=_alternative 0073D55585256B6D_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 27 16:34:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19887 for ; Wed, 27 Feb 2002 16:34:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RLNM206749 for ietf-calendar-bks; Wed, 27 Feb 2002 13:23:22 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RLNMi06745 for ; Wed, 27 Feb 2002 13:23:22 -0800 (PST) To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 27 Feb 2002 16:26:20 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/27/2002 04:23:25 PM, Serialize complete at 02/27/2002 04:23:25 PM Content-Type: multipart/alternative; boundary="=_alternative 007564B885256B6D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007564B885256B6D_= Content-Type: text/plain; charset="US-ASCII" John responed on 02/27/2002 03:41:07 PM: > An iCalendar object which does not have a METHOD:COUNTER property MUST NOT > include an ATTCOUNTER property. An implementation creating an iCalendar > object which has a METHOD:COUNTER property MUST include an ATTCOUNTER > property. However, an implementation which receives an iCalendar object > with a METHOD:COUNTER property and no ATTCOUNTER property SHOULD accept > it, for compatibility with an earlier version of this specification. I had neglected to put in the backwards compatable text but the intent was there. Thanks for reminding me. (We could rev maxver to be 2.1 for this change so that a VERSION:2.0;2.0 would clearly be ruled out as a mandated case but thats more prose than I wanted to do but its an alternative none the less.) I would wordsmith "iCalendar object" into "iCalendar group scheduled entry" because we use "object" to mean the entire VCALENDAR contained critter and it is legal to have multiple entities in 1 VCALENDAR that have different METHODs. We agree on the intent; just need to make sure we dont use too broad a word brush... Any other thoughts? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007564B885256B6D_= Content-Type: text/html; charset="US-ASCII"
John responed on 02/27/2002 03:41:07 PM:
> An iCalendar object which does not have a METHOD:COUNTER property MUST NOT
> include an ATTCOUNTER property.  An implementation creating an iCalendar
> object which has a METHOD:COUNTER property MUST include an ATTCOUNTER
> property.  However, an implementation which receives an iCalendar object
> with a METHOD:COUNTER property and no ATTCOUNTER property SHOULD accept
> it, for compatibility with an earlier version of this specification.
I had neglected to put in the backwards compatable text but the intent was there.  Thanks for reminding me.  (We could rev maxver to be 2.1 for this change so that a VERSION:2.0;2.0 would clearly be ruled out as a mandated case but thats more prose than I wanted to do but its an alternative none the less.)

I would wordsmith "iCalendar object" into "iCalendar group scheduled entry" because we use "object" to mean the entire VCALENDAR contained critter and it is legal to have multiple entities in 1 VCALENDAR that have different METHODs.  We agree on the intent; just need to make sure we dont use too broad a word brush...

Any other thoughts?

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

--=_alternative 007564B885256B6D_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 27 16:45:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20599 for ; Wed, 27 Feb 2002 16:45:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RLXib06968 for ietf-calendar-bks; Wed, 27 Feb 2002 13:33:44 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RLXhi06963 for ; Wed, 27 Feb 2002 13:33:43 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA12209 for ; Wed, 27 Feb 2002 16:33:40 -0500 Received: from c1271 (c-1271.in.steltor.com [101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id g1RLXeQ09784 for ; Wed, 27 Feb 2002 16:33:40 -0500 (EST) Message-ID: <06f901c1bfd6$98650b70$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: Subject: Re: RFC 2445 Proposal: ATTCOUNTER Date: Wed, 27 Feb 2002 16:34:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Maybe I'm missing one of those "obvious reasons" here, but based on the proposed Conformance text for RFC 2445: > Conformance: This property MUST be specified in an iCalendar object > that specifies a counter proposal to a group scheduled calendar entity. > This property MUST NOT be specified in an iCalendar object that > specifies only a time zone definition or that defines calendar > entities that are not group scheduled entities, but are entities > only on a single user's calendar. This property MUST NOT be specified > on an iCalendar object that does not involve counter proposing a > new definition or content for a group scheduled calendar entity. In what case(s) could ATTCOUNTER have 0 rather than 1 occurrence in the two COUNTER sections mentioned for RFC 2446? Should it simply be 1? : > The changes to RFC 2446 involve inserting a: > > ATTCOUNTER 0 > > into ALL restriction tables _except_ the ones in Sections 3.2.7 COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO). For those 2 cases it would be: > > ATTCOUNTER 0 or 1 > > for the obvious reasons. Graham From owner-ietf-calendar@mail.imc.org Wed Feb 27 17:27:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22344 for ; Wed, 27 Feb 2002 17:27:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1RMCC507890 for ietf-calendar-bks; Wed, 27 Feb 2002 14:12:12 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RMC9i07882 for ; Wed, 27 Feb 2002 14:12:09 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA28533 for ; Wed, 27 Feb 2002 14:12:11 -0800 (PST) Message-ID: <3C7D59B5.65700020@Royer.com> Date: Wed, 27 Feb 2002 15:12:05 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER References: Content-Type: multipart/mixed; boundary="------------E21F6ED245AE102626803199" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E21F6ED245AE102626803199 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > The DECLINECOUNTER should go to the users in the ATTCOUNTER value. It > should not go to the SENT-BY user as well. After all, all the > workflow went thru the ATTENDEE and not thru the SENT-BY user(s). I did not say it should. I said what if YOU AND your AA BOTH send a COUNTER; Now BOTH DECLINE-COUNERs go the the same ATTCOUNTER value AND they both look the same. So I concluded that the ATTCOUNTER would have to also be in DECLINE-COUNTER as well. And then without something to differentiate them, how does your CUA know why it got two identical DECLINE-COUNTER objects? Unless one is tagged with the SENT-BY that was in the original COUNTER from your AA. > All > future workflow (ie: other reschedules, updates, etc ) will go thru > the ATTENDEE and none of their SENT-BY(s) so to KISS Id opt for NOT > adding the SENT-BY into the decline process. I was not proposing that the AA be added to DECLINE-COUNER. I was proposing that the COUNTER ATTCOUNER value be copied entirely to the DECLINE-COUNTER so the origin of the original COUNTER can be identified. If the COUNTERs orginated from the same CAP address (one from the OWNER and another from the AA), then won't the the DECLINE-COUNTER have the same identification problem as the orginal COUNTER (without adding the orginal ATTCOUNTER property)? --------------E21F6ED245AE102626803199 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------E21F6ED245AE102626803199-- From owner-ietf-calendar@mail.imc.org Wed Feb 27 17:41:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22903 for ; Wed, 27 Feb 2002 17:41:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1RMWYg08418 for ietf-calendar-bks; Wed, 27 Feb 2002 14:32:34 -0800 (PST) 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 g1RMWXi08414 for ; Wed, 27 Feb 2002 14:32:33 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 27 Feb 2002 17:41:21 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 02/27/2002 05:41:27 PM, Serialize complete at 02/27/2002 05:41:27 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I would wordsmith "iCalendar object" into "iCalendar group scheduled >entry" because we use "object" to mean the entire VCALENDAR contained >critter and it is legal to have multiple entities in 1 VCALENDAR that >have different METHODs. Mmm...but then the MUST/MUST NOT clauses apply to each (e.g.) VEVENT separately. A component which has a METHOD:COUNTER property MUST have an ATTCOUNTER; a component which does not MUST NOT. That way you don't have to get into, e.g., differences between events, timezones, etc. Perhaps "component" rather than "object"? /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |Rope is rope, and string is string, and never the twine shall| |meet. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 27 18:22:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23978 for ; Wed, 27 Feb 2002 18:22:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1RN81909292 for ietf-calendar-bks; Wed, 27 Feb 2002 15:08:01 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RN80i09288 for ; Wed, 27 Feb 2002 15:08:00 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA28608 for ; Wed, 27 Feb 2002 15:08:02 -0800 (PST) Message-ID: <3C7D66CC.199B1EBF@Royer.com> Date: Wed, 27 Feb 2002 16:07:56 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC 2445 Proposal: ATTCOUNTER References: Content-Type: multipart/mixed; boundary="------------7BE487F94A1243AE23DC9805" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7BE487F94A1243AE23DC9805 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > 4.8.4.x Countering Attendee > > Property Name: ATTCOUNTER > Description: The property is specified within the "VEVENT", "VTODO", > "VJOURNAL calendar components to specify the sender of a counter > proposal to a group scheduled calendar entity. The value of the > property MUST match one of the ATTENDEE properties specified on the (1) Per iTIP, COUNTER is not allowed in a VJOURNAL. (So it could never have a ATTCOUNTER?) (2) Rather than saying ("VEVENT", "VTODO", "VJOURNAL"), how about saying: The property is specified within iTIP components that contain the COUNTER property to specify the sender ... (3) Lets let iTIP and any of its future rev's dictate where ATTCOUNTER (COUNTER) goes in iTIP objects. In CAP lets just add it to 'whatever iTIP allows for COUNTER properties' ? (4) Where you also proposing we allow COUNTER in VJOURNAL? --------------7BE487F94A1243AE23DC9805 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------7BE487F94A1243AE23DC9805-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 09:57:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26484 for ; Thu, 28 Feb 2002 09:57:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SEe9X02257 for ietf-calendar-bks; Thu, 28 Feb 2002 06:40:09 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SEe8i02253 for ; Thu, 28 Feb 2002 06:40:08 -0800 (PST) To: "Graham Gilmore" Cc: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 28 Feb 2002 09:38:35 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/28/2002 09:47:12 AM, Serialize complete at 02/28/2002 09:47:12 AM Content-Type: multipart/alternative; boundary="=_alternative 005075A185256B6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005075A185256B6E_= Content-Type: text/plain; charset="US-ASCII" Graham asked on 02/27/2002 04:34:54 PM: > In what case(s) could ATTCOUNTER have 0 rather than 1 occurrence in the > two COUNTER sections mentioned for RFC 2446? Should it simply be 1? : Just as John noted in his changetext to the proposal, there are going to be older, existing clients that do NOT know about this new property so in order for them to work with 'newer' clients, the newer clients have to take this into account. We could make that: ATTCOUNTER 0 or 1 ; Older clients are unable to put this ; property on so it is possible to receive ; a COUNTER from them without this property ; ALL newer clients MUST include this property ; when COUNTERing. but that just restates the text I forgot to put in originally that John noted. (At least I remembered it for the restriction tables...) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005075A185256B6E_= Content-Type: text/html; charset="US-ASCII"
Graham asked on 02/27/2002 04:34:54 PM:
>     In what case(s) could ATTCOUNTER have 0 rather than 1 occurrence in the
> two COUNTER sections mentioned for RFC 2446?  Should it simply be 1?  :
Just as John noted in his changetext to the proposal, there are going to be older, existing clients that do NOT know about this new property so in order for them to work with 'newer' clients, the newer clients have to take this into account.  

We could make that:

      ATTCOUNTER     0 or 1        ; Older clients are unable to put this
                              ; property on so it is possible to receive
                              ; a COUNTER from them without this property
                              ; ALL newer clients MUST include this property
                              ; when COUNTERing.
but that just restates the text I forgot to put in originally that John noted.  (At least I remembered it for the restriction tables...)

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

--=_alternative 005075A185256B6E_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 10:11:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27296 for ; Thu, 28 Feb 2002 10:11:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SExFe03068 for ietf-calendar-bks; Thu, 28 Feb 2002 06:59:15 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SExEi03063 for ; Thu, 28 Feb 2002 06:59:14 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 28 Feb 2002 09:57:41 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/28/2002 10:06:18 AM, Serialize complete at 02/28/2002 10:06:18 AM Content-Type: multipart/alternative; boundary="=_alternative 0052354C85256B6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0052354C85256B6E_= Content-Type: text/plain; charset="US-ASCII" Doug clarified on 02/27/2002 05:12:05 PM: > I said what if YOU AND your AA BOTH > send a COUNTER; Now BOTH DECLINE-COUNERs go the the same ATTCOUNTER > value AND they both look the same. Not quite; unless sent at the exact same time they would at least have different DTSTAMPs and likely have different COMMENTs too. If you were countering for different instances too then the RECURRENCE-ID would also differentiate them. Had I accepted _any_ COUNTER then you'd be seeing a new REQUEST come along wouldnt you?? The DECLINECOUNTER is mainly used so that an ATTENDEE who counter proposes knows that the Organizer has received and rejected the COUNTER; its not the means to doing renegotiation of the new date/time/info. Besides its no different than if I receive 2 COUNTERs from you alone and I DECLINECOUNTER them both. Or I could have recieved duplicate COUNTERs from you because some spooler in the middle hiccupd and sent 2 of them. Or on the return path a mailer hiccupd and you got 2 copys of the 1 DECINECOUNTER I sent. Or you and your AA COUNTERed with different dates/times and I reject them both. Or ... The point is that it doesnt matter if you get mulitple DECINECOUNTERs I am still declining the counter proposal. There is no great magic to a DECLINECOUNTER that requires tons of "what ifs...". They are all simply treated as "The Organzier had rejected your (or your proxys) counter proposal". > So I concluded that the ATTCOUNTER > would have to also be in DECLINE-COUNTER as well. And then > without something to differentiate them, how does your CUA > know why it got two identical DECLINE-COUNTER objects? How does it know your AA sent a COUNTER and that you sent a COUNTER? How does it distinguish between the 2 COUNTERs you sent (you changed your mind after the 1st one)? It doesnt really matter since the COUNTER(s) was not accepted. > I was proposing that the COUNTER ATTCOUNER value be copied > entirely to the DECLINE-COUNTER so the origin of the original > COUNTER can be identified. That still wont match it up to any particular COUNTER unless you only allow 1 COUNTER per cal-address. We've never had any such restriction and I dont see a need to add one. Im just trying to fix an oversight in our original spec, not add new functionality. If you want to add new functionality, draft up some text and propose it as an alternative to mine. > If the COUNTERs orginated from the same CAP address (one from > the OWNER and another from the AA), ... Same response as above... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0052354C85256B6E_= Content-Type: text/html; charset="US-ASCII"
Doug clarified on 02/27/2002 05:12:05 PM:
>                            I said what if YOU AND your AA BOTH
> send a COUNTER; Now BOTH DECLINE-COUNERs go the the same ATTCOUNTER
> value AND they both look the same.

Not quite; unless sent at the exact same time they would at least have different DTSTAMPs and likely have different COMMENTs too.  If you were countering for different instances too then the RECURRENCE-ID would also differentiate them.  Had I accepted _any_ COUNTER then you'd be seeing a new REQUEST come along wouldnt you??  The DECLINECOUNTER is mainly used so that an ATTENDEE who counter proposes knows that the Organizer has received and rejected the COUNTER; its not the means to doing renegotiation of the new date/time/info.

Besides its no different than if I receive 2 COUNTERs from you alone and I DECLINECOUNTER them both.  Or I could have recieved duplicate COUNTERs from you because some spooler in the middle hiccupd and sent 2 of them. Or on the return path a mailer hiccupd and you got 2 copys of the 1 DECINECOUNTER I sent.  Or you and your AA COUNTERed with different dates/times and I reject them both.  Or ...  

The point is that it doesnt matter if you get mulitple DECINECOUNTERs I am still declining the counter proposal.  There is no great magic to a DECLINECOUNTER that requires tons of "what ifs...".  They are all simply treated as "The Organzier had rejected your (or your proxys) counter proposal".  

>                        So I concluded that the ATTCOUNTER
> would have to also be in DECLINE-COUNTER as well. And then
> without something to differentiate them, how does your CUA
> know why it got two identical DECLINE-COUNTER objects?
How does it know your AA sent a COUNTER and that you sent a COUNTER?  How does it distinguish between the 2 COUNTERs you sent (you changed your mind after the 1st one)?  It doesnt really matter since the COUNTER(s) was not accepted.

> I was proposing that the COUNTER ATTCOUNER value be copied
> entirely to the DECLINE-COUNTER so the origin of the original
> COUNTER can be identified.
That still wont match it up to any particular COUNTER unless you only allow 1 COUNTER per cal-address.  We've never had any such restriction and I dont see a need to add one.  

Im just trying to fix an oversight in our original spec, not add new functionality.  If you want to add new functionality, draft up some text and propose it as an alternative to mine.

> If the COUNTERs orginated from the same CAP address (one from
> the OWNER and another from the AA), ...

Same response as above...

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

--=_alternative 0052354C85256B6E_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 10:35:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28675 for ; Thu, 28 Feb 2002 10:35:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SFGsO03789 for ietf-calendar-bks; Thu, 28 Feb 2002 07:16:54 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SFGri03785 for ; Thu, 28 Feb 2002 07:16:53 -0800 (PST) To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 28 Feb 2002 10:15:19 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/28/2002 10:23:57 AM, Serialize complete at 02/28/2002 10:23:57 AM Content-Type: multipart/alternative; boundary="=_alternative 0053D2D885256B6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053D2D885256B6E_= Content-Type: text/plain; charset="US-ASCII" John wrote on 02/27/2002 05:41:21 PM: > Mmm...but then the MUST/MUST NOT clauses apply to each (e.g.) VEVENT > separately. A component which has a METHOD:COUNTER property MUST have an > ATTCOUNTER; a component which does not MUST NOT. The phrase "group scheduled calendar entity" was directly borrowed from RFC 2445 (Sections 4.8.4.1 Attendee and 4.8.4.3 Organizer) because thats how we previously drew a distinction on where the property should be allowed. ATTCOUNTER has the same needs so I borrowed much of the phrasing to be consistant. > Perhaps "component" rather than "object"? Actually, because the METHOD is NOT on the VEVENT or VTODO but rather on the containing VCALENDAR I think that your suggestion would move the ATTCOUNTER out of the VEVENT/VTODO into the VCALENDAR and thats not where it should go. I think it belongs inside them at the same level as ORGANIZER or ATTENDEE. After all its possible to 'optimize' the iCalendar stream and have > 1 COUNTER from > 1 ATTENDEE to > 1 VEVENT/VTODO inside 1 VCALENDAR and moving it out would negate this ability (and just require that > 1 VCALENDAR be sent instead). Still I think we have basic agreement on the meat of the text. Ill get some wordsmithing done on the "component" vs "group scheduled calendar entity" and repost the proposal unless there are other concerns. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0053D2D885256B6E_= Content-Type: text/html; charset="US-ASCII"
John wrote on 02/27/2002 05:41:21 PM:
> Mmm...but then the MUST/MUST NOT clauses apply to each (e.g.) VEVENT
> separately.  A component which has a METHOD:COUNTER property MUST have an
> ATTCOUNTER; a component which does not MUST NOT.
The phrase "group scheduled calendar entity" was directly borrowed from RFC 2445 (Sections 4.8.4.1 Attendee and 4.8.4.3 Organizer) because thats how we previously drew a distinction on where the property should be allowed.  ATTCOUNTER has the same needs so I borrowed much of the phrasing to be consistant.

> Perhaps "component" rather than "object"?
Actually, because the METHOD is NOT on the VEVENT or VTODO but rather on the containing VCALENDAR I think that your suggestion would move the ATTCOUNTER out of the VEVENT/VTODO into the VCALENDAR and thats not where it should go.  I think it belongs inside them at the same level as ORGANIZER or ATTENDEE.  After all its possible to 'optimize' the iCalendar stream and have > 1 COUNTER from > 1 ATTENDEE to > 1 VEVENT/VTODO inside 1 VCALENDAR and moving it out would negate this ability (and just require that > 1 VCALENDAR be sent instead).

Still I think we have basic agreement on the meat of the text.  Ill get some wordsmithing done on the "component" vs "group scheduled calendar entity" and repost the proposal unless there are other concerns.

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


--=_alternative 0053D2D885256B6E_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 11:08:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00550 for ; Thu, 28 Feb 2002 11:08:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SFoZN07227 for ietf-calendar-bks; Thu, 28 Feb 2002 07:50:35 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SFoYi07223 for ; Thu, 28 Feb 2002 07:50:34 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 28 Feb 2002 10:49:00 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/28/2002 10:57:38 AM, Serialize complete at 02/28/2002 10:57:38 AM Content-Type: multipart/alternative; boundary="=_alternative 0056E81585256B6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056E81585256B6E_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 02/27/2002 06:07:56 PM: > (1) Per iTIP, COUNTER is not allowed in a VJOURNAL. > (So it could never have a ATTCOUNTER?) Correct. Its not scheduled between CUs so COUNTERing is not logical and as such ATTCOUNTER is not necessary. > (2) Rather than saying ("VEVENT", "VTODO", "VJOURNAL"), how > about saying: > > The property is specified within iTIP components that contain > the COUNTER property to specify the sender ... I borrowed whole blocks of text from the existing RFC 2445 descriptions of ATTENDEE (and then added the restriction about the METHOD). I would prefer that the text be consistant w/the published RFCs than have a new 'tone' or wordsmithing. Besides as already noted in response to John, the ATTCOUNTER belongs at the same level as ATTENDEE/ORGANIZER and not at the level where METHOD is (for opitmization reasons mostly). We could put it at the METHOD level if we wanted to though... Hmm, in rereading the iTIP restriction tables I see that for COUNTER we mandated that only 1 VEVENT/VTODO per VCALENDAR for those METHODs so we could have it at the same level as METHOD. Id just have to add some prose to the proposal to clearly indicate that the counter is NOT for any components in the stream apart from the VEVENT/VTODO (or as the verbage goes "a group scheduled calendar entry"). Otherwise some folks may incorrectly assume that one could also COUNTER the VTIMEZONE definitions or some other TBD components instead of just the entry itself. > (3) Lets let iTIP and any of its future rev's dictate where > ATTCOUNTER (COUNTER) goes in iTIP objects. In CAP lets just add > it to 'whatever iTIP allows for COUNTER properties' ? Since I used much of the existing text from Section 4.8.4.1 Attendee Im guessing you want to rewrite the rules for ATTENDEE too?? What Ive proposed fits the requirements we discussed back in 2000 and does not make any radical new requirements that we do not already have in RFC 2445 so I think the basic text is sound. As for iTIP, are you saying that the changes proposed are wrong/incorrect? As for CAP, thats in progress and can include what it wants/needs. > (4) Where you also proposing we allow COUNTER in > VJOURNAL? Not sure where you got that from. My original text regarding iTIP was: The changes to RFC 2446 involve inserting a: ATTCOUNTER 0 into ALL restriction tables _except_ the ones in Sections 3.2.7 COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO). For those 2 cases it would be: ATTCOUNTER 0 or 1 so Im not sure where you got that I wanted to create a COUNTER for VJOURNALs... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0056E81585256B6E_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 02/27/2002 06:07:56 PM:
> (1) Per iTIP, COUNTER is not allowed in a VJOURNAL.
>     (So it could never have a ATTCOUNTER?)
Correct.  Its not scheduled between CUs so COUNTERing is not logical and as such ATTCOUNTER is not necessary.

> (2) Rather than saying ("VEVENT", "VTODO", "VJOURNAL"), how
> about saying:
>
>    The property is specified within iTIP components that contain
>    the COUNTER property to specify the sender ...
I borrowed whole blocks of text from the existing RFC 2445 descriptions of ATTENDEE (and then added the restriction about the METHOD).  I would prefer that the text be consistant w/the published RFCs than have a new 'tone' or wordsmithing.

Besides as already noted in response to John, the ATTCOUNTER belongs at the same level as ATTENDEE/ORGANIZER and not at the level where METHOD is (for opitmization reasons mostly).  We could put it at the METHOD level if we wanted to though...

Hmm, in rereading the iTIP restriction tables I see that for COUNTER we mandated that only 1 VEVENT/VTODO per VCALENDAR for those METHODs so we could have it at the same level as METHOD.  Id just have to add some prose to the proposal to clearly indicate that the counter is NOT for any components in the stream apart from the VEVENT/VTODO (or as the verbage goes "a group scheduled calendar entry").  Otherwise some folks may incorrectly assume that one could also COUNTER the VTIMEZONE definitions or some other TBD components instead of just the entry itself.

> (3) Lets let iTIP and any of its future rev's dictate where
>     ATTCOUNTER (COUNTER) goes in iTIP objects. In CAP lets just add
>     it to 'whatever iTIP allows for COUNTER properties' ?
Since I used much of the existing text from Section 4.8.4.1 Attendee Im guessing you want to rewrite the rules for ATTENDEE too??  What Ive proposed fits the requirements we discussed back in 2000 and does not make any radical new requirements that we do not already have in RFC 2445 so I think the basic text is sound.  As for iTIP, are you saying that the changes proposed are wrong/incorrect?  As for CAP, thats in progress and can include what it wants/needs.

> (4) Where you also proposing we allow COUNTER in
> VJOURNAL?

Not sure where you got that from.  My original text regarding iTIP was:

The changes to RFC 2446 involve inserting a:

    ATTCOUNTER     0

into ALL restriction tables _except_ the ones in Sections 3.2.7 COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO).  For those 2 cases it would be:

    ATTCOUNTER     0 or 1

so Im not sure where you got that I wanted to create a COUNTER for VJOURNALs...

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

--=_alternative 0056E81585256B6E_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 11:14:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00953 for ; Thu, 28 Feb 2002 11:14:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1SFu3207346 for ietf-calendar-bks; Thu, 28 Feb 2002 07:56:03 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SFu2i07342 for ; Thu, 28 Feb 2002 07:56:02 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 28 Feb 2002 10:54:30 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/28/2002 11:03:06 AM, Serialize complete at 02/28/2002 11:03:06 AM Content-Type: multipart/alternative; boundary="=_alternative 005768F485256B6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005768F485256B6E_= Content-Type: text/plain; charset="US-ASCII" I originally wrote: > Description: The property is specified within the "VEVENT", "VTODO", > "VJOURNAL calendar components to specify the sender of a counter Strike any and all references to "VJOURNAL" in the proposal. I missed that deletion. Ugh, thats what I get for deleting my own text and restarting w/some copied text. Sorry. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005768F485256B6E_= Content-Type: text/html; charset="US-ASCII"
I originally wrote:
>   Description: The property is specified within the "VEVENT", "VTODO",
>   "VJOURNAL calendar components to specify the sender of a counter

Strike any and all references to "VJOURNAL" in the proposal.  I missed that deletion.  Ugh, thats what I get for deleting my own text and restarting w/some copied text.  Sorry.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 005768F485256B6E_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 13:01:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09049 for ; Thu, 28 Feb 2002 13:01:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SHmXA12573 for ietf-calendar-bks; Thu, 28 Feb 2002 09:48:33 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SHmWi12569 for ; Thu, 28 Feb 2002 09:48:32 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA29761 for ; Thu, 28 Feb 2002 09:48:32 -0800 (PST) Message-ID: <3C7E6D6A.D492A8E4@Royer.com> Date: Thu, 28 Feb 2002 10:48:26 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER References: Content-Type: multipart/mixed; boundary="------------7C99238204D5E652F011F72B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7C99238204D5E652F011F72B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > I said what if YOU AND your AA BOTH > > send a COUNTER; Now BOTH DECLINE-COUNERs go the the same ATTCOUNTER > > value AND they both look the same. > Besides its no different than if I receive 2 COUNTERs from you alone > and I DECLINECOUNTER them both. Or I could have recieved duplicate > COUNTERs from you because some spooler in the middle hiccupd and sent > 2 of them. Or on the return path a mailer hiccupd and you got 2 copys > of the 1 DECINECOUNTER I sent. Or you and your AA COUNTERed with > different dates/times and I reject them both. Or ... As I am working mostly in creating a CS and not a CUA, my *thoughts* were that a CUA would have to remember that it sent a COUNTER so that it could inform the CU when the DECLINECOUNTER or new object arrived. Some kind of 'this is pending' stack in the CUA and out of scope for the CAP protocol. If CU-1 processes both, then will not CU-2 just keep wondering what happened? The next time CUA-1 did a sync, it would process both. Then when CUA-2 did a sync, it would appear that nothing at all changed. I would think that CU-2 might think that the ORGANIZER never responded. > > So I concluded that the ATTCOUNTER > > would have to also be in DECLINE-COUNTER as well. And then > > without something to differentiate them, how does your CUA > > know why it got two identical DECLINE-COUNTER objects? > > How does it know your AA sent a COUNTER and that you sent a COUNTER? By looking at the SENT-BY (or its absence) in ATTCOUNTER. > How does it distinguish between the 2 COUNTERs you sent (you changed > your mind after the 1st one)? As you pointed out in another email: COMMENT. > It doesnt really matter since the COUNTER(s) was not accepted. The 1st CU will know that, the 2nd+ AA-CU will never know that. To the 2nd+ AA-CU, it will appear that the ORGANIZER never responded. > > I was proposing that the COUNTER ATTCOUNER value be copied > > entirely to the DECLINE-COUNTER so the origin of the original > > COUNTER can be identified. > > That still wont match it up to any particular COUNTER unless you only > allow 1 COUNTER per cal-address. We've never had any such restriction > and I dont see a need to add one. Not true: ATTCOUNTER:cu-1 vs. ATTCOUNTER:SENT-BY-cu-1-aa:cu-1 > Im just trying to fix an oversight in our original spec, not add new > functionality. If you want to add new functionality, draft up some > text and propose it as an alternative to mine. I think I am pointing out that it just moves the problem from the COUNTER to the DECLINECOUNTER. It is not exactly the same problem. Without replicating the ATTCOUNTER into the DECLINECOUNTER, it guarantees the ATTENDEE's AA, or the ATTENDEE will never know that it was rejected. And I might send a proposal soon, unless someone has pointed out that I missed something. --------------7C99238204D5E652F011F72B 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------7C99238204D5E652F011F72B-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 13:50:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12161 for ; Thu, 28 Feb 2002 13:50:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SITx013898 for ietf-calendar-bks; Thu, 28 Feb 2002 10:29:59 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SITti13894 for ; Thu, 28 Feb 2002 10:29:59 -0800 (PST) To: Doug Royer Cc: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 28 Feb 2002 13:29:55 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/28/2002 01:30:02 PM, Serialize complete at 02/28/2002 01:30:02 PM Content-Type: multipart/alternative; boundary="=_alternative 00657EE785256B6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00657EE785256B6E_= Content-Type: text/plain; charset="US-ASCII" Doug answered on 02/28/2002 12:48:26 PM: > As I am working mostly in creating a CS and not a CUA, my *thoughts* > were that a CUA would have to remember that it sent a COUNTER so > that it could inform the CU when the DECLINECOUNTER or new object > arrived. Some kind of 'this is pending' stack in the CUA and > out of scope for the CAP protocol. Also you have the dilemma if _you_ send 2+ COUNTERs. Just how do you determine which COUNTER matches the DECLINECOUNTER I send back? I may not have gotten one of them or I may have accepted/rejected it but the response got lost in transit... In any case, there is insufficient info in the DECLINECOUNTER to match it to > 1 COUNTER as we've defined it so far. > > How does it distinguish between the 2 COUNTERs you sent (you changed > > your mind after the 1st one)? > > As you pointed out in another email: COMMENT. Dont rely on it though! Its a "0 or 1". Even then I could send back "Sorry, cant do it then." for all declines and its not that useful... You still dont know exactly WHICH COUNTER I am declining. > > It doesnt really matter since the COUNTER(s) was not accepted. > > The 1st CU will know that, the 2nd+ AA-CU will never know that. > To the 2nd+ AA-CU, it will appear that the ORGANIZER never > responded. This is all future navel gazing and there are current limitations that make doing lots of these desirable but yet unspec'd features quite hard. Im simply proposing a fix for a problem we all agreed on back in Aug-2000. > > That still wont match it up to any particular COUNTER unless you only > > allow 1 COUNTER per cal-address. We've never had any such restriction > > and I dont see a need to add one. > > Not true: > > ATTCOUNTER:cu-1 > > vs. > > ATTCOUNTER:SENT-BY-cu-1-aa:cu-1 For the case of you (and each AA) can only send 1 COUNTER then this would be valid. However, is that a reasonable/valid restriction? I think not. For example, I COUNTER with a new date/time and later on I find I need to suggest another new time so I send a 2nd COUNTER w/a working time. Now, how do you determine which COUTNER my DECLINECOUNTER with "ATTCOUNTER:cu-1" matches? > I think I am pointing out that it just moves the problem from the > COUNTER to the DECLINECOUNTER. It is not exactly the same problem. No its not. The only problem we had was that an Organizer has no way to tell what ATTENDEE is COUNTERing. You're now saying that we need some way for the COUTNERing ATTENDEE to thread up DECLINECOUNTER(s). Since we have REQUEST (if they accept it) or DECLINECOUNTER (if they reject it) then is there a pressing need to identify which COUNTER?? Since even if we adopt the ATTCOUNTER on DECLINECOUNTER, it still wont resolve the need I say leave it off. > Without replicating the ATTCOUNTER into the DECLINECOUNTER, it > guarantees the ATTENDEE's AA, or the ATTENDEE will never > know that it was rejected. Not correct. The ATTENDEE would know because they always get the DECLINECOUNTER. The AA can tell by how the ATTENDEEs CUA deals with the DECLINECOUNTER (remove the marker you created for a pending COUNTER, etc). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00657EE785256B6E_= Content-Type: text/html; charset="US-ASCII"
Doug answered on 02/28/2002 12:48:26 PM:

> As I am working mostly in creating a CS and not a CUA, my *thoughts*
> were that a CUA would have to remember that it sent a COUNTER so
> that it could inform the CU when the DECLINECOUNTER or new object
> arrived. Some kind of 'this is pending' stack in the CUA and
> out of scope for the CAP protocol.
Also you have the dilemma if _you_ send 2+ COUNTERs.  Just how do you determine which COUNTER matches the DECLINECOUNTER I send back?  I may not have gotten one of them or I may have accepted/rejected it but the response got lost in transit...  In any case, there is insufficient info in the DECLINECOUNTER to match it to > 1 COUNTER as we've defined it so far.

> >  How does it distinguish between the 2 COUNTERs you sent (you changed
> > your mind after the 1st one)?
>
> As you pointed out in another email: COMMENT.
Dont rely on it though!  Its a "0 or 1".  Even then I could send back "Sorry, cant do it then." for all declines and its not that useful...  You still dont know exactly WHICH COUNTER I am declining.

> > It doesnt really matter since the COUNTER(s) was not accepted.
>
> The 1st CU will know that, the 2nd+ AA-CU will never know that.
> To the 2nd+ AA-CU, it will appear that the ORGANIZER never
> responded.
This is all future navel gazing and there are current limitations that make doing lots of these desirable but yet unspec'd features quite hard.  Im simply proposing a fix for a problem we all agreed on back in Aug-2000.

> > That still wont match it up to any particular COUNTER unless you only
> > allow 1 COUNTER per cal-address.  We've never had any such restriction
> > and I dont see a need to add one.
>
> Not true:
>
>    ATTCOUNTER:cu-1
>
> vs.
>
>    ATTCOUNTER:SENT-BY-cu-1-aa:cu-1
For the case of you (and each AA) can only send 1 COUNTER then this would be valid.  However, is that a reasonable/valid restriction?  I think not.  For example, I COUNTER with a new date/time and later on I find I need to suggest another new time so I send a 2nd COUNTER w/a working time.  Now, how do you determine which COUTNER my DECLINECOUNTER with "ATTCOUNTER:cu-1" matches?

> I think I am pointing out that it just moves the problem from the
> COUNTER to the DECLINECOUNTER. It is not exactly the same problem.
No its not.  The only problem we had was that an Organizer has no way to tell what ATTENDEE is COUNTERing.  You're now saying that we need some way for the COUTNERing ATTENDEE to thread up DECLINECOUNTER(s).  Since we have REQUEST (if they accept it) or DECLINECOUNTER (if they reject it) then is there a pressing need to identify which COUNTER??  Since even if we adopt the ATTCOUNTER on DECLINECOUNTER, it still wont resolve the need I say leave it off.

> Without replicating the ATTCOUNTER into the DECLINECOUNTER, it
> guarantees the ATTENDEE's AA, or the ATTENDEE will never
> know that it was rejected.
Not correct.  The ATTENDEE would know because they always get the DECLINECOUNTER.  The AA can tell by how the ATTENDEEs CUA deals with the DECLINECOUNTER (remove the marker you created for a pending COUNTER, etc).

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

--=_alternative 00657EE785256B6E_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 15:14:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17167 for ; Thu, 28 Feb 2002 15:14:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SJlFC15698 for ietf-calendar-bks; Thu, 28 Feb 2002 11:47:15 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SJlEi15694 for ; Thu, 28 Feb 2002 11:47:14 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA29988 for ; Thu, 28 Feb 2002 11:47:16 -0800 (PST) Message-ID: <3C7E893E.FF10681D@Royer.com> Date: Thu, 28 Feb 2002 12:47:10 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER References: Content-Type: multipart/mixed; boundary="------------BF98A1C9CD171970DF19B071" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BF98A1C9CD171970DF19B071 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > Without replicating the ATTCOUNTER into the DECLINECOUNTER, it > > guarantees the ATTENDEE's AA, or the ATTENDEE will never > > know that it was rejected. > > Not correct. The ATTENDEE would know because they always get the > DECLINECOUNTER. > The AA can tell by how the ATTENDEEs CUA deals with > the DECLINECOUNTER (remove the marker you created for a pending > COUNTER, etc). The marker would be in the ATTENDESS-CUA, how could the AA-CUA remove it? It can't be in the CS or two+ vendor implementations will not interoperate with respect to DECLINECOUNTER. --------------BF98A1C9CD171970DF19B071 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------BF98A1C9CD171970DF19B071-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 15:24:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17802 for ; Thu, 28 Feb 2002 15:24:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SKCon16388 for ietf-calendar-bks; Thu, 28 Feb 2002 12:12:50 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SKCli16367 for ; Thu, 28 Feb 2002 12:12:47 -0800 (PST) To: Doug Royer Cc: ietf-calendar@imc.org Subject: Re: RFC 2445 Proposal: ATTCOUNTER MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02252002 February 25, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 28 Feb 2002 15:12:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/28/2002 03:12:51 PM, Serialize complete at 02/28/2002 03:12:51 PM Content-Type: multipart/alternative; boundary="=_alternative 006EE70A85256B6E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006EE70A85256B6E_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 02/28/2002 02:47:10 PM: > The marker would be in the ATTENDESS-CUA, how could the AA-CUA > remove it? It can't be in the CS or two+ vendor implementations > will not interoperate with respect to DECLINECOUNTER. All this is moot as its all wishfull thinking as of now and it wont be in CAP and its not in any proposals on the table now. We've digressed but so far I dont hear any arguments against the proposal (just some possible additions). Is that a fair assessment? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006EE70A85256B6E_= Content-Type: text/html; charset="US-ASCII"
Doug  wrote on 02/28/2002 02:47:10 PM:
> The marker would be in the ATTENDESS-CUA, how could the AA-CUA
> remove it? It can't be in the CS or two+ vendor implementations
> will not interoperate with respect to DECLINECOUNTER.

All this is moot as its all wishfull thinking as of now and it wont be in CAP and its not in any proposals on the table now.  We've digressed but so far I dont hear any arguments against the proposal (just some possible additions).  Is that a fair assessment?

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

--=_alternative 006EE70A85256B6E_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 28 21:54:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01019 for ; Thu, 28 Feb 2002 21:54:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g212iwN25922 for ietf-calendar-bks; Thu, 28 Feb 2002 18:44:58 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g212ivi25917 for ; Thu, 28 Feb 2002 18:44:57 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id SAA00488 for ; Thu, 28 Feb 2002 18:44:55 -0800 (PST) Message-ID: <3C7EEB1E.5B4F27BE@Royer.com> Date: Thu, 28 Feb 2002 19:44:46 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: Summary - CAP editors call - 28-FEB-02 Content-Type: multipart/mixed; boundary="------------7A8B4255D058B7BAA17B99B4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7A8B4255D058B7BAA17B99B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The major point is below is that we have decided that CAP is not ready for last-call. So we are going to ship out a version of CAP that includes many of the changes discussed in the last few months. If you notice that some of the changes that you think are were agreed to, and are not included, send email to the editors. We are still consolidating the information over the last few months. Version -07 will contain much of the consolidation work, but not all of it. We are mostly issuing -07 to make it clear where the latest proposals exist, and to make it available for the MN IETF. THANK YOU. ---------------------------------------------------------------------- This is a summary of the issues talked about today on the CAP editors conference call: o What will go into the draft sent tomorrow (29th)? o Bob: Concerned that that XML is feature creep in cap. o Pat: At this time it seems that there is only one proponent of XML in CAP. o We talked about text/calendar vs application/...xml... It looks as if the consensus is text/calendar. Doug: Lets let xCal specify the XML-CAP/BEEP binding And have CAP do the text/calendar binding. xCal and iCal are 1:1 mapping. I think there is consensus for this approach. George: Concerned about how xCal will map CAP command. Doug: If it is CMD: in CAP, then it can map 1:1 in xCal. o Pat/Bob: Lets get the draft out tomorrow. It will not be the last-call as we hopped. More things may have to change. o Doug will merge the WG lists and errors into CAP plus check and fix the error codes. Rip out the requirement that CAP specifies the BEEP message boundaries. (Not beep compliant). Only have the 1st example in each section show BEEP commands. The other examples will be iCalendar data only. o We will update the security section with the latest proposal, may need more work later. o ATTCOUNTER will be sent by Bruce - it will NOT be in CAP. o Remove the 6.3. text and replace it with a 6.2.x "iTIP and CAP..." section o Rename 6.2.x to "CAP commands". o Doug will send to George tonight. o George will tweak/edit and send out by deadline. o Pat: Looks as if cal-connect is not going to be a face to face. Microsoft has contacted Pat and they may be interested in interoperability or conformance. --------------7A8B4255D058B7BAA17B99B4 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:;;;;;; version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-8832 fn:Doug Royer end:vcard --------------7A8B4255D058B7BAA17B99B4--