From owner-ietf-calendar@mail.imc.org Sat Dec 1 04:02:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04658 for ; Sat, 1 Dec 2001 04:02:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB18gYL25862 for ietf-calendar-bks; Sat, 1 Dec 2001 00:42:34 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB18gX825857 for ; Sat, 1 Dec 2001 00:42:33 -0800 (PST) Received: from Royer.com (IDENT:qVEtsyHupoNY6S6d5fzyqjv9P0ACsXyC@usr-if-100.rmci.net [208.14.172.100]) by royer.com (8.9.1/8.9.1) with ESMTP id AAA10245 for ; Sat, 1 Dec 2001 00:42:31 -0800 (PST) Message-ID: <3C089654.CA111807@Royer.com> Date: Sat, 01 Dec 2001 01:35:32 -0700 From: Doug Royer Reply-To: iietf-calendar@imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "ietf-calendar@imc.org" Subject: Re: iCalendar - "octets" question References: Content-Type: multipart/mixed; boundary="------------66D85B37788CEBD6A7375432" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------66D85B37788CEBD6A7375432 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >If you don't know the charset, you can't always tell how to put it > >back together. > > You're right. The problem I didn't see before is that, in a 2-byte > character set, you might have the characters 0D0A 2041, which, to > something built for ASCII, would look like CR LF SP A; the CR LF SP would > then get dropped. > > I think this complicates the story for senders; they need to split lines > at the 75-octet mark, but the code that splits the lines only sees > characters, not octets. You said that splitting lines was only for > presentation (does anybody disagree?); if so, we can change "75 octets" to > "75 characters". > > Make sense? I think that 2445 says it right. Split BETWEEN characters always so that the line is not longer than 72 octets. --------------66D85B37788CEBD6A7375432 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;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;ID;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------66D85B37788CEBD6A7375432-- From owner-ietf-calendar@mail.imc.org Mon Dec 3 10:26:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04388 for ; Mon, 3 Dec 2001 10:26:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3FAd527384 for ietf-calendar-bks; Mon, 3 Dec 2001 07:10:39 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3FAc227380 for ; Mon, 3 Dec 2001 07:10:38 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA03810; Mon Dec 3 10:08:34 2001 Received: from [10.10.30.8] by gate.incentivesystems.com for iietf-calendar@imc.org id KAA02584; Mon Dec 3 10:03:18 2001 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Subject: Re: iCalendar - "octets" question Message-ID: Date: Mon, 3 Dec 2001 10:14:19 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/03/2001 10:14:21 AM Content-type: text/plain; charset=us-ascii To: From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> I think this complicates the story for senders; they need to split lines >> at the 75-octet mark, but the code that splits the lines only sees >> characters, not octets. You said that splitting lines was only for >> presentation (does anybody disagree?); if so, we can change "75 octets" to >> "75 characters". > >I think that 2445 says it right. Split BETWEEN characters always so >that the line is not longer than 72 octets. Why? Characters (human legibility) are what matter for presentation, not octets. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=================================================================| |"Lollygaggers will be shot on sight!" "I didn't say that!" "I was| |paraphrasing." | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Dec 3 12:25:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15747 for ; Mon, 3 Dec 2001 12:25:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fB3H8UC06189 for ietf-calendar-bks; Mon, 3 Dec 2001 09:08: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 fB3H8T206185 for ; Mon, 3 Dec 2001 09:08: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 IAA04140; Mon, 3 Dec 2001 08:10:32 -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 fB3H84H04400; Mon, 3 Dec 2001 12:08:04 -0500 (EST) Message-Id: <5.1.0.14.0.20011203111326.06efd518@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Dec 2001 12:10:43 -0500 To: "John Stracke" , From: Alan Davies Subject: Re: iCalendar - "octets" question 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: What is the purpose of adding folding? If it's for human legibility of the iCalendar source, then folding between characters would make more sense than between octets. If folding is just for preventing absurdly long lines which some machines may not like, then folding between octets might make more sense. RFC 2445 states that folding should be added between characters of course. Is it OK to change this because it allows a certain parser implementation strategy to work? Of course, folding is only a "SHOULD"; are multibyte characters one of the "valid reasons in particular circumstances" [RFC2119] for not adding folding. By not folding, the sender can be sure that the text will not be misinterpreted, whether the receiving parser follows the spec or not. --Alan At 10:14 AM 03/12/2001 -0500, John Stracke wrote: >Why? Characters (human legibility) are what matter for presentation, not >octets. > >/=================================================================\ >|John Stracke |Principal Engineer | >|jstracke@incentivesystems.com |Incentive Systems, Inc. | >|http://www.incentivesystems.com|My opinions are my own. | >|=================================================================| >|"Lollygaggers will be shot on sight!" "I didn't say that!" "I was| >|paraphrasing." | >\=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Dec 3 12:59:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17740 for ; Mon, 3 Dec 2001 12:59:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3HcIv07356 for ietf-calendar-bks; Mon, 3 Dec 2001 09:38:18 -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 fB3Hc4207348 for ; Mon, 3 Dec 2001 09:38:04 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA27579; Mon, 3 Dec 2001 11:31:59 -0600 From: "Shannon J. Clark" To: "Alan Davies" , "John Stracke" , Subject: RE: iCalendar - "octets" question Date: Mon, 3 Dec 2001 11:37:33 -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) Importance: Normal In-Reply-To: <5.1.0.14.0.20011203111326.06efd518@imap1.in.steltor.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alan, I think this raises one of the core questions: How does the receiving system determine if folding has been done? UNFOLDING is a MUST - so all systems have to perform it prior to dealing with the iCalendar objects - one of the issues with Multibyte strings is the possibility that "inside" of a character will be the sequence of octets that is CRLF [Tab or Space]. So - while FOLDING is optional, not folding on a multibyte character object may not solve our problems... it is quite possible that another system receiving that iCalendar object would decide to "unfold" it - IF this occurred BEFORE dealing with CHARSET - if FOLDING is required to deal with OCTETS - then it is very logical to consider it as having to occur PRIOR to character detection (logical but probably wrong). Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Alan Davies Sent: Monday, December 03, 2001 11:11 AM To: John Stracke; ietf-calendar@imc.org Subject: Re: iCalendar - "octets" question What is the purpose of adding folding? If it's for human legibility of the iCalendar source, then folding between characters would make more sense than between octets. If folding is just for preventing absurdly long lines which some machines may not like, then folding between octets might make more sense. RFC 2445 states that folding should be added between characters of course. Is it OK to change this because it allows a certain parser implementation strategy to work? Of course, folding is only a "SHOULD"; are multibyte characters one of the "valid reasons in particular circumstances" [RFC2119] for not adding folding. By not folding, the sender can be sure that the text will not be misinterpreted, whether the receiving parser follows the spec or not. --Alan At 10:14 AM 03/12/2001 -0500, John Stracke wrote: >Why? Characters (human legibility) are what matter for presentation, not >octets. > >/=================================================================\ >|John Stracke |Principal Engineer | >|jstracke@incentivesystems.com |Incentive Systems, Inc. | >|http://www.incentivesystems.com|My opinions are my own. | >|=================================================================| >|"Lollygaggers will be shot on sight!" "I didn't say that!" "I was| >|paraphrasing." | >\=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Dec 3 16:16:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01454 for ; Mon, 3 Dec 2001 16:16:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3L3l816875 for ietf-calendar-bks; Mon, 3 Dec 2001 13:03:47 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3L3j216871 for ; Mon, 3 Dec 2001 13:03: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 NAA28482 for ; Mon, 3 Dec 2001 13:03:36 -0800 (PST) Message-ID: <3C0BE8A5.29CBEB89@Royer.com> Date: Mon, 03 Dec 2001 14:03:33 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: iCalendar - "octets" question References: <5.1.0.14.0.20011203111326.06efd518@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------08A768B77750475AE19722BC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------08A768B77750475AE19722BC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > > What is the purpose of adding folding? > > If it's for human legibility of the iCalendar source, then folding > between characters would make more sense than between octets. > > If folding is just for preventing absurdly long lines which some > machines may not like, then folding between octets might make more > sense. But makes unfolding - a guess if you don't know the charset. > RFC 2445 states that folding should be added between characters of > course. Is it OK to change this because it allows a certain parser > implementation strategy to work? That was because iCalendar objects can be sent via email, and email (821 or 822) specifies folding? > Of course, folding is only a "SHOULD"; are multibyte characters > one of the "valid reasons in particular circumstances" [RFC2119] > for not adding folding. Fold between characters - not at octets. --------------08A768B77750475AE19722BC 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------08A768B77750475AE19722BC-- From owner-ietf-calendar@mail.imc.org Mon Dec 3 16:16:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01465 for ; Mon, 3 Dec 2001 16:16:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fB3L4vu16927 for ietf-calendar-bks; Mon, 3 Dec 2001 13:04:57 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3L4u216922 for ; Mon, 3 Dec 2001 13:04: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 NAA28486; Mon, 3 Dec 2001 13:04:57 -0800 (PST) Message-ID: <3C0BE8F5.1E5A50B0@Royer.com> Date: Mon, 03 Dec 2001 14:04:53 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.or Subject: Re: iCalendar - "octets" question References: Content-Type: multipart/mixed; boundary="------------793409857D9D587FF9125503" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------793409857D9D587FF9125503 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >> I think this complicates the story for senders; they need to split > lines > >> at the 75-octet mark, but the code that splits the lines only sees > >> characters, not octets. You said that splitting lines was only for > >> presentation (does anybody disagree?); if so, we can change "75 octets" > to > >> "75 characters". > > > >I think that 2445 says it right. Split BETWEEN characters always so > >that the line is not longer than 72 octets. > > Why? Characters (human legibility) are what matter for presentation, not > octets. For iMIP and sending via email. But you don't have to do it. --------------793409857D9D587FF9125503 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------793409857D9D587FF9125503-- From owner-ietf-calendar@mail.imc.org Tue Dec 4 10:16:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27628 for ; Tue, 4 Dec 2001 10:16:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB4EuRH03909 for ietf-calendar-bks; Tue, 4 Dec 2001 06:56:27 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4EuQ203905 for ; Tue, 4 Dec 2001 06:56:26 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA05386; Tue Dec 4 09:29:52 2001 Subject: Re: iCalendar - "octets" question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 4 Dec 2001 09:35:37 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/04/2001 09:35:44 AM, Serialize complete at 12/04/2001 09:35:44 AM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> >I think that 2445 says it right. Split BETWEEN characters always so >> >that the line is not longer than 72 octets. >> >> Why? Characters (human legibility) are what matter for presentation, not >> octets. > >For iMIP and sending via email. ?? Isn't that what quoted-printable is for? (RFC-2045, sec. 6.7) I mean, we're not going to be sending a text/calendar to anybody who doesn't grok MIME; and MIME MUAs are required to decode quoted-printable (RFC-2049, sec. 2, point (2)). /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Do not suspect that I am not human. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Mon Dec 10 13:31:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08083 for ; Mon, 10 Dec 2001 13:31:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBAIEth23215 for ietf-calendar-bks; Mon, 10 Dec 2001 10:14:55 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAIEn223206 for ; Mon, 10 Dec 2001 10:14:53 -0800 (PST) To: ietf-calendar@imc.org Subject: Reminder - dinner 6:30 in lobby MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 12 Dec 2000 11:11:12 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 12/10/2001 01:14:55 PM, Serialize complete at 12/10/2001 01:14:55 PM Content-Type: multipart/alternative; boundary="=_alternative 0058EAD8852569B3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058EAD8852569B3_= Content-Type: text/plain; charset="us-ascii" For all of you here in Salt Lake City, this is a reminder of getting together for dinner - 6:30 in the lobby of the Grand Hotel. See you there. --=_alternative 0058EAD8852569B3_= Content-Type: text/html; charset="us-ascii"
For all of you here in Salt Lake City, this is a reminder of getting together for dinner - 6:30 in the lobby of the Grand Hotel. See you there. --=_alternative 0058EAD8852569B3_=-- From owner-ietf-calendar@mail.imc.org Tue Dec 11 17:08:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25887 for ; Tue, 11 Dec 2001 17:08:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBLnNu18663 for ietf-calendar-bks; Tue, 11 Dec 2001 13:49:23 -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 fBBLnI218659 for ; Tue, 11 Dec 2001 13:49:22 -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 fBBLn9x00646 for ; Tue, 11 Dec 2001 13:49:10 -0800 (PST) Received: from netscape.com ([205.217.229.119]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO78LX00.ARC for ; Tue, 11 Dec 2001 13:49:09 -0800 Message-ID: <3C167F57.AEAC1FA8@netscape.com> Date: Tue, 11 Dec 2001 13:49:11 -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 Draft 6 comments Content-Type: multipart/mixed; boundary="------------C6709775A0648866972FE9FE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C6709775A0648866972FE9FE Content-Type: multipart/alternative; boundary="------------24E6F68C1986A6EE94A43017" --------------24E6F68C1986A6EE94A43017 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All, Thanks to a delayed flight, I managed to get through the entire draft. Here are some things I noted (I'm not listing all the typos): 1. Section 2.1. We can use BEEP as a handle for "transport protocol", However, there was no explicit mention of an "application protocol". I believe that is what CAP has become now that we use BEEP. I think it's important to state it. 2. Section 2.2 - We refer to many new components before ever listing them and before we provide even a one-liner describing what they are. I think a table that lists each of the components CAP deals with and a quick one-line description would be really useful. 3. Is there a VSCHEDULE anymore? We still refer to it in 2.2. 4. Section 2.4.4 we mention trusted server relationships. We should mention explicitly that this is out of the scope of [CAP] 5. Section 2.6 - we mention "printable 7 bit ASCII characters". Is this sufficiently explicit? Should we list the character value range? 6. Section 3.3 in the example, the MSG number changes from 4 to 2, shouldn't they match? 7. Section 4.1.2 Use 'DTSTART <= ...' -- the two strings look identical. I think it's a typo... or is it? 8. What was intended for 4.1.3 Querying Experimental Properties ? 9. Section 4.1.6 versus 4.1.8 -- the value for METHOD. In some places, we refer to the METHOD value for "booked" events as NULL, and in other places we refer to it as CREATED. I happen to prefer being explicit and keeping it at CREATED, but whatever we choose we must be consistent. 10. Section 4.1.6 -- I thought we decided that we need a METHOD state for a CANCELled event or a DELETEd event. This is important for several reasons. One was mentioned in the draft, another is that it's important for synchronization applications to determine which events have been deleted. If we use the METHOD property to mark cancelled / deleted events, then the query needs to be fixed. 11. Section 6.1.3 needs an example 12. We need to close on the iCalendar version we're going to require for CAP. In the current draft we specify that we require VERSION 2.0 and VERSION 2.1. Let's pick one :-) 13. Section 6.2.4.1. (and most of the other commands that follow it) -- need more error return values to be listed. All commands are showing 2.0, 6.1, 6.3. But there are many other errors that can occur; security violations, etc. We need to list them. 14. Section 6.2.4.2. Regarding the editors note - my recommendation is that the way to delete a VALARM is to modify or delete the component that contains it. The delete command should apply to the VTIMEZONES that exist at the calstore level. I don't think components like VEVENTS can contain VTIMEZONE components, I think they only reference VTIMEZONE components that exist at the calstore level. 15. Section 6.2.4.3. Are there sequencing (ordering) issues? are removes always processed before updates? does it matter? 16. Section 6.2.4.3. The returned REQUEST-STATUS has a single 2.0 return value, yet many error conditions can occur. Some of the requested edits / removes may be successful while others are not (perhaps due to access control). When multiple errors occur, is there a separate REQUEST-STATUS for each update/remove that failed? 17. Section 6.2.4.4. "CS MUST ensure that VCARs are still valid after the move" seems pretty nebulous to me. I think the issue is the following: given that VCARs are hierarchic, moving a calendar from one location in the hierarchy to another could possibly change the access control considerably and yield unexpected and unwanted results. I think what we want to do is make sure that the access control is at least as restrictive (and possibly more restrictive) than it was prior to the move. Note that with hierarchic VCARs the way they are defined now, it may not be possible to provide exactly the same access to a calendar as prior to the move -- something further up the new hierarchy may be more restrictive. Also, there are ownership issues. Is there something we want to say about the ownership of the new parent calendar(s) given the owners of the previous parent calendars? (this problem is pointed out in the editors note). 18. Section 6.2.4.4, in the example query for moving "Nellis" to "area-51" there can only 0 or 1 calendars will match the query. Do we want to put in a statement that discusses what would happen if the query resulted in multiple calids (I'm not sure what it means). Or do we want to state that the query can only produce 0 or 1 result, and if more than 1 calids result from the query it would be an error ? 19. Section 6.2.4.5, just past the last example we show this query: QUERY: SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com' CALSTORE is being used as a special keyword here. We should probably list this somewhere or find another way to do the query. 20. Section 6.3.3.1 was the Organizer intentionally left out of the ATTENDEE list? Seems like the organizer should be in the attendee list. 21. Section 6.3.3.4 the second part of the example is wrong. C cannot send a DECLINECOUNTER. DECLINECOUNTER is sent by the Organizer to the Attendee who countered. C is not the Organizer. We'll fix it. --------------24E6F68C1986A6EE94A43017 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All,

Thanks to a delayed flight, I managed to get through the entire draft.  Here are some things I noted (I'm not listing all the typos):

  1. Section 2.1.  We can use BEEP as a handle for "transport protocol",  However, there was no explicit mention of an "application protocol". I believe that is what CAP has become now that we use BEEP.  I think it's important to state it.
  2. Section 2.2 - We refer to many new components before ever listing them and before we provide even a one-liner describing what they are. I think a table that lists each of the components CAP deals with and a quick one-line description would be really useful.
  3. Is there a VSCHEDULE anymore? We still refer to it in 2.2.
  4. Section 2.4.4 we mention trusted server relationships. We should mention explicitly that this is out of the scope of [CAP]
  5. Section 2.6 - we mention "printable 7 bit ASCII characters".  Is this sufficiently explicit? Should we list the character value range?
  6. Section 3.3 in the example, the MSG number changes from 4 to 2, shouldn't they match?
  7. Section 4.1.2 Use 'DTSTART <= ...'  -- the two strings look identical. I think it's a typo... or is it?
  8. What was intended for 4.1.3 Querying Experimental Properties ?
  9. Section 4.1.6 versus 4.1.8 -- the value for METHOD.  In some places, we refer to the METHOD value for "booked" events as NULL, and in other places we refer to it as CREATED.  I happen to prefer being explicit and keeping it at CREATED, but whatever we choose we must be consistent.
  10. Section 4.1.6 -- I thought we decided that we need a METHOD state for a CANCELled event or a DELETEd event. This is important for several reasons. One was mentioned in the draft, another is that it's important for synchronization applications to determine which events have been deleted. If we use the METHOD property to mark cancelled / deleted events, then the query needs to be fixed.
  11. Section 6.1.3 needs an example
  12. We need to close on the iCalendar version we're going to require for CAP.  In the current draft we specify that we require VERSION 2.0 and VERSION 2.1.  Let's pick one :-)
  13. Section 6.2.4.1.  (and most of the other commands that follow it) -- need more error return values to be listed. All commands are showing 2.0, 6.1, 6.3. But there are many other errors that can occur; security violations, etc. We need to list them.
  14. Section 6.2.4.2.  Regarding the editors note -  my recommendation is that the way to delete a VALARM is to modify or delete the component that contains it.  The delete command should apply to the VTIMEZONES that exist at the calstore level.  I don't think components like VEVENTS can contain VTIMEZONE components, I think they only reference VTIMEZONE components that exist at the calstore level.
  15. Section 6.2.4.3.  Are there sequencing (ordering) issues? are removes always processed before updates? does it matter?
  16. Section 6.2.4.3.  The returned REQUEST-STATUS has a single 2.0 return value, yet many error conditions can occur. Some of the requested edits / removes may be successful while others are not (perhaps due to access control).  When multiple errors occur, is there a separate REQUEST-STATUS for each update/remove that failed?
  17. Section 6.2.4.4. "CS MUST ensure that VCARs are still valid after the move" seems pretty nebulous to me. I think the issue is the following: given that VCARs are hierarchic, moving a calendar from one location in the hierarchy to another could possibly change the access control considerably and yield unexpected and unwanted results.  I think what we want to do is make sure that the access control is at least as restrictive (and possibly more restrictive) than it was prior to the move.  Note that with hierarchic VCARs the way they are defined now, it may not be possible to provide exactly the same access to a calendar as prior to the move -- something further up the new hierarchy may be more restrictive.  Also, there are ownership issues. Is there something we want to say about the ownership of the new parent calendar(s) given the owners of the previous parent calendars?  (this problem is pointed out in the editors note).
  18. Section 6.2.4.4, in the example query for moving "Nellis" to "area-51" there can only 0 or 1 calendars will match the query. Do we want to put in a statement that discusses what would happen if the query resulted in multiple calids (I'm not sure what it means).  Or do we want to state that the query can only produce 0 or 1 result, and if more than 1 calids result from the query it would be an error ?
  19. Section 6.2.4.5, just past the last example we show this query:   QUERY: SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com'   CALSTORE is being used as a special keyword here. We should probably list this somewhere or find another way to do the query.
  20. Section 6.3.3.1   was the Organizer intentionally left out of the ATTENDEE list?  Seems like the organizer should be in the attendee list.
  21. Section 6.3.3.4   the second part of the example is wrong.  C cannot send a DECLINECOUNTER.  DECLINECOUNTER is sent by the Organizer to the Attendee who countered.  C is not the Organizer.  We'll fix it.
--------------24E6F68C1986A6EE94A43017-- --------------C6709775A0648866972FE9FE 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------C6709775A0648866972FE9FE-- From owner-ietf-calendar@mail.imc.org Tue Dec 11 17:15:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26098 for ; Tue, 11 Dec 2001 17:15:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBBM3aQ19133 for ietf-calendar-bks; Tue, 11 Dec 2001 14:03:36 -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 fBBM3Y219128 for ; Tue, 11 Dec 2001 14:03:34 -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 fBBM3UY09840 for ; Tue, 11 Dec 2001 14:03:30 -0800 (PST) Received: from netscape.com ([205.217.229.119]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO799U00.MQZ for ; Tue, 11 Dec 2001 14:03:30 -0800 Message-ID: <3C1682B4.5D45B300@netscape.com> Date: Tue, 11 Dec 2001 14:03:32 -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: VCAR question Content-Type: multipart/mixed; boundary="------------43C4BFD1DD55784950927C42" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------43C4BFD1DD55784950927C42 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does "write" permission to a VAGENDA give you the right to move another VAGENDA into it? -Steve --------------43C4BFD1DD55784950927C42 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------43C4BFD1DD55784950927C42-- From owner-ietf-calendar@mail.imc.org Tue Dec 11 17:53:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26847 for ; Tue, 11 Dec 2001 17:53:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBBMe5S21978 for ietf-calendar-bks; Tue, 11 Dec 2001 14:40:05 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBMe4221972 for ; Tue, 11 Dec 2001 14:40:04 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA16078; Tue Dec 11 17:37:37 2001 Subject: Re: VCAR question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 11 Dec 2001 17:44:10 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/11/2001 05:44:17 PM, Serialize complete at 12/11/2001 05:44:17 PM Content-Type: text/plain; charset="us-ascii" To: CalSched IETF From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Does "write" permission to a VAGENDA give you the right to move another >VAGENDA into it? It does seem like it should. Er...does it give you the right to create subagendas, and create components within them? If so, then I'd say yes, since there's no way to distinguish (after the fact) between: (a) Move VAGENDA X into VAGENDA Y. (b) Create VAGENDA Y2 inside VAGENDA X; for each component C in Y, create a copy C2 in Y2; delete Y. Obviously, (b) is less efficient than (a), but has the same net effect, so we shouldn't set any rules that cause people to do (b) when they mean (a). /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |I'm not a bibliophile, I'm a bibliophiliac. Put me in a| |bookstore, & my wallet bleeds. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Tue Dec 11 18:16:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27233 for ; Tue, 11 Dec 2001 18:16:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBN4O824867 for ietf-calendar-bks; Tue, 11 Dec 2001 15:04:24 -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 fBBN4M224859 for ; Tue, 11 Dec 2001 15:04:22 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id RAA05340; Tue, 11 Dec 2001 17:00:36 -0600 From: "Shannon J. Clark" To: "John Stracke" , "CalSched IETF" Subject: RE: VCAR question Date: Tue, 11 Dec 2001 17:04:19 -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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just a question - and prefaced by the note that I have not fully read through the newest draft with VAGENDA so this may be answered elsewhere. Can a VAGENDA contain a VCAR? If so then isn't having "write" permission to a VAGENDA with the ability to move another VAGENDA into it the same has having full rights since you could create VCARS? Or am I missing something? Just a thought, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Tuesday, December 11, 2001 4:44 PM To: CalSched IETF Subject: Re: VCAR question >Does "write" permission to a VAGENDA give you the right to move another >VAGENDA into it? It does seem like it should. Er...does it give you the right to create subagendas, and create components within them? If so, then I'd say yes, since there's no way to distinguish (after the fact) between: (a) Move VAGENDA X into VAGENDA Y. (b) Create VAGENDA Y2 inside VAGENDA X; for each component C in Y, create a copy C2 in Y2; delete Y. Obviously, (b) is less efficient than (a), but has the same net effect, so we shouldn't set any rules that cause people to do (b) when they mean (a). /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |I'm not a bibliophile, I'm a bibliophiliac. Put me in a| |bookstore, & my wallet bleeds. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Tue Dec 11 18:32:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27571 for ; Tue, 11 Dec 2001 18:32:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBNCxs26232 for ietf-calendar-bks; Tue, 11 Dec 2001 15:12:59 -0800 (PST) Received: from tipjar.com (tipjar.com [128.121.115.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBNCv226224 for ; Tue, 11 Dec 2001 15:12:57 -0800 (PST) Received: (tipjar@localhost) by tipjar.com id fBBNCj455522; Tue, 11 Dec 2001 16:12:45 -0700 (MST) X-Received-For: ietf-calendar@mail.imc.org Date: Tue, 11 Dec 2001 16:12:45 -0700 (MST) From: tipjar@tipjar.com (tipjar LLC) Message-Id: <200112112312.fBBNCj455522@tipjar.com> To: ietf-calendar@mail.imc.org Subject: bearer certificates and VCARs and draft 6, oh my Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The feature I've been scouring all drafts for, which is the ability to designate a role without specifying who you are designating, is again missing. The section on the VCAR in draft six even places the association of the VCAR to the CU (rather than the session) in the MUST category: VCARs MUST be specifically granted to an authenticated CU. If the protocol is to support rights given to a session based on presentation within the session of some kind of certificate which would cause the session to gain that right, we might need to add "or session" to 2.4.2 summary. It also appears in 2.4.4 that the identify command remains, contrary to rumour of its demise (yes, I am looking at draft 6). I think that a suggested syntax involving the identify command would be a good choice for the question of how one would present a bearer authorization certificate to have additional VCARs added to the current session, should the committee approve of the concept. -- Tipjar Administrator and general stone in your shoe, David Nicol From owner-ietf-calendar@mail.imc.org Tue Dec 11 18:36:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27598 for ; Tue, 11 Dec 2001 18:36:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBBNO4f26821 for ietf-calendar-bks; Tue, 11 Dec 2001 15:24:04 -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 fBBNO3226817 for ; Tue, 11 Dec 2001 15:24: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 fBBNNtx20714 for ; Tue, 11 Dec 2001 15:23:55 -0800 (PST) Received: from netscape.com ([205.217.229.112]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO7CZV00.UT7; Tue, 11 Dec 2001 15:23:55 -0800 Message-ID: <3C16958D.612D0A45@netscape.com> Date: Tue, 11 Dec 2001 15:23:57 -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: "Shannon J. Clark" CC: John Stracke , CalSched IETF Subject: Re: VCAR question References: Content-Type: multipart/mixed; boundary="------------C6842325D1DF9A879D39A3CC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C6842325D1DF9A879D39A3CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > Just a question - and prefaced by the note that I have not fully read > through the newest draft with VAGENDA so this may be answered elsewhere. it's in CAP > Can a VAGENDA contain a VCAR? yes > If so then isn't having "write" permission to > a VAGENDA with the ability to move another VAGENDA into it the same has > having full rights since you could create VCARS? Or am I missing something? we were just wondering if this is enough of a special case. It seems like it could be a special case. Just interested in people's thoughts. -Steve > > > Just a thought, > > Shannon > > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke > Sent: Tuesday, December 11, 2001 4:44 PM > To: CalSched IETF > Subject: Re: VCAR question > > >Does "write" permission to a VAGENDA give you the right to move another > >VAGENDA into it? > > It does seem like it should. > > Er...does it give you the right to create subagendas, and create > components within them? If so, then I'd say yes, since there's no way to > distinguish (after the fact) between: > > (a) Move VAGENDA X into VAGENDA Y. > (b) Create VAGENDA Y2 inside VAGENDA X; for each component C in Y, create > a copy C2 in Y2; delete Y. > > Obviously, (b) is less efficient than (a), but has the same net effect, so > we shouldn't set any rules that cause people to do (b) when they mean (a). > > /=======================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc.| > |http://www.incentivesystems.com|My opinions are my own.| > |=======================================================| > |I'm not a bibliophile, I'm a bibliophiliac. Put me in a| > |bookstore, & my wallet bleeds. | > \=======================================================/ --------------C6842325D1DF9A879D39A3CC 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------C6842325D1DF9A879D39A3CC-- From owner-ietf-calendar@mail.imc.org Tue Dec 11 19:30:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28454 for ; Tue, 11 Dec 2001 19:30:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC0AW428908 for ietf-calendar-bks; Tue, 11 Dec 2001 16:10:32 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC0AT228902 for ; Tue, 11 Dec 2001 16:10:30 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA18326; Tue, 11 Dec 2001 19:10:23 -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 TAA02421; Tue, 11 Dec 2001 19:10:21 -0500 (EST) Received: from monalisa (114-201-131-12.bellhead.com [12.131.201.114]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id TAA21256; Tue, 11 Dec 2001 19:10:21 -0500 (EST) From: "Paul B. Hill" To: "Steve Mansour" , "CalSched IETF" Subject: RE: VCAR question Date: Tue, 11 Dec 2001 19:10:22 -0500 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) In-Reply-To: <3C1682B4.5D45B300@netscape.com> Importance: Normal 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 Hi, There is no "write" VCAR action or permission... From cal-updates: "The ACTION rule part defines one or more CAP actions that are allowed for the UPN. The valid values are CREATE, DELETE, MODIFY, MOVE, READ, and all of the [iTIP] scheduling commands; PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER, corresponding to the scheduling commands; and '*', meaning all of calendaring commands and scheduling commands. Multiple ACTION enumerations can be specified as a COMMA character (US-ASCII decimal 44) separated list of ACTION enumerated values. The text '*' is the same as specifying the enumerated values "CREATE,MODIFY,DELETE,READ,MOVE",." So, if I grant you CREATE access you can create an entire VAGENDA heirarchy. The file system analogy would be like giving you the ability to create new subdirectories. I don't think MOVE would provide you with the same ability. At the moment I think MODIFY is underspecified in this case. I suspect most people would think that MODIFY would give you this ability as well. Is that what we want? -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Steve Mansour Sent: Tuesday, December 11, 2001 5:04 PM To: CalSched IETF Subject: VCAR question Does "write" permission to a VAGENDA give you the right to move another VAGENDA into it? -Steve From owner-ietf-calendar@mail.imc.org Tue Dec 11 19:48:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28768 for ; Tue, 11 Dec 2001 19:48:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC0ZmA00721 for ietf-calendar-bks; Tue, 11 Dec 2001 16:35:48 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC0Zb200714 for ; Tue, 11 Dec 2001 16:35:37 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA25034; Tue, 11 Dec 2001 19:35:35 -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 TAA04278; Tue, 11 Dec 2001 19:30:25 -0500 (EST) Received: from monalisa (114-201-131-12.bellhead.com [12.131.201.114]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id TAA25123; Tue, 11 Dec 2001 19:30:24 -0500 (EST) From: "Paul B. Hill" To: "Shannon J. Clark" , "John Stracke" , "CalSched IETF" Subject: RE: VCAR question Date: Tue, 11 Dec 2001 19:30:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal 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 >...Can a VAGENDA contain a VCAR? If so then isn't having "write" permission to >a VAGENDA with the ability to move another VAGENDA into it the same has >having full rights since you could create VCARS? Or am I missing something? A VAGENDA can contain most things, so at first glance, having the ability to move another VAGENDA into an existing one, or create a new sub-VAGENDA, feels like having full rights, it might not be. If our access control model is changed to: 1) default access is grant 2) inheritence evaluation starts at the root and you work your way down 3) evaluation stops when an explicit DENY is reached Then you could give someone CREATE or MODIFY access on a VAGENDA to someone and use other VCARS to still limit what could be done in the "sub" VAGENDAs introduced by the user. Paul From owner-ietf-calendar@mail.imc.org Tue Dec 11 19:55:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28954 for ; Tue, 11 Dec 2001 19:55:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC0geG01239 for ietf-calendar-bks; Tue, 11 Dec 2001 16:42:40 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC0gd201232 for ; Tue, 11 Dec 2001 16:42:39 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA26687; Tue, 11 Dec 2001 19:42:39 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA06502; Tue, 11 Dec 2001 19:40:29 -0500 (EST) Received: from monalisa (114-201-131-12.bellhead.com [12.131.201.114]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id TAA26881; Tue, 11 Dec 2001 19:40:27 -0500 (EST) From: "Paul B. Hill" To: "tipjar LLC" , Subject: RE: bearer certificates and VCARs and draft 6, oh my Date: Tue, 11 Dec 2001 19:40:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200112112312.fBBNCj455522@tipjar.com> Importance: Normal 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 I disagree. First, certificates have nothing to do with the issue. Certificates are simply one mechanism of providing an authentication. Suppose a VCAR says something like, "GRANT:UPN=library-patron@example.com;ACTION=*;OBJECT=*;VALUE=*;" Now you might authenticate using BEEP TLS profile, using an X.509 certificate that doesn't contain your username but instead asserts that you are "library-patron@example.com". But soley relying on certificates to do something like this is pretty limiting. Suppose that instead you authenticate using the SASL profile and you are able to authenticate as David Nicol, but use a SASL authorization ID of library-patron@example.com. That will also work. I feel that the methods described in CAP are much more flexible than your suggestion and we are enabling the underlying requirements that you are looking for. Paul -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of tipjar LLC Sent: Tuesday, December 11, 2001 6:13 PM To: ietf-calendar@mail.imc.org Subject: bearer certificates and VCARs and draft 6, oh my The feature I've been scouring all drafts for, which is the ability to designate a role without specifying who you are designating, is again missing. The section on the VCAR in draft six even places the association of the VCAR to the CU (rather than the session) in the MUST category: VCARs MUST be specifically granted to an authenticated CU. If the protocol is to support rights given to a session based on presentation within the session of some kind of certificate which would cause the session to gain that right, we might need to add "or session" to 2.4.2 summary. It also appears in 2.4.4 that the identify command remains, contrary to rumour of its demise (yes, I am looking at draft 6). I think that a suggested syntax involving the identify command would be a good choice for the question of how one would present a bearer authorization certificate to have additional VCARs added to the current session, should the committee approve of the concept. -- Tipjar Administrator and general stone in your shoe, David Nicol From owner-ietf-calendar@mail.imc.org Tue Dec 11 19:56:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28970 for ; Tue, 11 Dec 2001 19:56:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC0hnD01410 for ietf-calendar-bks; Tue, 11 Dec 2001 16:43:49 -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 fBC0hm201404 for ; Tue, 11 Dec 2001 16:43:48 -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 fBC0hjx02017 for ; Tue, 11 Dec 2001 16:43:45 -0800 (PST) Received: from netscape.com ([205.217.229.138]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO7GOX00.3UP for ; Tue, 11 Dec 2001 16:43:45 -0800 Message-ID: <3C16A843.5EAA5F59@netscape.com> Date: Tue, 11 Dec 2001 16:43:47 -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: Question on calstore current time. Content-Type: multipart/mixed; boundary="------------025B00CA39A9F6685812BD3A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------025B00CA39A9F6685812BD3A Content-Type: multipart/alternative; boundary="------------0777AAF4C411765A862CDE4D" --------------0777AAF4C411765A862CDE4D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All, Ages ago, when we decided it would be a good thing for the calstore to return the current date/time, we came up with this: Property Name Rqd Type Description CURRENT_DATETIME Y DATE-TIME Current server time. This is returned as a local time and TZID. We seem to recall that someone had a good reason for returning it as the server's localtime value and a TZID. None of us here at the ietf meeting can remember what that was. If no one can come up with a good reason for this, we would like to change it to return the time in UTC. -Steve --------------0777AAF4C411765A862CDE4D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All,

Ages ago, when we decided it would be a good thing for the calstore to return the current date/time, we came up with this:

Property Name     Rqd  Type        Description
CURRENT_DATETIME  Y    DATE-TIME   Current server time. This is returned as a local
                                   time and TZID.
We seem to recall that someone had a good reason for returning it as the server's localtime value and a TZID.  None of us here at the ietf meeting can remember what that was.

If no one can come up with a good reason for this, we would like to change it to return the time in UTC.

-Steve --------------0777AAF4C411765A862CDE4D-- --------------025B00CA39A9F6685812BD3A 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------025B00CA39A9F6685812BD3A-- From owner-ietf-calendar@mail.imc.org Tue Dec 11 20:15:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29373 for ; Tue, 11 Dec 2001 20:15:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC13ah03086 for ietf-calendar-bks; Tue, 11 Dec 2001 17:03:36 -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 fBC13Y203082 for ; Tue, 11 Dec 2001 17:03:34 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA05513; Tue, 11 Dec 2001 18:59:49 -0600 From: "Shannon J. Clark" To: "Paul B. Hill" , "John Stracke" , "CalSched IETF" Subject: RE: VCAR question Date: Tue, 11 Dec 2001 19:03:34 -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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul, Hmmm this raises another question - what does a "VCAR" apply to? i.e. does it apply to a PARTICULAR object - i.e. specified by a UID? - to a particular type of object? (all VEVENTS?) - to a particular "user" for all objects? (this raises the serious question of "what is a user?" - to some other means of specifying objects? I guess what I am asking is how in a multi-level VAGENDA environment, where each VAGENDA can contain VCALENDARS with other objects - do these VCARs in practice work? Shannon (note - CAP is not my area of greatest expertise - so apologies in advance if this is dealt with in draft 6 of CAP) -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Paul B. Hill Sent: Tuesday, December 11, 2001 6:30 PM To: Shannon J. Clark; John Stracke; CalSched IETF Subject: RE: VCAR question >...Can a VAGENDA contain a VCAR? If so then isn't having "write" permission to >a VAGENDA with the ability to move another VAGENDA into it the same has >having full rights since you could create VCARS? Or am I missing something? A VAGENDA can contain most things, so at first glance, having the ability to move another VAGENDA into an existing one, or create a new sub-VAGENDA, feels like having full rights, it might not be. If our access control model is changed to: 1) default access is grant 2) inheritence evaluation starts at the root and you work your way down 3) evaluation stops when an explicit DENY is reached Then you could give someone CREATE or MODIFY access on a VAGENDA to someone and use other VCARS to still limit what could be done in the "sub" VAGENDAs introduced by the user. Paul From owner-ietf-calendar@mail.imc.org Tue Dec 11 20:21:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29503 for ; Tue, 11 Dec 2001 20:21:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC1AaW03345 for ietf-calendar-bks; Tue, 11 Dec 2001 17:10:36 -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 fBC1AY203341 for ; Tue, 11 Dec 2001 17:10:34 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id TAA05530; Tue, 11 Dec 2001 19:06:42 -0600 From: "Shannon J. Clark" To: "Steve Mansour" , "CalSched IETF" Subject: RE: Question on calstore current time. Date: Tue, 11 Dec 2001 19:10:27 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C18277.7EA44B20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3C16A843.5EAA5F59@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C18277.7EA44B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Well the one reason I could initially think of would be as follows: Say you have a server dealing with a number of events and actions (such as VALARMS) and your CUA needs to provide an answer to you about when your SERVER will take a particular action. Just knowing what "time" in UTC that the server thinks it is (which should also be covered to some degree by the Internet Time protocols???) only tells you if the server is off in terms of minutes and seconds - it doesn't tell you what "timezone/local" the server itself is working in. An alternative would be to say that servers should ALWAYS work in UTC, but in general servers will be machines that are probably configured for a particular locale - including for a particular timezone. It might be clearer if there were TWO separate actions that a calstore could return - one indicating what the SERVER's locale/default timezone etc were, and a second for time sync questions? (and/or some indications about how to formally do timesync stuff?) This will be a major concern when you are dealing with SYNC issues between two calstores (such as a local calstore and a server calstore) - the two servers need to know how to order timestamps - if ALL timestamps were done in UTC this is not a major problem - just one of detecting if the two system's clocks are in synch or not, but if objects are timestamped in a server/application specific local time then ordering them is dependant on resolving Timezone issues. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Steve Mansour Sent: Tuesday, December 11, 2001 6:44 PM To: CalSched IETF Subject: Question on calstore current time. Hey All, Ages ago, when we decided it would be a good thing for the calstore to return the current date/time, we came up with this: Property Name Rqd Type Description CURRENT_DATETIME Y DATE-TIME Current server time. This is returned as a local time and TZID. We seem to recall that someone had a good reason for returning it as the server's localtime value and a TZID. None of us here at the ietf meeting can remember what that was. If no one can come up with a good reason for this, we would like to change it to return the time in UTC. -Steve ------=_NextPart_000_0004_01C18277.7EA44B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well = the one reason=20 I could initially think of would be as follows:
 
Say = you have a=20 server dealing with a number of events and actions (such as VALARMS) and = your=20 CUA needs to provide an answer to you about when your SERVER will take a = particular action.
 
Just = knowing what=20 "time" in UTC that the server thinks it is (which should also be covered = to some=20 degree by the Internet Time protocols???) only tells you if the server = is off in=20 terms of minutes and seconds - it doesn't tell you what "timezone/local" = the=20 server itself is working in.
 
An = alternative would=20 be to say that servers should ALWAYS work in UTC, but in general servers = will be=20 machines that are probably configured for a particular locale - = including for a=20 particular timezone.
 
It = might be clearer=20 if there were TWO separate actions that a calstore could return - one = indicating=20 what the SERVER's locale/default timezone etc were, and a second for = time sync=20 questions? (and/or some indications about how to formally do timesync=20 stuff?)
 
This = will be a major=20 concern when you are dealing with SYNC issues between two calstores = (such as a=20 local calstore and a server calstore) - the two servers need to know how = to=20 order timestamps - if ALL timestamps were done in UTC this is not a = major=20 problem - just one of detecting if the two system's clocks are in synch = or not,=20 but if objects are timestamped in a server/application specific local = time then=20 ordering them is dependant on resolving Timezone = issues.
 
Shannon
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Steve=20 Mansour
Sent: Tuesday, December 11, 2001 6:44 = PM
To:=20 CalSched IETF
Subject: Question on calstore current=20 time.

Hey All,=20

Ages ago, when we decided it would be a good thing for the calstore = to=20 return the current date/time, we came up with this:=20

Property Name     Rqd =20 Type        Description=20
CURRENT_DATETIME  Y    = DATE-TIME  =20 Current server time. This is returned as a local=20 =
           = ;            =            =20 time and TZID.
We seem to recall that someone had a = good=20 reason for returning it as the server's localtime value and a = TZID.  None=20 of us here at the ietf meeting can remember what that was.=20

If no one can come up with a good reason for this, we would like to = change=20 it to return the time in UTC.=20

-Steve

------=_NextPart_000_0004_01C18277.7EA44B20-- From owner-ietf-calendar@mail.imc.org Tue Dec 11 21:53:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01832 for ; Tue, 11 Dec 2001 21:53:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC2e7N07839 for ietf-calendar-bks; Tue, 11 Dec 2001 18:40:07 -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 fBC2e5207835 for ; Tue, 11 Dec 2001 18:40:05 -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 fBC2e2x01523 for ; Tue, 11 Dec 2001 18:40:02 -0800 (PST) Received: from netscape.com ([205.217.229.135]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO7M2R00.EZ8; Tue, 11 Dec 2001 18:40:03 -0800 Message-ID: <3C16C384.E07BF09@netscape.com> Date: Tue, 11 Dec 2001 18:40:05 -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: "Paul B. Hill" CC: CalSched IETF Subject: Re: VCAR question References: Content-Type: multipart/mixed; boundary="------------FED3547E538A3FEA567CB253" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FED3547E538A3FEA567CB253 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > Hi, > There is no "write" VCAR action or permission... And by "write", of course, I meant "CREATE" :-) > From cal-updates: > > ... > So, if I grant you CREATE access you can create an entire VAGENDA heirarchy. > The file system analogy would be like giving you the ability to create new > subdirectories. > > I don't think MOVE would provide you with the same ability. why not? Following your file system analogy, I can move a file into a directory to which I have write access. > At the moment I think MODIFY is underspecified in this case. I suspect most > people would think that MODIFY would give you this ability as well. Is that > what we want? so, you're modifying the CHILDREN property of a calendar? OK this works for me. How do others feel about this? -Steve --------------FED3547E538A3FEA567CB253 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------FED3547E538A3FEA567CB253-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 01:29:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08356 for ; Wed, 12 Dec 2001 01:29:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBC6DUg14804 for ietf-calendar-bks; Tue, 11 Dec 2001 22:13:30 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC6DS214793 for ; Tue, 11 Dec 2001 22:13:28 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.65]) by royer.com (8.9.1/8.9.1) with ESMTP id WAA10728 for ; Tue, 11 Dec 2001 22:13:20 -0800 (PST) Message-ID: <3C16F534.5FCB6280@Royer.com> Date: Tue, 11 Dec 2001 23:12:04 -0700 From: Doug Royer Reply-To: ietf-calendar@mail.imc.or Organization: INET-Consulting 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@mail.imc.org" Subject: Re: bearer certificates and VCARs and draft 6, oh my References: <200112112312.fBBNCj455522@tipjar.com> Content-Type: multipart/mixed; boundary="------------909760D405AFD51A80AA786A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------909760D405AFD51A80AA786A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit tipjar LLC wrote: > > The feature I've been scouring all drafts for, which is the > ability to designate a role without specifying who you are > designating, is again missing. The section on the VCAR in draft > six even places the association of the VCAR to the CU (rather than > the session) in the MUST category: > > VCARs MUST be specifically granted to an authenticated CU. > > If the protocol is to support rights given to a session based on > presentation within the session of some kind of certificate which > would cause the session to gain that right, we might need to > add "or session" to 2.4.2 summary. The 'certificate' has some name, hostname, or some unique (to CAP) ID associated with it. A CU does not have to be a person. A CU is *anything* that uses CAP. > It also appears in 2.4.4 that the identify command remains, contrary > to rumour of its demise (yes, I am looking at draft 6). I think > that a suggested syntax involving the identify command would be > a good choice for the question of how one would present a bearer > authorization certificate to have additional VCARs added to the > current session, should the committee approve of the concept. I don't recall certificate's being discussed in the requirements doc. And 'identify' is for changing ID, not adding (2.4.4). --------------909760D405AFD51A80AA786A 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 12 Dec 2001 01:32:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBC6KL015005 for ietf-calendar-bks; Tue, 11 Dec 2001 22:20:21 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC6KK215001 for ; Tue, 11 Dec 2001 22:20:20 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.65]) by royer.com (8.9.1/8.9.1) with ESMTP id WAA10796 for ; Tue, 11 Dec 2001 22:20:22 -0800 (PST) Message-ID: <3C16F6DA.23A9F548@Royer.com> Date: Tue, 11 Dec 2001 23:19:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@mail.imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: VCAR question References: Content-Type: multipart/mixed; boundary="------------0787FE9A6336D9853E1A4FAB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0787FE9A6336D9853E1A4FAB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > > >...Can a VAGENDA contain a VCAR? If so then isn't having "write" permission > to > >a VAGENDA with the ability to move another VAGENDA into it the same has > >having full rights since you could create VCARS? Or am I missing > something? > > A VAGENDA can contain most things, so at first glance, having the ability to > move another VAGENDA into an existing one, or create a new sub-VAGENDA, > feels like having full rights, it might not be. > > If our access control model is changed to: > 1) default access is grant I thought the security guru's did not like (1). > 2) inheritence evaluation starts at the root and you work your way down That is the way it is now. > 3) evaluation stops when an explicit DENY is reached > > Then you could give someone CREATE or MODIFY access on a VAGENDA to someone > and use other VCARS to still limit what could be done in the "sub" VAGENDAs > introduced by the user. With a VCAR (as it is now - default is DENY), you can not create without permission. So if you don't want to give permission to create new objects, then don't give permission to create those objects. I can't see the difference. If you do not have a: GRANT ... OBJECT=VAGENDA ... then, you can;t do it now. --------------0787FE9A6336D9853E1A4FAB 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 12 Dec 2001 01:41:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC6UJU15218 for ietf-calendar-bks; Tue, 11 Dec 2001 22:30:19 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC6UI215214 for ; Tue, 11 Dec 2001 22:30:18 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.65]) by royer.com (8.9.1/8.9.1) with ESMTP id WAA10934 for ; Tue, 11 Dec 2001 22:30:21 -0800 (PST) Message-ID: <3C16F931.95B3E3EA@Royer.com> Date: Tue, 11 Dec 2001 23:29:05 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting 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@mail.imc.org" Subject: Re: Question on calstore current time. References: <3C16A843.5EAA5F59@netscape.com> Content-Type: multipart/mixed; boundary="------------18C7D1D2C2EBFF6F200D7EA5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------18C7D1D2C2EBFF6F200D7EA5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > Hey All, > > Ages ago, when we decided it would be a good thing for the calstore to > return the current date/time, we came up with this: > > Property Name Rqd Type Description > CURRENT_DATETIME Y DATE-TIME Current server time. This > is returned as a local > time and TZID. > > We seem to recall that someone had a good reason for returning it as > the server's localtime value and a TZID. None of us here at the ietf > meeting can remember what that was. It was for small devices that are stupid outside of CAP. Why not just have date-time returned in the capability? Also the TZ was the Calendar Properties TZID. I would not argue if date-time went away. Lets keep TZID so the CUA can 'know' the TZ of the CS or calendar. So that a CUA will know when it finds components without any TZ (localtime) what the localtime is when it sees 10pm. > If no one can come up with a good reason for this, we would like to > change it to return the time in UTC. That;s fine with me. Lets keep the Calendar - property TZID --------------18C7D1D2C2EBFF6F200D7EA5 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 12 Dec 2001 01:51:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC6boB15395 for ietf-calendar-bks; Tue, 11 Dec 2001 22:37:50 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC6bn215391 for ; Tue, 11 Dec 2001 22:37:49 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.65]) by royer.com (8.9.1/8.9.1) with ESMTP id WAA11066 for ; Tue, 11 Dec 2001 22:37:51 -0800 (PST) Message-ID: <3C16FAF3.7A72658E@Royer.com> Date: Tue, 11 Dec 2001 23:36:35 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting 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@mail.imc.org" Subject: Re: VCAR question References: Content-Type: multipart/mixed; boundary="------------E203DE6CD3262E370697A8B0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E203DE6CD3262E370697A8B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Paul, > > Hmmm this raises another question - what does a "VCAR" apply to? To the constrains in the VCAR, by METHOD, component, property, parameters, and property values, as applies to the named UPN's in the VCAR and constrained to the scope and below by inheritance and where it is placed in the CS (CS, VAGENDA, Calendar, ...). > i.e. does it apply to a PARTICULAR object - i.e. specified by a UID? It can. > - to a particular type of object? (all VEVENTS?) It can. > - to a particular "user" for all objects? (this raises the serious question of "what is a user?" It can apply to UPN's. > - to some other means of specifying objects? I don't understand that question. > I guess what I am asking is how in a multi-level VAGENDA environment, > where each VAGENDA can contain VCALENDARS with other objects - do > these VCARs in practice work? Big question. ACL's of any kind are a pain. In calendaring with the ability to not only share objects, but to share specific parts of objects, any ACL is going to be complex. --------------E203DE6CD3262E370697A8B0 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 12 Dec 2001 02:01:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC6n8815684 for ietf-calendar-bks; Tue, 11 Dec 2001 22:49:08 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC6n7215680 for ; Tue, 11 Dec 2001 22:49:07 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.65]) by royer.com (8.9.1/8.9.1) with ESMTP id WAA11218 for ; Tue, 11 Dec 2001 22:49:09 -0800 (PST) Message-ID: <3C16FD99.D6649D2E@Royer.com> Date: Tue, 11 Dec 2001 23:47:53 -0700 From: Doug Royer Reply-To: "ietf-calendar@mail.imc.org" Organization: INET-Consulting 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@mail.imc.org" Subject: RE: Question on calstore current time Content-Type: multipart/mixed; boundary="------------916A114EC5BC4E64E7C9FBD0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------916A114EC5BC4E64E7C9FBD0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > An alternative would be to say that servers should ALWAYS work in UTC, Yes, but it is nice to know that Mr. Fu is in China and he probably wont want to have a phone meeting with you in the middle of his night. Which is why TZID is a calendar property. And each calendar in a CS can be in a different TZ. And I agree - UTC + TZ is better than local time + TZ. -Doug --------------916A114EC5BC4E64E7C9FBD0 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 12 Dec 2001 02:13:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC6xPe15945 for ietf-calendar-bks; Tue, 11 Dec 2001 22:59:25 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC6xO215941 for ; Tue, 11 Dec 2001 22:59:24 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.65]) by royer.com (8.9.1/8.9.1) with ESMTP id WAA11361 for ; Tue, 11 Dec 2001 22:59:26 -0800 (PST) Message-ID: <3C170002.65487775@Royer.com> Date: Tue, 11 Dec 2001 23:58:10 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting 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@mail.imc.org" Subject: Re: VCAR question References: <3C16C384.E07BF09@netscape.com> Content-Type: multipart/mixed; boundary="------------B018BE41A6C3A541AF72A864" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B018BE41A6C3A541AF72A864 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > "Paul B. Hill" wrote: > > > Hi, > > There is no "write" VCAR action or permission... > > And by "write", of course, I meant "CREATE" :-) > > > From cal-updates: > > > > ... > > So, if I grant you CREATE access you can create an entire VAGENDA > > heirarchy. The file system analogy would be like giving you the > > ability to create new subdirectories. > > > > I don't think MOVE would provide you with the same ability. > > why not? Following your file system analogy, I can move a file > into a directory to which I have write access. In CAP - GRANT is not a blanket GRANT to all objects. You have to GRANT something. When we invented the VCAR in Orlando, VAGENDA did not exist. But it can fit into the model: DENY:UPN=xxx;...OBJECT=VAGENDR.... or DENY:UPN=yyy:...OBJECT=VCALENDAR... or GRANT:UPN=xxx;...OBJECT=VAGENDR.... or GRANT:UPN=yyy:...OBJECT=VCALENDAR... > > > At the moment I think MODIFY is underspecified in this case. > > I suspect most people would think that MODIFY would give you > > this ability as well. Is that what we want? MODIFY is for modifying objects or entries in objects. As you can not specify two targets in MODIFY, it can't be used for that. > so, you're modifying the CHILDREN property of a calendar? OK this works for > me. How do others feel about this? That will not work as you have to also MODIFY the parent of the other. Moving a calendar was discussed on this list just a month or so ago, I thought everyone wanted it to be a MOVE (not MODIFY) command. In fact that is one of the issues I have with 06 - the MODIFY command changed without any WG list discussion. And MOVE was updated to allow moving calendars. --------------B018BE41A6C3A541AF72A864 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 12 Dec 2001 03:58:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBC8ihZ02964 for ietf-calendar-bks; Wed, 12 Dec 2001 00:44:43 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC8if202958 for ; Wed, 12 Dec 2001 00:44:41 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.65]) by royer.com (8.9.1/8.9.1) with ESMTP id AAA12863 for ; Wed, 12 Dec 2001 00:44:38 -0800 (PST) Message-ID: <3C1718A7.C9759B57@Royer.com> Date: Wed, 12 Dec 2001 01:43:19 -0700 From: Doug Royer Reply-To: "ietf-calendar@mail.imc.org" Organization: INET-Consulting 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@mail.imc.org" Subject: Re: CAP Draft 6 comments References: <3C167F57.AEAC1FA8@netscape.com> Content-Type: multipart/mixed; boundary="------------492991F3EE4BF7AD6139E494" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------492991F3EE4BF7AD6139E494 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > 4. Section 2.4.4 we mention trusted server relationships. We should > mention explicitly that this is out of the scope of [CAP] Yes > 5. Section 2.6 - we mention "printable 7 bit ASCII characters". Is > this sufficiently explicit? Should we list the character value > range? Yes, I can print lots of printable form feeds :-) > 7. Section 4.1.2 Use 'DTSTART <= ...' -- the two strings look > identical. I think it's a typo... or is it? Yes - The formating/grouping is also incorrect: Is: Use 'VEVENT,VTODO', not 'VEVENT, VTODO' Use 'DTSTART <= 20000605T131313Z', not 'DTSTART <= 20000605T131313Z'. Use ' AND ' and ' OR ', not 'AND' and not 'OR'. Should Be: Use 'VEVENT,VTODO', not 'VEVENT, VTODO' Use 'DTSTART <= 20000605T131313Z', not: 'DTSTART<= 20000605T131313Z'. Use ' AND ' and ' OR ', not 'AND' and not 'OR'. > 9. Section 4.1.6 versus 4.1.8 -- the value for METHOD. In some > places, we refer to the METHOD value for "booked" events as NULL, > and in other places we refer to it as CREATED. I happen to > prefer being explicit and keeping it at CREATED, but whatever we > choose we must be consistent. I agree - lets keep it 'CREATE' (same as METHOD:CREATE) not CREATEd. > 10. Section 4.1.6 -- I thought we decided that we need a METHOD state > for a CANCELled event or a DELETEd event. This is important for > several reasons. One was mentioned in the draft, another is that > it's important for synchronization applications to determine > which events have been deleted. If we use the METHOD property to > mark cancelled / deleted events, then the query needs to be > fixed. Yes - I think the discussion took place as the changes were made. I think that a hard working person edited too much :-) Without the ability to tag objects as CANCELed and DELETEd, things will bust - for synchronization. > 12. We need to close on the iCalendar version we're going to require > for CAP. In the current draft we specify that we require VERSION > 2.0 and VERSION 2.1. Let's pick one :-) (A) We are NOT upgrading the format. Why would we update the iCalendar Version. (B) Lets not wait for iCal-V-next. > 14. Section 6.2.4.2. Regarding the editors note - my recommendation > is that the way to delete a VALARM is to modify or delete the > component that contains it. The delete command should apply to > the VTIMEZONES that exist at the calstore level. I don't think > components like VEVENTS can contain VTIMEZONE components, I think > they only reference VTIMEZONE components that exist at the > calstore level. In Chicago timefraime, I thought we agreed that the MODIFY only has to list what makes something unique. So if you list the *entire* alarm in the 'is' section, and not in the 'change to' section - it gets deleted. And I would like to extend that idea for binary inline attachments to say: When deleting inline binary attachments with METHOD:MOVE: Only sufficient octets to uniquely identify the attachment MAY BE sent. It is not necessary to send the entire contents of the inline attachment. And add: When using the MODIFY command, the property values for inline attachments can only be updated, deleted, or added. You can not modify part if a inline binary attachment. > 15. Section 6.2.4.3. Are there sequencing (ordering) issues? are > removes always processed before updates? does it matter? I don't see how it can matter. > 17. Section 6.2.4.4. "CS MUST ensure that VCARs are still valid after > the move" seems pretty nebulous to me. I think the issue is the > following: given that VCARs are hierarchic, moving a calendar > from one location in the hierarchy to another could possibly > change the access control considerably and yield unexpected and > unwanted results. I think what we want to do is make sure that > the access control is at least as restrictive (and possibly more > restrictive) than it was prior to the move. Note that with > hierarchic VCARs the way they are defined now, it may not be > possible to provide exactly the same access to a calendar as > prior to the move -- something further up the new hierarchy may > be more restrictive. Also, there are ownership issues. Is there > something we want to say about the ownership of the new parent > calendar(s) given the owners of the previous parent calendars? > (this problem is pointed out in the editors note). Last point first. - if you have the VCAR for it :-), you should be able to move it. I agree with the VCAR issues you point out. It's hard to say what is more restrictive, adding access you did not want, or no longer having access denied. The only way to do this would be to allow only moves to top level calendars - where they can control all of their own VCARs. And as that would be a kludge, should we drop the ability to move calendars? > 19. Section 6.2.4.5, just past the last example we show this query: > QUERY: SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com' CALSTORE > is being used as a special keyword here. We should probably list > this somewhere or find another way to do the query. In addition (reminder) we need to add back the VCAR and other text back into CAP - and add CALSTORE and VSCHEDULE to the VCAR and VQUERY ABNF - (if not already there). > 20. Section 6.3.3.1 was the Organizer intentionally left out of the > ATTENDEE list? Seems like the organizer should be in the > attendee list. The ORGANIZER does not have to be in the ATTENDEE list. I'll organize it - you do the work :-) --------------492991F3EE4BF7AD6139E494 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 12 Dec 2001 11:45:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCGVAh16565 for ietf-calendar-bks; Wed, 12 Dec 2001 08:31:10 -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 fBCGV8216556 for ; Wed, 12 Dec 2001 08:31:08 -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 fBCGV2Y15062 for ; Wed, 12 Dec 2001 08:31:02 -0800 (PST) Received: from netscape.com ([205.217.229.142]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO8OJR00.R8X; Wed, 12 Dec 2001 08:31:03 -0800 Message-ID: <3C178646.30EEC5A7@netscape.com> Date: Wed, 12 Dec 2001 08:31:03 -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 CC: "ietf-calendar@mail.imc.org" Subject: Re: VCAR question References: <3C16C384.E07BF09@netscape.com> <3C170002.65487775@Royer.com> Content-Type: multipart/mixed; boundary="------------59EFD609B2B0B3D50634E23F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------59EFD609B2B0B3D50634E23F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > > "Paul B. Hill" wrote: > > > > > Hi, > > > There is no "write" VCAR action or permission... > > > > And by "write", of course, I meant "CREATE" :-) > > > > > From cal-updates: > > > > > > ... > > > So, if I grant you CREATE access you can create an entire VAGENDA > > > heirarchy. The file system analogy would be like giving you the > > > ability to create new subdirectories. > > > > > > I don't think MOVE would provide you with the same ability. > > > > why not? Following your file system analogy, I can move a file > > into a directory to which I have write access. > > In CAP - GRANT is not a blanket GRANT to all objects. > You have to GRANT something. When we invented the VCAR in Orlando, > VAGENDA did not exist. But it can fit into the model: > > DENY:UPN=xxx;...OBJECT=VAGENDR.... > or > DENY:UPN=yyy:...OBJECT=VCALENDAR... > > or > GRANT:UPN=xxx;...OBJECT=VAGENDR.... > or > GRANT:UPN=yyy:...OBJECT=VCALENDAR... > > > > > > At the moment I think MODIFY is underspecified in this case. > > > I suspect most people would think that MODIFY would give you > > > this ability as well. Is that what we want? > > MODIFY is for modifying objects or entries in objects. > As you can not specify two targets in MODIFY, it can't be used > for that. > > > so, you're modifying the CHILDREN property of a calendar? OK this works for > > me. How do others feel about this? > > That will not work as you have to also MODIFY the parent of the other. wait... that should work fine. The person that's moving the calendar is most likely the owner > Moving a calendar was discussed on this list just a month or so > ago, I thought everyone wanted it to be a MOVE (not MODIFY) command. > In fact that is one of the issues I have with 06 - the MODIFY command > changed without any WG list discussion. hmm... I think we're not connecting here. We all want the MOVE command. We're just looking at what VCAR(s) are necessary to accomplish the move. > And MOVE was updated to allow moving calendars. yep. -Steve --------------59EFD609B2B0B3D50634E23F 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------59EFD609B2B0B3D50634E23F-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 11:52:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13140 for ; Wed, 12 Dec 2001 11:52:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCGRmV16369 for ietf-calendar-bks; Wed, 12 Dec 2001 08:27:48 -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 fBCGRj216358 for ; Wed, 12 Dec 2001 08:27:45 -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 fBCGRex25825 for ; Wed, 12 Dec 2001 08:27:40 -0800 (PST) Received: from netscape.com ([205.217.229.142]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO8OE300.U8Y; Wed, 12 Dec 2001 08:27:39 -0800 Message-ID: <3C17857B.A751C23A@netscape.com> Date: Wed, 12 Dec 2001 08:27:39 -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 CC: "ietf-calendar@mail.imc.org" Subject: Re: Question on calstore current time. References: <3C16A843.5EAA5F59@netscape.com> <3C16F931.95B3E3EA@Royer.com> Content-Type: multipart/mixed; boundary="------------C416DA7FB813623B37092D03" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C416DA7FB813623B37092D03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > > Hey All, > > > > Ages ago, when we decided it would be a good thing for the calstore to > > return the current date/time, we came up with this: > > > > Property Name Rqd Type Description > > CURRENT_DATETIME Y DATE-TIME Current server time. This > > is returned as a local > > time and TZID. > > > > We seem to recall that someone had a good reason for returning it as > > the server's localtime value and a TZID. None of us here at the ietf > > meeting can remember what that was. > > It was for small devices that are stupid outside of CAP. OK. That sounds familiar. Can you explain it further. I still don't get it. > Why not just have date-time returned in the capability? I believe it is returned in the capability. > Also the TZ was the Calendar Properties TZID. > > I would not argue if date-time went away. > > Lets keep TZID so the CUA can 'know' the TZ of the CS or calendar. > So that a CUA will know when it finds components without > any TZ (localtime) what the localtime is when it sees 10pm. > > > If no one can come up with a good reason for this, we would like to > > change it to return the time in UTC. > > That;s fine with me. Lets keep the Calendar - property TZID Sounds good. -Steve --------------C416DA7FB813623B37092D03 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------C416DA7FB813623B37092D03-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 11:55:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13192 for ; Wed, 12 Dec 2001 11:55:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCGRmV16368 for ietf-calendar-bks; Wed, 12 Dec 2001 08:27:48 -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 fBCGRj216360 for ; Wed, 12 Dec 2001 08:27:45 -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 fBCGRex25826 for ; Wed, 12 Dec 2001 08:27:41 -0800 (PST) Received: from netscape.com ([205.217.229.142]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO8OE300.U8Y; Wed, 12 Dec 2001 08:27:39 -0800 Message-ID: <3C17857B.A751C23A@netscape.com> Date: Wed, 12 Dec 2001 08:27:39 -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 CC: "ietf-calendar@mail.imc.org" Subject: Re: Question on calstore current time. References: <3C16A843.5EAA5F59@netscape.com> <3C16F931.95B3E3EA@Royer.com> Content-Type: multipart/mixed; boundary="------------C416DA7FB813623B37092D03" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C416DA7FB813623B37092D03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > > Hey All, > > > > Ages ago, when we decided it would be a good thing for the calstore to > > return the current date/time, we came up with this: > > > > Property Name Rqd Type Description > > CURRENT_DATETIME Y DATE-TIME Current server time. This > > is returned as a local > > time and TZID. > > > > We seem to recall that someone had a good reason for returning it as > > the server's localtime value and a TZID. None of us here at the ietf > > meeting can remember what that was. > > It was for small devices that are stupid outside of CAP. OK. That sounds familiar. Can you explain it further. I still don't get it. > Why not just have date-time returned in the capability? I believe it is returned in the capability. > Also the TZ was the Calendar Properties TZID. > > I would not argue if date-time went away. > > Lets keep TZID so the CUA can 'know' the TZ of the CS or calendar. > So that a CUA will know when it finds components without > any TZ (localtime) what the localtime is when it sees 10pm. > > > If no one can come up with a good reason for this, we would like to > > change it to return the time in UTC. > > That;s fine with me. Lets keep the Calendar - property TZID Sounds good. -Steve --------------C416DA7FB813623B37092D03 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------C416DA7FB813623B37092D03-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 12:05:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13362 for ; Wed, 12 Dec 2001 12:05:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCGVAE16566 for ietf-calendar-bks; Wed, 12 Dec 2001 08:31:10 -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 fBCGV8216558 for ; Wed, 12 Dec 2001 08:31:08 -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 fBCGV2Y15065 for ; Wed, 12 Dec 2001 08:31:02 -0800 (PST) Received: from netscape.com ([205.217.229.142]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO8OJR00.R8X; Wed, 12 Dec 2001 08:31:03 -0800 Message-ID: <3C178646.30EEC5A7@netscape.com> Date: Wed, 12 Dec 2001 08:31:03 -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 CC: "ietf-calendar@mail.imc.org" Subject: Re: VCAR question References: <3C16C384.E07BF09@netscape.com> <3C170002.65487775@Royer.com> Content-Type: multipart/mixed; boundary="------------59EFD609B2B0B3D50634E23F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------59EFD609B2B0B3D50634E23F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > > "Paul B. Hill" wrote: > > > > > Hi, > > > There is no "write" VCAR action or permission... > > > > And by "write", of course, I meant "CREATE" :-) > > > > > From cal-updates: > > > > > > ... > > > So, if I grant you CREATE access you can create an entire VAGENDA > > > heirarchy. The file system analogy would be like giving you the > > > ability to create new subdirectories. > > > > > > I don't think MOVE would provide you with the same ability. > > > > why not? Following your file system analogy, I can move a file > > into a directory to which I have write access. > > In CAP - GRANT is not a blanket GRANT to all objects. > You have to GRANT something. When we invented the VCAR in Orlando, > VAGENDA did not exist. But it can fit into the model: > > DENY:UPN=xxx;...OBJECT=VAGENDR.... > or > DENY:UPN=yyy:...OBJECT=VCALENDAR... > > or > GRANT:UPN=xxx;...OBJECT=VAGENDR.... > or > GRANT:UPN=yyy:...OBJECT=VCALENDAR... > > > > > > At the moment I think MODIFY is underspecified in this case. > > > I suspect most people would think that MODIFY would give you > > > this ability as well. Is that what we want? > > MODIFY is for modifying objects or entries in objects. > As you can not specify two targets in MODIFY, it can't be used > for that. > > > so, you're modifying the CHILDREN property of a calendar? OK this works for > > me. How do others feel about this? > > That will not work as you have to also MODIFY the parent of the other. wait... that should work fine. The person that's moving the calendar is most likely the owner > Moving a calendar was discussed on this list just a month or so > ago, I thought everyone wanted it to be a MOVE (not MODIFY) command. > In fact that is one of the issues I have with 06 - the MODIFY command > changed without any WG list discussion. hmm... I think we're not connecting here. We all want the MOVE command. We're just looking at what VCAR(s) are necessary to accomplish the move. > And MOVE was updated to allow moving calendars. yep. -Steve --------------59EFD609B2B0B3D50634E23F 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------59EFD609B2B0B3D50634E23F-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 12:24:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13622 for ; Wed, 12 Dec 2001 12:24:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCH9Ib19872 for ietf-calendar-bks; Wed, 12 Dec 2001 09:09: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 fBCH9G219864 for ; Wed, 12 Dec 2001 09:09:16 -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 MAA09854 for ; Wed, 12 Dec 2001 12:09:10 -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 fBCH97H28830 for ; Wed, 12 Dec 2001 12:09:07 -0500 (EST) Message-ID: <3C178F5F.1F85AF94@steltor.com> Date: Wed, 12 Dec 2001 12:09: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: VCAR question 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 "Paul B. Hill" wrote: > > Hi, > > There is no "write" VCAR action or permission... > > From cal-updates: > > "The ACTION rule part defines one or more CAP actions that are allowed > for the UPN. The valid values are CREATE, DELETE, MODIFY, MOVE, READ, > and all of the [iTIP] scheduling commands; PUBLISH, REQUEST, REPLY, > ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER, corresponding to the > scheduling commands; and '*', meaning all of calendaring commands and > scheduling commands. Multiple ACTION enumerations can be specified as a > COMMA character (US-ASCII decimal 44) separated list of ACTION > enumerated values. The text '*' is the same as specifying the > enumerated values "CREATE,MODIFY,DELETE,READ,MOVE",." Actually, this paragraph is not in line with the ABNF, which specifies CREATE, MODIFY, DELETE, READ and * as the only valid values for ACTION. By looking at the CARID:REQUESTONLY example, BEGIN:VCAR CARID:REQUESTONLY GRANT:UPN=NONOWNER;ACTION=CREATE;OBJECT=* ;OBJECT=METHOD;VALUE=REQUEST END:VCAR it seems that the original intent was not to use the ACTION rule part to restrict RIGHTS to submitted VCALENDARs with a matching METHOD property, but rather to restrict RIGHTS to the submitted VCALENDARs that will require the specified ACTION to take place. For instance, for a "move" command to succeed a user should have the READ and DELETE ACTION granted for the source calendar (or CS) and the CREATE ACTION granted for the destination calendar (or CS). We shouldn't need a MOVE ACTION. Furthermore, the MODIFY ACTION could probably be eliminated, given that if you can READ and CREATE you can MODIFY. The relationship between the CAP commands (i.e., create, delete, modify, move, search and schedule) and the CAP actions should be clarified. Renaming the ACTION CREATE to WRITE would probably help reducing the confusion. > So, if I grant you CREATE access you can create an entire VAGENDA heirarchy. > The file system analogy would be like giving you the ability to create new > subdirectories. > > I don't think MOVE would provide you with the same ability. > > At the moment I think MODIFY is underspecified in this case. I suspect most > people would think that MODIFY would give you this ability as well. Is that > what we want? > > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Steve Mansour > Sent: Tuesday, December 11, 2001 5:04 PM > To: CalSched IETF > Subject: VCAR question > > Does "write" permission to a VAGENDA give you the right to move another > VAGENDA into it? > -Steve As I said above, only if you have the READ and DELETE ACTION granted for the source calendar (or CS) as well. 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 Dec 12 13:19:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15000 for ; Wed, 12 Dec 2001 13:19:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCI4UF22856 for ietf-calendar-bks; Wed, 12 Dec 2001 10:04:30 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCI4S222847 for ; Wed, 12 Dec 2001 10:04:28 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id NAA07068; Wed Dec 12 13:00:39 2001 Subject: RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Dec 2001 13:07:23 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/12/2001 01:07:24 PM, Serialize complete at 12/12/2001 01:07:24 PM Content-Type: text/plain; charset="us-ascii" To: "CalSched IETF" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Say you have a server dealing with a number of events and actions >(such as VALARMS) and your CUA needs to provide an answer to you >about when your SERVER will take a particular action. > >Just knowing what "time" in UTC that the server thinks it is [...] > only tells you if the server is off in terms of minutes >and seconds - it doesn't tell you what "timezone/local" the server >itself is working in. The server's concept of its own timezone is irrelevant. All that matters is the timezone specified in the VALARM; that tells the server how to convert to/from UTC to render the alarm correctly. I suppose the server's OS could (a) be maintaining its own clock in local time, and (b) have a bug in its timezone conversions, so that it tells the server application the wrong UTC time. However, I don't think we really need to support servers chipped out of flint by Homo erectus. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===============================================================| |"Power corrupts; Powerpoint corrupts absolutely." -- Vint Cerf | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 13:36:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15390 for ; Wed, 12 Dec 2001 13:36:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCINFi24447 for ietf-calendar-bks; Wed, 12 Dec 2001 10:23:15 -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 fBCINE224441 for ; Wed, 12 Dec 2001 10:23:14 -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 fBCINAx15474 for ; Wed, 12 Dec 2001 10:23:10 -0800 (PST) Received: from netscape.com ([205.217.229.238]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO8TQM00.ECE for ; Wed, 12 Dec 2001 10:23:10 -0800 Message-ID: <3C178A55.91A63654@netscape.com> Date: Wed, 12 Dec 2001 08:48:21 -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: "ietf-calendar@mail.imc.org" Subject: Re: CAP Draft 6 comments References: <3C167F57.AEAC1FA8@netscape.com> <3C1718A7.C9759B57@Royer.com> Content-Type: multipart/mixed; boundary="------------B700668A3405EDFF2AFC839F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B700668A3405EDFF2AFC839F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > 4. Section 2.4.4 we mention trusted server relationships. We should > > mention explicitly that this is out of the scope of [CAP] > > Yes OK. This is done. > > 5. Section 2.6 - we mention "printable 7 bit ASCII characters". Is > > this sufficiently explicit? Should we list the character value > > range? > > Yes, I can print lots of printable form feeds :-) Right. Pat has the action item of giving us the exact character set. Alright! > > 7. Section 4.1.2 Use 'DTSTART <= ...' -- the two strings look > > identical. I think it's a typo... or is it? > > Yes - The formating/grouping is also incorrect: > > Is: > Use 'VEVENT,VTODO', not 'VEVENT, VTODO' > Use 'DTSTART <= 20000605T131313Z', not > 'DTSTART <= 20000605T131313Z'. > Use ' AND ' and ' OR ', not 'AND' and not 'OR'. > > Should Be: > > Use 'VEVENT,VTODO', not 'VEVENT, VTODO' > > Use 'DTSTART <= 20000605T131313Z', > not: 'DTSTART<= 20000605T131313Z'. got it. Fixed. > Use ' AND ' and ' OR ', not 'AND' and not 'OR'. > > > 9. Section 4.1.6 versus 4.1.8 -- the value for METHOD. In some > > places, we refer to the METHOD value for "booked" events as NULL, > > and in other places we refer to it as CREATED. I happen to > > prefer being explicit and keeping it at CREATED, but whatever we > > choose we must be consistent. > > I agree - lets keep it 'CREATE' (same as METHOD:CREATE) not CREATEd. We all came to that conclusion. One suggestion was that we use "BOOKED" instead of "CREATED". > > 10. Section 4.1.6 -- I thought we decided that we need a METHOD state > > for a CANCELled event or a DELETEd event. This is important for > > several reasons. One was mentioned in the draft, another is that > > it's important for synchronization applications to determine > > which events have been deleted. If we use the METHOD property to > > mark cancelled / deleted events, then the query needs to be > > fixed. > > Yes - I think the discussion took place as the changes were made. > I think that a hard working person edited too much :-) > Without the ability to tag objects as CANCELed and DELETEd, things > will bust - for synchronization. OK. It we'll make it better. > > 12. We need to close on the iCalendar version we're going to require > > for CAP. In the current draft we specify that we require VERSION > > 2.0 and VERSION 2.1. Let's pick one :-) > > (A) We are NOT upgrading the format. Why would we update the > iCalendar Version. > (B) Lets not wait for iCal-V-next. Version 2.0 it is! > > 14. Section 6.2.4.2. Regarding the editors note - my recommendation > > is that the way to delete a VALARM is to modify or delete the > > component that contains it. The delete command should apply to > > the VTIMEZONES that exist at the calstore level. I don't think > > components like VEVENTS can contain VTIMEZONE components, I think > > they only reference VTIMEZONE components that exist at the > > calstore level. > > In Chicago timefraime, I thought we agreed that the MODIFY > only has to list what makes something unique. So if you list > the *entire* alarm in the 'is' section, and not in the 'change to' > section - it gets deleted. > > And I would like to extend that idea for binary inline > attachments to say: > > When deleting inline binary attachments with METHOD:MOVE: > > Only sufficient octets to uniquely identify the attachment > MAY BE sent. It is not necessary to send the entire contents > of the inline attachment. > > And add: > > When using the MODIFY command, the property values for > inline attachments can only be updated, deleted, or > added. You can not modify part if a inline binary attachment. George, Bruce, others... what do you think of this? > > 15. Section 6.2.4.3. Are there sequencing (ordering) issues? are > > removes always processed before updates? does it matter? > > I don't see how it can matter. > > > 17. Section 6.2.4.4. "CS MUST ensure that VCARs are still valid after > > the move" seems pretty nebulous to me. I think the issue is the > > following: given that VCARs are hierarchic, moving a calendar > > from one location in the hierarchy to another could possibly > > change the access control considerably and yield unexpected and > > unwanted results. I think what we want to do is make sure that > > the access control is at least as restrictive (and possibly more > > restrictive) than it was prior to the move. Note that with > > hierarchic VCARs the way they are defined now, it may not be > > possible to provide exactly the same access to a calendar as > > prior to the move -- something further up the new hierarchy may > > be more restrictive. Also, there are ownership issues. Is there > > something we want to say about the ownership of the new parent > > calendar(s) given the owners of the previous parent calendars? > > (this problem is pointed out in the editors note). > > Last point first. - if you have the VCAR for it :-), you should > be able to move it. agreed, question is which vcar gives you access to move a calendar into it? > I agree with the VCAR issues you point out. It's hard to say > what is more restrictive, adding access you did not want, > or no longer having access denied. > > The only way to do this would be to allow only moves to top > level calendars - where they can control all of their own VCARs. > And as that would be a kludge, should we drop the ability > to move calendars? hmm... I think it's pretty severe to drop it. Do people have an issue with calenders possibly becoming more restrictive after a move? > > 19. Section 6.2.4.5, just past the last example we show this query: > > QUERY: SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com' CALSTORE > > is being used as a special keyword here. We should probably list > > this somewhere or find another way to do the query. > > In addition (reminder) we need to add back the VCAR and other > text back into CAP - and add CALSTORE and VSCHEDULE to the VCAR > and VQUERY ABNF - (if not already there). > > > 20. Section 6.3.3.1 was the Organizer intentionally left out of the > > ATTENDEE list? Seems like the organizer should be in the > > attendee list. > > The ORGANIZER does not have to be in the ATTENDEE list. > I'll organize it - you do the work :-) Right. But later in the example an Attendee sends another Attendee a DECLINECOUNTER, which cannot happen. I've fixed up the example -- but I did add the Organizer as an Attendee (I think this will be the most common case). Have a look at it and see what you think. -Steve --------------B700668A3405EDFF2AFC839F 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------B700668A3405EDFF2AFC839F-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 13:58:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15828 for ; Wed, 12 Dec 2001 13:58:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCIgZi25118 for ietf-calendar-bks; Wed, 12 Dec 2001 10:42:35 -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 fBCIgU225113 for ; Wed, 12 Dec 2001 10:42:31 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA06543; Wed, 12 Dec 2001 12:38:23 -0600 From: "Shannon J. Clark" To: "John Stracke" , "CalSched IETF" Subject: RE: Question on calstore current time. Date: Wed, 12 Dec 2001 12:42:31 -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 In-Reply-To: Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, Are VALARMS required to specify time in a TIMEZONE or UTC format? I can clearly see many use cases for VALARMS where local time would be very desirable - i.e. an alarm that performs some action prior to my lunch time each day. Under a number of cases this would then vary in behavior in accord with the server's own view of "local time" - i.e. defined by the server's choice of timezone. The point being that servers may reasonably be doing actions in the case of VALARMS, and users (and their CUA) would need to know how the server views the world. The other use case being when synchronization actions are taking place - i.e. actions requiring an interpretation of DTIME (i.e. timestamps on objects) - if those timestamps are in local time (which perhaps they "shouldn't" be... but is it a MUST that they are in UTC?) Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Wednesday, December 12, 2001 12:07 PM To: CalSched IETF Subject: RE: Question on calstore current time. >Say you have a server dealing with a number of events and actions >(such as VALARMS) and your CUA needs to provide an answer to you >about when your SERVER will take a particular action. > >Just knowing what "time" in UTC that the server thinks it is [...] > only tells you if the server is off in terms of minutes >and seconds - it doesn't tell you what "timezone/local" the server >itself is working in. The server's concept of its own timezone is irrelevant. All that matters is the timezone specified in the VALARM; that tells the server how to convert to/from UTC to render the alarm correctly. I suppose the server's OS could (a) be maintaining its own clock in local time, and (b) have a bug in its timezone conversions, so that it tells the server application the wrong UTC time. However, I don't think we really need to support servers chipped out of flint by Homo erectus. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===============================================================| |"Power corrupts; Powerpoint corrupts absolutely." -- Vint Cerf | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 14:06:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15964 for ; Wed, 12 Dec 2001 14:06:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCIsOH25650 for ietf-calendar-bks; Wed, 12 Dec 2001 10:54:24 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCIsM225644 for ; Wed, 12 Dec 2001 10:54:22 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id NAA18676; Wed Dec 12 13:51:16 2001 Subject: RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Dec 2001 13:57:59 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/12/2001 01:58:01 PM, Serialize complete at 12/12/2001 01:58:01 PM Content-Type: text/plain; charset="us-ascii" To: "CalSched IETF" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Are VALARMS required to specify time in a TIMEZONE or UTC format? Uh......no; they're relative to an event, and an event can be in floating time. But wait a minute--VALARMs don't go off on the server, do they? A VALARM going off is a UI thing; it should be the CUA's responsibility. ...the CAP draft says nothing about server-side VALARMs. (You might want a server to send email at a particular time--say, to send a reminder to your cellphone--but that would have to be a separate server, using CAP to get its data.) And, if there were such a thing as server-side VALARMs, it would still be inappropriate to use the server's default timezone for floating events; you'd use the CU's TZID property. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |============================================================| |If all the world's a stage, I want to operate the trap door.| \============================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 14:21:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16294 for ; Wed, 12 Dec 2001 14:21:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCIx6Z25964 for ietf-calendar-bks; Wed, 12 Dec 2001 10:59:06 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCIx5225960 for ; Wed, 12 Dec 2001 10:59:05 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@mail.imc.org id NAA19556; Wed Dec 12 13:55:59 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Dec 2001 14:02:43 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/12/2001 02:02:44 PM, Serialize complete at 12/12/2001 02:02:44 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@mail.imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Do people have an issue with >calenders possibly becoming more restrictive after a move? What if I *wanted* it to become less restrictive? By analogy to filesystems, sometimes I move a file into my ~/public_html directory, so it can be accessed via HTTP. If I want to make a set of events publicly visible, I might move them into a calendar which grants read access to the world. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |==============================================================| |The Net regards censorship as damage, and routes around it. --| |John Gilmore | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 15:40:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17667 for ; Wed, 12 Dec 2001 15:40:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCKPX000680 for ietf-calendar-bks; Wed, 12 Dec 2001 12:25:33 -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 fBCKPV200675 for ; Wed, 12 Dec 2001 12:25:31 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA25039; Wed, 12 Dec 2001 15:25:31 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA08714; Wed, 12 Dec 2001 15:25:30 -0500 (EST) Received: from monalisa (211-198-131-12.bellhead.com [12.131.198.211]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id PAA18122; Wed, 12 Dec 2001 15:25:29 -0500 (EST) From: "Paul B. Hill" To: "John Stracke" , Subject: RE: CAP Draft 6 comments Date: Wed, 12 Dec 2001 15:25:31 -0500 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Once you have moved an object you could set new VCARs to make it be less restrictive. The alternatives that I can think of are: 1) Don't carry any of the inherited VCARS during a move. The resultant behavior would be a result of the explicity VCARs and the inherited VCARs from the new location. 2) Provide 2 move commands, one version would copy the current resultant VCARs and the other would provide the semantics of choice 1 from above. -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Wednesday, December 12, 2001 2:03 PM To: ietf-calendar@mail.imc.org Subject: Re: CAP Draft 6 comments >Do people have an issue with >calenders possibly becoming more restrictive after a move? What if I *wanted* it to become less restrictive? By analogy to filesystems, sometimes I move a file into my ~/public_html directory, so it can be accessed via HTTP. If I want to make a set of events publicly visible, I might move them into a calendar which grants read access to the world. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |==============================================================| |The Net regards censorship as damage, and routes around it. --| |John Gilmore | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 15:41:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17700 for ; Wed, 12 Dec 2001 15:41:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCKPVE00677 for ietf-calendar-bks; Wed, 12 Dec 2001 12:25:31 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCKPU200670 for ; Wed, 12 Dec 2001 12:25:30 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA25563; Wed, 12 Dec 2001 15:25:29 -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 PAA24834; Wed, 12 Dec 2001 15:25:27 -0500 (EST) Received: from monalisa (211-198-131-12.bellhead.com [12.131.198.211]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id PAA18107; Wed, 12 Dec 2001 15:25:27 -0500 (EST) From: "Paul B. Hill" To: "John Stracke" , "CalSched IETF" Subject: RE: Question on calstore current time. Date: Wed, 12 Dec 2001 15:25:29 -0500 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, >...But wait a minute--VALARMs don't go off on the server, do they? A VALARM >going off is a UI thing; it should be the CUA's responsibility. dig>...the CAP draft says nothing about server-side VALARMs. The behavior that results from a VALARM is not part of the protocol. I hope that implementors will develop servers that can generate events based on VALARMS. I may not always have my CUA running, but I can probably be reached in a variety of other ways, for example by pager, phone, or an instant messaging service. Paul From owner-ietf-calendar@mail.imc.org Wed Dec 12 15:56:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18007 for ; Wed, 12 Dec 2001 15:56:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCKhvk03019 for ietf-calendar-bks; Wed, 12 Dec 2001 12:43:57 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCKht203010 for ; Wed, 12 Dec 2001 12:43:55 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@mail.imc.org id PAA11216; Wed Dec 12 15:40:25 2001 Subject: RE: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Dec 2001 15:47:07 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/12/2001 03:47:10 PM, Serialize complete at 12/12/2001 03:47:10 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@mail.imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Once you have moved an object you could set new VCARs to make it be less >restrictive. True. >The alternatives that I can think of are: > >1) Don't carry any of the inherited VCARS during a move. The resultant >behavior would be a result of the explicity VCARs and the inherited VCARs >from the new location. This is what I would consider most sensible. It's the behavior users will expect from their CUAs (if I move things into my public calendar, they become public), and we should make it simple for CUAs to provide the expected behavior; and it's easier to implement in the CS (no need to rework the VCARs when you move something). I do realize that you could accidentally open up extra permissions this way; but I think the right place to prevent that is in the UI, not the protocol; embedding that carefulness into the protocol makes it difficult to build UIs that do the risky thing when it's appropriate. By analogy, would you expect the unlink() system call (deletes a file) to prompt the user for confirmation? No. Instead, unlink() does what you tell it to, and the rm command prompts for confirmation (sometimes). /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Please do not look into laser with remaining eyeball. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 16:27:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18492 for ; Wed, 12 Dec 2001 16:27:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCL8a705029 for ietf-calendar-bks; Wed, 12 Dec 2001 13:08:36 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCL8Y205025 for ; Wed, 12 Dec 2001 13:08:34 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id QAA18224; Wed Dec 12 16:05:46 2001 Subject: RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Dec 2001 16:12:29 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/12/2001 04:12:31 PM, Serialize complete at 12/12/2001 04:12:31 PM Content-Type: text/plain; charset="us-ascii" To: "CalSched IETF" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >The behavior that results from a VALARM is not part of the protocol. I hope >that implementors will develop servers that can generate events based on >VALARMS. But, if the VALARM behavior isn't part of the protocol, how do you tell the server you want it? Perhaps an external server that uses CAP to talk to the CS, and generate events to match? /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Unless. -- The Lorax | \=======================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 16:55:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19344 for ; Wed, 12 Dec 2001 16:55:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCLeTi06683 for ietf-calendar-bks; Wed, 12 Dec 2001 13:40:29 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCLeS206678 for ; Wed, 12 Dec 2001 13:40:28 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA28246; Wed, 12 Dec 2001 16:40:27 -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 QAA09583; Wed, 12 Dec 2001 16:35:32 -0500 (EST) Received: from monalisa (211-198-131-12.bellhead.com [12.131.198.211]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id QAA18998; Wed, 12 Dec 2001 16:35:32 -0500 (EST) From: "Paul B. Hill" To: "John Stracke" , "CalSched IETF" Subject: RE: Question on calstore current time. Date: Wed, 12 Dec 2001 16:35:34 -0500 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >...Perhaps an external server that uses CAP to talk to the CS, and generate >events to match? That sounds like the most generic solution. >...But, if the VALARM behavior isn't part of the protocol, how do you tell >the server you want it? Like a full administrative interface, this aspect isn't getting standardized at this time. From owner-ietf-calendar@mail.imc.org Wed Dec 12 16:57:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19379 for ; Wed, 12 Dec 2001 16:57:22 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCLk4F06921 for ietf-calendar-bks; Wed, 12 Dec 2001 13:46:04 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCLk3206916 for ; Wed, 12 Dec 2001 13:46: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 NAA23439 for ; Wed, 12 Dec 2001 13:46:04 -0800 (PST) Message-ID: <3C17D01A.426CA0A1@Royer.com> Date: Wed, 12 Dec 2001 14:46:02 -0700 From: Doug Royer Reply-To: ietf-calendar@mail.imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Draft 6 comments References: <3C167F57.AEAC1FA8@netscape.com> <3C1718A7.C9759B57@Royer.com> <3C178A55.91A63654@netscape.com> Content-Type: multipart/mixed; boundary="------------B05F389F65846AF6DA896C65" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B05F389F65846AF6DA896C65 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > > 9. Section 4.1.6 versus 4.1.8 -- the value for METHOD. In some > > > places, we refer to the METHOD value for "booked" events as NULL, > > > and in other places we refer to it as CREATED. I happen to > > > prefer being explicit and keeping it at CREATED, but whatever we > > > choose we must be consistent. > > > > I agree - lets keep it 'CREATE' (same as METHOD:CREATE) not CREATEd. > > We all came to that conclusion. One suggestion was that we use "BOOKED" > instead of "CREATED". I could go for that, that would bring up another question. Can I queue 'CREATE' and store it (like iTIP methods)? Or must CREATE always be acted on and never stored? > > > > The only way to do this would be to allow only moves to top > > level calendars - where they can control all of their own VCARs. > > And as that would be a kludge, should we drop the ability > > to move calendars? > > hmm... I think it's pretty severe to drop it. Do people have an issue with > calenders possibly becoming more restrictive after a move? I would towards dropping it until CAP-v-next. As pointed out in another email, VCARs are complex, this just multiplies the states changes to consider. By dropping it, it does not mean you can not do it, it means the WG has not thought out all of the VCAR issues. Lets work out VCAR interoperability first, before we try to make it more complicated. You can always - copy to new, delete old until we have MOVE worked out. --------------B05F389F65846AF6DA896C65 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------B05F389F65846AF6DA896C65-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 17:09:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19733 for ; Wed, 12 Dec 2001 17:09:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCLtas07224 for ietf-calendar-bks; Wed, 12 Dec 2001 13:55:36 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCLtZ207220 for ; Wed, 12 Dec 2001 13:55: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 NAA23586 for ; Wed, 12 Dec 2001 13:55:36 -0800 (PST) Message-ID: <3C17D255.CD54C4CF@Royer.com> Date: Wed, 12 Dec 2001 14:55:33 -0700 From: Doug Royer Reply-To: ietf-calendar@mail.imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Draft 6 comments References: Content-Type: multipart/mixed; boundary="------------0F144A79289FA51BAFB5858A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0F144A79289FA51BAFB5858A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >Do people have an issue with > >calenders possibly becoming more restrictive after a move? > > What if I *wanted* it to become less restrictive? By analogy to > filesystems, sometimes I move a file into my ~/public_html directory, so > it can be accessed via HTTP. If I want to make a set of events publicly > visible, I might move them into a calendar which grants read access to the > world. The more we talk, the more I am sure we have not thought about this - I am leaning more to the lets drop moving calendars in the current CAP. We can do an add on later after we solved the issues. --------------0F144A79289FA51BAFB5858A 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------0F144A79289FA51BAFB5858A-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 17:18:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19921 for ; Wed, 12 Dec 2001 17:18:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCM5TY07553 for ietf-calendar-bks; Wed, 12 Dec 2001 14:05:29 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCM5S207548 for ; Wed, 12 Dec 2001 14:05: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 OAA23737 for ; Wed, 12 Dec 2001 14:05:29 -0800 (PST) Message-ID: <3C17D4A6.D469EF2C@Royer.com> Date: Wed, 12 Dec 2001 15:05:26 -0700 From: Doug Royer Reply-To: ietf-calendar@mail.imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Draft 6 comments References: Content-Type: multipart/mixed; boundary="------------CF5D1B42E3152F08A24FF1EA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CF5D1B42E3152F08A24FF1EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > > Once you have moved an object you could set new VCARs to make it be less > restrictive. > > The alternatives that I can think of are: > > 1) Don't carry any of the inherited VCARS during a move. The resultant > behavior would be a result of the explicity VCARs and the inherited VCARs > from the new location. The only way to find out that you don't have the ability to undo what you did is after you did it :-) > 2) Provide 2 move commands, one version would copy the current resultant > VCARs ... You can configure a VCAR so that the user can't see it by not GRANTing them access to reading some, a set, or all VCARS. How would you find the result set? >. ...and the other would provide the semantics of choice 1 from above. Without any way (that I can think of) for getting the result set, I don't know how to do that. I can VQUERY for all the VCARs stored that I have access to. But I will never be able to find that a system administrator has configured (for a valid reason) an implementation that will not allow some of the new (destination) VCARS to work. -Doug --------------CF5D1B42E3152F08A24FF1EA 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------CF5D1B42E3152F08A24FF1EA-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 17:35:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20117 for ; Wed, 12 Dec 2001 17:35:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCMM6g08429 for ietf-calendar-bks; Wed, 12 Dec 2001 14:22:06 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMM5208422; Wed, 12 Dec 2001 14:22: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 OAA23952; Wed, 12 Dec 2001 14:22:06 -0800 (PST) Message-ID: <3C17D88A.973A5985@Royer.com> Date: Wed, 12 Dec 2001 15:22:02 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@mail.imc.org Subject: Re: CAP Draft 6 comments References: Content-Type: multipart/mixed; boundary="------------CEB28A73243FD9C85C845CC9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CEB28A73243FD9C85C845CC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > >1) Don't carry any of the inherited VCARS during a move. The resultant > >behavior would be a result of the explicity VCARs and the inherited VCARs > >from the new location. > > This is what I would consider most sensible. It's the behavior users will > expect from their CUAs (if I move things into my public calendar, they > become public), and we should make it simple for CUAs to provide the > expected behavior; and it's easier to implement in the CS (no need to > rework the VCARs when you move something). I strongly agree. But can it work? > I do realize that you could accidentally open up extra permissions this > way; but I think the right place to prevent that is in the UI, not the > protocol; embedding that carefulness into the protocol makes it difficult > to build UIs that do the risky thing when it's appropriate. By analogy, > would you expect the unlink() system call (deletes a file) to prompt the > user for confirmation? No. Instead, unlink() does what you tell it to, > and the rm command prompts for confirmation (sometimes). Yes, but if I move a file from one location to another on any OS, it does not allow someone to see some of the PRIVATE data insie the file just because the grandparent directory allowed it, and my old one did not. I agree we want this feature. I am not sure we know how to do it. What would the UI/CU be faced with. For a huge calendar with thousands of entries, do you want a message that says: You moved the calendar, so please pick one of the following two choices on how to handle the move: (1) Thousands of of pop-ups saying 'for this entry - what do you want this one to be GRANT/DENU . - because it the old VCAR set is so much different than the new VCAR set (well maybe because - we can't tell as the move takes place on the CS). or (2) Stale cookies - all of the work you did over the last few years to set things up the way you wanted or needed are gone. Please go through the thousands of object and fix them - again. The more we talk, the more I am sure the CUA has to load the calendar then make a new one - with as you say - the CUA making the choices. I don't think we have solved the problem of transferring the CU's reason to the CS so the CS can decide what to do. --------------CEB28A73243FD9C85C845CC9 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------CEB28A73243FD9C85C845CC9-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 17:36:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20140 for ; Wed, 12 Dec 2001 17:36:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCMObx08507 for ietf-calendar-bks; Wed, 12 Dec 2001 14:24:37 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMOZ208503 for ; Wed, 12 Dec 2001 14:24:35 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@mail.imc.org id RAA05315; Wed Dec 12 17:20:43 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Dec 2001 17:27:25 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/12/2001 05:27:29 PM, Serialize complete at 12/12/2001 05:27:29 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@mail.imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Can I queue 'CREATE' and store it (like iTIP methods)? Or must >CREATE always be acted on and never stored? I'd guess the CREATE shouldn't be queued. The reason for queueing iTIP methods is that they're coming from untrusted sources, right? /===========================================================\ |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 Dec 12 17:38:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20171 for ; Wed, 12 Dec 2001 17:38:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCMQfL08634 for ietf-calendar-bks; Wed, 12 Dec 2001 14:26:41 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMQe208628 for ; Wed, 12 Dec 2001 14:26: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 OAA24025 for ; Wed, 12 Dec 2001 14:26:41 -0800 (PST) Message-ID: <3C17D99E.D7E0A03D@Royer.com> Date: Wed, 12 Dec 2001 15:26:38 -0700 From: Doug Royer Reply-To: "ietf-calendar@mail.imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question on calstore current time. References: <3C16A843.5EAA5F59@netscape.com> <3C16F931.95B3E3EA@Royer.com> <3C17857B.A751C23A@netscape.com> Content-Type: multipart/mixed; boundary="------------95664E8F9833D48F5AC69BE9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------95664E8F9833D48F5AC69BE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > > We seem to recall that someone had a good reason for returning it as > > > the server's localtime value and a TZID. None of us here at the ietf > > > meeting can remember what that was. > > > > It was for small devices that are stupid outside of CAP. > > OK. That sounds familiar. Can you explain it further. > I still don't get it. It was not (or if it was I dropped it) my idea. I seem to recall it had to do with device that could not do NTP, but this is the IETF and we do internet protocols - not random stupid interfaces (well not on purpose). So - would debate the point if I could remember the details. --------------95664E8F9833D48F5AC69BE9 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------95664E8F9833D48F5AC69BE9-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 17:46:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20276 for ; Wed, 12 Dec 2001 17:46:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCMZZt09902 for ietf-calendar-bks; Wed, 12 Dec 2001 14:35:35 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMZY209897 for ; Wed, 12 Dec 2001 14:35: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 OAA24116 for ; Wed, 12 Dec 2001 14:35:35 -0800 (PST) Message-ID: <3C17DBB4.9F9DF5CF@Royer.com> Date: Wed, 12 Dec 2001 15:35:32 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR question References: <3C178F5F.1F85AF94@steltor.com> Content-Type: multipart/mixed; boundary="------------D11A3E79CCAEC9F7768775F8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D11A3E79CCAEC9F7768775F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Furthermore, the MODIFY ACTION could probably be > eliminated, given that if you can READ and CREATE > you can MODIFY. No they are not the same. - I can make a VCAR that allows you only to MODIFY your PARTSTAT - but I do NOT want you to CREATE anything new and I do not want you to READ anything at all. > The relationship between the CAP commands (i.e., > create, delete, modify, move, search and schedule) > and the CAP actions should be clarified. Renaming > the ACTION CREATE to WRITE would probably help > reducing the confusion. OR we could rename the command to CREATE as WRITE implies modify as you pointed out above. --------------D11A3E79CCAEC9F7768775F8 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------D11A3E79CCAEC9F7768775F8-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 17:50:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20329 for ; Wed, 12 Dec 2001 17:50:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCMe3V10551 for ietf-calendar-bks; Wed, 12 Dec 2001 14:40:03 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMe2210546 for ; Wed, 12 Dec 2001 14:40: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 OAA24187 for ; Wed, 12 Dec 2001 14:40:04 -0800 (PST) Message-ID: <3C17DCC0.5C400257@Royer.com> Date: Wed, 12 Dec 2001 15:40:00 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------8830C4827C756C34E09162AE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8830C4827C756C34E09162AE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > Are VALARMS required to specify time in a TIMEZONE or UTC format? Both PLUS with a time not in UTC and without a TIMEZONE. As in December 31st at 12:59:59 - New Year. It is not in any time zone or UTC. Yet I can make a sharable VEVENT with that data in it that is valid in all time zones. > The other use case being when synchronization actions are taking place - > i.e. actions requiring an interpretation of DTIME (i.e. timestamps on > objects) - if those timestamps are in local time (which perhaps they > "shouldn't" be... but is it a MUST that they are in UTC?) (DTSTAMP not DTIME?) What doe RFC-2445 say? --------------8830C4827C756C34E09162AE 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------8830C4827C756C34E09162AE-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 17:56:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20422 for ; Wed, 12 Dec 2001 17:56:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCMixa11274 for ietf-calendar-bks; Wed, 12 Dec 2001 14:44: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 fBCMiu211258 for ; Wed, 12 Dec 2001 14:44: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 RAA18498 for ; Wed, 12 Dec 2001 17:44:52 -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 fBCMiqH25105 for ; Wed, 12 Dec 2001 17:44:52 -0500 (EST) Message-ID: <3C17DE10.C9455E90@steltor.com> Date: Wed, 12 Dec 2001 17:45: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: Re: CAP Draft 6 comments References: <3C167F57.AEAC1FA8@netscape.com> <3C1718A7.C9759B57@Royer.com> <3C178A55.91A63654@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: > > Doug Royer wrote: > > > Steve Mansour wrote: > > > > > 5. Section 2.6 - we mention "printable 7 bit ASCII characters". Is > > > this sufficiently explicit? Should we list the character value > > > range? > > > > Yes, I can print lots of printable form feeds :-) > > Right. Pat has the action item of giving us the exact character set. > Alright! Pat, we should comply with RFC 2396 (URI Generic Syntax) (see section 2, URI Characters and Escape Sequences), and follow RFC 2718 (Guidelines for new URL Schemes) as well. > > > 9. Section 4.1.6 versus 4.1.8 -- the value for METHOD. In some > > > places, we refer to the METHOD value for "booked" events as NULL, > > > and in other places we refer to it as CREATED. I happen to > > > prefer being explicit and keeping it at CREATED, but whatever we > > > choose we must be consistent. > > > > I agree - lets keep it 'CREATE' (same as METHOD:CREATE) not CREATEd. > > We all came to that conclusion. One suggestion was that we use "BOOKED" > instead of "CREATED". So the VSCHEDULE would now be: METHOD != 'BOOKED' AND METHOD != 'DELETED' ? > > > > 10. Section 4.1.6 -- I thought we decided that we need a METHOD state > > > for a CANCELled event or a DELETEd event. This is important for > > > several reasons. One was mentioned in the draft, another is that > > > it's important for synchronization applications to determine > > > which events have been deleted. If we use the METHOD property to > > > mark cancelled / deleted events, then the query needs to be > > > fixed. > > > > Yes - I think the discussion took place as the changes were made. > > I think that a hard working person edited too much :-) > > Without the ability to tag objects as CANCELed and DELETEd, things > > will bust - for synchronization. > > OK. It we'll make it better. > > > > 12. We need to close on the iCalendar version we're going to require > > > for CAP. In the current draft we specify that we require VERSION > > > 2.0 and VERSION 2.1. Let's pick one :-) > > > > (A) We are NOT upgrading the format. Why would we update the > > iCalendar Version. > > (B) Lets not wait for iCal-V-next. > > Version 2.0 it is! Doesn't the addition of new components (e.g., VAGENDA, VQUERY, and VCAR) as well as new properties in existent components (e.g., UID in VALARM) call for a new iCalendar version? What's the safest? Use VERSION:2.1 to warn presumably 2.0 compliant applications that they may not handle the object properly, or use VERSION:2.0 and let them choke on it? > > > 14. Section 6.2.4.2. Regarding the editors note - my recommendation > > > is that the way to delete a VALARM is to modify or delete the > > > component that contains it. The delete command should apply to > > > the VTIMEZONES that exist at the calstore level. I don't think > > > components like VEVENTS can contain VTIMEZONE components, I think > > > they only reference VTIMEZONE components that exist at the > > > calstore level. > > > > In Chicago timefraime, I thought we agreed that the MODIFY > > only has to list what makes something unique. So if you list > > the *entire* alarm in the 'is' section, and not in the 'change to' > > section - it gets deleted. > > > > And I would like to extend that idea for binary inline > > attachments to say: > > > > When deleting inline binary attachments with METHOD:MOVE: I assume you meant "the modify command". > > > > Only sufficient octets to uniquely identify the attachment > > MAY BE sent. It is not necessary to send the entire contents > > of the inline attachment. Would it matter if the encoding used to specify the "sufficient octets" is different from the encoding that was used to create the attachement in the first place? Will the server have to decode the attachments to see if they match? > > > > And add: > > > > When using the MODIFY command, the property values for > > inline attachments can only be updated, deleted, or > > added. You can not modify part if a inline binary attachment. > > George, Bruce, others... what do you think of this? > > > > 15. Section 6.2.4.3. Are there sequencing (ordering) issues? are > > > removes always processed before updates? does it matter? > > > > I don't see how it can matter. > > > > > 17. Section 6.2.4.4. "CS MUST ensure that VCARs are still valid after > > > the move" seems pretty nebulous to me. I think the issue is the > > > following: given that VCARs are hierarchic, moving a calendar > > > from one location in the hierarchy to another could possibly > > > change the access control considerably and yield unexpected and > > > unwanted results. I think what we want to do is make sure that > > > the access control is at least as restrictive (and possibly more > > > restrictive) than it was prior to the move. Note that with > > > hierarchic VCARs the way they are defined now, it may not be > > > possible to provide exactly the same access to a calendar as > > > prior to the move -- something further up the new hierarchy may > > > be more restrictive. Also, there are ownership issues. Is there > > > something we want to say about the ownership of the new parent > > > calendar(s) given the owners of the previous parent calendars? > > > (this problem is pointed out in the editors note). > > > > Last point first. - if you have the VCAR for it :-), you should > > be able to move it. > > agreed, question is which vcar gives you access to move a calendar into it? See my last post. > > I agree with the VCAR issues you point out. It's hard to say > > what is more restrictive, adding access you did not want, > > or no longer having access denied. > > > > The only way to do this would be to allow only moves to top > > level calendars - where they can control all of their own VCARs. > > And as that would be a kludge, should we drop the ability > > to move calendars? > > hmm... I think it's pretty severe to drop it. Do people have an issue with > calenders possibly becoming more restrictive after a move? I agree with John. The server should not try to be smart with my VCAR. > > > 19. Section 6.2.4.5, just past the last example we show this query: > > > QUERY: SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com' CALSTORE > > > is being used as a special keyword here. We should probably list > > > this somewhere or find another way to do the query. > > > > In addition (reminder) we need to add back the VCAR and other > > text back into CAP - and add CALSTORE and VSCHEDULE to the VCAR > > and VQUERY ABNF - (if not already there). Doug, how do you intend to add VSCHEDULE into the VQUERY ABNF? Salut! 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 Dec 12 18:00:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20490 for ; Wed, 12 Dec 2001 18:00:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCMmxM11409 for ietf-calendar-bks; Wed, 12 Dec 2001 14:48: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 fBCMmv211405 for ; Wed, 12 Dec 2001 14:48: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 RAA18551 for ; Wed, 12 Dec 2001 17:48: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 fBCMmrH25357 for ; Wed, 12 Dec 2001 17:48:53 -0500 (EST) Message-ID: <3C17DF01.9166C3E@steltor.com> Date: Wed, 12 Dec 2001 17:49: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: VCAR question References: <3C178F5F.1F85AF94@steltor.com> <3C17DBB4.9F9DF5CF@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: > > > Furthermore, the MODIFY ACTION could probably be > > eliminated, given that if you can READ and CREATE > > you can MODIFY. > > No they are not the same. > - I can make a VCAR that allows you only to MODIFY > your PARTSTAT - but I do NOT want you to CREATE > anything new and I do not want you to READ anything at all. I see. > > The relationship between the CAP commands (i.e., > > create, delete, modify, move, search and schedule) > > and the CAP actions should be clarified. Renaming > > the ACTION CREATE to WRITE would probably help > > reducing the confusion. > > OR we could rename the command to CREATE as WRITE implies > modify as you pointed out above. You lost me. Rename which 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 Wed Dec 12 18:11:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20643 for ; Wed, 12 Dec 2001 18:11:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCMrSO11531 for ietf-calendar-bks; Wed, 12 Dec 2001 14:53:28 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMrR211525 for ; Wed, 12 Dec 2001 14:53: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 OAA24422 for ; Wed, 12 Dec 2001 14:53:28 -0800 (PST) Message-ID: <3C17DFE4.A2BD1F03@Royer.com> Date: Wed, 12 Dec 2001 15:53:24 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------BB284B4D81AC16A81DBE0840" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BB284B4D81AC16A81DBE0840 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > But wait a minute--VALARMs don't go off on the server, do they? A VALARM > going off is a UI thing; it should be the CUA's responsibility. dig>...the CAP draft says nothing about server-side VALARMs. This is another point I wanted to raise. Why not? Perhaps we need a way to say what the CUA expects? (a) CS Always processes VALARMs. (b) CS Only processes VALARMs when the CUA is not connected. (c) CS Never processes VALARMs. (d) CS Only process the tagged VALARMs. (e) CS Only process the tagged VALARMs when the CUA is not connected. (f) CS Only processes specific types of VALARMs (email only for example). (g) CS Only processes specific types of VALARMs when the CUA is not connected. ... BIG BIG interoperability issues!!! What if the CS Can't process any VALARMs: As in - you don't own the server and it does not do those things for you. (Unless we make it a MUST and that won't fly). What if the CUA can't process some kinds of VALARMs: My Non-Net Palm Pilot can't send an email when it is in my bag at 30,000 feet - what if that email goes to my co-workers - that's why I put the information in a VALARM). What if multiple CUA are connected and we agree that the CUA send the VALARMs? Do they all send the same email, process the procedure, ... (assume they are all the calendar owner). > (You might want a server to send email at a particular time--say, to send > a reminder to your cellphone--but that would have to be a separate server, > using CAP to get its data.) Did we specify that - nope? Do we need to - yep. MUST it be the CUA - not sure. > And, if there were such a thing as server-side VALARMs, it would still be > inappropriate to use the server's default timezone for floating events; > you'd use the CU's TZID property. Or Calendars TZID property - only if no TZ attached to the object and it is not in UTC. Or the objects TZID property - yep - if it has one - else the calendars. --------------BB284B4D81AC16A81DBE0840 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------BB284B4D81AC16A81DBE0840-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 18:14:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20717 for ; Wed, 12 Dec 2001 18:14:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCN0ga12520 for ietf-calendar-bks; Wed, 12 Dec 2001 15:00:42 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCN0f212514 for ; Wed, 12 Dec 2001 15:00: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 PAA24507 for ; Wed, 12 Dec 2001 15:00:43 -0800 (PST) Message-ID: <3C17E196.F4268C23@Royer.com> Date: Wed, 12 Dec 2001 16:00:38 -0700 From: Doug Royer Reply-To: ietf-calendar@mail.imc.org Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Draft 6 comments References: Content-Type: multipart/mixed; boundary="------------3C7FDE036B9D8ED719CACBBA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3C7FDE036B9D8ED719CACBBA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >Can I queue 'CREATE' and store it (like iTIP methods)? Or must > >CREATE always be acted on and never stored? > > I'd guess the CREATE shouldn't be queued. I agree. > The reason for queueing iTIP > methods is that they're coming from untrusted sources, right? And because a CUA that is not your GUI might deposit them into your calendar and they need user action. --------------3C7FDE036B9D8ED719CACBBA 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------3C7FDE036B9D8ED719CACBBA-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 18:15:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20761 for ; Wed, 12 Dec 2001 18:15:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCMtaq11758 for ietf-calendar-bks; Wed, 12 Dec 2001 14:55:36 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMtZ211751 for ; Wed, 12 Dec 2001 14:55: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 OAA24434 for ; Wed, 12 Dec 2001 14:55:37 -0800 (PST) Message-ID: <3C17E064.47DCEB3F@Royer.com> Date: Wed, 12 Dec 2001 15:55:32 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------0315530B096C38894614AE84" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0315530B096C38894614AE84 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > The behavior that results from a VALARM is not part of the protocol. > I hope that implementors will develop servers that can generate > events based on VALARMS. I may not always have my CUA running, > but I can probably be reached in a variety of other ways, > for example by pager, phone, or an instant messaging service. I agree. We need to write down the rules or you are going to get two or more VALARMs or none depending on the implementations. --------------0315530B096C38894614AE84 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------0315530B096C38894614AE84-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 18:44:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21484 for ; Wed, 12 Dec 2001 18:44:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCNWVI14437 for ietf-calendar-bks; Wed, 12 Dec 2001 15:32:31 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCNWT214432 for ; Wed, 12 Dec 2001 15:32:30 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id SAA12512; Wed Dec 12 18:25:54 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Dec 2001 18:32:36 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/12/2001 06:32:40 PM, Serialize complete at 12/12/2001 06:32:40 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Yes, but if I move a file from one location to another on any OS, >it does not allow someone to see some of the PRIVATE data insie the >file just because the grandparent directory allowed it, and my >old one did not. Er...it might. On Unix, if you have a file in a directory where I do not have permissions, I cannot list the directory, and I cannot read or write the file even if the file itself says I have permissions to do so. If you then move that file into a directory where I *do* have execute permissions, then I can read the file if the file says I can. I'm not convinced that this is too complex to solve right now. However, I am convinced that putting it off is safe (safer than getting it wrong, anyway :-), so maybe that's the right thing to do. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=================================================================| |For the life of me, I've never understood why people dismiss the | |importance of "semantics" in communication. After all, if | |semantics had no purpleness, you'd slitheringly go bold at by-sit| |it I'm climbing. -- Tangwystyl | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 18:46:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21539 for ; Wed, 12 Dec 2001 18:46:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCNVvs14418 for ietf-calendar-bks; Wed, 12 Dec 2001 15:31:57 -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 fBCNVs214413 for ; Wed, 12 Dec 2001 15:31:55 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id RAA07032 for ; Wed, 12 Dec 2001 17:27:43 -0600 From: "Shannon J. Clark" To: "CalSched IETF" Subject: RE: Question on calstore current time. Date: Wed, 12 Dec 2001 17:31:51 -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) In-Reply-To: <3C17DCC0.5C400257@Royer.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, Well RFC 2445 appears to have this handled fairly reasonably: To quote from the description of the DTSTAMP property: Description: The value MUST be specified in the UTC time format. So all processes that use the DTSTAMP (to sort objects for example), or use the LAST-MODIFIED or CREATED (?) properties will be using UTC to sort and handle them. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Wednesday, December 12, 2001 4:40 PM To: ietf-calendar@imc.org Subject: Re: Question on calstore current time. "Shannon J. Clark" wrote: > Are VALARMS required to specify time in a TIMEZONE or UTC format? Both PLUS with a time not in UTC and without a TIMEZONE. As in December 31st at 12:59:59 - New Year. It is not in any time zone or UTC. Yet I can make a sharable VEVENT with that data in it that is valid in all time zones. > The other use case being when synchronization actions are taking place - > i.e. actions requiring an interpretation of DTIME (i.e. timestamps on > objects) - if those timestamps are in local time (which perhaps they > "shouldn't" be... but is it a MUST that they are in UTC?) (DTSTAMP not DTIME?) What doe RFC-2445 say? From owner-ietf-calendar@mail.imc.org Wed Dec 12 19:05:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22057 for ; Wed, 12 Dec 2001 19:05:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCNqDG15365 for ietf-calendar-bks; Wed, 12 Dec 2001 15:52:13 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCNqC215360 for ; Wed, 12 Dec 2001 15:52: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 PAA25291; Wed, 12 Dec 2001 15:52:07 -0800 (PST) Message-ID: <3C17ED9C.36535386@Royer.com> Date: Wed, 12 Dec 2001 16:51:56 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Desruisseaux CC: "ietf-calendar@imc.org" Subject: Re: CAP Draft 6 comments References: <3C167F57.AEAC1FA8@netscape.com> <3C1718A7.C9759B57@Royer.com> <3C178A55.91A63654@netscape.com> <3C17DE10.C9455E90@steltor.com> Content-Type: multipart/mixed; boundary="------------D48616492F1E8E6AD98333FD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D48616492F1E8E6AD98333FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > So the VSCHEDULE would now be: > METHOD != 'BOOKED' AND METHOD != 'DELETED' ? Or is it 'DELETE' ? > > > > 2.0 and VERSION 2.1. Let's pick one :-) > > > > > > (A) We are NOT upgrading the format. Why would we update the > > > iCalendar Version. > > > (B) Lets not wait for iCal-V-next. > > > > Version 2.0 it is! > > Doesn't the addition of new components (e.g., VAGENDA, VQUERY, > and VCAR) as well as new properties in existent components > (e.g., UID in VALARM) call for a new iCalendar version? No, 2445 says that the objects are any IANA component property, parameter, value type (my words). As long as we don't change the format - it is 2.0. > What's the safest? Use VERSION:2.1 to warn presumably 2.0 > compliant applications that they may not handle the object > properly, or use VERSION:2.0 and let them choke on it? If they choke, they were already busted as 2.0 is the format, not the version of iCalendar. The problem is that in the future there could be X different additions to iCalendar, only Y of which you need in your implementation. If we bump the rev each time, that's X time Y versions. And for no reason. They should be doing it right already. > > > And I would like to extend that idea for binary inline > > > attachments to say: > > > > > > When deleting inline binary attachments with METHOD:MOVE: > > I assume you meant "the modify command". Yes - thanks! > > > > > > Only sufficient octets to uniquely identify the attachment > > > MAY BE sent. It is not necessary to send the entire contents > > > of the inline attachment. > > Would it matter if the encoding used to specify the "sufficient > octets" is different from the encoding that was used to create > the attachement in the first place? Will the server have to > decode the attachments to see if they match? We should add something like: ... of the resulting data after any decoding... > > > Last point first. - if you have the VCAR for it :-), you should > > > be able to move it. > > > > agreed, question is which vcar gives you access to move a calendar into it? > > See my last post. I am beginning to think that MOVE of calendars should not be in CAP at this time. Else, add VAGENDA to the valid VCAR objects and treat it like the rest of the objects. > > > > I agree with the VCAR issues you point out. It's hard to say > > > what is more restrictive, adding access you did not want, > > > or no longer having access denied. > > > > > > The only way to do this would be to allow only moves to top > > > level calendars - where they can control all of their own VCARs. > > > And as that would be a kludge, should we drop the ability > > > to move calendars? > > > > hmm... I think it's pretty severe to drop it. Do people have an > > issue with calenders possibly becoming more restrictive after a move? > > I agree with John. The server should not try to be smart > with my VCAR. One persons smart is another persons dumb. The CS can never know why you set the VCAR - only the CU can know that. It would be a BIG mess. Let the CUA - COPY to new, delete old - the issues say with the CU/CUA and not in the CS. Lets get CAP out the door and figure out how to move a calendar without copy/delete by the CUA later. > > > > 19. Section 6.2.4.5, just past the last example we show this query: > > > > QUERY: SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com' CALSTORE > > > > is being used as a special keyword here. We should probably list > > > > this somewhere or find another way to do the query. > > > > > > In addition (reminder) we need to add back the VCAR and other > > > text back into CAP - and add CALSTORE and VSCHEDULE to the VCAR > > > and VQUERY ABNF - (if not already there). > > Doug, how do you intend to add VSCHEDULE into the VQUERY ABNF? As any other named object (+ any other IANA container, property, parameter, parameter value, or value). My Unix box main disk died - All of my data is backed up. (It was 12 years old!) I have much of the IETF work on that box. I'll send specific changes in the next few days. --------------D48616492F1E8E6AD98333FD 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------D48616492F1E8E6AD98333FD-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 19:06:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22077 for ; Wed, 12 Dec 2001 19:06:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBCNs7K15411 for ietf-calendar-bks; Wed, 12 Dec 2001 15:54:07 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCNs6215406 for ; Wed, 12 Dec 2001 15:54: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 PAA25363; Wed, 12 Dec 2001 15:54:07 -0800 (PST) Message-ID: <3C17EE18.82517D1F@Royer.com> Date: Wed, 12 Dec 2001 16:54:00 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR question References: <3C178F5F.1F85AF94@steltor.com> <3C17DBB4.9F9DF5CF@Royer.com> <3C17DF01.9166C3E@steltor.com> Content-Type: multipart/mixed; boundary="------------F1754403DCE75F86FE6156A7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F1754403DCE75F86FE6156A7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > The relationship between the CAP commands (i.e., > > > create, delete, modify, move, search and schedule) > > > and the CAP actions should be clarified. Renaming > > > the ACTION CREATE to WRITE would probably help > > > reducing the confusion. > > > > OR we could rename the command to CREATE as WRITE implies > > modify as you pointed out above. > > You lost me. Rename which command? Rename the WRITE command to CREATE (or is that a BXXP thing?). --------------F1754403DCE75F86FE6156A7 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------F1754403DCE75F86FE6156A7-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 19:06:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22088 for ; Wed, 12 Dec 2001 19:06:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBCNt9v15442 for ietf-calendar-bks; Wed, 12 Dec 2001 15:55:09 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCNt8215438 for ; Wed, 12 Dec 2001 15:55:08 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id SAA14092; Wed Dec 12 18:48:00 2001 Subject: Re: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 12 Dec 2001 18:54:42 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/12/2001 06:54:46 PM, Serialize complete at 12/12/2001 06:54:46 PM Content-Type: text/plain; charset="us-ascii" To: CalSched IETF From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Perhaps we need a way to say what the CUA expects? > (a) CS Always processes VALARMs. This won't work, because some VALARMs aren't possible on the server side (e.g., audio alarms) > (b) CS Only processes VALARMs when the CUA is not connected. "When the CUA is/is not connected" is tricky, because you can get a race condition: the CUA crashes, the CS decides not to process a VALARM because the CUA is connected, then the CS notices the CUA has disconnected. The alarm never goes off. Also, more prosaically, the bit that processes alarms may be a completely separate process from the bit that speaks CAP. > (c) CS Never processes VALARMs. This is valid, and simple. A helper daemon polling the CS via CAP would suffice to make email-based alarms work. Of course, the helper daemon would need privileges to read all VALARMs. > (d) CS Only process the tagged VALARMs. This might be a good approach; then the CUA can say, "please handle this VALARM when it goes off", and the CS can say, "I can't handle audio alarms, you dope.". > (e) CS Only process the tagged VALARMs when the CUA is not > connected. See (b). > (f) CS Only processes specific types of VALARMs (email only > for example). This might work. We'd have to either (1) standardize on a set of required types (and only email can be reasonably required) or (2) expose the list of supported types in the capabilities. > (g) CS Only processes specific types of VALARMs when the > CUA is not connected. See (b). So, the choices are: (c): none; (d) CUA asks for alarms on an individual basis; (f1) CS processes all email alarms; (f2) CS processes an advertised set of alarm types. Personally, I'd prefer (f1) over (f2) (of the standard types, only email makes sense anyway), and (d) over (f1) (the CUA might prefer to sign the alarm message, for example). But (c) would not trouble me. /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |All your problems can be solved by not caring! | \=======================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 12 22:04:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26659 for ; Wed, 12 Dec 2001 22:04:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBD2jAQ25132 for ietf-calendar-bks; Wed, 12 Dec 2001 18:45:10 -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 fBD2j9225127 for ; Wed, 12 Dec 2001 18:45:09 -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 fBD2ixY15648 for ; Wed, 12 Dec 2001 18:44:59 -0800 (PST) Received: from netscape.com ([205.217.229.47]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO9GZ000.HSZ; Wed, 12 Dec 2001 18:45:00 -0800 Message-ID: <3C181629.19E6BEB6@netscape.com> Date: Wed, 12 Dec 2001 18:44:59 -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: John Stracke CC: ietf-calendar@mail.imc.org Subject: Re: CAP Draft 6 comments References: Content-Type: multipart/mixed; boundary="------------03D945FDC015851ED0242D33" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------03D945FDC015851ED0242D33 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > >Do people have an issue with > >calenders possibly becoming more restrictive after a move? > > What if I *wanted* it to become less restrictive? By analogy to > filesystems, sometimes I move a file into my ~/public_html directory, so > it can be accessed via HTTP. If I want to make a set of events publicly > visible, I might move them into a calendar which grants read access to the > world. then you should move it to a parent that is less restrictive and adjust the vcars accordingly. We're err'ing on the side of caution. -Steve --------------03D945FDC015851ED0242D33 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------03D945FDC015851ED0242D33-- From owner-ietf-calendar@mail.imc.org Wed Dec 12 22:04:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26679 for ; Wed, 12 Dec 2001 22:04:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBD2pQ925287 for ietf-calendar-bks; Wed, 12 Dec 2001 18:51:26 -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 fBD2pO225283 for ; Wed, 12 Dec 2001 18:51:24 -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 fBD2pLY17684 for ; Wed, 12 Dec 2001 18:51:21 -0800 (PST) Received: from netscape.com ([205.217.229.47]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GO9H9M00.4WC for ; Wed, 12 Dec 2001 18:51:22 -0800 Message-ID: <3C1817A9.9CD6ABF8@netscape.com> Date: Wed, 12 Dec 2001 18:51:21 -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: ietf-calendar@mail.imc.org Subject: Re: CAP Draft 6 comments References: <3C167F57.AEAC1FA8@netscape.com> <3C1718A7.C9759B57@Royer.com> <3C178A55.91A63654@netscape.com> <3C17D01A.426CA0A1@Royer.com> Content-Type: multipart/mixed; boundary="------------A2CCBE4A057F18F778F87340" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A2CCBE4A057F18F778F87340 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > > 9. Section 4.1.6 versus 4.1.8 -- the value for METHOD. In some > > > > places, we refer to the METHOD value for "booked" events as NULL, > > > > and in other places we refer to it as CREATED. I happen to > > > > prefer being explicit and keeping it at CREATED, but whatever we > > > > choose we must be consistent. > > > > > > I agree - lets keep it 'CREATE' (same as METHOD:CREATE) not CREATEd. > > > > We all came to that conclusion. One suggestion was that we use "BOOKED" > > instead of "CREATED". > > I could go for that, that would bring up another question. > Can I queue 'CREATE' and store it (like iTIP methods)? Or must > CREATE always be acted on and never stored? yea, this is weird, we use the "create" command to store METHOD:BOOKED ??? maybe we should just stick with "CREATED" -Steve --------------A2CCBE4A057F18F778F87340 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;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;28912 fn:Steve Mansour end:vcard --------------A2CCBE4A057F18F778F87340-- From owner-ietf-calendar@mail.imc.org Thu Dec 13 08:35:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20688 for ; Thu, 13 Dec 2001 08:35:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBDDCTJ16760 for ietf-calendar-bks; Thu, 13 Dec 2001 05:12: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 fBDDCR216750 for ; Thu, 13 Dec 2001 05:12: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 IAA24871; Thu, 13 Dec 2001 08:12:22 -0500 Received: from steltor.com (IDENT:patricel@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 fBDDCIH06736; Thu, 13 Dec 2001 08:12:19 -0500 (EST) Message-ID: <3C18A96B.87D33549@steltor.com> Date: Thu, 13 Dec 2001 08:13:15 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: CAP Draft 6 comments References: <3C167F57.AEAC1FA8@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: > 6. Section 3.3 in the example, the MSG number changes from 4 to 2, shouldn't > they match? No this was on purpose, they are distinct messages originating from different peers. The msgno 4 is for the client request and the associated reply from the server. The msgno 2 is for the the "timeout" request from the server and the associated reply from the client. A comment should probably be added to the example to make this clearer. -- Patrice. From owner-ietf-calendar@mail.imc.org Thu Dec 13 09:22:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21181 for ; Thu, 13 Dec 2001 09:22:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBDE7Uv20599 for ietf-calendar-bks; Thu, 13 Dec 2001 06:07:30 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDE7S220594 for ; Thu, 13 Dec 2001 06:07:28 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@mail.imc.org id JAA08175; Thu Dec 13 09:03:32 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 13 Dec 2001 09:10:17 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/13/2001 09:10:22 AM, Serialize complete at 12/13/2001 09:10:22 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@mail.imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> What if I *wanted* it to become less restrictive? By analogy to > >then you should move it to a parent that is less restrictive and adjust the >vcars accordingly. We're err'ing on the side of caution. Yeah, OK. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===============================================================| |Both candidates are better than a megalomaniac mutant lab mouse| |bent on world domination...but it's pretty close. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Dec 13 14:36:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27960 for ; Thu, 13 Dec 2001 14:36:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBDJKWn12583 for ietf-calendar-bks; Thu, 13 Dec 2001 11:20:32 -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 fBDJKV212579 for ; Thu, 13 Dec 2001 11:20:31 -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 fBDJKNY00762 for ; Thu, 13 Dec 2001 11:20:24 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GOAR2200.R86; Thu, 13 Dec 2001 11:20:26 -0800 Message-ID: <3C18FFC2.9176246@netscape.com> Date: Thu, 13 Dec 2001 11:21:38 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Lapierre CC: CalSched IETF Subject: Re: CAP Draft 6 comments References: <3C167F57.AEAC1FA8@netscape.com> <3C18A96B.87D33549@steltor.com> Content-Type: multipart/mixed; boundary="------------4E444F64A06486606EC9AF92" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4E444F64A06486606EC9AF92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Right. I talked with George about this at the meeting. I'm clear on it now. Yes, we should add some comments to clarify. -Steve Patrice Lapierre wrote: > Steve Mansour wrote: > > 6. Section 3.3 in the example, the MSG number changes from 4 to 2, shouldn't > > they match? > > No this was on purpose, they are distinct messages originating from > different peers. The msgno 4 is for the client request and the > associated reply from the server. The msgno 2 is for the the > "timeout" request from the server and the associated reply > from the client. > > A comment should probably be added to the example to make > this clearer. > > -- > Patrice. --------------4E444F64A06486606EC9AF92 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:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------4E444F64A06486606EC9AF92-- From owner-ietf-calendar@mail.imc.org Thu Dec 13 20:48:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03669 for ; Thu, 13 Dec 2001 20:48:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBE1XcY04478 for ietf-calendar-bks; Thu, 13 Dec 2001 17:33:38 -0800 (PST) Received: from royer.com (royer.com [206.162.94.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE1Xb204474 for ; Thu, 13 Dec 2001 17:33:37 -0800 (PST) Received: from Royer.com (red.royer.com [199.104.81.57]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA16110 for ; Thu, 13 Dec 2001 17:33:35 -0800 (PST) Message-ID: <3C1956ED.C4396EE2@Royer.com> Date: Thu, 13 Dec 2001 18:33:33 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: CalSched IETF Subject: Re: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------335AB5F5D641366E1FCC2B5F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------335AB5F5D641366E1FCC2B5F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > (c) CS Never processes VALARMs. > > This is valid, and simple. A helper daemon polling the CS via CAP would > suffice to make email-based alarms work. Of course, the helper daemon > would need privileges to read all VALARMs. Would ALL CUA's send alarms - including the one the user is connected to? If not, how would they know other CUA's were connected? > > ... (d) CS Only process the tagged VALARMs. > > This might be a good approach; then the CUA can say, "please handle this > VALARM when it goes off", and the CS can say, "I can't handle audio > alarms, you dope.". We would need a new property / parameter in VALARM for this to work. My real purpose was to point out that I don't think that this has been discussed yet on this list. I would lean for (d), with a capability or VCAR in the CS to signify what kinds of alarms the CS can support at all or will do for the authenticated entity. Should we tweak VCAR to add this? What the CS will do may depend on the calendar, source of VALARM, or authenticated or anonymous requesting entity. --------------335AB5F5D641366E1FCC2B5F 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------335AB5F5D641366E1FCC2B5F-- From owner-ietf-calendar@mail.imc.org Fri Dec 14 09:35:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00107 for ; Fri, 14 Dec 2001 09:35:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBEE7SN00840 for ietf-calendar-bks; Fri, 14 Dec 2001 06:07:28 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBEE7Q200833 for ; Fri, 14 Dec 2001 06:07:26 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA13617; Fri Dec 14 09:04:51 2001 Subject: Re: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 14 Dec 2001 09:11:38 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/14/2001 09:11:46 AM, Serialize complete at 12/14/2001 09:11:46 AM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> > (c) CS Never processes VALARMs. >> >> This is valid, and simple. > >Would ALL CUA's send alarms Er. Good point. >> > ... (d) CS Only process the tagged VALARMs. >> >> This might be a good approach; then the CUA can say, "please handle this >> VALARM when it goes off", and the CS can say, "I can't handle audio >> alarms, you dope.". > >We would need a new property / parameter in VALARM for this to work. True. Not a big deal. We might also be able to generalize the property to be a "who will send this alarm?" marker. Off the top of my head...call the property "SENDER"; it's a UID; the UID "CS" would mean the CS; each CUA would have a UID that means itself; when a CU wants to tell their current CUA to send the alarm, it sets SENDER to its UID. Or perhaps SENDERS, a list of UIDs, if we think it'd be useful to have multiple CUAs send the alarm (might be more practical to have multiple alarms, though). This would solve the problem you raised about (c), because there will always be types of alarms that the CS doesn't handle, and you probably don't want all your CUAs processing all of them. (On the other hand, for most people, that may not be too much of a problem; most users have no more than 2 CUAs, desktop and PDA, if that. 80/20 rule?) /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |This space intentionally left blank. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Tue Dec 18 14:42:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24996 for ; Tue, 18 Dec 2001 14:42:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIJLlc25312 for ietf-calendar-bks; Tue, 18 Dec 2001 11:21: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 fBIJLA225299 for ; Tue, 18 Dec 2001 11:21:11 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.85]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA01488 for ; Tue, 18 Dec 2001 11:20:18 -0800 (PST) Message-ID: <3C1F966D.CF96380C@Royer.com> Date: Tue, 18 Dec 2001 12:18: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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@mail.imc.org" Subject: Re: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------E463B7852C55497C143FBDED" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E463B7852C55497C143FBDED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > > >> > ... (d) CS Only process the tagged VALARMs. > >> > >> This might be a good approach; then the CUA can say, "please handle > this > >> VALARM when it goes off", and the CS can say, "I can't handle audio > >> alarms, you dope.". > > > >We would need a new property / parameter in VALARM for this to work. > > True. Not a big deal. > > We might also be able to generalize the property to be a "who will send > this alarm?" marker. Off the top of my head...call the property "SENDER"; > it's a UID; the UID "CS" would mean the CS; each CUA would have a UID that > means itself; when a CU wants to tell their current CUA to send the alarm, > it sets SENDER to its UID. Or perhaps SENDERS, a list of UIDs, if we > think it'd be useful to have multiple CUAs send the alarm (might be more > practical to have multiple alarms, though). We need to stop overloading 'UID'. I mean do we really NEED to have the value of this tag Unique in the World for each entry (else it's not unique)? How about just a URI? It does not matter what it is, as long as the CUA and CS know if it is them. For a CS, the URI is its own RELCALID. If it's not its own ID, then the CS does not care who it is - it's just stored. > This would solve the problem you raised about (c), because there will > always be types of alarms that the CS doesn't handle, and you probably > don't want all your CUAs processing all of them. (On the other hand, for > most people, that may not be too much of a problem; most users have no > more than 2 CUAs, desktop and PDA, if that. 80/20 rule?) Do we need a CS (or CAL) property that identifies which types the CS supports? (BTW: After I got my system up, Royer.com's upstream provider died, then it took Verison 5 Days to fix it! So I am now alive and well - living in the snowy Snake River Valley). --------------E463B7852C55497C143FBDED 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 18 Dec 2001 15:56:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIKhsx29085 for ietf-calendar-bks; Tue, 18 Dec 2001 12:43:54 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIKhq229076; Tue, 18 Dec 2001 12:43:52 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@mail.imc.org id PAA01318; Tue Dec 18 15:37:08 2001 Subject: Re: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 18 Dec 2001 15:44:18 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/18/2001 03:44:28 PM, Serialize complete at 12/18/2001 03:44:28 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Cc: "ietf-calendar@mail.imc.org" , owner-ietf-calendar@mail.imc.org Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> We might also be able to generalize the property to be a "who will send >> this alarm?" marker. Off the top of my head...call the property "SENDER"; >> it's a UID; the UID "CS" would mean the CS; each CUA would have a UID that >> means itself; when a CU wants to tell their current CUA to send the alarm, >> it sets SENDER to its UID. Or perhaps SENDERS, a list of UIDs, if we >> think it'd be useful to have multiple CUAs send the alarm (might be more >> practical to have multiple alarms, though). > >We need to stop overloading 'UID'. I mean do we really NEED >to have the value of this tag Unique in the World for each >entry (else it's not unique)? Uh...yes, I think we do. Otherwise, how do you keep two CUAs from picking the same one? Remember, in this case, "two CUAs" might mean the same software installed on two different machines, or different software on the same machine, or, conceivably, even two different user profiles of the same software on the same machine. Using a UID to identify it may be overkill, but it means that we don't have to figure out how unique we need to be. >Do we need a CS (or CAL) property that identifies which types >the CS supports? Maybe. I'm inclined to punt it, though, because the only standard type that makes sense on the CS at this point is email. Given the existence of procedure alarms, it could become a hard problem--we'd have to distinguish between subtypes of procedure alarms that the CS can support and those that it can't. The "ask and you shall be refused" approach has the virtue that the CS can decide on an ad hoc basis. Maybe there should be a way to ask the CS whether a given alarm would be supported, without actually asking the CS to handle it? Then the CUA could grey out its "Trigger on server" command (or whatever) when it's not possible. /============================================================\ |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 Tue Dec 18 15:56:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26573 for ; Tue, 18 Dec 2001 15:56:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIKi1W29095 for ietf-calendar-bks; Tue, 18 Dec 2001 12:44:01 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIKi0229091 for ; Tue, 18 Dec 2001 12:44:00 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id PAA01317; Tue Dec 18 15:37:09 2001 Subject: Re: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 18 Dec 2001 15:44:18 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/18/2001 03:44:28 PM, Serialize complete at 12/18/2001 03:44:28 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Cc: "ietf-calendar@mail.imc.org" , owner-ietf-calendar@mail.imc.org Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> We might also be able to generalize the property to be a "who will send >> this alarm?" marker. Off the top of my head...call the property "SENDER"; >> it's a UID; the UID "CS" would mean the CS; each CUA would have a UID that >> means itself; when a CU wants to tell their current CUA to send the alarm, >> it sets SENDER to its UID. Or perhaps SENDERS, a list of UIDs, if we >> think it'd be useful to have multiple CUAs send the alarm (might be more >> practical to have multiple alarms, though). > >We need to stop overloading 'UID'. I mean do we really NEED >to have the value of this tag Unique in the World for each >entry (else it's not unique)? Uh...yes, I think we do. Otherwise, how do you keep two CUAs from picking the same one? Remember, in this case, "two CUAs" might mean the same software installed on two different machines, or different software on the same machine, or, conceivably, even two different user profiles of the same software on the same machine. Using a UID to identify it may be overkill, but it means that we don't have to figure out how unique we need to be. >Do we need a CS (or CAL) property that identifies which types >the CS supports? Maybe. I'm inclined to punt it, though, because the only standard type that makes sense on the CS at this point is email. Given the existence of procedure alarms, it could become a hard problem--we'd have to distinguish between subtypes of procedure alarms that the CS can support and those that it can't. The "ask and you shall be refused" approach has the virtue that the CS can decide on an ad hoc basis. Maybe there should be a way to ask the CS whether a given alarm would be supported, without actually asking the CS to handle it? Then the CUA could grey out its "Trigger on server" command (or whatever) when it's not possible. /============================================================\ |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 Tue Dec 18 17:28:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28017 for ; Tue, 18 Dec 2001 17:28:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBIM7mu04316 for ietf-calendar-bks; Tue, 18 Dec 2001 14:07: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 fBIM7b204298 for ; Tue, 18 Dec 2001 14:07:37 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.85]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA02295 for ; Tue, 18 Dec 2001 14:07:06 -0800 (PST) Message-ID: <3C1FBD7F.A2E7E787@Royer.com> Date: Tue, 18 Dec 2001 15:04: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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "ietf-calendar@mail.imc.org" Subject: Re: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------AD7F39E928031F4E64F53591" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AD7F39E928031F4E64F53591 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > >We need to stop overloading 'UID'. I mean do we really NEED > >to have the value of this tag Unique in the World for each > >entry (else it's not unique)? > > Uh...yes, I think we do. Otherwise, how do you keep two CUAs from picking > the same one? What if I want it to go to the CUA that I am connected with? And not a specific CUA? As in if ANY CUA is connected, then the CUA will send the alarm, else the CS sends it. So the value could be CUA or CS and not a UID. I am not yet proposing we do this, I am just trying to figure out the requirements. > Remember, in this case, "two CUAs" might mean the same software installed > on two different machines, or different software on the same machine, or, > conceivably, even two different user profiles of the same software on the > same machine. Using a UID to identify it may be overkill, but it means > that we don't have to figure out how unique we need to be. The problem is we may be too unique. --------------AD7F39E928031F4E64F53591 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 19 Dec 2001 11:06:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJFVBB27275 for ietf-calendar-bks; Wed, 19 Dec 2001 07:31:11 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJFVA227271 for ; Wed, 19 Dec 2001 07:31:10 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA03219; Wed Dec 19 10:25:44 2001 Subject: Re: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 19 Dec 2001 10:33:00 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/19/2001 10:33:08 AM, Serialize complete at 12/19/2001 10:33:08 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >What if I want it to go to the CUA that I am connected with? >And not a specific CUA? As in if ANY CUA is connected, then >the CUA will send the alarm, else the CS sends it. I think there are problems with that. The big one: Suppose the clocks on the CUA and the CS are not in sync--say, the CS's clock is 1 minute ahead of the CUA's. I have an alarm set for 2:00. At 1:59:30, CS time (1:58:30, CUA time), the CUA connects. At 2:00:00, CS time (1:59:00, CUA time), the CS decides it doesn't need to send an alarm. At 2:00:10, CS time (1:59:10, CUA time), the CUA disconnects and exits. At 2:00:00, CUA time, the CUA is not running, so it doesn't send an alarm. The alarm is lost. In addition, there are a couple of scenarios involving CUAs that don't fit the mold of a long-lived app with a continual connection to the CS. For example, you might have a daemon syncing your calendar down to a desktop PIM; it's got no UI at all, and shouldn't be sending alarms. Or you might have a Web-based app that makes transient connections to the CS; the only way for it to handle alarms would be if it queried the CS for them on every single page view. /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Unless. -- The Lorax | \=======================================================/ From owner-ietf-calendar@mail.imc.org Wed Dec 19 16:30:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07818 for ; Wed, 19 Dec 2001 16:30:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJLFcB19878 for ietf-calendar-bks; Wed, 19 Dec 2001 13:15: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 fBJLFb219874 for ; Wed, 19 Dec 2001 13:15:37 -0800 (PST) Received: from Royer.com (red.royer.com [12.7.223.214]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA03469 for ; Wed, 19 Dec 2001 13:14:54 -0800 (PST) Message-ID: <3C2102BE.25493826@Royer.com> Date: Wed, 19 Dec 2001 14:12: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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------1877C3A9D0B81C7A25B99388" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1877C3A9D0B81C7A25B99388 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >What if I want it to go to the CUA that I am connected with? > >And not a specific CUA? As in if ANY CUA is connected, then > >the CUA will send the alarm, else the CS sends it. > > I think there are problems with that. Yep. > The big one: Suppose the clocks on the CUA and the CS are not in > sync--say, the CS's clock is 1 minute ahead of the CUA's. I have an alarm > set for 2:00. At 1:59:30, CS time (1:58:30, CUA time), the CUA connects. > At 2:00:00, CS time (1:59:00, CUA time), the CS decides it doesn't need to > send an alarm. At 2:00:10, CS time (1:59:10, CUA time), the CUA > disconnects and exits. At 2:00:00, CUA time, the CUA is not running, so > it doesn't send an alarm. The alarm is lost. Yep. The same problem exists if several CUA's are connected and you only want one to send the alarm. > In addition, there are a couple of scenarios involving CUAs that don't fit > the mold of a long-lived app with a continual connection to the CS. For > example, you might have a daemon syncing your calendar down to a desktop > PIM; it's got no UI at all, and shouldn't be sending alarms. Or you might > have a Web-based app that makes transient connections to the CS; the only > way for it to handle alarms would be if it queried the CS for them on > every single page view. We need MUCH more work on the alarms. I don't think this should slow down or stop CAP. But it is unresolved. -Doug --------------1877C3A9D0B81C7A25B99388 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 19 Dec 2001 17:02:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJLpXU21307 for ietf-calendar-bks; Wed, 19 Dec 2001 13:51:33 -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 fBJLpV221303 for ; Wed, 19 Dec 2001 13:51:31 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id PAA15055 for ; Wed, 19 Dec 2001 15:50:26 -0600 From: "Shannon J. Clark" To: Subject: Alarms - was RE: Question on calstore current time. Date: Wed, 19 Dec 2001 15:51:22 -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: <3C2102BE.25493826@Royer.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just a thought along these lines: First - how do vendors CURRENTLY handle alarms - i.e. can the vendors here each speak up and explain how they handle it today... interoperability etc will be greatly eased if we set a standard that is not too distant from current practices. Second - fundamentally what are the REQUIREMENTS around alarms? Are ALL alarms a user-centric condition - i.e. each attendee for a given event might want DIFFERENT alarm conditions (including no alarm at all) - if this is the case - do they belong in CAP at all? Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Wednesday, December 19, 2001 3:12 PM To: ietf-calendar@imc.org Subject: Re: Question on calstore current time. John Stracke wrote: > > >What if I want it to go to the CUA that I am connected with? > >And not a specific CUA? As in if ANY CUA is connected, then > >the CUA will send the alarm, else the CS sends it. > > I think there are problems with that. Yep. > The big one: Suppose the clocks on the CUA and the CS are not in > sync--say, the CS's clock is 1 minute ahead of the CUA's. I have an alarm > set for 2:00. At 1:59:30, CS time (1:58:30, CUA time), the CUA connects. > At 2:00:00, CS time (1:59:00, CUA time), the CS decides it doesn't need to > send an alarm. At 2:00:10, CS time (1:59:10, CUA time), the CUA > disconnects and exits. At 2:00:00, CUA time, the CUA is not running, so > it doesn't send an alarm. The alarm is lost. Yep. The same problem exists if several CUA's are connected and you only want one to send the alarm. > In addition, there are a couple of scenarios involving CUAs that don't fit > the mold of a long-lived app with a continual connection to the CS. For > example, you might have a daemon syncing your calendar down to a desktop > PIM; it's got no UI at all, and shouldn't be sending alarms. Or you might > have a Web-based app that makes transient connections to the CS; the only > way for it to handle alarms would be if it queried the CS for them on > every single page view. We need MUCH more work on the alarms. I don't think this should slow down or stop CAP. But it is unresolved. -Doug From owner-ietf-calendar@mail.imc.org Wed Dec 19 17:10:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08787 for ; Wed, 19 Dec 2001 17:10:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJLw5w21459 for ietf-calendar-bks; Wed, 19 Dec 2001 13:58:05 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJLw3221454 for ; Wed, 19 Dec 2001 13:58:03 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id fBJLrEf04565; Wed, 19 Dec 2001 13:53:14 -0800 (PST) Message-ID: <042401c188d8$3acd2180$fe0aa840@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" References: <3C2102BE.25493826@Royer.com> Subject: apb to any author of the cap or guide documents Date: Wed, 19 Dec 2001 13:58:01 -0800 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 hi. can any author of either the cap or guide documents please reply to this note? i've tried sending you some email with some formatting comments, but it bounces. thanks, /mtr From owner-ietf-calendar@mail.imc.org Wed Dec 19 18:50:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10457 for ; Wed, 19 Dec 2001 18:50:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBJNSea28030 for ietf-calendar-bks; Wed, 19 Dec 2001 15:28: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 fBJNSd228026 for ; Wed, 19 Dec 2001 15:28: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 PAA03607 for ; Wed, 19 Dec 2001 15:28:10 -0800 (PST) Message-ID: <3C21227D.C149F373@Royer.com> Date: Wed, 19 Dec 2001 16:27:57 -0700 From: Doug Royer Organization: INET-Consulting LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: Alarms - was RE: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------9F19CCC14DB4A97324A69A15" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9F19CCC14DB4A97324A69A15 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Just a thought along these lines: > > First - how do vendors CURRENTLY handle alarms - i.e. can the vendors here > each speak up and explain how they handle it today... interoperability etc > will be greatly eased if we set a standard that is not too distant from > current practices. There are no standard current practices. When I was working at Sun one of the most common bugs filed was 'The alarms do not work'. Only to find out that the CUA was not connected or was not running at the time of the alarm. People expect them to work. It is not clear what that is. Some CS's (yahoo and hotmail for example), only send alarms from their calendar servers - the CUA's never send the alarms. I don't know what AOL does. There is no one way to do it. > Second - fundamentally what are the REQUIREMENTS around alarms? > Are ALL alarms a user-centric condition - i.e. each attendee > for a given event might want DIFFERENT alarm conditions (including > no alarm at all) - if this is the case - do they belong in CAP > at all? I think that the CALSCH WG needs to address the issues. CAP is the calendar access protocol for iCalendar - they are in iCalendar so this WG needs to figure it out. And as there does not seem to be a standard or even common way to handle this, we need to look at why there are different methods: (1) Web based CUA's can't send alarms if they are html clients only because calendaring is not (and should not be) built into html. (Why am I limited to email alarms only?) (2) Some CS's can't send alarms because they may be roaming systems. So they could only queue the alarm when not connected to the net. (My CUA had the alarm in it - why did I not get the alarm?) (3) Some implementations ONLY send alarms from the CUA. These seem to be intra-net systems where it is assumed both the CUA and CS are on the same local domain and connected most or all of the time. (The CS had the alarm - and it did not go to me, that's why I put the stupid alarm in the CS). Notification of sporting events that you have signed up for. They are not going to wait around for the CU to login with a CUA. The reason these alarms exist is to notify users of things when they don't know when they are occurring, or when the CUA should connect just to process alarms. In addition these CS's may not want everyone polling them for alarms or staying connected 24x7 just to see when the NFL schedule is updated. I think these variations exist because there is no standard way to exchange alarm information. We have standardized on a way to specify what alarm we want (the VALARM). Now we need to standardize on a way to exchange the importance of getting the alarm processed and sent on time. We need to acknowledge that having all alarms processed at one end or the other may not always work. I don't know the answer yet - but ignoring this issue for very long is going to cause interoperability issues. --------------9F19CCC14DB4A97324A69A15 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard --------------9F19CCC14DB4A97324A69A15-- From owner-ietf-calendar@mail.imc.org Wed Dec 19 20:16:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11312 for ; Wed, 19 Dec 2001 20:16:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBK11x802725 for ietf-calendar-bks; Wed, 19 Dec 2001 17:01:59 -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 fBK11w202721 for ; Wed, 19 Dec 2001 17:01:58 -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 fBK11rY04385 for ; Wed, 19 Dec 2001 17:01:54 -0800 (PST) Received: from netscape.com ([208.12.57.177]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GOMAV700.6KO; Wed, 19 Dec 2001 17:01:55 -0800 Message-ID: <3C213857.C0E32BC0@netscape.com> Date: Wed, 19 Dec 2001 17:01:11 -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: "Marshall T. Rose" CC: ietf-calendar@imc.org, Marshall Rose Subject: Re: apb to any author of the cap or guide documents References: <3C2102BE.25493826@Royer.com> <042401c188d8$3acd2180$fe0aa840@FATORA> 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 "Marshall T. Rose" wrote: > hi. can any author of either the cap or guide documents please reply to this > note? i've tried sending you some email with some formatting comments, but > it bounces. Hi Marshall, what's up? -Steve From owner-ietf-calendar@mail.imc.org Thu Dec 20 12:31:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13606 for ; Thu, 20 Dec 2001 12:31:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKH8YS14222 for ietf-calendar-bks; Thu, 20 Dec 2001 09: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 fBKH8X214218 for ; Thu, 20 Dec 2001 09:08:33 -0800 (PST) To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: Re: Alarms - was RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_12112001 December 11, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 20 Dec 2001 12:23:45 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 12/20/2001 12:24:10 PM, Serialize complete at 12/20/2001 12:24:10 PM Content-Type: multipart/alternative; boundary="=_alternative 005DBC1F85256B28_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DBC1F85256B28_= Content-Type: text/plain; charset="US-ASCII" Shannon asked on 12/19/2001 04:51:22 PM: > First - how do vendors CURRENTLY handle alarms - i.e. can the vendors here > each speak up and explain how they handle it today... For every vendor here Im sure you'll get a slightly different answer. Basically it falls into 2 categories: some use 'server push' models and some use 'client pull' models. Notes uses the latter scheme so that it can present "missed alarms" to the user the next time they log in ("Mobile" or "Disconnected" users access an 'internal' server in the client). No matter what route you take, every method has its strengths and weaknesses (otherwise there would be just "the" accepted way to implement it). I suspect that in order to get a "client pull" CS to work with a "server push" CUA that some negotiation between the two is going to be necessary and the same for the converse rolls. > Second - fundamentally what are the REQUIREMENTS around alarms? [Snip, snip] > do they belong in CAP at all? I think CAP MUST address it. As an access protocol for C&S, it must provide some way for a user to access their alarms as well as the actual entries. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005DBC1F85256B28_= Content-Type: text/html; charset="US-ASCII"
Shannon asked on 12/19/2001 04:51:22 PM:
> First - how do vendors CURRENTLY handle alarms - i.e. can the vendors here
> each speak up and explain how they handle it today...

For every vendor here Im sure you'll get a slightly different answer.  Basically it falls into 2 categories: some use 'server push' models and some use 'client pull' models.  Notes uses the latter scheme so that it can present "missed alarms" to the user the next time they log in ("Mobile" or "Disconnected" users access an 'internal' server in the client).

No matter what route you take, every method has its strengths and weaknesses (otherwise there would be just "the" accepted way to implement it).  I suspect that in order to get a "client pull" CS to work with a "server push" CUA that some negotiation between the two is going to be necessary and the same for the converse rolls.

> Second - fundamentally what are the REQUIREMENTS around alarms?
[Snip, snip]
>       do they belong in CAP at all?
I think CAP MUST address it.  As an access protocol for C&S, it must provide some way for a user to access their alarms as well as the actual entries.  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005DBC1F85256B28_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 20 12:46:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14320 for ; Thu, 20 Dec 2001 12:46:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKHP5Y14683 for ietf-calendar-bks; Thu, 20 Dec 2001 09:25: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 fBKHP4214679 for ; Thu, 20 Dec 2001 09:25: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 MAA06876 for ; Thu, 20 Dec 2001 12:25:00 -0500 Received: from steltor.com ([192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBKHOoH05113 for ; Thu, 20 Dec 2001 12:24:50 -0500 (EST) Message-ID: <3C221F20.D92B2355@steltor.com> Date: Thu, 20 Dec 2001 12:25:52 -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: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> <3BFEBEE2.2F736E3D@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 For those that haven't follow this thread closely here's a summary of my proposition : 1- Let's add a UID property in VCAR components to have a way to uniquely identify them. How can we go wrong by putting unique ids in components? :-) 2- Let's add a NAME property in VCAR components to allow users to specify a localizable display name in their VCARs. 3- Let's use the NAME property in VCAR components to hold the predefined names of the CAR-MIN VCARs. These predefined names would not be localized, but a CUA could always display them in a localized form. 4- CARREF should be made to unique ids (UID) instead of names (NAME) which are not unique. Here's some examples: Definition of the CAR-MIN DEFAULTOWNER: BEGIN:VCAR UID:20011121T120000Z-00005@host.com NAME:DEFAULTOWNER ... END:VCAR Definition of a VCAR that grants READ rights to Doug: BEGIN:VCAR UID:20011121T120000Z-00006@host.com NAME;LANGUAGE=FR-ca:Octroyer droits de lecture a Doug ... END:VCAR Definition of a VCAR that makes a reference to the previous VCAR: BEGIN:VCAR UID:20011121T120000Z-00007@host.com GRANT:CARREF=20011121T120000Z-00006@host.com ... END:VCAR Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > BTW, OWNERRIGHTS is not part of the predefined CARID, > > but that's beside the point. > > Should have said DEFAULTOWNER -- :-) > (This one moved from the end, I modified the text send by Bernard > and myself by replacing OWNERRIGHTS with the correct tag: DEFAULTOWNER). > > > Doug Royer wrote: > > > > > > Bernard Desruisseaux wrote: > > > > > > > 2- Do we really need a VCAR specific property to hold > > > > VCAR identifiers? Couldn't we simply use the UID > > > > property for that purpose? > > > > > > The more I think about this, the more I am concerned that > > > it's not a good idea. Take the predefined CARID's for example: > > > > > > DEFAULTOWNER is the CARID. > > > > > > However MANY different calendars will not have the same contents > > > for that VCAR. So it is no longer a unique ID for a VCAR. It is only > > > unique for its scope. So by definition we would be defining VCARS > > > with Unique IDs that were not Unique IDs. And a VCAR/UID would then > > > not uniquely define a VCAR. > > > > > > For ALARMID, we are not pre-defining any, so UID would be okay > > > with me. > > > > On the other hand, when I would write the following VCAR: > > > > BEGIN:VCAR > > GRANT:CARREF:DEFAULTOWER > > ... > > END:VCAR > > You could, but I don't think that is a valid VCAR. > Did you mean the following VCAR that uses an existing VCAR? > > BEGIN:VCAR > GRANT;CARID=DEFAULTOWNER:... > ... > END:VCAR I mistakenly put a colon (:) after CARREF instead of an equal sign (=). Other than that, my examples follows the specification (http://calsch.org/ietf/iCal-updates.html). On the other hand, I would agree that we need to review how VCAR should make reference to other VCARs. I will propose something to the list. > > I wouldn't know for sure that it will always make reference > > to the same VCAR. As I said above, by making reference to non-unique CARID, VCARs making reference to a VCAR that has just been deleted will all of a sudden start making reference to another VCAR. In my opinion, this could lead to bad surprise. References (CARREF) should be made to unique ids (UID) to avoid such surprise. > > Furthermore, a VQUERY performed on a hierarchy of VAGENDAs > > could return multiple VCARs with the same CARID. The calendar > > user wouldn't have any way to distinguish the returned VCARs. > > For the same TARGET, the contents of CARID 'foo' is only the > same at one instance in time. And a VCAR is contained in the hierarchy > of BEGIN/END matched to a TARGET and CMDID, thus TARGET+CARID is > unique at one point in time. > > It is true that TARGET:1 and TARGET:2 can each have a CARID:123 > and they might not have same contents. That's my point - it is > CARID is only unique per calendar. Unlike UID which is supposed > to be unique in the world. > > With CARID, a CUA can find out what it can do, and there is > a handle to help organize them in a calendar. But the contents > of that VCAR are not static - only the CARID value is static > and as CUA's need to find out what they can do, that is why > the predefined CARIDs were created - so a CUA can find > things by predefined name - CARID. > > > Finally, enforcing specific identifier for the CAR-MIN VCAR > > will not allow users to make reference to the VCAR they are > > re-defining (their new definition would hide the previous > > definition(s)). > > The point of the defined VCARs is that a CUA can find > if it can do specific things and find the calendars specific > contents for that known named CARID. So no matter what > the contents of that VCAR, a CUA can find its REQUESTONLY by > doing a VQUERY for REQUESTONLY by name. > > Otherwise a CUA would have to VQUERY for all VCARs, then > sort them itself. You are assuming that a CU will always have READ access to all the VCARs that applies to him. If I'm giving you access to my calendar I may not want you to know who else has access to my calendar. Although CUAs may try to evaluate the VCARs, only the CS will be able to evaluate them properly. > > > What would you think of using reserved names for the CAR-MIN > > VCARs instead? > > The predefined CARIDs are part of CAR-MIN. So, what do > you mean by 'instead'? Did you mean CAR-MIN only? If so > we would have two version of VCAR. Currently one is just an > extension of the other. I meant using the NAME property to hold the value of predefined "names", e.g., NAME:DEFAULTOWNER while using UID to hold an Id unique in the world : UID:20011121T120000Z-00003@host.com > > > It is not ideal, since we would have to make > > the CUA responsible for the localization of these reserved > > names, > > The point is that they are FIXED names, so a CUA can do > a VQUERY by name - localizing the 'reserved names' breaks > that ability. The NAMEs would NOT be stored localized on the server in order to keep this ability. As I said, it would be the responsiblity of the CUA to localized these reserved-names (if at all). > >but on the other hand, it should be sufficient to meet > > our requirements. For instance: > > > > BEGIN:VCAR > > UID:20011121T120000Z-00003@host.com > > NAME:DEFAULTOWNER > > ... > > END:VCAR > > How? Above you said that DEFAULTOWNER can be localized, so > tell me, how I find the DEFAULTOWNER if you call it 'asldkfjfjs' > in your locale? Show me a VQUERY that can fetch DEFAULTOWNER > no matter what the localized name? I meant to say that the CUA could localized DEFAULTOWNER if it wants to, not that the NAME could not be stored localized in the server. So the CUA would always query the NAME DEFAULTOWNER. > > > That raises another question with respect to overriding > > inherited VCARs: > > > > Was a VCAR with the CARID:DEFALTOWNER(a) supposed to override > > all RIGHTS value type of other VCARs with the same CARID > > in the calendar hierarchy, or (b) simply specific GRANT and > > DENY as you mentioned in your reply to (VCAR: Overriding > > inherited VCAR)? > > In all cases, a calendars specific VCARS details override any > inherited VCAR details. So yes (b). > > I took your original question to mean: > > What happens if the VCAR for a calendar overrides > some (but not all) of the GRANT/DENY that it would > have inherited? > > I think I said that those specific differences are resolved > to the calendar specific VCARs - the specific calendar VCAR > details win. > > Top level calendar: > > BEGIN:VCAR > CARID:REQUESTONLY > GRANT:UPN=joe,sam,tom;.... > ... > END:VCAR > > Target Sub-Calendar under the Top level calendar: > > BEGIN:VCAR > CARID:REQUESTONLY > DENY:UPN=joe:... > ... > END:VCAR > > Sam and Tom only can do METHOD:REQUEST on the target calendar. > A VQUERY for REQUSESTONLY on the target calendar would return: > > BEGIN:VCAR > CARID:REQUESTONLY > GRANT:UPN=sam,tom > ... > END:VCAR Hold on, if the VCAR returned by the "search" command is the computed VCAR as you say, how will I be able to get the value of the stored VCAR so that I can modify it? Although it may seem handy to return computed VCAR to CUA, we have to keep in mind that the main goal is to allow calendar users to set their access rights through CAP, not to perform the evaluation of VCARs themselves. > Even though no specific VCAR with those contents was specifically > stored. The predefined VCARs are by function identifiable > by CARID, not by contents. That's why UID is not valid, at > no point would that UID in a VCAR uniquely identify any contents. > > > If (a) is true, why the CAR-MIN VCAR need to be handled in > > a special way? > > CAR-MIN is a subset of CAR-FULL. The fact is that there > are some VCARs predefined by 'function', VQUERYable by predefined > CARIDs who's contents are not predefined and thus not unique. > > > If (b) is true, there is no reason to use the same CARID > > more than once. Any VCAR can override the CAR-MIN VCARs > > regardless of its CARID. > > I think that my example shows that the same CARID is used > more than once in a CS- and needs to be. > > -Doug 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 Dec 20 13:32:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15729 for ; Thu, 20 Dec 2001 13:32:30 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBKIA6V17365 for ietf-calendar-bks; Thu, 20 Dec 2001 10:10:06 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKIA5217361 for ; Thu, 20 Dec 2001 10:10:05 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id NAA04885; Thu Dec 20 13:05:00 2001 Subject: Re: Alarms - was RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 20 Dec 2001 13:12:28 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/20/2001 01:12:30 PM, Serialize complete at 12/20/2001 01:12:30 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I suspect that in order to get a "client pull" CS to work with a >"server push" CUA that some negotiation between the two is going to >be necessary and the same for the converse rolls. Definitely. Unless we want to mandate one way or the other (a Bad Thing, I think), we'll probably need some way for the CUA to say, "please push this alarm", and for the CS to say yes or no. /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |Round up the usual disclaimers. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Thu Dec 20 13:54:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16654 for ; Thu, 20 Dec 2001 13:54:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKIWi918394 for ietf-calendar-bks; Thu, 20 Dec 2001 10:32:44 -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 fBKIWV218390 for ; Thu, 20 Dec 2001 10:32:31 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA16025; Thu, 20 Dec 2001 12:30:18 -0600 From: "Shannon J. Clark" To: Cc: Subject: RE: Alarms - was RE: Question on calstore current time. Date: Thu, 20 Dec 2001 12:31:35 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C18952.437EEDC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C18952.437EEDC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bruce, Thanks - I guess what I am getting at when I ask whether CAP must address alarms is asking whether alarms are fundamental (i.e. a requirement) for interoperating calendar systems - or whether they are a characteristic of Calendar USER agents - i.e. since so far the examples appear to be specific to ONE user - are they something that must be a part of the core calendaring specs? Or could they be considered a very optional component and something that is specific to the vendor(s) involved in a given application? Perhaps though there should be a standard way to separate off and store this vendor specific information - so I could see an argument for some data structure - just wondering how much or how little is really required. I am struggling a bit to see a clear reason alarms are a standardized element - i.e. they seem to be very specific in nature to a given vendor's application - unless we are suggesting that there be two elements to an alarm - one "when it should happen" - and a second, specific to a given application, of "what" should then happen???? Shannon -----Original Message----- From: Bruce_Kahn@iris.com [mailto:Bruce_Kahn@iris.com] Sent: Thursday, December 20, 2001 11:24 AM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: Re: Alarms - was RE: Question on calstore current time. Shannon asked on 12/19/2001 04:51:22 PM: > First - how do vendors CURRENTLY handle alarms - i.e. can the vendors here > each speak up and explain how they handle it today... For every vendor here Im sure you'll get a slightly different answer. Basically it falls into 2 categories: some use 'server push' models and some use 'client pull' models. Notes uses the latter scheme so that it can present "missed alarms" to the user the next time they log in ("Mobile" or "Disconnected" users access an 'internal' server in the client). No matter what route you take, every method has its strengths and weaknesses (otherwise there would be just "the" accepted way to implement it). I suspect that in order to get a "client pull" CS to work with a "server push" CUA that some negotiation between the two is going to be necessary and the same for the converse rolls. > Second - fundamentally what are the REQUIREMENTS around alarms? [Snip, snip] > do they belong in CAP at all? I think CAP MUST address it. As an access protocol for C&S, it must provide some way for a user to access their alarms as well as the actual entries. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... ------=_NextPart_000_000D_01C18952.437EEDC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bruce,
 
Thanks = - I guess=20 what I am getting at when I ask whether CAP must address alarms is = asking=20 whether alarms are fundamental (i.e. a requirement) for interoperating = calendar=20 systems - or whether they are a characteristic of Calendar USER agents - = i.e.=20 since so far the examples appear to be specific to ONE user - are they = something=20 that must be a part of the core calendaring specs? Or could they be = considered a=20 very optional component and something that is specific to the vendor(s) = involved=20 in a given application?
 
Perhaps though there=20 should be a standard way to separate off and store this vendor specific=20 information - so I could see an argument for some data structure - just=20 wondering how much or how little is really required.
 
I am = struggling a=20 bit to see a clear reason alarms are a standardized element - i.e. they = seem to=20 be very specific in nature to a given vendor's application - unless we = are=20 suggesting that there be two elements to an alarm - one "when it should = happen"=20 - and a second, specific to a given application, of "what" should then=20 happen????
 
Shannon
-----Original Message-----
From: = Bruce_Kahn@iris.com=20 [mailto:Bruce_Kahn@iris.com]
Sent: Thursday, December 20, = 2001 11:24=20 AM
To: Shannon J. Clark
Cc:=20 ietf-calendar@imc.org
Subject: Re: Alarms - was RE: Question = on=20 calstore current time.


Shannon asked=20 on 12/19/2001 04:51:22 PM:
> First - how do vendors CURRENTLY = handle=20 alarms - i.e. can the vendors here
> each speak up and explain = how they=20 handle it today...

For every=20 vendor here Im sure you'll get a slightly different answer. =  Basically it=20 falls into 2 categories: some use 'server push' models and some use = 'client=20 pull' models.  Notes uses the latter scheme so that it can = present=20 "missed alarms" to the user the next time they log in ("Mobile" or=20 "Disconnected" users access an 'internal' server in the = client).=20

No matter what route you = take, every=20 method has its strengths and weaknesses (otherwise there would be just = "the"=20 accepted way to implement it).  I suspect that in order to get a = "client=20 pull" CS to work with a "server push" CUA that some negotiation = between the=20 two is going to be necessary and the same for the converse = rolls.=20

> Second - fundamentally what are the = REQUIREMENTS=20 around alarms?
[Snip, snip]
>  =20     do they belong in CAP at all?

I think CAP = MUST address=20 it.  As an access protocol for C&S, it must provide some way = for a=20 user to access their alarms as well as the actual entries. =  =20

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Bruce=20 Kahn                   =  =20            INet: = Bruce_Kahn@iris.com
Iris=20 Associates                 =  =20        Phone: 978.392.5335
Westford, MA, USA = 01886=20                   =  FAX: and=20 nothing but the FAX...
Standard disclaimers apply, even where = prohibited by=20 law...
------=_NextPart_000_000D_01C18952.437EEDC0-- From owner-ietf-calendar@mail.imc.org Thu Dec 20 14:55:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18709 for ; Thu, 20 Dec 2001 14:55:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBKJT7X20305 for ietf-calendar-bks; Thu, 20 Dec 2001 11:29:07 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKJT5220301 for ; Thu, 20 Dec 2001 11:29:05 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id OAA20175; Thu Dec 20 14:22:54 2001 Subject: RE: Alarms - was RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 20 Dec 2001 14:30:21 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/20/2001 02:30:24 PM, Serialize complete at 12/20/2001 02:30:24 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I am struggling a bit to see a clear reason alarms are a standardized >element - i.e. they seem to be very specific in nature to a given >vendor's application - unless we are suggesting that there be two >elements to an alarm - one "when it should happen" - and a second, >specific to a given application, of "what" should then happen???? No. There are very clear semantics on what happens for alarms. See RFC-2445, section 4.6.6. The only real variation going on here is the division of labor between CS and CUA. /=================================================================\ |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 Thu Dec 20 16:08:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20537 for ; Thu, 20 Dec 2001 16:08:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKKn3d25122 for ietf-calendar-bks; Thu, 20 Dec 2001 12:49: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 fBKKn2225116 for ; Thu, 20 Dec 2001 12:49: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 PAA14238 for ; Thu, 20 Dec 2001 15:48:59 -0500 Received: from steltor.com ([192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBKKmtH21347 for ; Thu, 20 Dec 2001 15:48:55 -0500 (EST) Message-ID: <3C224EF5.2D0BD2F6@steltor.com> Date: Thu, 20 Dec 2001 15:49:57 -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: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@Royer.com> <3BFC2E3C.375E9640@steltor.com> <3BFC3A84.57438517@Royer.com> <3BFC4F8B.287BB80F@steltor.com> <3BFEC4F7.FD7A6CD1@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: > > > > > > > > > > > Sorry. My question should have been: > > > > > > > > Do we need "default VCARs for newly created top level > > > > calendars" given that we have VCAR inheritance? > > > > > > > > That is, a newly created top level calendar automatically inherits > > > > the VCARs directly contained under CALSTORE. The default VCARs > > > > could simply be all the VCARs directly contained under CALSTORE. > > > > > > > > I don't understand why we would need to copy the default VCARs > > > > in every top level calendar. > > > > > > I was getting these confused: > > > > > > 11.1 Calendar Store Properties / DEFAULT_VCAR > > > 11.2 Calendar Properties / DEFAULT_VCAR > > > > > > I agree, 11.2 DEFAULT_VCARS is not needed. > > > > Why do you think 11.1 DEFAULT_VCARS is needed? > > > > The list of DEFAULT_VCARS is simply the list of > > all the VCARs directly contained under the > > CALSTORE. > > No, it is a list of the defined CARIDs at the CS level. > Not all VCARs at the CS level need to be named with a CARID. > > > There is no need to define this one > > as well. It can be obtained with a simple VQUERY. > > It lists any predefined VCARS that exist by CARID. > > It allowed small devices to determine which 'predefined' VCARs > the CS knows, that the small CUA understands. So the small CUA > can just query for what it wants and does not have to do a full > VQUERY of what might be a large set of VCARs - then sort them. > REQUESTONLY is by definition limited to what the authenticated > entity can do, so the small CUA does not have to care about anything > other than understanding that what comes back applied to the current > authenticated entity. Sorry Doug, but I think I'm missing some basic information here! Why would a CUA (small or thick) want to get the list of predefined CARIDs? What is it going to do with this list? My understanding is that DEFAULT_VCAR would only be useful (used?) by the CS to duplicate the predefined VCAR in newly created VAGENDAs (which I questioned the usefulness given that we have inheritance). > > A small CUA can say: 'I know the function of CARID:REQUESTONLY', but > I don't care about the rest of them. How can a CUA not care about certain VCARs? Doesn't all VCARs for which the user's UPN match applies to the user regarless of their CARID? How can a CUA claim to "know the function of" a VCAR based on its CARID? Can't a user change the definition of the predefined VCARs at will, that is, to the extent where CARID:DEFAULTOWNER would not even apply to UPN=OWNER? If I want to deny you the right to create new event invitations in my calendar, am I forced to specify that RIGHTS (i.e., DENY) in the VCAR with CARID:REQUESTONLY? What is the purpose of predefined CARID? Is it related to CAR-MIN versus CAR-FULL-1? Currently, according to the specification, VCAR support restricted to CAR-MIN doesn't imply that only the predefined CARID are supported by the CS. If on the contrary it implies it, it should be written in the draft. > > There was a lot of resistance to not having predefined CARID's by > function VQUERYable by name. So then the debate went to, how > do I find out which predefined CARIDs does the CS support? The > answer was to add DEFAULT_VCAR at the CS level. Then we agreed > that any predefined 'access' MUST BE identifiable by a VCAR. > Then others asked - 'how can we expand this list in the future?'. > Then others asked what about any current VCAR with a CARID at the > CS level, so then DEFAULT_VCARs was expanded to include any VCAR in the CS > that had a CARID. In that way any CARID in DEFAULT_VCAR might > be a predefined CARID, and it no long matters to the CUA, it simply > gets a list, some of which may be predefined in an RFC. 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 Dec 20 16:12:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20681 for ; Thu, 20 Dec 2001 16:12:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBKKxU826210 for ietf-calendar-bks; Thu, 20 Dec 2001 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 fBKKxT226206 for ; Thu, 20 Dec 2001 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 PAA14478 for ; Thu, 20 Dec 2001 15:59:26 -0500 Received: from steltor.com ([192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBKKxHH22070 for ; Thu, 20 Dec 2001 15:59:17 -0500 (EST) Message-ID: <3C225163.84CABA9D@steltor.com> Date: Thu, 20 Dec 2001 16:00:19 -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 - limiting READ References: <3BF94A22.A791DF21@Royer.com> 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 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. Good idea, but I could simply setup my VCAR to deny you the right to read all my VCARs altogether. In any case, I think we should add your idea as a MAY in the specification. 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 Dec 20 16:52:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21776 for ; Thu, 20 Dec 2001 16:52:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBKLbGE27398 for ietf-calendar-bks; Thu, 20 Dec 2001 13:37: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 fBKLbF227394 for ; Thu, 20 Dec 2001 13:37: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 QAA15457 for ; Thu, 20 Dec 2001 16:37:12 -0500 Received: from steltor.com ([192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBKLb8H25310 for ; Thu, 20 Dec 2001 16:37:09 -0500 (EST) Message-ID: <3C225A43.D88608F1@steltor.com> Date: Thu, 20 Dec 2001 16:38:11 -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 Draft 6 comments 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: > > >Yes, but if I move a file from one location to another on any OS, > >it does not allow someone to see some of the PRIVATE data insie the > >file just because the grandparent directory allowed it, and my > >old one did not. > > Er...it might. On Unix, if you have a file in a directory where I do not > have permissions, I cannot list the directory, and I cannot read or write > the file even if the file itself says I have permissions to do so. If you > then move that file into a directory where I *do* have execute > permissions, then I can read the file if the file says I can. Exactly : "if the file says I can". We agreed about a month ago to allow VCARs in all (or most) components. So let's take advantage of it. If a user is concerned about a particular VEVENT's access rights, he will add a VCAR within that VEVENT. When that VEVENT will be moved from one calendar to another the VCAR will remain with the VEVENT. When moving a VEVENT (or a group of VEVENT) from one calendar to another, a CUA could propose the calendar user to duplicate the VCARs that currently apply to the VEVENT within the VEVENT itself before moving it. Doesn't that address the concern? > > I'm not convinced that this is too complex to solve right now. However, I > am convinced that putting it off is safe (safer than getting it wrong, > anyway :-), so maybe that's the right thing to do. The move command is too important to be left out. If more work is required in the VCAR, let's do it now, instead of dropping basic functionnality such as moving a component. 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 Dec 20 16:57:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21973 for ; Thu, 20 Dec 2001 16:57:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBKLiTx27526 for ietf-calendar-bks; Thu, 20 Dec 2001 13:44:29 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKLiQ227521 for ; Thu, 20 Dec 2001 13:44:27 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id QAA16032; Thu Dec 20 16:38:31 2001 Subject: Re: CAP: VCAR - limiting READ MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 20 Dec 2001 16:45:56 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/20/2001 04:46:01 PM, Serialize complete at 12/20/2001 04:46:01 PM Content-Type: text/plain; charset="us-ascii" To: "ietf-calendar@imc.org" From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > '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. Nit: that should be "affects". To effect Joe would be to cause him to exist. That's his parents' job. :-) /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |==============================================================| |No matter how subtle the wizard, a knife in the shoulderblades| |will cramp his style. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Dec 20 17:02:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22131 for ; Thu, 20 Dec 2001 17:02:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKLm4V27592 for ietf-calendar-bks; Thu, 20 Dec 2001 13:48:04 -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 fBKLm3227588 for ; Thu, 20 Dec 2001 13:48:03 -0800 (PST) To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: RE: Alarms - was RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_12112001 December 11, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 20 Dec 2001 17:03:32 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 12/20/2001 04:48:06 PM, Serialize complete at 12/20/2001 04:48:06 PM Content-Type: multipart/alternative; boundary="=_alternative 0077592885256B28_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077592885256B28_= Content-Type: text/plain; charset="US-ASCII" "Shannon J. Clark" wrote on 12/20/2001 01:31:35 PM: > Thanks - I guess what I am getting at when I ask whether CAP must > address alarms is asking whether alarms are fundamental (i.e. a > requirement) for interoperating calendar systems - or whether they > are a characteristic of Calendar USER agents I seriouly think the answer is YES! CAP is supposed to be the protocol that allows a user to use ANY CU to access their calendar on anyones CS. Part of doing this is being able to access the alarm(s) on an entry. The real issue that has yet to be directly addressed is how to get a "push" both "pull" clients/servers to play nicely together. Otherwise our users will just say "My alarms dont work when I try to get to my calendar on Blech's server. It worked w/Sanzzy's server! The other server must be broken". Frustrating our users by removing functionality that they rely on is NOT a good idea. Unlike a CUA that polls the CS for any new requests, etc,; alarms are more time sensitive in order to remain functional. Perhaps its confusing you that CAP is not funamentally a push model but for alarms in some models it is... > I am struggling a bit to see a clear reason alarms are a > standardized element You are mixing the standardizing the representation of an alarm in iCalendar and their actual usage 'implimentation' in a CUA using CAP. Dont confuse the two. iCalendar absolutely is correct to represent alarms in the core standard. Whats costing you gray cells is functional interop design for an area thats been neglected. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0077592885256B28_= Content-Type: text/html; charset="US-ASCII"
"Shannon J. Clark" <shannon@jigzaw.com> wrote on 12/20/2001 01:31:35 PM:
> Thanks - I guess what I am getting at when I ask whether CAP must
> address alarms is asking whether alarms are fundamental (i.e. a
> requirement) for interoperating calendar systems - or whether they
> are a characteristic of Calendar USER agents

I seriouly think the answer is YES!  CAP is supposed to be the protocol that allows a user to use ANY CU to access their calendar on anyones CS.    Part of doing this is being able to access the alarm(s) on an entry.   The real issue that has yet to be directly addressed is how to get a "push" both "pull" clients/servers to play nicely together.  Otherwise our users will just say "My alarms dont work when I try to get to my calendar on Blech's server.  It worked w/Sanzzy's server!  The other server must be broken".  Frustrating our users by removing functionality that they rely on is NOT a good idea.

Unlike a CUA that polls the CS for any new requests, etc,; alarms are more time sensitive in order to remain functional.  Perhaps its confusing you that CAP is not funamentally a push model but for alarms in some models it is...

> I am struggling a bit to see a clear reason alarms are a
> standardized element

You are mixing the standardizing the representation of an alarm in iCalendar and their actual usage 'implimentation' in a CUA using CAP.  Dont confuse the two.  iCalendar absolutely is correct to represent alarms in the core standard.  Whats costing you gray cells is functional interop design for an area thats been neglected.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0077592885256B28_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 20 17:42:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23386 for ; Thu, 20 Dec 2001 17:42:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBKMUbO29327 for ietf-calendar-bks; Thu, 20 Dec 2001 14:30:37 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKMUZ229320 for ; Thu, 20 Dec 2001 14:30:35 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA22682; Thu Dec 20 17:24:42 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 20 Dec 2001 17:32:08 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/20/2001 05:32:13 PM, Serialize complete at 12/20/2001 05:32:13 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >The move command is too important to be left out. I'm not sure. It's *useful*, but it's not *essential*. You can always do a get, put, delete. And, since we do arbitrary queries, you can do all that in two round trips, even if you're moving multiple components, so you can fill the TCP pipe and blast the data straight through. CAP would certainly be less efficient without MOVE, but that's better than hurrying and getting the ACLs wrong. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=================================================================| |I imagine the wages of sin *are* death, but by the time they take| |taxes out it's just sort of a tired feeling. --Paula Poundstone | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Dec 20 17:55:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23703 for ; Thu, 20 Dec 2001 17:55:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBKMiCM01299 for ietf-calendar-bks; Thu, 20 Dec 2001 14:44:12 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKMiB201292 for ; Thu, 20 Dec 2001 14:44:11 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id RAA24445; Thu Dec 20 17:38:29 2001 Subject: RE: Alarms - was RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 20 Dec 2001 17:45:54 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/20/2001 05:46:00 PM, Serialize complete at 12/20/2001 05:46:00 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Unlike a CUA that polls the CS for any new requests, etc,; alarms are >more time sensitive in order to remain functional. Perhaps its >confusing you that CAP is not funamentally a push model but for >alarms in some models it is... Wait a minute; I think we've got another disconnect. I was thinking the only kinds of alarms the server might watch for would be the email-based ones; if a CUA is running and intends to report the alarm, it doesn't need the CS to tell it so. It can just query the server, say, once an hour, and ask for all the alarms which it should report in the next hour. (Or more, actually--say, 90 minutes--to avoid edge problems.) Then it sets an internal reminder to report those alarms when they occur. This scales better, because it doesn't require the CS to do as much work to service all the alarms; it pushes the work to the edges. /=========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=========================================================| |Peace, justice, morality, culture, family, sport, and the| |extinction of all other life forms! | \=========================================================/ From owner-ietf-calendar@mail.imc.org Thu Dec 20 17:56:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23768 for ; Thu, 20 Dec 2001 17:56:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBKMhfS01225 for ietf-calendar-bks; Thu, 20 Dec 2001 14:43: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 fBKMhe201219 for ; Thu, 20 Dec 2001 14:43:40 -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 RAA16647 for ; Thu, 20 Dec 2001 17:43:37 -0500 Received: from steltor.com ([192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBKMhaH00047 for ; Thu, 20 Dec 2001 17:43:37 -0500 (EST) Message-ID: <3C2269D7.28FB5E37@steltor.com> Date: Thu, 20 Dec 2001 17:44:39 -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 Draft 6 comments 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: > > >The move command is too important to be left out. > > I'm not sure. It's *useful*, but it's not *essential*. You can always do > a get, put, delete. And, since we do arbitrary queries, you can do all > that in two round trips, even if you're moving multiple components, so you > can fill the TCP pipe and blast the data straight through. > > CAP would certainly be less efficient without MOVE, but that's better than > hurrying and getting the ACLs wrong. But how does the "get, put, delete" help us getting the ACLs right? 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 Fri Dec 21 09:20:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24096 for ; Fri, 21 Dec 2001 09:20:23 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLDrxM28382 for ietf-calendar-bks; Fri, 21 Dec 2001 05:53:59 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLDrv228372 for ; Fri, 21 Dec 2001 05:53:57 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id IAA29954; Fri Dec 21 08:49:06 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 21 Dec 2001 08:56:37 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/21/2001 08:56:40 AM, Serialize complete at 12/21/2001 08:56:40 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> CAP would certainly be less efficient without MOVE, but that's better than >> hurrying and getting the ACLs wrong. > >But how does the "get, put, delete" help us getting the >ACLs right? Er...because it lets us defer the question of what happens to ACLs on MOVE. It then becomes the CUA's responsibility to create the new components with ACLs that express the user's intention. Since expressing the user's intentions is the CUA's entire job, this seems appropriate to me. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |============================================================| |If all the world's a stage, I want to operate the trap door.| \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Dec 21 10:02:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24547 for ; Fri, 21 Dec 2001 10:02:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLEpSe01555 for ietf-calendar-bks; Fri, 21 Dec 2001 06:51: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 fBLEpQ201550 for ; Fri, 21 Dec 2001 06:51: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 JAA22984 for ; Fri, 21 Dec 2001 09:51:22 -0500 Received: from steltor.com (IDENT:patricel@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 fBLEpLH16721 for ; Fri, 21 Dec 2001 09:51:21 -0500 (EST) Message-ID: <3C234E4E.C8489803@steltor.com> Date: Fri, 21 Dec 2001 09:59:26 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Draft 6 comments 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 Beside efficiency, there is another fundamental difference between a "move" and a combination of "search", "create" and "delete". The "move" command is atomic, and since there is no transaction in CAP, "search" + "create" + "delete" is not. This makes it very hard (impossible?) for a CUA to implement a safe move. -- Patrice. John Stracke wrote: > > >> CAP would certainly be less efficient without MOVE, but that's better > than > >> hurrying and getting the ACLs wrong. > > > >But how does the "get, put, delete" help us getting the > >ACLs right? > > Er...because it lets us defer the question of what happens to ACLs on > MOVE. It then becomes the CUA's responsibility to create the new > components with ACLs that express the user's intention. Since expressing > the user's intentions is the CUA's entire job, this seems appropriate to > me. > > /============================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc. | > |http://www.incentivesystems.com|My opinions are my own. | > |============================================================| > |If all the world's a stage, I want to operate the trap door.| > \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Dec 21 11:03:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25582 for ; Fri, 21 Dec 2001 11:03:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLFjV804639 for ietf-calendar-bks; Fri, 21 Dec 2001 07:45:31 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLFjT204635 for ; Fri, 21 Dec 2001 07:45:29 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA19087; Fri Dec 21 10:40:16 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 21 Dec 2001 10:47:50 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/21/2001 10:47:51 AM, Serialize complete at 12/21/2001 10:47:51 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Beside efficiency, there is another fundamental difference >between a "move" and a combination of "search", "create" >and "delete". The "move" command is atomic, That's not necessarily a trivial requirement, you know. >and since there is >no transaction in CAP, "search" + "create" + "delete" is not. > > This makes it very hard (impossible?) for a CUA to implement >a safe move. Yeah, well, there are different kinds of safety. In this case, safety from errors in the CS is competing with safety from errors in the security design. The security design is longer-lived than any one CS. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |================================================================| |I'm on a Mission From God to Save The World from megalomania! | |(Question: which God? Answer: Milhouse, God of Humility. You | |probably haven't heard of him; he doesn't put himself forward.) | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Dec 21 11:45:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26246 for ; Fri, 21 Dec 2001 11:45:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLGTk509652 for ietf-calendar-bks; Fri, 21 Dec 2001 08:29: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 fBLGTh209645 for ; Fri, 21 Dec 2001 08:29: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 LAA25196 for ; Fri, 21 Dec 2001 11:29:40 -0500 Received: from steltor.com (IDENT:patricel@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 fBLGTUH24361 for ; Fri, 21 Dec 2001 11:29:30 -0500 (EST) Message-ID: <3C23654F.F02A75D1@steltor.com> Date: Fri, 21 Dec 2001 11:37:35 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> <3BFEBEE2.2F736E3D@Royer.com> <3C221F20.D92B2355@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > For those that haven't follow this thread closely > here's a summary of my proposition : > > 1- Let's add a UID property in VCAR components to have > a way to uniquely identify them. How can we go > wrong by putting unique ids in components? :-) > > 2- Let's add a NAME property in VCAR components to > allow users to specify a localizable display name > in their VCARs. > > 3- Let's use the NAME property in VCAR components to > hold the predefined names of the CAR-MIN VCARs. > These predefined names would not be localized, but > a CUA could always display them in a localized form. > > 4- CARREF should be made to unique ids (UID) instead > of names (NAME) which are not unique. Actually, it is already specified that the identifier specified by CARREF must be unique to the CS. From section 1.2 of the "Proposed Changes To iCalendar Needed For CAP": "The CARREF rule part specifies a reference to a particular "VCAR" calendar component. The text is matched to a CARID property value within a "VCAR" calendar component. This allows for a particular set of calendar access rights to be defined once and referenced multiple times. The "VCAR" identifier specified by this rule part is unique to the calendar store." Given that restriction, it would make sence to use UID instead of CARID. And to retrieve CAR-MIN VCARS a CUA shouldn't have any problems searching on the NAME property. > > Here's some examples: > > Definition of the CAR-MIN DEFAULTOWNER: > > BEGIN:VCAR > UID:20011121T120000Z-00005@host.com > NAME:DEFAULTOWNER > ... > END:VCAR > > Definition of a VCAR that grants READ rights > to Doug: > > BEGIN:VCAR > UID:20011121T120000Z-00006@host.com > NAME;LANGUAGE=FR-ca:Octroyer droits de lecture a Doug > ... > END:VCAR > > Definition of a VCAR that makes a reference > to the previous VCAR: > > BEGIN:VCAR > UID:20011121T120000Z-00007@host.com > GRANT:CARREF=20011121T120000Z-00006@host.com > ... > END:VCAR > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > BTW, OWNERRIGHTS is not part of the predefined CARID, > > > but that's beside the point. > > > > Should have said DEFAULTOWNER -- :-) > > (This one moved from the end, I modified the text send by Bernard > > and myself by replacing OWNERRIGHTS with the correct tag: DEFAULTOWNER). > > > > > Doug Royer wrote: > > > > > > > > Bernard Desruisseaux wrote: > > > > > > > > > 2- Do we really need a VCAR specific property to hold > > > > > VCAR identifiers? Couldn't we simply use the UID > > > > > property for that purpose? > > > > > > > > The more I think about this, the more I am concerned that > > > > it's not a good idea. Take the predefined CARID's for example: > > > > > > > > DEFAULTOWNER is the CARID. > > > > > > > > However MANY different calendars will not have the same contents > > > > for that VCAR. So it is no longer a unique ID for a VCAR. It is only > > > > unique for its scope. So by definition we would be defining VCARS > > > > with Unique IDs that were not Unique IDs. And a VCAR/UID would then > > > > not uniquely define a VCAR. > > > > > > > > For ALARMID, we are not pre-defining any, so UID would be okay > > > > with me. > > > > > > On the other hand, when I would write the following VCAR: > > > > > > BEGIN:VCAR > > > GRANT:CARREF:DEFAULTOWER > > > ... > > > END:VCAR > > > > You could, but I don't think that is a valid VCAR. > > Did you mean the following VCAR that uses an existing VCAR? > > > > BEGIN:VCAR > > GRANT;CARID=DEFAULTOWNER:... > > ... > > END:VCAR > > I mistakenly put a colon (:) after CARREF instead of an > equal sign (=). Other than that, my examples follows the > specification (http://calsch.org/ietf/iCal-updates.html). > > On the other hand, I would agree that we need to review > how VCAR should make reference to other VCARs. I will > propose something to the list. > > > > > I wouldn't know for sure that it will always make reference > > > to the same VCAR. > > As I said above, by making reference to non-unique CARID, > VCARs making reference to a VCAR that has just been deleted > will all of a sudden start making reference to another VCAR. > In my opinion, this could lead to bad surprise. > > References (CARREF) should be made to unique ids (UID) to > avoid such surprise. > > > > Furthermore, a VQUERY performed on a hierarchy of VAGENDAs > > > could return multiple VCARs with the same CARID. The calendar > > > user wouldn't have any way to distinguish the returned VCARs. > > > > For the same TARGET, the contents of CARID 'foo' is only the > > same at one instance in time. And a VCAR is contained in the hierarchy > > of BEGIN/END matched to a TARGET and CMDID, thus TARGET+CARID is > > unique at one point in time. > > > > It is true that TARGET:1 and TARGET:2 can each have a CARID:123 > > and they might not have same contents. That's my point - it is > > CARID is only unique per calendar. Unlike UID which is supposed > > to be unique in the world. > > > > With CARID, a CUA can find out what it can do, and there is > > a handle to help organize them in a calendar. But the contents > > of that VCAR are not static - only the CARID value is static > > and as CUA's need to find out what they can do, that is why > > the predefined CARIDs were created - so a CUA can find > > things by predefined name - CARID. > > > > > Finally, enforcing specific identifier for the CAR-MIN VCAR > > > will not allow users to make reference to the VCAR they are > > > re-defining (their new definition would hide the previous > > > definition(s)). > > > > The point of the defined VCARs is that a CUA can find > > if it can do specific things and find the calendars specific > > contents for that known named CARID. So no matter what > > the contents of that VCAR, a CUA can find its REQUESTONLY by > > doing a VQUERY for REQUESTONLY by name. > > > > Otherwise a CUA would have to VQUERY for all VCARs, then > > sort them itself. > > You are assuming that a CU will always have READ access > to all the VCARs that applies to him. If I'm giving you > access to my calendar I may not want you to know who else > has access to my calendar. > > Although CUAs may try to evaluate the VCARs, only the CS > will be able to evaluate them properly. > > > > > > What would you think of using reserved names for the CAR-MIN > > > VCARs instead? > > > > The predefined CARIDs are part of CAR-MIN. So, what do > > you mean by 'instead'? Did you mean CAR-MIN only? If so > > we would have two version of VCAR. Currently one is just an > > extension of the other. > > I meant using the NAME property to hold the value of > predefined "names", e.g., > > NAME:DEFAULTOWNER > > while using UID to hold an Id unique in the world : > > UID:20011121T120000Z-00003@host.com > > > > > > It is not ideal, since we would have to make > > > the CUA responsible for the localization of these reserved > > > names, > > > > The point is that they are FIXED names, so a CUA can do > > a VQUERY by name - localizing the 'reserved names' breaks > > that ability. > > The NAMEs would NOT be stored localized on the server in order > to keep this ability. As I said, it would be the responsiblity > of the CUA to localized these reserved-names (if at all). > > > >but on the other hand, it should be sufficient to meet > > > our requirements. For instance: > > > > > > BEGIN:VCAR > > > UID:20011121T120000Z-00003@host.com > > > NAME:DEFAULTOWNER > > > ... > > > END:VCAR > > > > How? Above you said that DEFAULTOWNER can be localized, so > > tell me, how I find the DEFAULTOWNER if you call it 'asldkfjfjs' > > in your locale? Show me a VQUERY that can fetch DEFAULTOWNER > > no matter what the localized name? > > I meant to say that the CUA could localized DEFAULTOWNER if it > wants to, not that the NAME could not be stored localized in > the server. So the CUA would always query the NAME DEFAULTOWNER. > > > > > > That raises another question with respect to overriding > > > inherited VCARs: > > > > > > Was a VCAR with the CARID:DEFALTOWNER(a) supposed to override > > > all RIGHTS value type of other VCARs with the same CARID > > > in the calendar hierarchy, or (b) simply specific GRANT and > > > DENY as you mentioned in your reply to (VCAR: Overriding > > > inherited VCAR)? > > > > In all cases, a calendars specific VCARS details override any > > inherited VCAR details. So yes (b). > > > > I took your original question to mean: > > > > What happens if the VCAR for a calendar overrides > > some (but not all) of the GRANT/DENY that it would > > have inherited? > > > > I think I said that those specific differences are resolved > > to the calendar specific VCARs - the specific calendar VCAR > > details win. > > > > Top level calendar: > > > > BEGIN:VCAR > > CARID:REQUESTONLY > > GRANT:UPN=joe,sam,tom;.... > > ... > > END:VCAR > > > > Target Sub-Calendar under the Top level calendar: > > > > BEGIN:VCAR > > CARID:REQUESTONLY > > DENY:UPN=joe:... > > ... > > END:VCAR > > > > Sam and Tom only can do METHOD:REQUEST on the target calendar. > > A VQUERY for REQUSESTONLY on the target calendar would return: > > > > BEGIN:VCAR > > CARID:REQUESTONLY > > GRANT:UPN=sam,tom > > ... > > END:VCAR > > Hold on, if the VCAR returned by the "search" command is > the computed VCAR as you say, how will I be able to get > the value of the stored VCAR so that I can modify it? > > Although it may seem handy to return computed VCAR to CUA, > we have to keep in mind that the main goal is to allow > calendar users to set their access rights through CAP, not > to perform the evaluation of VCARs themselves. > > > Even though no specific VCAR with those contents was specifically > > stored. The predefined VCARs are by function identifiable > > by CARID, not by contents. That's why UID is not valid, at > > no point would that UID in a VCAR uniquely identify any contents. > > > > > If (a) is true, why the CAR-MIN VCAR need to be handled in > > > a special way? > > > > CAR-MIN is a subset of CAR-FULL. The fact is that there > > are some VCARs predefined by 'function', VQUERYable by predefined > > CARIDs who's contents are not predefined and thus not unique. > > > > > If (b) is true, there is no reason to use the same CARID > > > more than once. Any VCAR can override the CAR-MIN VCARs > > > regardless of its CARID. > > > > I think that my example shows that the same CARID is used > > more than once in a CS- and needs to be. > > > > -Doug > > Regards, > Bernard > -- > Bernard Desruisseaux mailto:bernard@steltor.com > Research & Development Tel. : +1 514 733-8500 x4213 > Steltor Fax : +1 514 733-8878 -- Patrice. From owner-ietf-calendar@mail.imc.org Fri Dec 21 12:26:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27198 for ; Fri, 21 Dec 2001 12:26:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLH3Lq12645 for ietf-calendar-bks; Fri, 21 Dec 2001 09:03:21 -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 fBLH3K212638 for ; Fri, 21 Dec 2001 09:03:20 -0800 (PST) MIME-Version: 1.0 To: "John Stracke" Cc: ietf-calendar@imc.org Subject: RE: Alarms - was RE: Question on calstore current time. X-Mailer: Lotus Notes Build V60_12112001 December 11, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Fri, 21 Dec 2001 11:56:02 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 12/21/2001 12:03:23 PM, Serialize complete at 12/21/2001 12:03:23 PM Content-Type: multipart/alternative; boundary="=_alternative 005CBA2785256B29_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CBA2785256B29_= Content-Type: text/plain; charset="US-ASCII" John replied: >Wait a minute; I think we've got another disconnect. Nah, we never have those here... :^) > I was thinking the >only kinds of alarms the server might watch for would be the email-based >ones; Again, depending on the current CS and CUA models this is not automatically a good thing to have happen. If not engineered properly, its possible that ATTENDEEs get 2 email reminders where only 1 should have been sent. Granted that the ATTENDEE list is fully expanded in the alarm when stored, it is not inconceivable that a CUA would want to possibly refresh the list before sending the email if the group membership has changed (or can change outside of the control of the CUA such as in a "Westford Employees" mailing list maintained by someone else). This is a bell and whistle type feature but one that could not be implemented if the CS did it automagically for the CUA. Also, the CS can send the email alarm on behalf of the CU but not all C&S systems have that as their model currently. As stated before, by myself and others, this is an area that has not had any real cycles spent on it to deal w/disparate models of behaviour between the different products that currently exist. Chalk it up as an issue set that needs to be addressed. However I think that there are bigger fish in the CAP pond that need frying before we deal w/something of this size. > if a CUA is running and intends to report the alarm, it doesn't need >the CS to tell it so. It can just query the server, say, once an hour, >and ask for all the alarms which it should report in the next hour. That would work if I didnt allow other CUs to access and put entries on my calendar. For example, my AA gets a call from another mgr requesting some block of time so she 'over books' me and sets a display alarm for me to see to get me out of my other meeting(s). As such, if the CUA only polled hourly (or longer) it would miss new entries that arrive in that time frame. Add to this mix the ability to have the CS autoprocess requests (ie: from my mgr gets overridding priority compared to my peers) then its apparent that smaller polling windows are necessary (in the client poll model). This "what alarms are scheduled to trigger in the next xx minutes" also does not address the "What alarms did I miss since I last checked / logged in" case where a CUA or CS can be unavailable when query would have normally detected it or is one of the examples above. >This scales better, because it doesn't require the CS to do as much work >to service all the alarms; it pushes the work to the edges. This argues for a 'client pull' model for alarms. Since thats the model we've had for years Im kinda partial to it. To keep the designe simpler, I think that the CS should not be involved in servicing any alarms since it removes the "Im a 'client pull' CS and he's a 'server push' CUA so what do we do?" quandry. If the CUA was responsible for handling all alarms then its keeps this part of CAP simple to grok and more likely to allow for better interop. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005CBA2785256B29_= Content-Type: text/html; charset="US-ASCII"
John replied:
>Wait a minute; I think we've got another disconnect.  

Nah, we never have those here... :^)

>                                                      I was thinking the
>only kinds of alarms the server might watch for would be the email-based
>ones;

Again, depending on the current CS and CUA models this is not automatically a good thing to have happen.   If not engineered properly, its possible that ATTENDEEs get 2 email reminders where only 1 should have been sent.

Granted that the ATTENDEE list is fully expanded in the alarm when stored, it is not inconceivable that a CUA would want to possibly refresh the list before sending the email if the group membership has changed (or can change outside of the control of the CUA such as in a "Westford Employees" mailing list maintained by someone else).  This is a bell and whistle type feature but one that could not be implemented if the CS did it automagically for the CUA.

Also, the CS can send the email alarm on behalf of the CU but not all C&S systems have that as their model currently.  As stated before, by myself and others, this is an area that has not had any real cycles spent on it to deal w/disparate models of behaviour between the different products that currently exist.  Chalk it up as an issue set that needs to be addressed.  However I think that there are bigger fish in the CAP pond that need frying before we deal w/something of this size.

>     if a CUA is running and intends to report the alarm, it doesn't need
>the CS to tell it so.  It can just query the server, say, once an hour,
>and ask for all the alarms which it should report in the next hour.

That would work if I didnt allow other CUs to access and put entries on my calendar.  For example, my AA gets a call from another mgr requesting some block of time so she 'over books' me and sets a display alarm for me to see to get me out of my other meeting(s).  As such, if the CUA only polled hourly (or longer) it would miss new entries that arrive in that time frame.  

Add to this mix the ability to have the CS autoprocess requests (ie: from my mgr gets overridding priority compared to my peers) then its apparent that smaller polling windows are necessary (in the client poll model).

This "what alarms are scheduled to trigger in the next xx minutes" also does not address the "What alarms did I miss since I last checked / logged in" case where a CUA or CS can be unavailable when query would have normally detected it or is one of the examples above.

>This scales better, because it doesn't require the CS to do as much work
>to service all the alarms; it pushes the work to the edges.
This argues for a 'client pull' model for alarms.  Since thats the model we've had for years Im kinda partial to it.  

To keep the designe simpler, I think that the CS should not be involved in servicing any alarms since it removes the "Im a 'client pull' CS and he's a 'server push' CUA so what do we do?" quandry.  If the CUA was responsible for handling all alarms then its keeps this part of CAP simple to grok and more likely to allow for better interop.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005CBA2785256B29_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 21 12:55:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27875 for ; Fri, 21 Dec 2001 12:55:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLHhYx15701 for ietf-calendar-bks; Fri, 21 Dec 2001 09:43: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 fBLHhX215697 for ; Fri, 21 Dec 2001 09:43: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 MAA26662 for ; Fri, 21 Dec 2001 12:43: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 fBLHhTH29698 for ; Fri, 21 Dec 2001 12:43:29 -0500 (EST) Message-ID: <3C2374F7.17093CD5@steltor.com> Date: Fri, 21 Dec 2001 12:44: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: VCAR question References: <3C178F5F.1F85AF94@steltor.com> <3C17DBB4.9F9DF5CF@Royer.com> <3C17DF01.9166C3E@steltor.com> <3C17EE18.82517D1F@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 relationship between the CAP commands (i.e., > > > > create, delete, modify, move, search and schedule) > > > > and the CAP actions should be clarified. Renaming > > > > the ACTION CREATE to WRITE would probably help > > > > reducing the confusion. > > > > > > OR we could rename the command to CREATE as WRITE implies > > > modify as you pointed out above. > > > > You lost me. Rename which command? > > Rename the WRITE command to CREATE There is no WRITE command in CAP. > (or is that a BXXP thing?). I don't know what you mean by that. I proposed to rename the ACTION CREATE (not the "create" command) to WRITE (i.e., ACTION=WRITE) to make it clear that is doesn't only apply to the "create" command. Is that okay with you? 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 Dec 21 13:09:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28228 for ; Fri, 21 Dec 2001 13:09:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLHwDX16088 for ietf-calendar-bks; Fri, 21 Dec 2001 09:58: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 fBLHwC216084 for ; Fri, 21 Dec 2001 09:58:12 -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 MAA26873 for ; Fri, 21 Dec 2001 12:58: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 fBLHw5H00633 for ; Fri, 21 Dec 2001 12:58:05 -0500 (EST) Message-ID: <3C237863.9E371655@steltor.com> Date: Fri, 21 Dec 2001 12:58: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: VCAR: CARREF rule part 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 CARREF rule parts specifies a reference to a particular "VCAR" calendar components in the CS. I don't understand why CARREF is a rule part of a RIGHTS value type and not a property of a VCAR component. It would make sense for a VCAR to be defined in terms of another VCAR but not for a RIGHTS to be defined in terms of a VCAR. What would be the difference between specifying CARREF in the GRANT property versus in the DENY property? Which UPN should be considered when a RIGHTS value type that has both a UPN rule part and a CARREF rule part makes reference to a VCAR that has RIGHTS value types with specific UPNs? I propopose that we make CARREF a property of VCAR components instead of a rule part of the RIGHTS value type. That is, we would now have: BEGIN:VCAR CARREF=20011121T120000Z-00006@host.com ... 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 Fri Dec 21 14:00:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29469 for ; Fri, 21 Dec 2001 14:00:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLInfU19090 for ietf-calendar-bks; Fri, 21 Dec 2001 10:49: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 fBLIne219086 for ; Fri, 21 Dec 2001 10:49:40 -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 NAA27724 for ; Fri, 21 Dec 2001 13:49: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 fBLInXH04034 for ; Fri, 21 Dec 2001 13:49:33 -0500 (EST) Message-ID: <3C238473.966CFE9E@steltor.com> Date: Fri, 21 Dec 2001 13: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: CAP: Calendar Adresses vs CAP URIs 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 opinion, it should be possible to use CAP URIs for more than just calendar addresses. CAP URIs could eventually be used to designate calendar stores, calendars, components, properties, and search operations on Internet hosts accessible using the CAP protocol. Have a look at the LDAP URL Format [RFC 2255] for an example of another application protocol's URI format. Section 2.6 of the current draft states that "Calendar Addresses are URIs", and specifies a syntax that would consider a alone as a valid CAP URI. Although a alone could constitute a valid "relative CAP URI", it could not be considered as an "absolute CAP URI" (absoluteURI must contains the name of the scheme being used) [RFC 2396]. CAP should only specify that calendar addresses can be specified as both relative or absolute CAP URIs, and CAP URIs could be specified in another section, or in a separate document altogether. With fanout left out, are there still cases where an absolute CAP URI is required to specify a calendar address? 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 Dec 21 14:01:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29554 for ; Fri, 21 Dec 2001 14:01:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLIlka18850 for ietf-calendar-bks; Fri, 21 Dec 2001 10:47: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 fBLIli218843 for ; Fri, 21 Dec 2001 10:47: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 NAA27690 for ; Fri, 21 Dec 2001 13:47:40 -0500 Received: from steltor.com (IDENT:patricel@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 fBLIleH03966 for ; Fri, 21 Dec 2001 13:47:40 -0500 (EST) Message-ID: <3C2385B0.8B9D7E7@steltor.com> Date: Fri, 21 Dec 2001 13:55:44 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@mail.imc.org Subject: Re: CAP Draft 6 comments 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: > > > Beside efficiency, there is another fundamental difference > >between a "move" and a combination of "search", "create" > >and "delete". The "move" command is atomic, > > That's not necessarily a trivial requirement, you know. > > >and since there is > >no transaction in CAP, "search" + "create" + "delete" is not. > > > > This makes it very hard (impossible?) for a CUA to implement > >a safe move. > > Yeah, well, there are different kinds of safety. In this case, safety > from errors in the CS is competing with safety from errors in the security > design. The security design is longer-lived than any one CS. > The point that I wanted to make is that a "move" can't really fully be implemented on the client side. I don't understand what access right issues would be resolved by dropping the "move". If I recall correctly the discussion started when Steve ask: "Do people have an issue with calenders possibly becoming more restrictive after a move?" Well if we drop the "move" command saying that most of the functionality could be achieved by a "search", "create" and "delete". What are we gaining? If a CUA uses a simple "search" and forward result to "create" method, then we are in the same situation, but we loose efficiency and open the door to concurrency problems. If it is possible for a CUA to implement a move that satisfies some access right requirements (what ever they may be), then what are we loosing by keeping the "move" command? Couldn't the access right settings be adjusted in the same manner by the CUA. -- Patrice. From owner-ietf-calendar@mail.imc.org Fri Dec 21 14:19:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29955 for ; Fri, 21 Dec 2001 14:19:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLJ62i19790 for ietf-calendar-bks; Fri, 21 Dec 2001 11:06: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 fBLJ5p219785 for ; Fri, 21 Dec 2001 11:05: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 LAA05897 for ; Fri, 21 Dec 2001 11:05:11 -0800 (PST) Message-ID: <3C238743.61387D6F@Royer.com> Date: Fri, 21 Dec 2001 12:02: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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@mail.imc.org" Subject: Re: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> <3BFEBEE2.2F736E3D@Royer.com> <3C221F20.D92B2355@steltor.com> Content-Type: multipart/mixed; boundary="------------DE3A1B35B472B4B58A7D9DF3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DE3A1B35B472B4B58A7D9DF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > For those that haven't follow this thread closely > here's a summary of my proposition : > > 1- Let's add a UID property in VCAR components to have > a way to uniquely identify them. How can we go > wrong by putting unique ids in components? :-) Does the UID change each time there is a local change to the VALARM contents? If yes, then that can break MODIFY. If no, then you have multiple VALARMs with the SAME UID (The one or more different VALARMS each the same UID each in a unique calendar/sub-calendar), and NOT the same contents. So how to you MODIFY?! I think both break things. This needs to be thought out. I don't think it can be done that way. 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. (2) Create a new SCOPE parameter for the SEQUENCE property. The default value if not specified is 'global', and can be set to 'local'. Where 'local' means only visible to the calendar owners(s) and 'local' VALARMS MUST NOT be sent to non-calendar-owner(s). This would allow global (ORGANIZER originated VALARMS), to have numbers starting at zero. And it would allow local VALARMS to start with a sequence of zero: BEGIN:VALARM SEQUENCE:0 ... END:VALARM BEGIN:VALARM SEQUENCE;SCOPE=local:0 ... END:VALARM This would solve the MODIFY problem. (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 owner MUST NOT export the ENABLE parameter to non-owners of the object when exporting from the local store. 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 SCOPE) and gives the local user control over VALARM TRIGGERs without breaking MODIFY. I don't see how using UID solves the MODIFY uniqueness problem (I see that it adds more problems). Plus using UID does not allow the local user to alter TRIGGERs without breaking MODIFY. > 2- Let's add a NAME property in VCAR components to > allow users to specify a localizable display name > in their VCARs. Then lets add the LANG parameter to the NAME property and allow multiple NAME properties in each object? And the NAME property is optional, and if not specified its value is CARID? (or if I understand you below, if it is a CUA property only - it is out of scope for CAP). > 3- Let's use the NAME property in VCAR components to > hold the predefined names of the CAR-MIN VCARs. > These predefined names would not be localized, but > a CUA could always display them in a localized form. So are you proposing that in this case the CARID and the NAME be the same, or are you saying that if NAME is not present you can use CARID? > 4- CARREF should be made to unique ids (UID) instead > of names (NAME) which are not unique. UID does not apply to VCAR's, the SAME UID has different contents - it there for does not uniquely identify anything. Lets stop overloading UID just because it is an id. CARID is by function, who's contents is not unique. > > > > I wouldn't know for sure that it will always make reference > > > to the same VCAR. > > As I said above, by making reference to non-unique CARID, > VCARs making reference to a VCAR that has just been deleted > will all of a sudden start making reference to another VCAR. > In my opinion, this could lead to bad surprise. > > References (CARREF) should be made to unique ids (UID) to > avoid such surprise. You see VCARS as static. They are NOT static. CARREF can break things if you don't have control over the object pointed to by CARREF. And as VCARs are both inherited and a logical AND there is no reason to have a CARREF. Simply define the VCAR you want. Add or delete from it, and/or add or delete more VCAR rules. You do NOT process them in order. They are more like bits in a hardware register who's default value is zero (for deny). You get your parents bits, AND them to your bits - the '1' (grant)'s that are left - are what you can do. And if the next time you try an operation if your parent bits have changed and it does not allow something, it won't work no matter how many other VCARS you have or pointed to. > > > Furthermore, a VQUERY performed on a hierarchy of VAGENDAs > > > could return multiple VCARs with the same CARID. The calendar > > > user wouldn't have any way to distinguish the returned VCARs. If for what ever reason, you get multiple VCAR's with the same CARID - then they are the same within the same scope. If they are not the same - your CS is busted. That's the idea. If you change by CARID, you CHANGE THEM ALL within that sphere of influence. If you want to modify one entry and not have that CARID apply to that object or sets of objects, then remove that CARID from that object or set of objects and add VCARS that you want. > > You are assuming that a CU will always have READ access > to all the VCARs that applies to him. If I'm giving you > access to my calendar I may not want you to know who else > has access to my calendar. No, I am not. As the default is DENY, I only have to show you what the currently authenticated UPN has access to. The CUA may make no other assumptions. The calendar owner MAY have full access, but might not. > Although CUAs may try to evaluate the VCARs, only the CS > will be able to evaluate them properly. True, but the CUA will see those as DENY as the CS will not have shown them a VCAR of GRANT. Again, they are not static. Any UPN including the OWNER, can only see what they are allowed to see, everything else to them at that point in time, in that session, for that UPN, is DENY - no matter what may actually be in the CS. For example, the CS administrator my have access, and not even the calendar owner can tell. > > > It is not ideal, since we would have to make > > > the CUA responsible for the localization of these reserved > > > names, > > > > The point is that they are FIXED names, so a CUA can do > > a VQUERY by name - localizing the 'reserved names' breaks > > that ability. > > The NAMEs would NOT be stored localized on the server in order > to keep this ability. As I said, it would be the responsiblity > of the CUA to localized these reserved-names (if at all). Then it is out of scope for CAP as it is the CUA <-> CS protocol. What ever you do in a CUA -only- is not in scope for CAP. > Hold on, if the VCAR returned by the "search" command is > the computed VCAR as you say, how will I be able to get > the value of the stored VCAR so that I can modify it? They are NOT static they are fluid. You grand or deny access only. If you were to "GRANT;UPN=Bennard" TEN (10) times, it is only set once. You would not get ten VCARs back you would only get one. > Although it may seem handy to return computed VCAR to CUA, > we have to keep in mind that the main goal is to allow > calendar users to set their access rights through CAP, not > to perform the evaluation of VCARs themselves. The CUA does not care how the GRANT or DENY was set. Just that is it. And it can send a new GRANT or DENY to the CS and it may or might not be taken depending on the currently authenticated users access. A CUA does not have to understand VCAR's. It MUST BE prepared to deal with 'permission denied'. --------------DE3A1B35B472B4B58A7D9DF3 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 14:21:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLJ9ub19874 for ietf-calendar-bks; Fri, 21 Dec 2001 11:09: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 fBLJ9s219870 for ; Fri, 21 Dec 2001 11:09: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 LAA05902 for ; Fri, 21 Dec 2001 11:09:25 -0800 (PST) Message-ID: <3C238842.9D5194E4@Royer.com> Date: Fri, 21 Dec 2001 12:06:42 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting 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: Alarms - was RE: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------6BD905E9E80DF8A497479B5B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6BD905E9E80DF8A497479B5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > "Shannon J. Clark" wrote: > > Bruce, > > Thanks - I guess what I am getting at when I ask whether CAP must > address alarms is asking whether alarms are fundamental (i.e. a > requirement) for interoperating calendar systems - or whether they are > a characteristic of Calendar USER agents - i.e. since so far the > examples appear to be specific to ONE user - are they something that > must be a part of the core calendaring specs? Or could they be > considered a very optional component and something that is specific to > the vendor(s) involved in a given application? They already are - see rfc2445 > Perhaps though there should be a standard way to separate off and > store this vendor specific information - so I could see an argument > for some data structure - just wondering how much or how little is > really required. This debate took place over years - lets not deprecate rfc2445. > I am struggling a bit to see a clear reason alarms are a standardized > element - i.e. they seem to be very specific in nature to a given > vendor's application - unless we are suggesting that there be two > elements to an alarm - one "when it should happen" - and a second, > specific to a given application, of "what" should then happen???? I just posted what I think will resolve the user preferences to VALARM issues. The reality is that they exists. We need to debate how to deal with them. -Doug --------------6BD905E9E80DF8A497479B5B 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 14:23:26 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLJ6XG19798 for ietf-calendar-bks; Fri, 21 Dec 2001 11:06:33 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLJ6V219794 for ; Fri, 21 Dec 2001 11:06:31 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id NAA24079; Fri Dec 21 13:58:40 2001 Subject: RE: Alarms - was RE: Question on calstore current time. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 21 Dec 2001 14:06:13 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/21/2001 02:06:15 PM, Serialize complete at 12/21/2001 02:06:15 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> I was thinking the >>only kinds of alarms the server might watch for would be the email-based >>ones; > >Again, depending on the current CS and CUA models this is not automatically a good thing to have happen. Well, that's why I don't want it to happen automatically; I don't want the CS to take on any alarm without being asked, and I want the CS to be able to refuse. >Granted that the ATTENDEE list is fully expanded in the alarm when >stored, it is not inconceivable that a CUA would want to possibly >refresh the list before sending the email if the group membership has >changed Probably not a good idea; you'd wind up sending a reminder to someone who never got the invitation. >>It can just query the server, say, once an hour, >>and ask for all the alarms which it should report in the next hour. > >That would work if I didnt allow other CUs to access and put entries on my calendar. Bleep. Right. (Personally, I've always felt that a good scheduling system should obviate the need for an assistant to put things on your calendar; but I'm aware that PHBs are not going to give up that status symbol easily.) >Add to this mix the ability to have the CS autoprocess requests (ie: >from my mgr gets overridding priority compared to my peers) then its >apparent that smaller polling windows are necessary (in the client >poll model). [...] >>This scales better, because it doesn't require the CS to do as much >>work >>to service all the alarms; it pushes the work to the edges. > >This argues for a 'client pull' model for alarms. Since thats the >model we've had for years Im kinda partial to it. Yeah, but your model is based on the CUA having a complete copy of what's in the CS (as near as I can tell from having used it the past two months). A thin-client model might not be able to cope with that. And the alternative is polling, which is really hard on the CS--harder than having the CS poll itself at similar frequency. So maybe we need a way for the CS to push alarm reminders to the CUA? Only if it's been asked to, of course. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=================================================================| |Whose cruel idea was it for the word "lisp" to have an "S" in it?| \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Dec 21 15:01:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00923 for ; Fri, 21 Dec 2001 15:01:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLJnQp21443 for ietf-calendar-bks; Fri, 21 Dec 2001 11:49: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 fBLJnP221439 for ; Fri, 21 Dec 2001 11:49: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 LAA05950; Fri, 21 Dec 2001 11:48:12 -0800 (PST) Message-ID: <3C239159.2558E3B9@Royer.com> Date: Fri, 21 Dec 2001 12:45:29 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Desruisseaux CC: ietf-calendar@imc.org Subject: Re: CAP Draft 6 comments References: <3C225A43.D88608F1@steltor.com> Content-Type: multipart/mixed; boundary="------------8365B2B2794A1DD5B5F902F7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8365B2B2794A1DD5B5F902F7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > John Stracke wrote: > > > > >Yes, but if I move a file from one location to another on any OS, > > >it does not allow someone to see some of the PRIVATE data insie the > > >file just because the grandparent directory allowed it, and my > > >old one did not. > > > > Er...it might. On Unix, if you have a file in a directory where I do not > > have permissions, I cannot list the directory, and I cannot read or write > > the file even if the file itself says I have permissions to do so. If you > > then move that file into a directory where I *do* have execute > > permissions, then I can read the file if the file says I can. > > Exactly : "if the file says I can". > > We agreed about a month ago to allow VCARs in all (or > most) components. So let's take advantage of it. Several of us agreed. But that does not mean it will work :-) There may be issues. > If a user is concerned about a particular VEVENT's > access rights, he will add a VCAR within that VEVENT. > When that VEVENT will be moved from one calendar to > another the VCAR will remain with the VEVENT. We have not talked about this yet. For example, what if you export a VEVENT with a GRANT for UPN=doug, but you mean doug@stelcor.com and not doug@Royer.com. We need to think about the issues here. > When moving a VEVENT (or a group of VEVENT) from one > calendar to another, a CUA could propose the calendar > user to duplicate the VCARs that currently apply to > the VEVENT within the VEVENT itself before moving it. > > Doesn't that address the concern? Do you really want ALL VCARS in each object? That is what I think you just said. > > > > I'm not convinced that this is too complex to solve right now. However, I > > am convinced that putting it off is safe (safer than getting it wrong, > > anyway :-), so maybe that's the right thing to do. > > The move command is too important to be left out. > If more work is required in the VCAR, let's do it > now, instead of dropping basic functionnality such > as moving a component. Too important? Is it worth holding up CAP for 6 months to 12 months when we can add it on later? Just wanting it does not solve the problems. I still say only the CU/CUA knows, load up the entire calendar, copy it, delete the old. Then the CU/CUA can address access issues. -Doug --------------8365B2B2794A1DD5B5F902F7 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 15:04:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLJptS21480 for ietf-calendar-bks; Fri, 21 Dec 2001 11:51: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 fBLJps221476 for ; Fri, 21 Dec 2001 11:51: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 LAA05954; Fri, 21 Dec 2001 11:51:03 -0800 (PST) Message-ID: <3C239204.A0E83CB9@Royer.com> Date: Fri, 21 Dec 2001 12:48:20 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Desruisseaux CC: ietf-calendar@imc.org Subject: Re: CAP Draft 6 comments References: <3C2269D7.28FB5E37@steltor.com> Content-Type: multipart/mixed; boundary="------------469F9A218E3C146721DBED8D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------469F9A218E3C146721DBED8D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > John Stracke wrote: > > > > >The move command is too important to be left out. > > > > I'm not sure. It's *useful*, but it's not *essential*. You can always do > > a get, put, delete. And, since we do arbitrary queries, you can do all > > that in two round trips, even if you're moving multiple components, so you > > can fill the TCP pipe and blast the data straight through. > > > > CAP would certainly be less efficient without MOVE, but that's better than > > hurrying and getting the ACLs wrong. > > But how does the "get, put, delete" help us getting the > ACLs right? Because the USER and the CUA can evaluate them, and it is not evaluated by the CS which can only guess and may get them wrong. At least the CU and CUA can show the issues to the user and get user input. AND - even if the MOVE command is in CAP. The CUA can still get, put, delete and do what it wants anyway. --------------469F9A218E3C146721DBED8D 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 15:07:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLJrDH21500 for ietf-calendar-bks; Fri, 21 Dec 2001 11:53:13 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLJrC221496 for ; Fri, 21 Dec 2001 11:53:12 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@mail.imc.org id OAA03804; Fri Dec 21 14:48:49 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 21 Dec 2001 14:56:21 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/21/2001 02:56:25 PM, Serialize complete at 12/21/2001 02:56:25 PM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@mail.imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If it is possible for a CUA to implement a move that >satisfies some access right requirements (what ever they >may be), then what are we loosing by keeping the "move" >command? The point is that the risk we're worrying about with CS is that we have to standardize what the user wants to happen to the ACLs. If the CUA does it, then the CUA can change the ACLs to whatever makes sense in its UI. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |============================================================| |If all the world's a stage, I want to operate the trap door.| \============================================================/ From owner-ietf-calendar@mail.imc.org Fri Dec 21 15:08:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01074 for ; Fri, 21 Dec 2001 15:08:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLJv8f21576 for ietf-calendar-bks; Fri, 21 Dec 2001 11:57: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 fBLJv7221571 for ; Fri, 21 Dec 2001 11:57:07 -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 LAA05964 for ; Fri, 21 Dec 2001 11:56:38 -0800 (PST) Message-ID: <3C239353.C899868@Royer.com> Date: Fri, 21 Dec 2001 12:53: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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Draft 6 comments References: <3C234E4E.C8489803@steltor.com> Content-Type: multipart/mixed; boundary="------------A02A9431511E67FD532227C5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A02A9431511E67FD532227C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > Beside efficiency, there is another fundamental difference > between a "move" and a combination of "search", "create" > and "delete". The "move" command is atomic, and since there is > no transaction in CAP, "search" + "create" + "delete" is not. Yes - it is a differance. > This makes it very hard (impossible?) for a CUA to implement > a safe move. You just brought up another reason not to hurry and put MOVE into CAP. What happends to all of the outstanding iTIP objects for the old calendar? How do you notify everyone? (One reason CAP does not do transactions) We need more talk about MOVE and it is a big issue. We can punt for now, and talk later. Lets get CAP out. -Doug --------------A02A9431511E67FD532227C5 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 15:14:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLK41C21741 for ietf-calendar-bks; Fri, 21 Dec 2001 12:04: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 fBLK40221730 for ; Fri, 21 Dec 2001 12:04: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 MAA05979 for ; Fri, 21 Dec 2001 12:03:31 -0800 (PST) Message-ID: <3C2394F0.5F76C8FE@Royer.com> Date: Fri, 21 Dec 2001 13:00: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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: CARREF rule part References: <3C237863.9E371655@steltor.com> Content-Type: multipart/mixed; boundary="------------A4EFF3DB913670CFE9D34D14" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A4EFF3DB913670CFE9D34D14 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The CARREF rule parts specifies a reference to a > particular "VCAR" calendar components in the CS. > > I don't understand why CARREF is a rule part of > a RIGHTS value type and not a property of a VCAR > component. It would make sense for a VCAR to be > defined in terms of another VCAR but not for a > RIGHTS to be defined in terms of a VCAR. > > What would be the difference between specifying > CARREF in the GRANT property versus in the DENY > property? Because you are not statically binding VCARS and they can be changed out from under you. The chain of events could be a mess for the CUA. > Which UPN should be considered when a RIGHTS value > type that has both a UPN rule part and a CARREF rule > part makes reference to a VCAR that has RIGHTS value > types with specific UPNs? You have a GRANT for the operation or not. If you have a GRANT you can do it. > I propopose that we make CARREF a property of VCAR > components instead of a rule part of the RIGHTS > value type. I propose NO CARREF. I say we do NOT have a CARREF static. You do NOT have to build on other VCARs. You simply have access or not. You proposing that each update to any VCAR that MIGHT have a CARREF to it, in effect update all VCARS? What if you don't have access to them? CARREF is placing inheritance inside of inheritance. We don't need that. PLUS now we have to have circular detection in VCARS (a->b->c->a). --------------A4EFF3DB913670CFE9D34D14 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 15:17:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLK67u21816 for ietf-calendar-bks; Fri, 21 Dec 2001 12:06: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 fBLK66221812 for ; Fri, 21 Dec 2001 12:06: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 MAA05985 for ; Fri, 21 Dec 2001 12:05:37 -0800 (PST) Message-ID: <3C23956E.379CC7F3@Royer.com> Date: Fri, 21 Dec 2001 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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Calendar Adresses vs CAP URIs References: <3C238473.966CFE9E@steltor.com> Content-Type: multipart/mixed; boundary="------------5182CF5A5500C98B52D5977F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5182CF5A5500C98B52D5977F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > CAP should only specify that calendar addresses can > be specified as both relative or absolute CAP URIs, > and CAP URIs could be specified in another section, > or in a separate document altogether. The problems is that there needs to be a way to say 'I mean local to the CS only' and we called that a relative URI. > With fanout left out, are there still cases where an > absolute CAP URI is required to specify a calendar > address? YES ! How else can I specify a CS other than my default? --------------5182CF5A5500C98B52D5977F 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 15:26:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLKET822363 for ietf-calendar-bks; Fri, 21 Dec 2001 12:14: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 fBLKE7222338 for ; Fri, 21 Dec 2001 12:14:07 -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 MAA06002 for ; Fri, 21 Dec 2001 12:13:38 -0800 (PST) Message-ID: <3C23974F.A9F1276B@Royer.com> Date: Fri, 21 Dec 2001 13:10:55 -0700 From: Doug Royer Reply-To: ietf-calendar@mail.imc.or Organization: INET-Consulting 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: CAP Draft 6 comments References: <3C2385B0.8B9D7E7@steltor.com> Content-Type: multipart/mixed; boundary="------------A03CA5EA90312DF109F42F7D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A03CA5EA90312DF109F42F7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > John Stracke wrote: > > > > > Beside efficiency, there is another fundamental difference > > >between a "move" and a combination of "search", "create" > > >and "delete". The "move" command is atomic, > > > > That's not necessarily a trivial requirement, you know. > > > > >and since there is > > >no transaction in CAP, "search" + "create" + "delete" is not. > > > > > > This makes it very hard (impossible?) for a CUA to implement > > >a safe move. > > > > Yeah, well, there are different kinds of safety. In this case, safety > > from errors in the CS is competing with safety from errors in the security > > design. The security design is longer-lived than any one CS. > > > > The point that I wanted to make is that a "move" can't > really fully be implemented on the client side. Nor on the server side. > I don't understand what access right issues would be > resolved by dropping the "move". If I recall correctly the > discussion started when Steve ask: "Do people have an issue > with calenders possibly becoming more restrictive after > a move?" The issues resolved (for later debate and resolution) are: What if the parent VCAR sets are not compatible? ... What if the UPN's in you GRANTs have DENY in the new parent. You now have bogus VCARS that do nothing. What if the new parent deny's you access that were the bases of the old VCARs? Now most of your VCARs are bogus. What if the new parent GRANTS all to everyone? And you did not know it? ... > Well if we drop the "move" command saying that most > of the functionality could be achieved by a "search", > "create" and "delete". What are we gaining? (1) CAP out the door faster. (2) More time to figure out MOVE which can be added later. > If a CUA uses a simple "search" and forward result to > "create" method, then we are in the same situation, but we > loose efficiency and open the door to concurrency problems. No - now the CU/CUA can resolve VCAR issues. We can use that usre experiance to learn what (or if) we can do move automaticly by the CS. For now (1) DENY everyone but owner. (2) Load calenndar to CUA. (3) CUA/CU updates any VCAR issues. (4) CUA/CU can decide what to do with outstanding iTIP objects. (4) Save calendar to new location. (5) delete old calendar. > If it is possible for a CUA to implement a move that > satisfies some access right requirements (what ever they > may be), then what are we loosing by keeping the "move" > command? Busted VCARs. > Couldn't the access right settings be adjusted > in the same manner by the CUA. (CS?) CUA - Yes. (did you mean CS - No - not withouot user input). --------------A03CA5EA90312DF109F42F7D 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 15:30:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBLKIRb22759 for ietf-calendar-bks; Fri, 21 Dec 2001 12:18: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 fBLKIQ222755 for ; Fri, 21 Dec 2001 12:18: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 MAA06013 for ; Fri, 21 Dec 2001 12:17:57 -0800 (PST) Message-ID: <3C239851.6D021BF2@Royer.com> Date: Fri, 21 Dec 2001 13:15: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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@Royer.com> <3BFC2E3C.375E9640@steltor.com> <3BFC3A84.57438517@Royer.com> <3BFC4F8B.287BB80F@steltor.com> <3BFEC4F7.FD7A6CD1@Royer.com> <3C224EF5.2D0BD2F6@steltor.com> Content-Type: multipart/mixed; boundary="------------7C9DD979EEB11895B5AEA616" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7C9DD979EEB11895B5AEA616 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > It lists any predefined VCARS that exist by CARID. > > > > It allowed small devices to determine which 'predefined' VCARs > > the CS knows, that the small CUA understands. So the small CUA > > can just query for what it wants and does not have to do a full > > VQUERY of what might be a large set of VCARs - then sort them. > > REQUESTONLY is by definition limited to what the authenticated > > entity can do, so the small CUA does not have to care about anything > > other than understanding that what comes back applied to the current > > authenticated entity. > > Sorry Doug, but I think I'm missing some basic information here! > > Why would a CUA (small or thick) want to get the list of > predefined CARIDs? What is it going to do with this list? Know what is suppored. > My understanding is that DEFAULT_VCAR would only be useful > (used?) by the CS to duplicate the predefined VCAR in newly > created VAGENDAs (which I questioned the usefulness given > that we have inheritance). And for the CUA to know which (by name) they are. > > > > A small CUA can say: 'I know the function of CARID:REQUESTONLY', but > > I don't care about the rest of them. > > How can a CUA not care about certain VCARs? Doesn't all VCARs > for which the user's UPN match applies to the user regarless > of their CARID? If I can't update my REQUESTONLY values - I won't try as I am a stupid CUA and don't understand (fully) VCARS. > How can a CUA claim to "know the function of" a VCAR based on > its CARID? Can't a user change the definition of the predefined > VCARs at will, that is, to the extent where CARID:DEFAULTOWNER > would not even apply to UPN=OWNER? Becase CAP defines that REQUESTONLY VCAR retruns ONLY the VCARS that apply to that need. > If I want to deny you the right to create new event invitations > in my calendar, am I forced to specify that RIGHTS (i.e., DENY) > in the VCAR with CARID:REQUESTONLY? The default is DENY, you don't have to do anyting to deny me. > What is the purpose of predefined CARID? See previous post (in fact in the text you quoted from be below). > Is it related to CAR-MIN versus CAR-FULL-1? > > Currently, according to the specification, VCAR support restricted > to CAR-MIN doesn't imply that only the predefined CARID are > supported by the CS. If on the contrary it implies it, it should > be written in the draft. It should - that is why they were added - good catch. > > > > There was a lot of resistance to not having predefined CARID's by > > function VQUERYable by name. So then the debate went to, how > > do I find out which predefined CARIDs does the CS support? The > > answer was to add DEFAULT_VCAR at the CS level. Then we agreed > > that any predefined 'access' MUST BE identifiable by a VCAR. > > Then others asked - 'how can we expand this list in the future?'. > > Then others asked what about any current VCAR with a CARID at the > > CS level, so then DEFAULT_VCARs was expanded to include any VCAR in the CS > > that had a CARID. In that way any CARID in DEFAULT_VCAR might > > be a predefined CARID, and it no long matters to the CUA, it simply > > gets a list, some of which may be predefined in an RFC. --------------7C9DD979EEB11895B5AEA616 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 21 Dec 2001 17:40:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBLMPD529581 for ietf-calendar-bks; Fri, 21 Dec 2001 14:25: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 fBLMPA229576 for ; Fri, 21 Dec 2001 14:25: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 RAA01739 for ; Fri, 21 Dec 2001 17:25:07 -0500 Received: from steltor.com (IDENT:patricel@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 fBLMP7H19440 for ; Fri, 21 Dec 2001 17:25:07 -0500 (EST) Message-ID: <3C23B8A7.955EE93B@steltor.com> Date: Fri, 21 Dec 2001 17:33:11 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Draft 6 comments References: <3C2385B0.8B9D7E7@steltor.com> <3C23974F.A9F1276B@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: > ... > What if the parent VCAR sets are not compatible? ... > > What if the UPN's in you GRANTs have DENY in the > new parent. You now have bogus VCARS that do > nothing. I don't think so, from CAP section 2.4.2: "The access for a particular UPN is the union of "all grants for that UPN minus the union of its denies." > > What if the new parent deny's you access that were > the bases of the old VCARs? Now most of your > VCARs are bogus. > > What if the new parent GRANTS all to everyone? > And you did not know it? > "did not know it?" that is a poor excuse. The only thing a protocol can do is to provide the mean to obtain the information and the "search" command does. > ... > > What are we gaining? > > (1) CAP out the door faster. > (2) More time to figure out MOVE which can be added later. > I still don't see the problems. However if the consensus is to wait, then could the first version of CAP supports the "move" command for some components (e.g., VEVENT, VTOTO), but prevent moving VAGENDA (and VCAR?). If we do so a new capability should be added to list the types of the component that may be moved. -- Patrice. From owner-ietf-calendar@mail.imc.org Fri Dec 21 19:54:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05727 for ; Fri, 21 Dec 2001 19:54:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBM0eb006209 for ietf-calendar-bks; Fri, 21 Dec 2001 16:40: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 fBM0ea206205 for ; Fri, 21 Dec 2001 16:40: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 QAA06415 for ; Fri, 21 Dec 2001 16:40:08 -0800 (PST) Message-ID: <3C23D5C2.FFFCE6D4@Royer.com> Date: Fri, 21 Dec 2001 17:37: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.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Draft 6 comments References: <3C2385B0.8B9D7E7@steltor.com> <3C23974F.A9F1276B@Royer.com> <3C23B8A7.955EE93B@steltor.com> Content-Type: multipart/mixed; boundary="------------37923AAFA0E43DDDCB049626" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------37923AAFA0E43DDDCB049626 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > Doug Royer wrote: > > ... > > What if the parent VCAR sets are not compatible? ... > > > > What if the UPN's in you GRANTs have DENY in the > > new parent. You now have bogus VCARS that do > > nothing. > > I don't think so, from CAP section 2.4.2: Not the same topic. That refers on how to determine the results of a calendars VCAR set. It does not declare that two or more calendars will have the same VCARS or that they are compatable. > "The access for a particular UPN is the union of > "all grants for that UPN minus the union of its denies." > > > > > What if the new parent deny's you access that were > > the bases of the old VCARs? Now most of your > > VCARs are bogus. > > > > What if the new parent GRANTS all to everyone? > > And you did not know it? > > > > "did not know it?" that is a poor excuse. The only thing a > protocol can do is to provide the mean to obtain the information > and the "search" command does. Exactly! That is why the CUA and CU MUST make the decissions. And the only way the CU can know that is if your CUA did the work, which is my point. Only the CU will know if that is an issue, and only after the CUA has loaded the new parent VCAR list, and after it has loaded the old calerndar VCARS - then the user can know if they are going to care about VCAR changes. I just don't see any way to automate this knowladge into the CS (yet). > > ... > > > What are we gaining? > > > > (1) CAP out the door faster. > > (2) More time to figure out MOVE which can be added later. > > > > I still don't see the problems. However if the consensus is to > wait, then could the first version of CAP supports the "move" > command for some components (e.g., VEVENT, VTOTO), but prevent > moving VAGENDA (and VCAR?). > If we do so a new capability should be added to list > the types of the component that may be moved. YES!! Great idea. --------------37923AAFA0E43DDDCB049626 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Sat, 22 Dec 2001 12:15:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBMGtYa09860 for ietf-calendar-bks; Sat, 22 Dec 2001 08:55:34 -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 fBMGtW209855 for ; Sat, 22 Dec 2001 08:55:32 -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 fBMGtSx11655 for ; Sat, 22 Dec 2001 08:55:29 -0800 (PST) Received: from sman-cpi ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GOR8CG00.49J for ; Sat, 22 Dec 2001 08:55:28 -0800 Date: Sat, 22 Dec 2001 08:54:56 -0800 (Pacific Standard Time) From: sman@netscape.com (Steve Mansour) Reply-To: sman@netscape.com Subject: Proposed removal of hierarchy from CAP To: CalSched IETF Message-ID: <3C24BAE0.6010201@netscape.com> X-Mailer: Photon, lighting the way, build 2001-12-14-11:53:15 (built by rogc) MIME-Version: 1.0 Content-Type: TEXT/HTML; CHARSET=UTF-8 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

Folks,

I hesitate to stir up the works here, but here goes...  It has been= =20 proposed to me in private email and phone conversations that we remove hier= archy=20 from CAP. That is, calendars would not be hierarchical in nature; they woul= d not=20 have the PARENT and CHILDREN properties.  This was proposed as a=20 simplification. It simplifies access control (especially around the "move"= =20 command); it will simplify implementations.  I talked with ta few peop= le=20 about this at the meeting in SLC.  It seems to have some support.=

What do you all think about dropping hierarchy from calendars?

-Steve
--
Steve Mansour
Director of Engineering
AOL /= =20 Netscape From owner-ietf-calendar@mail.imc.org Sat Dec 22 13:01:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01479 for ; Sat, 22 Dec 2001 13:01:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBMHkqb11289 for ietf-calendar-bks; Sat, 22 Dec 2001 09:46: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 fBMHko211285 for ; Sat, 22 Dec 2001 09:46: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 JAA06999 for ; Sat, 22 Dec 2001 09:46:21 -0800 (PST) Message-ID: <3C24C63F.4BD18DCC@Royer.com> Date: Sat, 22 Dec 2001 10:43:27 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting 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: Proposed removal of hierarchy from CAP References: <3C24BAE0.6010201@netscape.com> Content-Type: multipart/mixed; boundary="------------BA5EADB859932BD4F5847ADB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BA5EADB859932BD4F5847ADB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > Folks, > > I hesitate to stir up the works here, but here goes... It has been > proposed to me in private email and phone conversations that we remove > hierarchy from CAP. That is, calendars would not be hierarchical in > nature; they would not have the PARENT and CHILDREN properties. This > was proposed as a simplification. It simplifies access control > (especially around the "move" command); it will simplify > implementations. How about: We could do away with VCAR inheritance and keep the calendar hierarchical structure as is. This would also simplify the move command to the point it could be used. A calendar simply contains ALL of its own VCARs. Implementations would sill be free to implement the storage of VCARs the same as long as the net result was that it appeared to all calendars as if they contain their own VCARs? Immutable decreed VCARs would just 'seem' to be in each calendar. No inheritance needed. Same with the CAR-MIN VCARs. -Doug --------------BA5EADB859932BD4F5847ADB 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Sun, 23 Dec 2001 21:03:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBO1hsG19841 for ietf-calendar-bks; Sun, 23 Dec 2001 17:43: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 fBO1hq219837 for ; Sun, 23 Dec 2001 17:43: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 RAA08354 for ; Sun, 23 Dec 2001 17:42:54 -0800 (PST) Message-ID: <3C268760.F9FADA5@Royer.com> Date: Sun, 23 Dec 2001 18:39: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-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alarms - was RE: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------55BA5A94BAFC3A555AFB6672" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------55BA5A94BAFC3A555AFB6672 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > Granted that the ATTENDEE list is fully expanded in the alarm when > stored, ... Why? Are you saying the CS expands the list? If not the CS, then why would the CUA expand the list prior to storing? > ... it is not inconceivable that a CUA would want to possibly > refresh the list before sending the email if the group membership has > changed (or can change outside of the control of the CUA such as in a > "Westford Employees" mailing list maintained by someone else). This > is a bell and whistle type feature but one that could not be > implemented if the CS did it automagically for the CUA. Sure it could, store the VALARM with the 'Westford Employees" mailing list, and when the alarm went off, let the mailer (MUA or MTA) expand the list as they can do that anyway. The CU said "list name", not only who is on the list now. No matter if the CUA or CS sends the alarm. > Also, the CS can send the email alarm on behalf of the CU but not all > C&S systems have that as their model currently. As stated before, by > myself and others, this is an area that has not had any real cycles > spent on it to deal w/disparate models of behaviour between the > different products that currently exist. Chalk it up as an issue set > that needs to be addressed. However I think that there are bigger > fish in the CAP pond that need frying before we deal w/something of > this size. I agree. We can ship CAP and solve this later. > > if a CUA is running and intends to report the alarm, it doesn't > need > >the CS to tell it so. It can just query the server, say, once an > hour, > >and ask for all the alarms which it should report in the next hour. > > That would work if I didnt allow other CUs to access and put entries > on my calendar. For example, my AA gets a call from another mgr > requesting some block of time so she 'over books' me and sets a > display alarm for me to see to get me out of my other meeting(s). As > such, if the CUA only polled hourly (or longer) it would miss new > entries that arrive in that time frame. > > Add to this mix the ability to have the CS autoprocess requests (ie: > from my mgr gets overridding priority compared to my peers) then its > apparent that smaller polling windows are necessary (in the client > poll model). Or the notification model that we opted out for this version of CAP. Perhaps we can solve this issue at the next revision when we solve the notification issue. > ...>This scales better, because it doesn't require the CS to do as much > work > >to service all the alarms; it pushes the work to the edges. > > This argues for a 'client pull' model for alarms. Since thats the > model we've had for years Im kinda partial to it. Then we could agree to defer this until we can figure out how to have off-line alarms. I would agree as: Any CS that does it now has only a web or real stupid CUA. and those CUAs can not do it anyway so it would have to be a vendor specific feature for now. Any CS that does not already send alarms for the CUA is not going start soon. So it will work for those vendors already. > To keep the designe simpler, I think that the CS should not be > involved in servicing any alarms since it removes the "Im a 'client > pull' CS and he's a 'server push' CUA so what do we do?" quandry. If > the CUA was responsible for handling all alarms then its keeps this > part of CAP simple to grok and more likely to allow for better > interop. I Agree (until we have notification :-) --------------55BA5A94BAFC3A555AFB6672 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Sun, 23 Dec 2001 21:03:40 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBO1nFK19879 for ietf-calendar-bks; Sun, 23 Dec 2001 17:49: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 fBO1nE219874 for ; Sun, 23 Dec 2001 17:49: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 RAA08360 for ; Sun, 23 Dec 2001 17:48:47 -0800 (PST) Message-ID: <3C2688C1.F74515B2@Royer.com> Date: Sun, 23 Dec 2001 18:45: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-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Alarms - was RE: Question on calstore current time. References: Content-Type: multipart/mixed; boundary="------------7DBF82B3E5C81D1DA8D6DA51" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7DBF82B3E5C81D1DA8D6DA51 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > (Personally, I've always felt that a good scheduling system should obviate > the need for an assistant to put things on your calendar; but I'm aware > that PHBs are not going to give up that status symbol easily.) Not always a status symbol. It could be a company or group calendar where the maintainers of the calendar are multiple people. > >Add to this mix the ability to have the CS autoprocess requests (ie: > >from my mgr gets overridding priority compared to my peers) then its > >apparent that smaller polling windows are necessary (in the client > >poll model). > [...] > >>This scales better, because it doesn't require the CS to do as much > >>work > >>to service all the alarms; it pushes the work to the edges. > > > >This argues for a 'client pull' model for alarms. Since thats the > >model we've had for years Im kinda partial to it. > > Yeah, but your model is based on the CUA having a complete copy of what's > in the CS (as near as I can tell from having used it the past two months). > A thin-client model might not be able to cope with that. The CUA only needs to know the times of the alarms, then when the alarm is about to go off, VQUERY for whatever else it needs. There is (was?) and example of this in CAP. Each poll need only poll for alarm times and current "display" view range. It MAY pull down more. > And the alternative is polling, which is really hard on the CS--harder > than having the CS poll itself at similar frequency. I also don't like the poll model. But for now it works. > So maybe we need a way for the CS to push alarm reminders to the CUA? Only > if it's been asked to, of course. A.K.A. - notifications. --------------7DBF82B3E5C81D1DA8D6DA51 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 24 Dec 2001 09:30:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBOEDmW08532 for ietf-calendar-bks; Mon, 24 Dec 2001 06:13:48 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBOEDk208524 for ; Mon, 24 Dec 2001 06:13:46 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id JAA22042; Mon Dec 24 09:08:36 2001 Subject: Re: CAP Draft 6 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 24 Dec 2001 09:15:15 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 12/24/2001 09:16:28 AM, Serialize complete at 12/24/2001 09:16:28 AM Content-Type: text/plain; charset="us-ascii" To: ietf-calendar@imc.org From: "John Stracke" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> What if the new parent GRANTS all to everyone? >> And you did not know it? >> > > "did not know it?" that is a poor excuse. The only thing a >protocol can do is to provide the mean to obtain the information >and the "search" command does. I disagree. The protocol can, and must, make sure that the default behavior is safe. We haven't yet figured out how to do that. /=======================================================\ |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 Mon Dec 24 09:34:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22707 for ; Mon, 24 Dec 2001 09:34:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBOEKYC09055 for ietf-calendar-bks; Mon, 24 Dec 2001 06:20: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 fBOEKX209049 for ; Mon, 24 Dec 2001 06: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 JAA15294 for ; Mon, 24 Dec 2001 09:20:29 -0500 Received: from steltor.com (bernard-pc.CST.CA [192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBOEKSH03329 for ; Mon, 24 Dec 2001 09:20:28 -0500 (EST) Message-ID: <3C2739EA.7E940F41@steltor.com> Date: Mon, 24 Dec 2001 09:21:30 -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: Calendar Adresses vs CAP URIs References: <3C238473.966CFE9E@steltor.com> <3C23956E.379CC7F3@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: > > > CAP should only specify that calendar addresses can > > be specified as both relative or absolute CAP URIs, > > and CAP URIs could be specified in another section, > > or in a separate document altogether. > > The problems is that there needs to be a way to say 'I mean local > to the CS only' and we called that a relative URI. I understand that. I simply want section 2.6 to be changed so it becomes clear that: Calendar address -> Relative CAP URI | Absolute CAP URI and NOT that: CAP URI -> Calendar address 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 Dec 24 10:02:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22894 for ; Mon, 24 Dec 2001 10:02:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBOEme111461 for ietf-calendar-bks; Mon, 24 Dec 2001 06:48: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 fBOEmd211457 for ; Mon, 24 Dec 2001 06:48: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 JAA15552 for ; Mon, 24 Dec 2001 09:48:35 -0500 Received: from steltor.com (bernard-pc.CST.CA [192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBOEmYH04939 for ; Mon, 24 Dec 2001 09:48:34 -0500 (EST) Message-ID: <3C274080.70FA966D@steltor.com> Date: Mon, 24 Dec 2001 09:49:36 -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: VCAR: CARREF rule part References: <3C237863.9E371655@steltor.com> <3C2394F0.5F76C8FE@Royer.com> 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 Doug Royer wrote: > > I propose NO CARREF. I agree. I never understood why they were introduced 3 years ago! 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 Mon Dec 24 11:05:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23303 for ; Mon, 24 Dec 2001 11:05:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBOFnX616476 for ietf-calendar-bks; Mon, 24 Dec 2001 07:49: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 fBOFnT216465 for ; Mon, 24 Dec 2001 07:49: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 KAA16102 for ; Mon, 24 Dec 2001 10:49:25 -0500 Received: from steltor.com (IDENT:patricel@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 fBOFnPH08224 for ; Mon, 24 Dec 2001 10:49:25 -0500 (EST) Message-ID: <3C275062.B94F2148@steltor.com> Date: Mon, 24 Dec 2001 10:57:22 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Draft 6 comments 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: > > >> What if the new parent GRANTS all to everyone? > >> And you did not know it? > >> > > > > "did not know it?" that is a poor excuse. The only thing a > >protocol can do is to provide the mean to obtain the information > >and the "search" command does. > > I disagree. The protocol can, and must, make sure that the default > behavior is safe. We haven't yet figured out how to do that. > Ok, I'm finally getting some of your points. Using a a "search" on VCARs and making the proper adjustments to the VCARs before and/or after a "move" on a VAGENDA is complex and may not be performed correctly by all CUAs. In that case, wouldn't it make more sense to address the root of the problem, and explore Doug's suggestion to simplify the access rights model, rather that removing all conflicting features. -- Patrice. From owner-ietf-calendar@mail.imc.org Mon Dec 24 11:17:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23345 for ; Mon, 24 Dec 2001 11:17:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBOG5Tf20501 for ietf-calendar-bks; Mon, 24 Dec 2001 08:05: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 fBOG5S220497 for ; Mon, 24 Dec 2001 08:05: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 LAA16305 for ; Mon, 24 Dec 2001 11:05:24 -0500 Received: from steltor.com (bernard-pc.CST.CA [192.168.3.82]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBOG5NH09421 for ; Mon, 24 Dec 2001 11:05:23 -0500 (EST) Message-ID: <3C275281.272B98A@steltor.com> Date: Mon, 24 Dec 2001 11:06:25 -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: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@Royer.com> <3BFC2E3C.375E9640@steltor.com> <3BFC3A84.57438517@Royer.com> <3BFC4F8B.287BB80F@steltor.com> <3BFEC4F7.FD7A6CD1@Royer.com> <3C224EF5.2D0BD2F6@steltor.com> <3C239851.6D021BF2@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: > > > Why would a CUA (small or thick) want to get the list of > > predefined CARIDs? What is it going to do with this list? > > Know what is suppored. > > > My understanding is that DEFAULT_VCAR would only be useful > > (used?) by the CS to duplicate the predefined VCAR in newly > > created VAGENDAs (which I questioned the usefulness given > > that we have inheritance). > > And for the CUA to know which (by name) they are. But the CUA wouldn't have a clue about the semantic of the predefined CARID that weren't part of the CAP specs. As soon the DEFAULT_VCAR would contain a CARID that was not part of the CAP specs, the CUA wouldn't be able to assume anything. > > > > > > > A small CUA can say: 'I know the function of CARID:REQUESTONLY', but > > > I don't care about the rest of them. > > > > How can a CUA not care about certain VCARs? Doesn't all VCARs > > for which the user's UPN match applies to the user regarless > > of their CARID? > > If I can't update my REQUESTONLY values - I won't try as > I am a stupid CUA and don't understand (fully) VCARS. > > > How can a CUA claim to "know the function of" a VCAR based on > > its CARID? Can't a user change the definition of the predefined > > VCARs at will, that is, to the extent where CARID:DEFAULTOWNER > > would not even apply to UPN=OWNER? > > Becase CAP defines that REQUESTONLY VCAR retruns ONLY the VCARS > that apply to that need. Do you mean that the CS would need to interpret all the VCARs and return all the RIGHTS value type that would seem to apply to REQUESTONLY when the user is searching on CARID:REQUESTONLY? As far as I know, this is not defined in the CAP draft. Are users allowed to create, or modify, VCARs with predefined CARIDs, or does the predefined CARID can only be used with the search command to get a computed VCAR? > > > If I want to deny you the right to create new event invitations > > in my calendar, am I forced to specify that RIGHTS (i.e., DENY) > > in the VCAR with CARID:REQUESTONLY? > > The default is DENY, you don't have to do anyting to deny me. That's beside the point. What if I granted the right to everybody and I wanted to deny you the right, or for whatever reason I wanted to explicitly deny you access. So again, can't I setup my VCAR the way I want regardless of their CARID? > > > What is the purpose of predefined CARID? > > See previous post (in fact in the text you quoted from be below). Your previous post (still quoted below) only gives details about what has been done to accomodate predefined CARIDs, it doesn't say why they were introduced, or what is their purpose for that matter. > > > There was a lot of resistance to not having predefined CARID's by > > > function VQUERYable by name. So then the debate went to, how > > > do I find out which predefined CARIDs does the CS support? The > > > answer was to add DEFAULT_VCAR at the CS level. Then we agreed > > > that any predefined 'access' MUST BE identifiable by a VCAR. > > > Then others asked - 'how can we expand this list in the future?'. > > > Then others asked what about any current VCAR with a CARID at the > > > CS level, so then DEFAULT_VCARs was expanded to include any VCAR in the CS > > > that had a CARID. In that way any CARID in DEFAULT_VCAR might > > > be a predefined CARID, and it no long matters to the CUA, it simply > > > gets a list, some of which may be predefined in an RFC. > > > Is it related to CAR-MIN versus CAR-FULL-1? > > > > Currently, according to the specification, VCAR support restricted > > to CAR-MIN doesn't imply that only the predefined CARID are > > supported by the CS. If on the contrary it implies it, it should > > be written in the draft. > > It should - that is why they were added - good catch. > Then if my CS implementation has the capability CAR-FULL-1 all this CAR-MIN stuff becomes irrelevant. Right? Does a CS that advertised additional CARID in DEFAULT_VCAR needs to show the capability CAR-FULL-1? Do we want to keep CAR-MIN since they are a dead-end? Serious CS implementations will most likely implement CAR-FULL-1 and make logic built in CUA around CAR-MIN a waste of time, or so it seems given all the information that I have about 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 Mon Dec 24 11:38:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23657 for ; Mon, 24 Dec 2001 11:38:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fBOGQpg21513 for ietf-calendar-bks; Mon, 24 Dec 2001 08:26: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 fBOGQo221508 for ; Mon, 24 Dec 2001 08:26: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 IAA08926 for ; Mon, 24 Dec 2001 08:26:20 -0800 (PST) Message-ID: <3C275668.9B0CF46C@Royer.com> Date: Mon, 24 Dec 2001 09:23: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-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Calendar Adresses vs CAP URIs References: <3C238473.966CFE9E@steltor.com> <3C23956E.379CC7F3@Royer.com> <3C2739EA.7E940F41@steltor.com> Content-Type: multipart/mixed; boundary="------------3A49439C58F0E4BF28CB9AF7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3A49439C58F0E4BF28CB9AF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > CAP should only specify that calendar addresses can > > > be specified as both relative or absolute CAP URIs, > > > and CAP URIs could be specified in another section, > > > or in a separate document altogether. > > > > The problems is that there needs to be a way to say 'I mean local > > to the CS only' and we called that a relative URI. > > I understand that. I simply want section 2.6 > to be changed so it becomes clear that: > > Calendar address -> Relative CAP URI | > Absolute CAP URI > > and NOT that: > > CAP URI -> Calendar address Oh, yep great idea :-) --------------3A49439C58F0E4BF28CB9AF7 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 24 Dec 2001 12:26:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBOHDLH22549 for ietf-calendar-bks; Mon, 24 Dec 2001 09: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 fBOHDJ222545 for ; Mon, 24 Dec 2001 09:13: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 JAA08973 for ; Mon, 24 Dec 2001 09:12:49 -0800 (PST) Message-ID: <3C27614C.D0DB4DB5@Royer.com> Date: Mon, 24 Dec 2001 10:09: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-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: DEFAULT_VCARS References: <3BF9485D.69E8DF89@Royer.com> <3BFAD6B0.245B3AFA@steltor.com> <3BFC1958.E1E201CA@Royer.com> <3BFC2E3C.375E9640@steltor.com> <3BFC3A84.57438517@Royer.com> <3BFC4F8B.287BB80F@steltor.com> <3BFEC4F7.FD7A6CD1@Royer.com> <3C224EF5.2D0BD2F6@steltor.com> <3C239851.6D021BF2@Royer.com> <3C275281.272B98A@steltor.com> Content-Type: multipart/mixed; boundary="------------D116C12B5A548AFD6AA55AB8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D116C12B5A548AFD6AA55AB8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > Why would a CUA (small or thick) want to get the list of > > > predefined CARIDs? What is it going to do with this list? > > > > Know what is suppored. > > > > > My understanding is that DEFAULT_VCAR would only be useful > > > (used?) by the CS to duplicate the predefined VCAR in newly > > > created VAGENDAs (which I questioned the usefulness given > > > that we have inheritance). > > > > And for the CUA to know which (by name) they are. > > But the CUA wouldn't have a clue about the semantic of the > predefined CARID that weren't part of the CAP specs. As > soon the DEFAULT_VCAR would contain a CARID that was not > part of the CAP specs, the CUA wouldn't be able to assume > anything. A CUA can ask for the predefined (by access, queryable by name) VCAR's. So, the idea was that any CUA could find out IF it could do a REQUEST on the calendar. So the contents of the results of a VQUERY for REQUESTONLY might not be what the original setup was (for the original REQUESTONLY VCAR). The results of a VQUERY for a REQUESTONLY is the accumulated results of all of the VCARs - limited to telling the calling CUA just that information. By having these, a CUA does not have to parse ALL of the VCARs just to find out if it can do a METHOD:REQUEST. (same for the other named VCARS). The same for any predefined VCAR. > > > > > > > > > > A small CUA can say: 'I know the function of CARID:REQUESTONLY', but > > > > I don't care about the rest of them. > > > > > > How can a CUA not care about certain VCARs? Doesn't all VCARs > > > for which the user's UPN match applies to the user regarless > > > of their CARID? > > > > If I can't update my REQUESTONLY values - I won't try as > > I am a stupid CUA and don't understand (fully) VCARS. > > > > > How can a CUA claim to "know the function of" a VCAR based on > > > its CARID? Can't a user change the definition of the predefined > > > VCARs at will, that is, to the extent where CARID:DEFAULTOWNER > > > would not even apply to UPN=OWNER? > > > > Becase CAP defines that REQUESTONLY VCAR retruns ONLY the VCARS > > that apply to that need. > > Do you mean that the CS would need to interpret all the VCARs > and return all the RIGHTS value type that would seem to apply > to REQUESTONLY when the user is searching on CARID:REQUESTONLY? Yes. And the results can be simplified in many cases to this: GRANT:UPN=; .... or DENY:UPN=;.... > As far as I know, this is not defined in the CAP draft. It may be badly written. The idea was that a CUA can ask if it can do a named thing without having to understand and parse all of the VCARs. The list came from the Dallas TX face to face meeting (results were posted - a few years ago). > Are users allowed to create, or modify, VCARs with predefined > CARIDs, or does the predefined CARID can only be used with the > search command to get a computed VCAR? The results is the same. If a user updates any VCAR (including a named VCAR) the net results are a logical AND of the GRANTs. > > > If I want to deny you the right to create new event invitations > > > in my calendar, am I forced to specify that RIGHTS (i.e., DENY) > > > in the VCAR with CARID:REQUESTONLY? > > > > The default is DENY, you don't have to do anyting to deny me. > > That's beside the point. What if I granted the right to > everybody and I wanted to deny you the right, or for whatever > reason I wanted to explicitly deny you access. So again, > can't I setup my VCAR the way I want regardless of their CARID? Yes. If the following sequence of VCARs were sent: BEGIN:VCAR CARID:REQUESTONLY GRAN:UPN=*;OBJECT=*, ... END:VCAR Then later: BEGIN:VCAR DENY:UPN=doug@royer.com;OBJECT=*;.... END:VCAR Now my CUA can just VQUERY for REQUESTONLY and get: BEGIN:VCAR CARID:REQUESTONLY DENY:UPN=doug@royer.com;... END:VCAR > Then if my CS implementation has the capability CAR-FULL-1 > all this CAR-MIN stuff becomes irrelevant. Right? No. You MUST support at least CAR-MIN. > Does a CS that advertised additional CARID in DEFAULT_VCAR > needs to show the capability CAR-FULL-1? A CUA MUST support: (1) CAR-MIN or (2) CAR-MIN + CAR-FULL-1 You can have other named (CARID) VCARs. If you advertise CAR-MIN, then no one will know to ask except the CUAs that put them in. If you advertise CAR-FULL-1, then you have to support everything. > Do we want to keep CAR-MIN since they are a dead-end? They are not dead end. They are not static. They are how a CUA can find it can do common operations on a calendar without having to VQUERY for all VCARs and then parse and process all of them. > Serious CS implementations will most likely implement > CAR-FULL-1 and make logic built in CUA around CAR-MIN > a waste of time, or so it seems given all the information > that I have about VCAR. I would agree that the CAP draft needs to be updated to correctly describe CAR-MIN vs CAR-FULL-1. A serious CS implementation would have to implement both. I see the CAR-MIN set as a the most common set of requests from a foreign (not the owner) CUA with respect to VCARs. The list of CAR-MIN pre-defined VCARs is also open to debate. More of them? :-) -Doug --------------D116C12B5A548AFD6AA55AB8 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 27 Dec 2001 12:13:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRGv1603155 for ietf-calendar-bks; Thu, 27 Dec 2001 08:57:01 -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 fBRGv0203150 for ; Thu, 27 Dec 2001 08:57:00 -0800 (PST) To: CalSched IETF Cc: Doug@royer.com Subject: Re: Proposed removal of hierarchy from CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_12112001 December 11, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 27 Dec 2001 11:57:53 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_12172001|December 17, 2001) at 12/27/2001 11:52:30 AM, Serialize complete at 12/27/2001 11:52:30 AM Content-Type: multipart/alternative; boundary="=_alternative 005CA25785256B2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CA25785256B2F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 12/22/2001 12:43:27 PM: > How about: > > We could do away with VCAR inheritance and keep the > calendar hierarchical structure as is. 2 tidbits here: 1: Hierarchical calendars are currently defined for VCAR inheritance and NOT content inheritance (Section 1.3): The hierarchical calendar feature is not a storage relationship of the calendars within the CS. Instead it is a feature that relates access control rights to calendar content between different calendars in the CS. The hierarchical relationship of a calendar is specified in the "PARENT" and "CHILDREN" calendar properties. (Emphasis is mine) 2: This feature was created originally to make some vendor(s) more amenable to developing CAP due to how they intended to build it (ie: using folders w/inherited ACLs). Content was NOT included in the 'roll up' because not all existing systems have that archictectural concept and there are LOTS of issues w/content rollup that we collectively did not want to try and bite off for the first pass. However this has long since become moot given the changes in participation in the WG. Since hierarchical calendars are only for VCARs really, I see removing them a worthwhile design simplification given the benefits and the cost of doing so. (Of course I may regret those words in a couple years but hey, its the holidays here so Im blissfully numb about it now.) > A calendar simply contains ALL of its own VCARs. A wise choice... > Implementations would sill be free to implement the storage > of VCARs the same as long as the net result was that it appeared > to all calendars as if they contain their own VCARs? CAP does not mandate HOW you internally build your CS but this VCAR hierarchy is a bit much IMHO. I think that hierarchical VCARs is some baggage we need to jetison to make the design simpler and to aleviate some of the issues that Steve mentioned. Removing it makes the CS's job easier when doing rights checking and other operations. Keeping it adds complexity that I dont think most users will really use/need. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005CA25785256B2F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 12/22/2001 12:43:27 PM:

> How about:
>
>  We could do away with VCAR inheritance and keep the
>  calendar hierarchical structure as is.

2 tidbits here:

1: Hierarchical calendars are currently defined for VCAR inheritance and NOT content inheritance (Section 1.3):

The hierarchical calendar feature is not a storage relationship of the calendars within the CS. Instead it is a feature that relates access control rights to calendar content between different calendars in the CS. The hierarchical relationship of a calendar is specified in the "PARENT" and "CHILDREN" calendar properties.  (Emphasis is mine)

2: This feature was created originally to make some vendor(s) more amenable to developing CAP due to how they intended to build it (ie: using folders w/inherited ACLs).  Content was NOT included in the 'roll up' because not all existing systems have that archictectural concept and there are LOTS of issues w/content rollup that we collectively did not want to try and bite off for the first pass.  However this has long since become moot given the changes in participation in the WG.

Since hierarchical calendars are only for VCARs really, I see removing them a worthwhile design simplification given the benefits and the cost of doing so.  (Of course I may regret those words in a couple years but hey, its the holidays here so Im blissfully numb about it now.)

>  A calendar simply contains ALL of its own VCARs.
A wise choice...

>  Implementations would sill be free to implement the storage
>  of VCARs the same as long as the net result was that it appeared
>  to all calendars as if they contain their own VCARs?
CAP does not mandate HOW you internally build your CS but this VCAR hierarchy is a bit much IMHO.  I think that hierarchical VCARs is some baggage we need to jetison to make the design simpler and to aleviate some of the issues that Steve mentioned.  Removing it makes the CS's job easier when doing rights checking and other operations.  Keeping it adds complexity that I dont think most users will really use/need.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005CA25785256B2F_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 27 13:23:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19460 for ; Thu, 27 Dec 2001 13:23:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRI7O606297 for ietf-calendar-bks; Thu, 27 Dec 2001 10:07: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 fBRI7M206292 for ; Thu, 27 Dec 2001 10:07: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 KAA11339 for ; Thu, 27 Dec 2001 10:06:53 -0800 (PST) Message-ID: <3C2B6254.7D2A3318@Royer.com> Date: Thu, 27 Dec 2001 11:03:00 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Proposed removal of hierarchy from CAP References: Content-Type: multipart/mixed; boundary="------------ACAC01EA0D572B3547F3E599" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ACAC01EA0D572B3547F3E599 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > Doug replied on 12/22/2001 12:43:27 PM: > > > How about: > > > > We could do away with VCAR inheritance and keep the > > calendar hierarchical structure as is. > > 2 tidbits here: > > 1: Hierarchical calendars are currently defined for VCAR inheritance > and NOT content inheritance (Section 1.3): > > The hierarchical calendar feature is not a storage relationship of the > calendars within the CS. It is (at least logically). CAL-A | ...-------------------------... | | CAL-A.1 CAL-A.2 | --------------- | | CAL-A.2.1 CAL-A.2.2 > Instead it is a feature that relates access > control rights to calendar content between different calendars in the > CS. The hierarchical relationship of a calendar is specified in the > "PARENT" and "CHILDREN" calendar properties. (Emphasis is mine) No PARENT / CHILDREN have nothing to do with the VCAR model. > 2: This feature was created originally to make some vendor(s) more > amenable to developing CAP due to how they intended to build it (ie: > using folders w/inherited ACLs). No it was not. Calendar hierarchy was proposed (by me) in Dallas. VCARS (then VACL) were proposed by Frank and I later in Orlando. In Dallas we deferred ACLs because no one had a proposal and we agreed that even if ACLs did not make it into CAP, we needed calendar hierarchy. > Content was NOT included in the > 'roll up' because not all existing systems have that archictectural > concept and there are LOTS of issues w/content rollup that we > collectively did not want to try and bite off for the first pass. > However this has long since become moot given the changes in > participation in the WG. Yes - roll up was deferred at about the Dallas time. It was deferred because it was too complex at that time to debate without specific proposals (I do not think we have ever had any roll up proposed in any detail). > Since hierarchical calendars are only for VCARs really, No they are not. The debate in Dallas had to do with having hierarchical calendar so people could organize separate and unrelated or somewhat related events without cluttering their published accessible calendar. So that ISPs could give their customers one top level calendar, and access to sub-calendars for their social events or for their organizations and control the content. The debate included a youth baseball league, such that: CAL:Baseball-Leage-A | -------------------------------------...... | | CAL:Team-A schedule CAL:Team-B schedule ... So that organizations (or persons) could have a hierarchy of calendars that represented their organization. So that people familiar with that organization could find a schedule for only the particular part of the target organization. > I see removing > them a worthwhile design simplification given the benefits and the > cost of doing so. (Of course I may regret those words in a couple > years but hey, its the holidays here so Im blissfully numb about it > now.) I see removing VCAR inheritance as falling into that category. But I see calendar hierarchy as unrelated to that issue. > > A calendar simply contains ALL of its own VCARs. > > A wise choice... > > > Implementations would sill be free to implement the storage > > of VCARs the same as long as the net result was that it appeared > > to all calendars as if they contain their own VCARs? > > CAP does not mandate HOW you internally build your CS but this VCAR > hierarchy is a bit much IMHO. I think that hierarchical VCARs is some > baggage we need to jetison to make the design simpler and to aleviate > some of the issues that Steve mentioned. Removing it makes the CS's > job easier when doing rights checking and other operations. Keeping > it adds complexity that I dont think most users will really use/need. Removing VCAR inheritance - yes. Removing calendar hierarchy - no. If you don't want to do it, simply place an immutable decreed VCAR in your CS that does not allow child calendars to be created: BEGIN:VCAR DENY:UPN=*; .... OBJECT=CREATE ... \ OBJECT=VAGENDA ...\ OBJECT=CHILDREN .... \ ... END:VCALEN Paul (I think) in Montreal proposed immutable decreed VCARS so that system administrators or implementations could place them into a calendar or CS to allow for site policy and vertical market implementations. If you don't want child calendars, don't allow them. With VCAR inheritance removed, they really are no more complex that any other calendar, just two properties more - PARENT and CHILDREN. I personally never liked VCAR inheritance. I hope it goes away. --------------ACAC01EA0D572B3547F3E599 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 27 Dec 2001 13:43:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRISne06744 for ietf-calendar-bks; Thu, 27 Dec 2001 10:28:49 -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 fBRISl206740 for ; Thu, 27 Dec 2001 10:28:47 -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 fBRISfY25928 for ; Thu, 27 Dec 2001 10:28:41 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GP0LZV00.5MR; Thu, 27 Dec 2001 10:28:43 -0800 Message-ID: <3C2B682A.DBF6BA91@netscape.com> Date: Thu, 27 Dec 2001 10:27:54 -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: Bruce_Kahn@iris.com CC: CalSched IETF Subject: Re: Proposed removal of hierarchy from CAP References: Content-Type: multipart/alternative; boundary="------------6CBE50BB489A3C23C4B74A54" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------6CBE50BB489A3C23C4B74A54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > Doug replied on 12/22/2001 12:43:27 PM: > > > How about: > > > > We could do away with VCAR inheritance and keep the > > calendar hierarchical structure as is. > > 2 tidbits here: > > 1: Hierarchical calendars are currently defined for VCAR inheritance > and NOT content inheritance (Section 1.3): > > The hierarchical calendar feature is not a storage relationship of the > calendars within the CS. Instead it is a feature that relates access > control rights to calendar content between different calendars in the > CS. The hierarchical relationship of a calendar is specified in the > "PARENT" and "CHILDREN" calendar properties. (Emphasis is mine) This is true. The names of calids do not reflect their hierarchy. And CAP has never dictated how storage is to be implemented. The issues all revolve around VCAR inheritance. > 2: This feature was created originally to make some vendor(s) more > amenable to developing CAP due to how they intended to build it (ie: > using folders w/inherited ACLs). Content was NOT included in the > 'roll up' because not all existing systems have that archictectural > concept and there are LOTS of issues w/content rollup that we > collectively did not want to try and bite off for the first pass. > However this has long since become moot given the changes in > participation in the WG. hmm... we should include it or exclude it because it's the right technical decision, not because of anyone's participation. > Since hierarchical calendars are only for VCARs really, I see removing > them a worthwhile design simplification given the benefits and the > cost of doing so. (Of course I may regret those words in a couple > years but hey, its the holidays here so Im blissfully numb about it > now.) > > > A calendar simply contains ALL of its own VCARs. > > A wise choice... > > > Implementations would sill be free to implement the storage > > of VCARs the same as long as the net result was that it appeared > > to all calendars as if they contain their own VCARs? > > CAP does not mandate HOW you internally build your CS but this VCAR > hierarchy is a bit much IMHO. I think that hierarchical VCARs is some > baggage we need to jetison to make the design simpler and to aleviate > some of the issues that Steve mentioned. Removing it makes the CS's > job easier when doing rights checking and other operations. Keeping > it adds complexity that I dont think most users will really use/need. having calendars be self-contained in terms of access control will definitely make things simpler. -Steve --------------6CBE50BB489A3C23C4B74A54 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

Doug replied on 12/22/2001 12:43:27 PM:

> How about:
>
>  We could do away with VCAR inheritance and keep the
>  calendar hierarchical structure as is.

2 tidbits here:

1: Hierarchical calendars are currently defined for VCAR inheritance and NOT content inheritance (Section 1.3):

The hierarchical calendar feature is not a storage relationship of the calendars within the CS. Instead it is a feature that relates access control rights to calendar content between different calendars in the CS. The hierarchical relationship of a calendar is specified in the "PARENT" and "CHILDREN" calendar properties.  (Emphasis is mine)

This is true.  The names of calids do not reflect their hierarchy.  And CAP has never dictated how storage is to be implemented.  The issues all revolve around VCAR inheritance.
2: This feature was created originally to make some vendor(s) more amenable to developing CAP due to how they intended to build it (ie: using folders w/inherited ACLs).  Content was NOT included in the 'roll up' because not all existing systems have that archictectural concept and there are LOTS of issues w/content rollup that we collectively did not want to try and bite off for the first pass.  However this has long since become moot given the changes in participation in the WG.
hmm... we should include it or exclude it because it's the right technical decision, not because of anyone's participation.
Since hierarchical calendars are only for VCARs really, I see removing them a worthwhile design simplification given the benefits and the cost of doing so.  (Of course I may regret those words in a couple years but hey, its the holidays here so Im blissfully numb about it now.)

>  A calendar simply contains ALL of its own VCARs.

A wise choice...

>  Implementations would sill be free to implement the storage
>  of VCARs the same as long as the net result was that it appeared
>  to all calendars as if they contain their own VCARs?

CAP does not mandate HOW you internally build your CS but this VCAR hierarchy is a bit much IMHO.  I think that hierarchical VCARs is some baggage we need to jetison to make the design simpler and to aleviate some of the issues that Steve mentioned.  Removing it makes the CS's job easier when doing rights checking and other operations.  Keeping it adds complexity that I dont think most users will really use/need.

having calendars be self-contained in terms of access control will definitely make things simpler.

-Steve --------------6CBE50BB489A3C23C4B74A54-- From owner-ietf-calendar@mail.imc.org Thu Dec 27 14:53:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20226 for ; Thu, 27 Dec 2001 14:53:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRJdJR09884 for ietf-calendar-bks; Thu, 27 Dec 2001 11:39: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 fBRJdH209875 for ; Thu, 27 Dec 2001 11:39: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 LAA11444 for ; Thu, 27 Dec 2001 11:38:48 -0800 (PST) Message-ID: <3C2B77DE.9C08A7F3@Royer.com> Date: Thu, 27 Dec 2001 12:34:54 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Proposed removal of hierarchy from CAP References: <3C2B682A.DBF6BA91@netscape.com> Content-Type: multipart/mixed; boundary="------------F05C1A98CE9FC6F377675010" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F05C1A98CE9FC6F377675010 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > Bruce_Kahn@iris.com wrote: > > > Doug replied on 12/22/2001 12:43:27 PM: > > > > > How about: > > > > > > We could do away with VCAR inheritance and keep the > > > calendar hierarchical structure as is. > > > > 2 tidbits here: > > > > 1: Hierarchical calendars are currently defined for VCAR inheritance > > and NOT content inheritance (Section 1.3): > > > > The hierarchical calendar feature is not a storage relationship of > > the calendars within the CS. Instead it is a feature that relates > > access control rights to calendar content between different > > calendars in the CS. The hierarchical relationship of a calendar is > > specified in the "PARENT" and "CHILDREN" calendar properties. > > (Emphasis is mine) > > This is true. The names of calids do not reflect their hierarchy. > And CAP has never dictated how storage is to be implemented. The > issues all revolve around VCAR inheritance. The "MOVE" issues all revolve around VCAR inheritance, not hierarchical calendars - correct? However there is NO requirement that calids reflect their hierarchy (as I recall Steve - you are the one that most insisted on that), but this is not a requirement - correct? As in; "they MAY reflect calendarr hierarchical relationships"? Correct? As I recall this was also a Dallas meeting result where some wanted it to be a MUST, and everyone else said it should be a MAY. At the same time we agreed that there would NOT be a predefined hierarchical separator. (Some wanted it to be a '/' and others a '\'). We agreed that implementations and sites could use any (or no) separator. We also agreed that a CUA MUST NOT assume that any calid is or is not a calendar or sub-calendar by looking at the calid - The CUA MUST look at the PARENT and CHILDREN properties. That is NOT the same as as saying that a CS, site, or implementation must not have calids that are hierarchical as viewed by a user: baseball-league-calendar/team-a baseball-league-calendar/team-b Are valid calids, as is: fjjjdfjles09u0ufjdsoipuf and 9kmesdsf09dsa9032jfdp The last two could in fact be calids in another implementation if it did not want to export the hierarchy that exists. And the first two are valid calids and a user could understand the hierarchy by looking and guessing at the calids for; sites, calendars, or implementations, that wished the hierarchy to be viewable and understandable to a user (not the CUA). CS implementations were free to use what ever they wanted as a calid. Correct? > > > A calendar simply contains ALL of its own VCARs. > > > > A wise choice... > > > > > Implementations would sill be free to implement the storage > > > of VCARs the same as long as the net result was that it appeared > > > to all calendars as if they contain their own VCARs? > > > > CAP does not mandate HOW you internally build your CS but this VCAR > > hierarchy is a bit much IMHO. I think that hierarchical VCARs is > > some baggage we need to jetison to make the design simpler and to > > aleviate some of the issues that Steve mentioned. Removing it makes > > the CS's job easier when doing rights checking and other > > operations. Keeping it adds complexity that I dont think most users > > will really use/need. > > having calendars be self-contained in terms of access control will > definitely make things simpler. --------------F05C1A98CE9FC6F377675010 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 27 Dec 2001 16:45:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRLWDE13439 for ietf-calendar-bks; Thu, 27 Dec 2001 13:32:13 -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 fBRLWC213435 for ; Thu, 27 Dec 2001 13:32:12 -0800 (PST) To: CalSched IETF Cc: Doug@royer.com Subject: Re: Proposed removal of hierarchy from CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_12112001 December 11, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Thu, 27 Dec 2001 16:30:13 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_12172001|December 17, 2001) at 12/27/2001 04:27:42 PM, Serialize complete at 12/27/2001 04:27:42 PM Content-Type: multipart/alternative; boundary="=_alternative 0075C76585256B2F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075C76585256B2F_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 12/27/2001 01:03:00 PM: > > 1: Hierarchical calendars are currently defined for VCAR inheritance > > and NOT content inheritance (Section 1.3): > > > > The hierarchical calendar feature is not a storage relationship of the > > calendars within the CS. > > It is (at least logically). Conceptually you may view it that way. However, my citation (found below) was from the CAP spec, not from my imagination or personal opinion. The only thing I added was the bold emphasis. As such, hierarchical calendars as expressly defined as having no 'content' roll up (or other linkages) in CAP; its all for VCARs only. > > Instead it is a feature that relates access > > control rights to calendar content between different calendars in the > > CS. The hierarchical relationship of a calendar is specified in the > > "PARENT" and "CHILDREN" calendar properties. (Emphasis is mine) > > No PARENT / CHILDREN have nothing to do with the VCAR model. They are not part of VCARs but they are the ONLY way that you can build hierarchical calendars for hierarchical VCARs! Since CALIDs have no parsable meaning for conveying hierarchy (unlike your A.1, A.2.2, etc) the ONLY way you can build hierarchy is to have PARENT / CHILDREN links as attributes of the calendars. That's how/why that property was added. Besides, the quote I used was from Section 1.3 of the CAP draft. The point being that the hierarchy exists only for VCAR equivalence checking, NOT for content roll up. > > 2: This feature was created originally to make some vendor(s) more > > amenable to developing CAP due to how they intended to build it (ie: > > using folders w/inherited ACLs). > > No it was not. Calendar hierarchy was proposed (by me) in Dallas. > VCARS (then VACL) were proposed by Frank and I later in Orlando. In > Dallas we deferred ACLs because no one had a proposal and we > agreed that even if ACLs did not make it into CAP, we needed > calendar hierarchy. I wanted to avoid eFinger(TM) pointing but... Microsoft proposed hierarchical calendars so that they could build like they build "public folders" in Exchange and they rely on the folder ACL inheritance for access control. When the WG discussed hierarchy we all agreed that building an architecture for content roll up ("full blown hierarchical calendars") was too much. Most of this took place off the WG list that I recall (hall way talks and the like). This may have occurred at the same times you raised the issue but I cant be sure. The oldest reference to hierarchical calendar is Mark D. Anderson's posting of 21-Nov-1998 titled "capreq questions" and Andre's response the same date. It contains: 4. calendar hierarchy and sub-calendars. Sub calendars are a way to organize data elements in a hierarchy manner. That is, a calendar can contains components (Events, todo, journals, etc) as well as calendars. A use for this would be to store your kids baseball games in a sub calendar to yours. This is *Very* similar to files and directory. Inheritance is not defined as a requirement and is out of scope for the CAP definition. You're response to part of that thread included: Sub-calendars were meant to be conceptually the same as file system directories. (when talking about the actual hierarchical naming scheme actually) but the thread didn't actually cover restricting the hierarchy to VCARs and it focused on whether the names would be hierarchical or opaque, etc. Paul Hill revisited the issue on 9-Apr-1999 with is posting "(long) problems with CAP not having "users" and hierarchical calendars". He did a pretty good job putting many of the hierarchy related issues into prose but unfortunately it did not generate virtually any WG traffic outside the participants already engaged in resolving the issue. I cannot clearly pinpoint the time when we chose to drop the concept of content roll up but I vaguely recall it happening at some meeting where lots of vigorous debate and hand waiving occurred. (Issues like "When does content roll up occur?", "How is busy time searching affected (or effected) in hierarchical calendars?" etc all contributed to the agreement that no content roll up would occur. Microsoft (Lisa or Tony?) was still pushing hard for hierarchical ACLs (VCARs) for the aforementioned reasons. > > Content was NOT included in the > > 'roll up' because not all existing systems have that archictectural > > concept and there are LOTS of issues w/content rollup that we > > collectively did not want to try and bite off for the first pass. > > However this has long since become moot given the changes in > > participation in the WG. > > Yes - roll up was deferred at about the Dallas time. > It was deferred because it was too complex at that time > to debate without specific proposals (I do not think > we have ever had any roll up proposed in any detail). Ok, Ill buy the Dallas time frame. In any case, the current design for roll up is strictly for VCARs and it is causing some CAP complexities that I think can be resolved by simply removing the current hierarchy as Steve has mentioned. Benefits of removing seem to outweigh the problems they cause. That's my sentiments and I'm sticking to 'em... > > Since hierarchical calendars are only for VCARs really, > > No they are not. The debate in Dallas had to do with having > hierarchical calendar so people could organize separate > and unrelated or somewhat related events without cluttering > their published accessible calendar. [Snip, snip] > So that organizations (or persons) could have a hierarchy > of calendars that represented their organization. I can buy that concept but it does not cover all kinds of 'relationships' between all calendars. The use of a "League/Division/Team" kind of hierarchy example is logical for that kind of organization but it does not work for the "Husband/Wife" or "Mother/Father/Brother(s)/Sister(s)/Cousin(s)" model where no calendar is the "parent" really. However I still think that removing hierarchy for VCARs is a very worthwhile change. I can see a case for keeping some kind of 'relationship' meta information on each calendar but I see no strong case for keeping it on VCARs yet (which is how Hierarchical Calendars are expressly defined).. Also, your use of hierarchy is contrary to the definition of hierarchical calendar (see the original definition I cited) so perhaps you should propose some change text to include this design (above and beyond "access rights") > > > I see removing > > them a worthwhile design simplification given the benefits and the > > cost of doing so. (Of course I may regret those words in a couple > > years but hey, its the holidays here so Im blissfully numb about it > > now.) > > I see removing VCAR inheritance as falling into that category. > But I see calendar hierarchy as unrelated to that issue. They are not unrelated given the definition of hierarchical calendars in Section 1.3. > Removing VCAR inheritance - yes. Great! > Removing calendar hierarchy - no. Then provide a more accurate description of Hierarchical Calendar that conveys this. Its not how they are defined now (and why I didn't focus on the meta linkage which is related but not how we defined the linkage. > I personally never liked VCAR inheritance. I hope it goes > away. Sounds like all we need to do is redefine Hierarchical Calendars to remove access rights inheritance and to describe linkages a bit better then. I'm not sure that only adding PARENT/CHILD is the right choice (How would I link to my peer calendars in my team or to the CAP Editors calendars using PARENT/CHILD only?) Bruce PS: Sidebar: If we remove VCAR inheritance and allow for "peer" linkages/relationships then do we really need to restrict the 'hierarchy' to being w/in the same CS? After all, not all "Teams" in the "Division" may want to have their calendars on the same CS if they already have their own sites/systems (nor do I and my wife work at the same place)?? =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0075C76585256B2F_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 12/27/2001 01:03:00 PM:

> > 1: Hierarchical calendars are currently defined for VCAR inheritance
> > and NOT content inheritance (Section 1.3):
> >
> > The hierarchical calendar feature is not a storage relationship of the
> > calendars within the CS.
>
> It is (at least logically).
Conceptually you may view it that way.  However, my citation (found below) was from the CAP spec, not from my imagination or personal opinion.  The only thing I added was the bold emphasis.  As such, hierarchical calendars as expressly defined as having no 'content' roll up (or other linkages) in CAP; its all for VCARs only.

> > Instead it is a feature that relates access
> > control rights to calendar content between different calendars in the
> > CS. The hierarchical relationship of a calendar is specified in the
> > "PARENT" and "CHILDREN" calendar properties.  (Emphasis is mine)
>
> No PARENT / CHILDREN have nothing to do with the VCAR model.
They are not part of VCARs but they are the ONLY way that you can build hierarchical calendars for hierarchical VCARs!  Since CALIDs have no parsable meaning for conveying hierarchy (unlike your A.1, A.2.2, etc) the ONLY way you can build hierarchy is to have PARENT / CHILDREN links as attributes of the calendars.  That's how/why that property was added.

Besides, the quote I used was from Section 1.3 of the CAP draft.  The point being that the hierarchy exists only for VCAR equivalence checking, NOT for content roll up.

> > 2: This feature was created originally to make some vendor(s) more
> > amenable to developing CAP due to how they intended to build it (ie:
> > using folders w/inherited ACLs).
>
> No it was not. Calendar hierarchy was proposed (by me) in Dallas.
> VCARS (then VACL) were proposed by Frank and I later in Orlando. In
> Dallas we deferred ACLs because no one had a proposal and we
> agreed that even if ACLs did not make it into CAP, we needed
> calendar hierarchy.
I wanted to avoid eFinger(TM) pointing but...

Microsoft proposed hierarchical calendars so that they could build like they build "public folders" in Exchange and they rely on the folder ACL inheritance for access control.  When the WG discussed hierarchy we all agreed that building an architecture for content roll up ("full blown hierarchical calendars") was too much.  Most of this took place off the WG list that I recall (hall way talks and the like).  This may have occurred at the same times you raised the issue but I cant be sure.

The oldest reference to hierarchical calendar is Mark D. Anderson's posting of 21-Nov-1998 titled "capreq questions" and Andre's response the same date.  It contains:

4. calendar hierarchy and sub-calendars.


Sub calendars are a way to organize data elements in
a hierarchy manner. That is, a calendar can contains
components (Events, todo, journals, etc) as well as
calendars. A use for this would be to store your
kids baseball games in a sub calendar to yours.  This
is *Very* similar to files and directory.
Inheritance is not defined as a requirement and is
out of scope for the CAP definition.

You're response to part of that thread included:

                               Sub-calendars were meant
to be conceptually the same as file system directories.

(when talking about the actual hierarchical naming scheme actually) but the thread didn't actually cover restricting the hierarchy to VCARs and it focused on whether the names would be hierarchical or opaque, etc.  

Paul Hill revisited the issue on 9-Apr-1999 with is posting "(long) problems with CAP not having "users" and hierarchical calendars".  He did a pretty good job putting many of the hierarchy related issues into prose but unfortunately it did not generate virtually any WG traffic outside the participants already engaged in resolving the issue.

I cannot clearly pinpoint the time when we chose to drop the concept of content roll up but I vaguely recall it happening at some meeting where lots of vigorous debate and hand waiving occurred.  (Issues like "When does content roll up occur?", "How is busy time searching affected (or effected) in hierarchical calendars?" etc all contributed to the agreement that no content roll up would occur.  Microsoft (Lisa or Tony?) was still pushing hard for hierarchical ACLs (VCARs) for the aforementioned reasons.
> >  Content was NOT included in the
> > 'roll up' because not all existing systems have that archictectural
> > concept and there are LOTS of issues w/content rollup that we
> > collectively did not want to try and bite off for the first pass.
> >  However this has long since become moot given the changes in
> > participation in the WG.
>
> Yes - roll up was deferred at about the Dallas time.
> It was deferred because it was too complex at that time
> to debate without specific proposals (I do not think
> we have ever had any roll up proposed in any detail).
Ok, Ill buy the Dallas time frame.  

In any case, the current design for roll up is strictly for VCARs and it is causing some CAP complexities that I think can be resolved by simply removing the current hierarchy as Steve has mentioned.  Benefits of removing seem to outweigh the problems they cause.  That's my sentiments and I'm sticking to 'em...

> > Since hierarchical calendars are only for VCARs really,
>
> No they are not. The debate in Dallas had to do with having
> hierarchical calendar so people could organize separate
> and unrelated or somewhat related events without cluttering
> their published accessible calendar. [Snip, snip]
> So that organizations (or persons) could have a hierarchy
> of calendars that represented their organization.

I can buy that concept but it does not cover all kinds of 'relationships' between all calendars.  The use of a "League/Division/Team" kind of hierarchy example is logical for that kind of organization but it does not work for the "Husband/Wife" or "Mother/Father/Brother(s)/Sister(s)/Cousin(s)" model where no calendar is the "parent" really.

However I still think that removing hierarchy for VCARs is a very worthwhile change.  

I can see a case for keeping some kind of 'relationship' meta information on each calendar but I see no strong case for keeping it on VCARs yet (which is how Hierarchical Calendars are expressly defined)..

Also, your use of hierarchy is contrary to the definition of hierarchical calendar (see the original definition I cited) so perhaps you should propose some change text to include this design (above and beyond "access rights")

>
> > I see removing
> > them a worthwhile design simplification given the benefits and the
> > cost of doing so.  (Of course I may regret those words in a couple
> > years but hey, its the holidays here so Im blissfully numb about it
> > now.)
>
> I see removing VCAR inheritance as falling into that category.
> But I see calendar hierarchy as unrelated to that issue.
They are not unrelated given the definition of hierarchical calendars in Section 1.3.

> Removing VCAR inheritance - yes.
Great!

> Removing calendar hierarchy - no.

Then provide a more accurate description of Hierarchical Calendar that conveys this.  Its not how they are defined now (and why I didn't focus on the meta linkage which is related but not how we defined the linkage.

> I personally never liked VCAR inheritance. I hope it goes
> away.

Sounds like all we need to do is redefine Hierarchical Calendars to remove access rights inheritance and to describe linkages a bit better then.  I'm not sure that only adding PARENT/CHILD is the right choice (How would I link to my peer calendars in my team or to the CAP Editors calendars using PARENT/CHILD only?)

Bruce
PS: Sidebar: If we remove VCAR inheritance and allow for "peer" linkages/relationships then do we really need to restrict the 'hierarchy' to being w/in the same CS?  After all, not all "Teams" in the "Division" may want to have their calendars on the same CS if they already have their own sites/systems (nor do I and my wife work at the same place)??
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0075C76585256B2F_=-- From owner-ietf-calendar@mail.imc.org Thu Dec 27 18:14:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22147 for ; Thu, 27 Dec 2001 18:14:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRN2Go17963 for ietf-calendar-bks; Thu, 27 Dec 2001 15:02:16 -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 fBRN2E217959 for ; Thu, 27 Dec 2001 15:02:14 -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 fBRN21x24024 for ; Thu, 27 Dec 2001 15:02:01 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GP0YND00.AMS for ; Thu, 27 Dec 2001 15:02:01 -0800 Message-ID: <3C2BA838.5F451ADC@netscape.com> Date: Thu, 27 Dec 2001 15:01:12 -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: Re: Proposed removal of hierarchy from CAP References: <3C2B682A.DBF6BA91@netscape.com> <3C2B77DE.9C08A7F3@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: > Steve Mansour wrote: > > > > Bruce_Kahn@iris.com wrote: > > > > > Doug replied on 12/22/2001 12:43:27 PM: > > > > > > > How about: > > > > > > > > We could do away with VCAR inheritance and keep the > > > > calendar hierarchical structure as is. > > > > > > 2 tidbits here: > > > > > > 1: Hierarchical calendars are currently defined for VCAR inheritance > > > and NOT content inheritance (Section 1.3): > > > > > > The hierarchical calendar feature is not a storage relationship of > > > the calendars within the CS. Instead it is a feature that relates > > > access control rights to calendar content between different > > > calendars in the CS. The hierarchical relationship of a calendar is > > > specified in the "PARENT" and "CHILDREN" calendar properties. > > > (Emphasis is mine) > > > > This is true. The names of calids do not reflect their hierarchy. > > And CAP has never dictated how storage is to be implemented. The > > issues all revolve around VCAR inheritance. > > The "MOVE" issues all revolve around VCAR inheritance, not > hierarchical calendars - correct? Right. > However there is NO requirement that calids reflect their hierarchy > (as I recall Steve - you are the one that most insisted on that), but > this is not a requirement - correct? I was a proponent of this, yes. However, I was not one of the ones who insisted on it. I believe that was Andre's hot button :-). Nonetheless, I think it is a wise move to not have the calid reflect the hierarchy or anything else. It is simply an identifier which should not be overloaded. > As in; "they MAY reflect calendarr > hierarchical relationships"? Correct? As I recall this was also > a Dallas meeting result where some wanted it to be a MUST, and > everyone else said it should be a MAY. At the same time we > agreed that there would NOT be a predefined hierarchical separator. > (Some wanted it to be a '/' and others a '\'). We agreed that > implementations and sites could use any (or no) separator. there are no separaters - the calid is an opaque unique identifier > We also agreed that a CUA MUST NOT assume that any calid is or is > not a calendar or sub-calendar by looking at the calid - The CUA MUST > look at the PARENT and CHILDREN properties. That is NOT the same > as as saying that a CS, site, or implementation must not have calids > that are hierarchical as viewed by a user: > > baseball-league-calendar/team-a > > baseball-league-calendar/team-b > > Are valid calids, as is: > > fjjjdfjles09u0ufjdsoipuf > and > 9kmesdsf09dsa9032jfdp > > The last two could in fact be calids in another implementation > if it did not want to export the hierarchy that exists. > > And the first two are valid calids and a user could understand > the hierarchy by looking and guessing at the calids for; sites, > calendars, or implementations, that wished the hierarchy to > be viewable and understandable to a user (not the CUA). > > CS implementations were free to use what ever they wanted > as a calid. Correct? yes. All that you have written above jibes with my understanding. The simplification we seek revolves around access conrol and what it means. If we specify all access control for a calendar is self-contained (no inheritance from the calendar hierarchy) then most of the issues just go away. Bruce, do you have any issues with keeping hierarchy with the proviso that we make it clear that access control and hierarchy are disjoint and unrelated? How does this affect decreed vcars? -Steve From owner-ietf-calendar@mail.imc.org Thu Dec 27 18:56:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22437 for ; Thu, 27 Dec 2001 18:56:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBRNjOT20864 for ietf-calendar-bks; Thu, 27 Dec 2001 15:45: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 fBRNjN220859 for ; Thu, 27 Dec 2001 15:45: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 PAA11676 for ; Thu, 27 Dec 2001 15:44:54 -0800 (PST) Message-ID: <3C2BB18A.C8FEECC@Royer.com> Date: Thu, 27 Dec 2001 16:40:58 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Proposed removal of hierarchy from CAP References: Content-Type: multipart/mixed; boundary="------------D9F7D58F1DB2C38E657532C0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D9F7D58F1DB2C38E657532C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > > No it was not. Calendar hierarchy was proposed (by me) in Dallas. > > VCARS (then VACL) were proposed by Frank and I later in Orlando. In > > Dallas we deferred ACLs because no one had a proposal and we > > agreed that even if ACLs did not make it into CAP, we needed > > calendar hierarchy. > > I wanted to avoid eFinger(TM) pointing but... > > Microsoft proposed hierarchical calendars so that they could build > like they build "public folders" in Exchange and they rely on the > folder ACL inheritance for access control. Wrong - Frank, Steve and I talked Lisa and Tony into hierarchical calendars in Dallas prior to that they were fighting them. (Was this Pat's first calsch face-to-face meeting?) They initially fought the idea with lots of emotion. In fact Lisa Said (In Dallas): "Why would anyone want hierarchical anything [in calendaring]?" For which I replied: "In MS-DOS Version 1.0, Microsoft did NOT have sub-directories in the file system. They added it later because people wanted to organize themselves - same with calendars." Lisa's predecessor (who's name I forgot - last name Dunn?) said they had not decided if they were needed (in LA?). Once they saw the advantage of them, then they went full steam ahead and made the above proposals as you said. **My real point being that it had NOTHING to do with VCARS as they were not proposed in any detail at that time but were simply put on the requirements document item list for CAP. I don't know who added the definition of hierarchical calendars being a product of VCARs to CAP - but it must have been that editors views or understanding. That text should have never been in CAP. > When the WG discussed > hierarchy we all agreed that building an architecture for content roll > up ("full blown hierarchical calendars") was too much. Most of this > took place off the WG list that I recall (hall way talks and the > like). This may have occurred at the same times you raised the issue > but I cant be sure. That was in Orlando - later (did you go to the Dallas meeting?) > The oldest reference to hierarchical calendar is Mark D. Anderson's > posting of 21-Nov-1998 titled "capreq questions" and Andre's response > the same date. It contains: ... Dallas pre-dated cap requirements, as Dallas was the first face to face cap requirements meeting. Yes - Andre was in Dallas. The reason behind the Dallas meeting was to document the participants needs in order to propose the first cap requirements document which came out later. > I cannot clearly pinpoint the time when we chose to drop the concept > of content roll up but I vaguely recall it happening at some meeting > where lots of vigorous debate and hand waiving occurred. It was prior to cap requirements being *accepted*. It may have been mentioned, but there was never any specific proposal. > (Issues like > "When does content roll up occur?", "How is busy time searching > affected (or effected) in hierarchical calendars?" etc all contributed > to the agreement that no content roll up would occur. Microsoft (Lisa > or Tony?) was still pushing hard for hierarchical ACLs (VCARs) for the > aforementioned reasons. Yes - they did want hierarchical ACLs. They wanted to model it after the LDAP ACLs at that time. And that was after (and had nothing to do with) hierarchical calendars. It was because it would have fit into their LDAP schema. > > ... > > > > Yes - roll up was deferred at about the Dallas time. > > It was deferred because it was too complex at that time > > to debate without specific proposals (I do not think > > we have ever had any roll up proposed in any detail). > > Ok, Ill buy the Dallas time frame. > > In any case, the current design for roll up is strictly for VCARs and > it is causing some CAP complexities that I think can be resolved by > simply removing the current hierarchy as Steve has mentioned. > Benefits of removing seem to outweigh the problems they cause. > That's my sentiments and I'm sticking to 'em... There is NO current design for roll up - none at all that was dropped years ago. I am not sure I understand your point. If you meant drop VCAR inheritance - Steve did not propose that, he proposed that all child calendars go away. (Did I misunderstand him?) > > > Since hierarchical calendars are only for VCARs really, > > > > No they are not. The debate in Dallas had to do with having > > hierarchical calendar so people could organize separate > > and unrelated or somewhat related events without cluttering > > their published accessible calendar. [Snip, snip] > > So that organizations (or persons) could have a hierarchy > > of calendars that represented their organization. > > I can buy that concept but it does not cover all kinds of > 'relationships' between all calendars. The use of a > "League/Division/Team" kind of hierarchy example is logical for that > kind of organization but it does not work for the "Husband/Wife" or > "Mother/Father/Brother(s)/Sister(s)/Cousin(s)" model where no calendar > is the "parent" really. I agree. It does not cover all kinds of relationships. I do not think they were ever designed to cover all kinds of relationships. > However I still think that removing hierarchy for VCARs is a very > worthwhile change. I agree. But Steve's proposal was to remove the ability to have child ALL calendars. Steve did NOT propose removing VCAR inheritance directly. He said by removing hierarchical calendars - the VCAR/MOVE issue goes away (actually MOVE goes away as you can already rename a calendar by MODIFY of the property name). And of course, VCAR inheritance would go away as a side effect as there would be no child calendars to inherit anything. > I can see a case for keeping some kind of 'relationship' meta > information on each calendar but I see no strong case for keeping it > on VCARs yet (which is how Hierarchical Calendars are expressly > defined).. I would agree that it is how VCARs are defined. And I would again propose (and I think maybe we are violently agreeing), that VCAR inheritance goes away. > Also, your use of hierarchy is contrary to the definition of > hierarchical calendar (see the original definition I cited) so perhaps > you should propose some change text to include this design (above and > beyond "access rights") That's what we are debating? Removing this from 1.3 / Hierarchical Calendars and tweaking the words: Remove: ... Instead it is a feature that relates access control rights to calendar content between different calendars in the CS. > ... > Sounds like all we need to do is redefine Hierarchical Calendars to > remove access rights inheritance and to describe linkages a bit better > then. Yes - I agree. > I'm not sure that only adding PARENT/CHILD is the right choice. It is already there - nothing to add? > (How would I link to my peer calendars in my team or to the CAP > Editors calendars using PARENT/CHILD only?) No one has proposed any other linkage (other than CHILD/PARENT) - do you have a proposal :-) > Bruce > PS: Sidebar: If we remove VCAR inheritance and allow for "peer" > linkages/relationships then do we really need to restrict the > 'hierarchy' to being w/in the same CS? After all, not all "Teams" in > the "Division" may want to have their calendars on the same CS if they > already have their own sites/systems (nor do I and my wife work at the > same place)?? Do you have a proposal? As to CS <-> CS peer communication for cross CS peer relationships - that I think falls into the category of fanout. Off topic and deferred for CAP 1.0 But I agree. I had proposed years ago (in no detail) that a child calendar coul be a pseudo link to another calendar in order to propose exactly what you wanted. That was part of rollup - and was rejected or deferred. I still think that can be done inside of an implementation and not effect CAP at all. As long as it was ether: (a) Not visible outside the vendors implementation (CS + CUA). or (b) Looked to any non same vendor CUA as if it was just any other child calendar. I think the same is true for fanout. But I would like to see the CS <-> CS interface agreed on some day. --------------D9F7D58F1DB2C38E657532C0 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 28 Dec 2001 14:02:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBSIjG200444 for ietf-calendar-bks; Fri, 28 Dec 2001 10:45:16 -0800 (PST) Received: from capricorn.iris.com ([198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBSIjE200440 for ; Fri, 28 Dec 2001 10:45:15 -0800 (PST) To: CalSched IETF Subject: Re: Proposed removal of hierarchy from CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_12112001 December 11, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Fri, 28 Dec 2001 11:15:03 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_12172001|December 17, 2001) at 12/28/2001 01:40:37 PM, Serialize complete at 12/28/2001 01:40:37 PM Content-Type: multipart/alternative; boundary="=_alternative 0059115985256B30_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059115985256B30_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 12/27/2001 06:40:58 PM: > Wrong - Frank, Steve and I talked Lisa and Tony into hierarchical > calendars in Dallas prior to that they were fighting them. The history lesson debate is becoming a distraction from our apparent partial agreement. Ill just leave it with this final bit. I wasnt in Dallas so I cannot talk about who said what there but my full text indexed archive of this WG and my mail file bear out that Lisa was a proponent of hierarhical calendars for ACL reasons (for previously mentioned underlying shared folder implementation reasons). Those really interested can search the available archives for any future reading. > I don't know who added the definition of hierarchical calendars > being a product of VCARs to CAP - but it must have been > that editors views or understanding. That text should have > never been in CAP. The current text on hierarchical calendars was put there expressly to preclude content roll up (or roll down as some have suggested!). Thats why its there. (Frank can confirm this if hes still lurking.) It may or may not have predated the decision to make CalID opaque and thus non-hierarchical inherently. > > I cannot clearly pinpoint the time when we chose to drop the concept > > of content roll up but I vaguely recall it happening at some meeting > > where lots of vigorous debate and hand waiving occurred. > > It was prior to cap requirements being *accepted*. It may have been > mentioned, but there was never any specific proposal. It was not mentioned (or my full text index of the WG archives back to 1996 is busted big time). > > > ... > > > > > > Yes - roll up was deferred at about the Dallas time. > > > It was deferred because it was too complex at that time > > > to debate without specific proposals (I do not think > > > we have ever had any roll up proposed in any detail). > > > > Ok, Ill buy the Dallas time frame. > > > > In any case, the current design for roll up is strictly for VCARs and > > it is causing some CAP complexities that I think can be resolved by > > simply removing the current hierarchy as Steve has mentioned. > > Benefits of removing seem to outweigh the problems they cause. > > That's my sentiments and I'm sticking to 'em... > > There is NO current design for roll up - none at all that > was dropped years ago. I am not sure I understand your point. Bad phrasing on my part. I was not intending "content" roll up but rather VCAR roll up (in order to generate an effective rights list for a given CU, the CS has to 'roll up' all the VCARs from the given CALID and 'higher' into a composite list to be used for access checking. The point is that hierarhical VCARs is a CS maintenance pain to say the least and makes CAP life (and usage) harder rather than easier. Removing this from CAP simplifies our design and removes the issues that Steve originally posted. > If you meant drop VCAR inheritance - Steve did not propose that, > he proposed that all child calendars go away. (Did I misunderstand > him?) I think that Id go as far as saying that since we have no hierarchical roll up (or down) of content and by removing the concept of hierarchical calendars for VCARs only then we no longer really need to have hierarchical calendars. The term becomes a misnomer and is misleading. I could see some proposal to have 'linkages' between calendars but that text is yet to be written. Ill continue this concept in the other part of this thread. > > I can buy that concept but it does not cover all kinds of > > 'relationships' between all calendars. The use of a > > "League/Division/Team" kind of hierarchy example is logical for that > > kind of organization but it does not work for the "Husband/Wife" or > > "Mother/Father/Brother(s)/Sister(s)/Cousin(s)" model where no calendar > > is the "parent" really. > > I agree. It does not cover all kinds of relationships. I do not > think they were ever designed to cover all kinds of relationships. See thoughts on this in the other part of this thread (going out after this). > > However I still think that removing hierarchy for VCARs is a very > > worthwhile change. > > I agree. But Steve's proposal was to remove the ability to have > child ALL calendars. Steve did NOT propose removing VCAR inheritance > directly. He said by removing hierarchical calendars -[Snip, snip] > And of course, VCAR > inheritance would go away as a side effect as there would be > no child calendars to inherit anything. Its not a side effect if you remove the concept (as currently defined) of Hierarchical Calendars; its a design simplification. (Hierarchy only exists now for VCARs, NOT for any other reason like organizing or cross linking calendars) > I would agree that it is how VCARs are defined. And I would > again propose (and I think maybe we are violently agreeing), > that VCAR inheritance goes away. Id say its Violent Partial Agreement. (I dont think we agree 100% on keeping the concept of hierarchical or 'linked' calendars). Now all we need is John Strack to jump in and we can have more violent partial agreement... ;^) > > Also, your use of hierarchy is contrary to the definition of > > hierarchical calendar (see the original definition I cited) so perhaps > > you should propose some change text to include this design (above and > > beyond "access rights") > > That's what we are debating? > Removing this from 1.3 / Hierarchical Calendars and > tweaking the words: > > Remove: > ... Instead it is a > feature that relates access control rights to calendar content > between different calendars in the CS. Not quite. Id say the proposal on the table is to remove all concept of "hierarchical calendars" entirely. By just removing that line you open the door to someone making some improper assumptions about content roll up (or down). That would be a step backwards, not forwards... > > Sounds like all we need to do is redefine Hierarchical Calendars to > > remove access rights inheritance and to describe linkages a bit better > > then. > > Yes - I agree. Agreement is a great thing. Ill try to touch base w/Doug OOB and see if we can work up some kind of text to redefine his concept of hierarchical calendars (or my 'linked' calendars) and propose it to the WG. This will remove any mental baggage associated w/the term "hierarchical calendar" so we dont rehash this again in another 10-12 months. > > I'm not sure that only adding PARENT/CHILD is the right choice. > > It is already there - nothing to add? The point being that its insufficient for all the kinds of linkages/relationships that two CalIDs can have. My calendar is not a PARENT to or a CHILD of my wifes but they are 'related'. "Hierarchical calendars" w/in a CS may be a cute 1st start but it doesnt allow for your League/Division/Team hiearchy of "separate but related" calendars (which is really what they are despite the tree layout used). > > (How would I link to my peer calendars in my team or to the CAP > > Editors calendars using PARENT/CHILD only?) > > No one has proposed any other linkage (other than CHILD/PARENT) > - do you have a proposal :-) Lets talk and maybe I/we can propose one. > I had proposed years ago (in no detail) that a child calendar coul > be a pseudo link to another calendar in order to propose exactly > what you wanted. Hmm, a full text scan of all postings for "child" and "Doug" (or other permutations) reveal no postings in my archive. Not sure if I never got 'em or if they were in OOB emails. Still, its another good reason for us to talk... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0059115985256B30_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 12/27/2001 06:40:58 PM:
> Wrong - Frank, Steve and I talked Lisa and Tony into hierarchical
> calendars in Dallas prior to that they were fighting them.
The history lesson debate is becoming a distraction from our apparent partial agreement.  Ill just leave it with this final bit.  I wasnt in Dallas so I cannot talk about who said what there but my full text indexed archive of this WG and my mail file bear out that Lisa was a proponent of hierarhical calendars for ACL reasons (for previously mentioned underlying shared folder implementation reasons).  Those really interested can search the available archives for any future reading.

> I don't know who added the definition of hierarchical calendars
> being a product of VCARs to CAP - but it must have been
> that editors views or understanding. That text should have
> never been in CAP.
The current text on hierarchical calendars was put there expressly to preclude content roll up (or roll down as some have suggested!).  Thats why its there.  (Frank can confirm this if hes still lurking.) It may or may not have predated the decision to make CalID opaque and thus non-hierarchical inherently.

> > I cannot clearly pinpoint the time when we chose to drop the concept
> > of content roll up but I vaguely recall it happening at some meeting
> > where lots of vigorous debate and hand waiving occurred.
>
> It was prior to cap requirements being *accepted*. It may have been
> mentioned, but there was never any specific proposal.
It was not mentioned (or my full text index of the WG archives back to 1996 is busted big time).

> > > ...
> > >
> > > Yes - roll up was deferred at about the Dallas time.
> > > It was deferred because it was too complex at that time
> > > to debate without specific proposals (I do not think
> > > we have ever had any roll up proposed in any detail).
> >
> > Ok, Ill buy the Dallas time frame.
> >
> > In any case, the current design for roll up is strictly for VCARs and
> > it is causing some CAP complexities that I think can be resolved by
> > simply removing the current hierarchy as Steve has mentioned.
> >  Benefits of removing seem to outweigh the problems they cause.
> >  That's my sentiments and I'm sticking to 'em...
>
> There is NO current design for roll up - none at all that
> was dropped years ago. I am not sure I understand your point.
Bad phrasing on my part.  I was not intending "content" roll up but rather VCAR roll up (in order to generate an effective rights list for a given CU, the CS has to 'roll up' all the VCARs from the given CALID and 'higher' into a composite list to be used for access checking.  

The point is that hierarhical VCARs is a CS maintenance pain to say the least and makes CAP life (and usage) harder rather than easier.  Removing this from CAP simplifies our design and removes the issues that Steve originally posted.

> If you meant drop VCAR inheritance - Steve did not propose that,
> he proposed that all child calendars go away. (Did I misunderstand
> him?)
I think that Id go as far as saying that since we have no hierarchical roll up (or down) of content and by removing the concept of hierarchical calendars for VCARs only then we no longer really need to have hierarchical calendars.  The term becomes a misnomer and is misleading.  

I could see some proposal to have 'linkages' between calendars but that text is yet to be written.  Ill continue this concept in the other part of this thread.

> > I can buy that concept but it does not cover all kinds of
> > 'relationships' between all calendars.  The use of a
> > "League/Division/Team" kind of hierarchy example is logical for that
> > kind of organization but it does not work for the "Husband/Wife" or
> > "Mother/Father/Brother(s)/Sister(s)/Cousin(s)" model where no calendar
> > is the "parent" really.
>
> I agree. It does not cover all kinds of relationships. I do not
> think they were ever designed to cover all kinds of relationships.
See thoughts on this in the other part of this thread (going out after this).  

> > However I still think that removing hierarchy for VCARs is a very
> > worthwhile change.
>
> I agree. But Steve's proposal was to remove the ability to have
> child ALL calendars. Steve did NOT propose removing VCAR inheritance
> directly. He said by removing hierarchical calendars -[Snip, snip]
>                                                And of course, VCAR
> inheritance would go away as a side effect as there would be
> no child calendars to inherit anything.
Its not a side effect if you remove the concept (as currently defined) of Hierarchical Calendars; its a design simplification.  (Hierarchy only exists now for VCARs, NOT for any other reason like organizing or cross linking calendars)

> I would agree that it is how VCARs are defined. And I would
> again propose (and I think maybe we are violently agreeing),
> that VCAR inheritance goes away.
Id say its Violent Partial Agreement.  (I dont think we agree 100% on keeping the concept of hierarchical or 'linked' calendars).  Now all we need is John Strack to jump in and we can have more violent partial agreement... ;^)

> > Also, your use of hierarchy is contrary to the definition of
> > hierarchical calendar (see the original definition I cited) so perhaps
> > you should propose some change text to include this design (above and
> > beyond "access rights")
>
> That's what we are debating?
> Removing this from 1.3 / Hierarchical Calendars and
> tweaking the words:
>
> Remove:
>      ... Instead it is a
>       feature that relates access control rights to calendar content
>       between different calendars in the CS.

Not quite.  Id say the proposal on the table is to remove all concept of "hierarchical calendars" entirely.  By just removing that line you open the door to someone making some improper assumptions about content roll up (or down).  That would be a step backwards, not forwards...

> > Sounds like all we need to do is redefine Hierarchical Calendars to
> > remove access rights inheritance and to describe linkages a bit better
> > then.
>
> Yes - I agree.
Agreement is a great thing.  Ill try to touch base w/Doug OOB and see if we can work up some kind of text to redefine his concept of hierarchical calendars (or my 'linked' calendars) and propose it to the WG.  This will remove any mental baggage associated w/the term "hierarchical calendar" so we dont rehash this again in another 10-12 months.

> > I'm not sure that only adding PARENT/CHILD is the right choice.
>
> It is already there - nothing to add?
The point being that its insufficient for all the kinds of linkages/relationships that two CalIDs can have. My calendar is not a PARENT to or a CHILD of my wifes but they are 'related'.  "Hierarchical calendars" w/in a CS may be a cute 1st start but it doesnt allow for your League/Division/Team hiearchy of "separate but related" calendars (which is really what they are despite the tree layout used).

> > (How would I link to my peer calendars in my team or to the CAP
> > Editors calendars using PARENT/CHILD only?)
>
> No one has proposed any other linkage (other than CHILD/PARENT)
>  - do you have a proposal :-)
Lets talk and maybe I/we can propose one.

> I had proposed years ago (in no detail) that a child calendar coul
> be a pseudo link to another calendar in order to propose exactly
> what you wanted.

Hmm, a full text scan of all postings for "child" and "Doug" (or other permutations) reveal no postings in my archive.  Not sure if I never got 'em or if they were in OOB emails.  Still, its another good reason for us to talk...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0059115985256B30_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 28 14:44:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11174 for ; Fri, 28 Dec 2001 14:44:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBSJWfQ02868 for ietf-calendar-bks; Fri, 28 Dec 2001 11:32: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 fBSJWd202864 for ; Fri, 28 Dec 2001 11:32:39 -0800 (PST) To: sman@netscape.com (Steve Mansour) Cc: ietf-calendar@imc.org Subject: Re: Proposed removal of hierarchy from CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_12112001 December 11, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Fri, 28 Dec 2001 12:03:01 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_12172001|December 17, 2001) at 12/28/2001 02:28:02 PM, Serialize complete at 12/28/2001 02:28:02 PM Content-Type: multipart/alternative; boundary="=_alternative 005D758B85256B30_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005D758B85256B30_= Content-Type: text/plain; charset="US-ASCII" Steve replied on 12/27/2001 06:01:12 PM: > Nonetheless, I > think it is a wise move to not have the calid reflect the hierarchy or > anything else. It is simply an identifier which should not be overloaded. I agree that it was better NOT to overload CalID and that linkages like we are really talking about should be done via more appro means rather than restricting the CalID. > Bruce, do you have any issues with keeping hierarchy with the proviso > that we make it clear that access control and hierarchy are disjoint and > unrelated? I have no qualms about removing hierarhical calendars as defined (for VCAR use only really). I just dont want it them to be redefined in such a way that someone could incorrectly assume or infer that hierarchy means that some kind of content roll up (or down) is possible. That would be a step backwards instead of forwards. > How does this affect decreed vcars? Not sure. I dont see how they could be applied to the CS at large but given a CalID with NO RelCalID portion, couldnt that be used to maniuplate/query the VCARs at the CS level? Attempting to take any action that violates either the decreed VCARs or the expressed ones should result in an error as the text of 2.4.2.2 says. The only thing I didnt see was a distinction between "CS level" errors from decreed VCARs and "calendar level" errors from expressed VCARs. The design does get simpler since the CS only has to worry about 2 'sets' of VCARs to apply instead of evaluating a hierarchy (and a set at the CS level) of VCARs... Bruce PS: Content roll down is simply the concept that "My companys calendar (ie: Holidays) content could be inherited by my calendar" (being a 'child' of it as in Dougs League/Division/Team hiearchy). Its also not restricted to 1 level (ie: Company -> Site -> Organization -> Me ). Im NOT proposing we add this to CAP, Im just pointing out that roll up is not the only usable direction in town... =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005D758B85256B30_= Content-Type: text/html; charset="US-ASCII"
Steve replied on 12/27/2001 06:01:12 PM:
>                                                          Nonetheless, I
> think it is a wise move to not have the calid reflect the hierarchy or
> anything else. It is simply an identifier which should not be overloaded.
I agree that it was better NOT to overload CalID and that linkages like we are really talking about should be done via more appro means rather than restricting the CalID.

>         Bruce, do you have any issues with keeping hierarchy with the proviso
> that we make it clear that access control and hierarchy are disjoint and
> unrelated?
I have no qualms about removing hierarhical calendars as defined (for VCAR use only really).  I just dont want it them to be redefined in such a way that someone could incorrectly assume or infer that hierarchy means that some kind of content roll up (or down) is possible.  That would be a step backwards instead of forwards.

> How does this affect decreed vcars?
Not sure.  I dont see how they could be applied to the CS at large but given a CalID with NO RelCalID portion, couldnt that be used to maniuplate/query the VCARs at the CS level?  Attempting to take any action that violates either the decreed VCARs or the expressed ones should result in an error as the text of 2.4.2.2 says.  The only thing I didnt see was a distinction between "CS level" errors from decreed VCARs and "calendar level" errors from expressed VCARs.

The design does get simpler since the CS only has to worry about 2 'sets' of VCARs to apply instead of evaluating a hierarchy (and a set at the CS level) of VCARs...

Bruce
PS: Content roll down is simply the concept that "My companys calendar (ie: Holidays)  content could be inherited by my calendar" (being a 'child' of it as in Dougs League/Division/Team hiearchy).  Its also not restricted to 1 level (ie: Company -> Site -> Organization -> Me ).  Im NOT proposing we add this to CAP, Im just pointing out that roll up is not the only usable direction in town...
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 005D758B85256B30_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 28 16:21:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11968 for ; Fri, 28 Dec 2001 16:21:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBSL9gh06161 for ietf-calendar-bks; Fri, 28 Dec 2001 13:09: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 fBSL9e206154 for ; Fri, 28 Dec 2001 13:09: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 NAA12674 for ; Fri, 28 Dec 2001 13:09:11 -0800 (PST) Message-ID: <3C2CDE81.60154A13@Royer.com> Date: Fri, 28 Dec 2001 14:05:05 -0700 From: Doug Royer Reply-To: CalSched@royer.com, IETF@royer.com Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Proposed removal of hierarchy from CAP References: Content-Type: multipart/mixed; boundary="------------F64D3E0F08C1E64C29B0B919" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F64D3E0F08C1E64C29B0B919 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > > I don't know who added the definition of hierarchical calendars > > being a product of VCARs to CAP - but it must have been > > that editors views or understanding. That text should have > > never been in CAP. > > The current text on hierarchical calendars was put there expressly to > preclude content roll up (or roll down as some have suggested!). > Thats why its there. (Frank can confirm this if hes still lurking.) > It may or may not have predated the decision to make CalID opaque and > thus non-hierarchical inherently. Okay - it failed :-) An implementation can still do that and be compliant. I don't recall the WG saying no to content roll up. Just no to doing in in CAP 1.0. > > There is NO current design for roll up - none at all that > > was dropped years ago. I am not sure I understand your point. > > Bad phrasing on my part. I was not intending "content" roll up but > rather VCAR roll up (in order to generate an effective rights list for > a given CU, the CS has to 'roll up' all the VCARs from the given CALID > and 'higher' into a composite list to be used for access checking. > > The point is that hierarhical VCARs is a CS maintenance pain to say > the least and makes CAP life (and usage) harder rather than easier. > Removing this from CAP simplifies our design and removes the issues > that Steve originally posted. :-) !!! > > I agree. But Steve's proposal was to remove the ability to have > > child ALL calendars. Steve did NOT propose removing VCAR inheritance > > directly. He said by removing hierarchical calendars -[Snip, snip] > > And of course, VCAR > > inheritance would go away as a side effect as there would be > > no child calendars to inherit anything. > > Its not a side effect if you remove the concept (as currently defined) > of Hierarchical Calendars; its a design simplification. Same difference? > > Not quite. Id say the proposal on the table is to remove all concept > of "hierarchical calendars" entirely. By just removing that line you > open the door to someone making some improper assumptions about > content roll up (or down). That would be a step backwards, not > forwards... Okay now I am confused. Do you want: Inherited vcars? I say NO. Child calendars? I say YES. And if an implementation wanted to do content roll up, how would that break you? I could do content roll up now and you would never know - would you? You just do a VQUERY on a calendar, and no point in time do you ask; "Is some of this really from a child calendar that I don't have access to?" - Nope.. > The point being that its insufficient for all the kinds of > linkages/relationships that two CalIDs can have. My calendar is not a > PARENT to or a CHILD of my wifes but they are 'related'. > "Hierarchical calendars" w/in a CS may be a cute 1st start but it > doesnt allow for your League/Division/Team hiearchy of "separate but > related" calendars (which is really what they are despite the tree > layout used). Yes - does this need to be part of CAP now? Or can we start with child / parent in CAP 1.0 and work from there? Then do a more complete relationship draft later by advertising a new capability? > > > (How would I link to my peer calendars in my team or to the CAP > > > Editors calendars using PARENT/CHILD only?) > > > > No one has proposed any other linkage (other than CHILD/PARENT) > > - do you have a proposal :-) > > Lets talk and maybe I/we can propose one. > > > I had proposed years ago (in no detail) that a child calendar coul > > be a pseudo link to another calendar in order to propose exactly > > what you wanted. > > Hmm, a full text scan of all postings for "child" and "Doug" (or other > permutations) reveal no postings in my archive. Not sure if I never > got 'em or if they were in OOB emails. Still, its another good reason > for us to talk... My idea (part of fanout and roll up at the time) was that CS's could talk to each other in a transparent way by brokering the authentication for the CUA. (NOT storing the credentials) In that way it did not matter where or which CS contained the TARGET calendar. It only required the CUA to set up a link at some previous time. Such that when I ask to see Doug/Football the football calendar could in fact be the NFL schedule, which may have child calendars. As part of this was roll-up I could transparently drop components in using a copy-on-write mode so that I would cache interested components and set alarms, notes and such on them without them being written to the ultimate source (CS) of the appointment. Then it further could optionally show up on the parent calendar as busy time (busy time roll up) or the appointment could show up (roll up). This feature required both fanout and roll up. It also had the concept of 'trusted hosts' where if the CS's trusted each other (as determined by the system administrators), the CS could say in effect "trust me, this is doug@royer.com and here is his CAP command". This trust model was for scaleability. Trusted hosts were mostly for mega-sites so they could have multiple CS working in tandem. (much like the oscar. sites). It was not shot down as much as several editors said "I never heard of that, so it's off topic" - I am sensitive to any calsch idea having the right to be posted here. Don't forget that a few years ago the area directors wanted to close down calsch. There was a lot of out of band email at that time (one of the reasons that they wanted to close it down). The the drafts changed without any debate on the list. Lets not make that same mistake. The roll up debate may have been part of the Kiss-Cap mailing list (now gone). One of the problems with the current WG process is that it seems to be designed to update existing protocols and for fairly simple (pages of paper) protocols. It is very difficult to propose an entirely new protocol ideas on the WG lists without it being declared off topic (or distracting the WG). And if you do it out of band - more of a interested parties list - the ietf screams about doing things off of the list. So to the WG and the IETF (and I am sure Bruce agrees), any result that we would like to propose would be sent to this list as any other co-though-up idea. -Doug --------------F64D3E0F08C1E64C29B0B919 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 28 Dec 2001 16:53:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fBSLeI406994 for ietf-calendar-bks; Fri, 28 Dec 2001 13:40: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 fBSLeG206989 for ; Fri, 28 Dec 2001 13:40: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 NAA12694 for ; Fri, 28 Dec 2001 13:39:47 -0800 (PST) Message-ID: <3C2CE5AD.23CF912E@Royer.com> Date: Fri, 28 Dec 2001 14:35: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-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Proposed removal of hierarchy from CAP References: Content-Type: multipart/mixed; boundary="------------95C8C9B558A7BF6035AA9239" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------95C8C9B558A7BF6035AA9239 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > > Bruce, do you have any issues with keeping hierarchy with > the proviso > > that we make it clear that access control and hierarchy are disjoint > and > > unrelated? > > I have no qualms about removing hierarhical calendars as defined (for > VCAR use only really). I just dont want it them to be redefined in > such a way that someone could incorrectly assume or infer that > hierarchy means that some kind of content roll up (or down) is > possible. That would be a step backwards instead of forwards. How about just saying that content roll up is not defined in CAP 1.0. > > How does this affect decreed vcars? > > Not sure. I dont see how they could be applied to the CS at large but > given a CalID with NO RelCalID portion, couldnt that be used to > maniuplate/query the VCARs at the CS level? Attempting to take any > action that violates either the decreed VCARs or the expressed ones > should result in an error as the text of 2.4.2.2 says. The only thing > I didnt see was a distinction between "CS level" errors from decreed > VCARs and "calendar level" errors from expressed VCARs. It could be a pain. If I send you a huge VCAR, and only one small part of it can not be done because of an implementation or site policy - how could I say that? I do not think we have to: Time-1 (By CUA-1): BEGIN:VCAR GRANT: END:VQUERY Time-2 (By CUA-2): BEGIN:VCAR GRANT: DENY: END:VQUERY Time-3 (CUA-1): The CUA-1 performs an operation and it fails because if the VCAR set by CUA-2 or by a decreed VCAR? Given: CAP does not guarantee that VCARs will not change over time. CAP has no record keeping of who or when they changed. Will at CUA-1 at time-3 know if it is a result if CUA-2, or by administrative configuration done outside of CAP (A decreed VCAR). No - And it can not care. The only thing a CUA can do is get ALL of the VCARs for the TARGET and look. With the limitation that the authenticated UPN might not be able to get all of them, or get any of them. And that leaves VCARs as I think they were intended to be used - to control access from the CS's point of view, not to describe access to any random CUA or to any random UPN. So, an operation fails if you can't do 'that'. So now, what if a CUA sends a new set of VCARs to the CUA and only one small part of that fails - what happens? (a) Does the entire operation fail? (b) Or a partial success return code? (c) Or a success return code that ignores the partial failures? I say (b). The CUA can then perform a VQUERY to find out what was not done as it can not override decreed VCARs. Now, what if the CUA sends a non-VCAR component be stored on the CS. What happens: (a) Does the entire operation fail? (b) Or a partial success return code? (c) Or a success return code that ignores the partial failures? If (a) how does the CUA know what went wrong in order for the CUA, CU, OWNER, or administrator to fix it (assuming something is buggy or busted)? If (b), there needs to be a way to say what the problem was else it looks like (c) and behaves like (a as the entire opertationn was not done. If (c), things that are important to the CU could be lost. I think this is unacceptable. Do we need some kind of structured 'what when wrong' error messages containing CUA parable content? > Bruce > PS: Content roll down is simply the concept that "My companys calendar > (ie: Holidays) content could be inherited by my calendar" (being a > 'child' of it as in Dougs League/Division/Team hiearchy). Its also > not restricted to 1 level (ie: Company -> Site -> Organization -> Me > ). Im NOT proposing we add this to CAP, Im just pointing out that > roll up is not the only usable direction in town... I could make the company calendar a child calenar link (as I proposed) and then have roll-up only :-) -Doug --------------95C8C9B558A7BF6035AA9239 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;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC