From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:43:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04120 for ; Thu, 3 Jan 2002 10:43:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g03FMxB13767 for ietf-calendar-bks; Thu, 3 Jan 2002 07:22: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 g03FMv313758 for ; Thu, 3 Jan 2002 07:22:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26825; Thu, 3 Jan 2002 10:22:52 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FMpH25007; Thu, 3 Jan 2002 10:22:51 -0500 (EST) Message-ID: <3C347771.3628E9FD@steltor.com> Date: Thu, 03 Jan 2002 11:23:29 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: Bernard Desruisseaux CC: "ietf-calendar@imc.org" Subject: Re: VCAR: CARREF rule part References: <3C237863.9E371655@steltor.com> <3C2394F0.5F76C8FE@Royer.com> <3C274080.70FA966D@steltor.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 If no one objects, I'll remove it from the draft. George Bernard Desruisseaux wrote: > > 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 Thu Jan 3 10:44:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04144 for ; Thu, 3 Jan 2002 10:44:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FN1213777 for ietf-calendar-bks; Thu, 3 Jan 2002 07:23:01 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FN0313771 for ; Thu, 3 Jan 2002 07:23:00 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26835; Thu, 3 Jan 2002 10:22:54 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FMsH25030; Thu, 3 Jan 2002 10:22:54 -0500 (EST) Message-ID: <3C347779.F0A0CBF1@steltor.com> Date: Thu, 03 Jan 2002 11:23:37 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CMDID required in reply if supplied in command References: <3BF4477B.4AF91EE1@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 This no longer applies since the format of the response has been changed with BEEP. George Doug Royer wrote: > > In 7.2.1.2: > > ... > > The response contains the calendar (CALID) and UID of the component > so that the CUA can match up the TARGET from multiple objects created > on multiple calendars (TARGETs). > > Should say: > > The response contains the calendar (CALID) and UID of the component > so that the CUA can match up the TARGET from multiple objects created > * on multiple calendars (TARGETs). Additionally if the original command > * had a CMDID, then that CMDID MUST BE supplied in the reply. From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:44:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04155 for ; Thu, 3 Jan 2002 10:44:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FN4E13794 for ietf-calendar-bks; Thu, 3 Jan 2002 07:23:04 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FN3313787 for ; Thu, 3 Jan 2002 07:23:03 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26848; Thu, 3 Jan 2002 10:22:58 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FMvH25057; Thu, 3 Jan 2002 10:22:57 -0500 (EST) Message-ID: <3C347785.65367B61@steltor.com> Date: Thu, 03 Jan 2002 11:23:49 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: typo 2.4.4.2 References: <3BF931BE.36E82DF5@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 Fixed. George Doug Royer wrote: > > Is: > > BEGIN:VCAR > CARID:Users Default Access > GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* > DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; > VALUE="Users Default Access" > ;OBJECT=METHOD,VALUE=DELETE,MODIFY > END:VCAR > > Should be (see * for error - two OBJECT= values in a row): > > BEGIN:VCAR > CARID:Users Default Access > * GRANT:UPN=OWNER;OBJECT=*;OBJECT=METHOD;VALUE=* > DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; > VALUE="Users Default Access" > ;OBJECT=METHOD,VALUE=DELETE,MODIFY > END:VCAR From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:44:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04167 for ; Thu, 3 Jan 2002 10:44:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FN2D13782 for ietf-calendar-bks; Thu, 3 Jan 2002 07:23:02 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FN1313776 for ; Thu, 3 Jan 2002 07:23:01 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26840; Thu, 3 Jan 2002 10:22:56 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FMtH25039; Thu, 3 Jan 2002 10:22:55 -0500 (EST) Message-ID: <3C34777E.C9E7AD38@steltor.com> Date: Thu, 03 Jan 2002 11:23:42 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Typo - wrap. References: <3BF462C3.7F33197C@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 This has been fixed in the latest version of CAP. George Doug Royer wrote: > > The following text is badly formatted in the CAP draft and > it looks as if text is missing from the first paragraph: > > 7.2.3.1 Sending and Receiving an iTIP request > > In this example A invites B and C to a meeting, B accepts the meeting > and BEGIN:VEVENT > UID:abcd12345 > DTSTART:19990307T180000Z > DTEND:19990307T190000Z > ORGANIZER:cap://cal.foo.com/relcal1 > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- > ACTION:cap://cal.foo.com/relcal2 > ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- > ACTION:cap://cal.foo.com/relcal3 > SUMMARY:Important Meeting > END:VEVENT > END:VCOMMAND > END:VCALENDAR From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:44:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04178 for ; Thu, 3 Jan 2002 10:44:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FP3P13838 for ietf-calendar-bks; Thu, 3 Jan 2002 07:25: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 g03FP2313832 for ; Thu, 3 Jan 2002 07:25: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 KAA26901; Thu, 3 Jan 2002 10:24:57 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FOuH25166; Thu, 3 Jan 2002 10:24:56 -0500 (EST) Message-ID: <3C34780A.C3AD5442@steltor.com> Date: Thu, 03 Jan 2002 11:26:02 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Uniqueness of RELCALID References: <3BF467CF.B6F4C15A@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 Done. George Doug Royer wrote: > > Where it says: > > RELCALID N URI A unique identifier for the calendar. > There is no default value and > This value MUST NOT be empty. > > Perhaps: > > A unique identifier within this > cal-store for the calendar. > ... From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:45:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04189 for ; Thu, 3 Jan 2002 10:45:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FN4K13789 for ietf-calendar-bks; Thu, 3 Jan 2002 07:23:04 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FN2313781 for ; Thu, 3 Jan 2002 07:23: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 KAA26844; Thu, 3 Jan 2002 10:22:57 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FMuH25048; Thu, 3 Jan 2002 10:22:56 -0500 (EST) Message-ID: <3C347782.E5284956@steltor.com> Date: Thu, 03 Jan 2002 11:23:46 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CHILDREN calendar attribute and comma. References: <3BF4667E.ADD8653B@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 Done. George Doug Royer wrote: > > This implies that a CALID MUST NOT contain a comma. > If so we need to say that in the description of CALID. > > I think this should be a multi-instance (and not multi-valued) entry. > That is a calendar may have 0+ CHILDREN entries. > > Is: > CHILDREN Y TEXT The list of sub-calendars > Belonging to this calendar. An > empty list means no children. > The results may be a comma > separated list of children. > Each entry returned is a CALID. > The default is an empty list. > > Should be ? : > > This list of sub-calendars belonging to this calendar. > There may be multiple sub-calendars, each returning > a CHILDREN property. Each instance of of CHILDREN would > return a single CALID. From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:45:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04202 for ; Thu, 3 Jan 2002 10:45:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FQD113880 for ietf-calendar-bks; Thu, 3 Jan 2002 07:26: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 g03FQB313876 for ; Thu, 3 Jan 2002 07:26: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 KAA26920; Thu, 3 Jan 2002 10:25:45 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FPZH25216; Thu, 3 Jan 2002 10:25:35 -0500 (EST) Message-ID: <3C347832.D17AAD41@steltor.com> Date: Thu, 03 Jan 2002 11:26:42 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: John Stracke CC: "ietf-calendar@imc.org" Subject: Re: Specify LANG values. 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 Done. George John Stracke wrote: > > >We need to add something like: > > > > The value of this property is those specified in > > {RFCxxxx ISOxxxx ???) > > RFC-3066. > > /=======================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc.| > |http://www.incentivesystems.com|My opinions are my own.| > |=======================================================| > |Belief is not relevant to truth. | > \=======================================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:45:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04217 for ; Thu, 3 Jan 2002 10:45:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FN5A13798 for ietf-calendar-bks; Thu, 3 Jan 2002 07:23: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 g03FN4313793 for ; Thu, 3 Jan 2002 07:23: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 KAA26852; Thu, 3 Jan 2002 10:22:59 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FMwH25066; Thu, 3 Jan 2002 10:22:58 -0500 (EST) Message-ID: <3C347789.A1AB865F@steltor.com> Date: Thu, 03 Jan 2002 11:23:53 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: PRODID capability References: <3BF9616A.2CA04B46@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Added to the capability command. George Doug Royer wrote: > > I thought that PRODID was going to be returned in CAPABILITY? > It is in the examples, but not in the 7.1.4 section. > > Please add to 7.1.4: > > PRODID 0 or 1 The PRODID of the CS. From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:45:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04230 for ; Thu, 3 Jan 2002 10:45:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FN0o13772 for ietf-calendar-bks; Thu, 3 Jan 2002 07:23:00 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FMx313766 for ; Thu, 3 Jan 2002 07:22:59 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26831; Thu, 3 Jan 2002 10:22:53 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FMrH25019; Thu, 3 Jan 2002 10:22:53 -0500 (EST) Message-ID: <3C347775.C7CE64F0@steltor.com> Date: Thu, 03 Jan 2002 11:23:33 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR - ordering References: <3BF4352C.7D9E713F@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 Done. George Doug Royer wrote: > > > 2.4.4.1 VCalendar Access Right (VCAR) > > > > Access rights within CAP are specified with the "VCAR" calendar > > component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" > > component properties. > > > > Properties within an iCalendar object are unordered. This also is > > the case for the "GRANT", "DENY" and "CARID" properties. Likewise, > > there is no implied ordering required for components of a "RIGHTS" > > value type other than that specified by the ABNF. [EDITOR'S NOTE, > > this requires a lot of review. We think that this paragraph may be > . incorrect. ] > > I think we can remove the editors note. For a component > the ordering is not important - other than what is said > above ... in 2.4.4 > > > The access for a particular UPN is the union of all grants for that > > UPN minus the union of its denies. > > -Doug From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:45:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04242 for ; Thu, 3 Jan 2002 10:45:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FP1S13828 for ietf-calendar-bks; Thu, 3 Jan 2002 07:25:01 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FP0313823 for ; Thu, 3 Jan 2002 07:25:00 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26893; Thu, 3 Jan 2002 10:24:55 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FOsH25153; Thu, 3 Jan 2002 10:24:54 -0500 (EST) Message-ID: <3C347801.87C6D87A@steltor.com> Date: Thu, 03 Jan 2002 11:25:53 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP TODO: Digest References: <3BEC3104.AF69F206@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 Yes the issue went away with BEEP. George Doug Royer wrote: > > > - 2.4.2.3 Required Security Mechanisms > > The following implementation conformance requirements are in place: > > > > [deletia...] > > > > (2) Implementations providing password-based authenticated > > access MUST support authentication using Digest, as described > > in section > > > > What section discusses authentication using Digest? I did a > > quick search on "Digest" and didn't see anything that looked > > like what was being referred to. Can you confirm > > whether or not the section it's referring to is either in or > > not in the latest draft? > > Is this issue going away - BXXP? If not, we need our security > expert (Paul?) to add this text. > > -Doug From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:45:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04258 for ; Thu, 3 Jan 2002 10:45:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FPdo13857 for ietf-calendar-bks; Thu, 3 Jan 2002 07:25:39 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FPb313853 for ; Thu, 3 Jan 2002 07:25:38 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26912; Thu, 3 Jan 2002 10:25:33 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FPWH25199; Thu, 3 Jan 2002 10:25:32 -0500 (EST) Message-ID: <3C34782A.119FE4D4@steltor.com> Date: Thu, 03 Jan 2002 11:26:34 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: MODIFY restriction table... References: <3BF30434.78007D47@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 Done. George Doug Royer wrote: > > (I included some cut-paste text from CAP) I think they MUST BE > changed per my comments. > > This would be removed. > > . . . METHOD 1 < to meta-info>> > > These would be '0 or 1' or '0+', if they are not being changed > with the MODIFY method - they MUST NOT be included (EXCEPT > UID which CAN NOT BE CHANGED and ALARMID - which CAN NOT BE CHANGED). > > . . . OWNER 1+ > . . . RELCALID 1 > . . . QUERYNAME 1 > . . . QUERY 1 > . . . SUMMARY 1 Can be null > . . . DTSTAMP 1 > . . . DTSTART 1 > > > . . . ORGANIZER 1 > . . . . ACTION 1 > > . . . . TRIGGER 1 > . . . METHOD 1 < to meta-info>> > . . . ORGANIZER 1 > . . . PRIORITY 1 > . . . . . TZOFFSET 1 > . . . . . TZOFFSETFROM 1 > . . . . . TZOFFSETTO 1 > . . . TZID 1 > > These MUST BE '1' and CAN NOT BE CHANGED by the MODIFY command. > > . . . UID 1 > > If ANY VALARM is being modified - MUST BE '1' and CAN NOT BE > CHANGED by the MODIFY command. > > . . . . ALARMID 0 or 1 MUST be 1 if multiple > VALARMs are present in same > component. From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:46:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04271 for ; Thu, 3 Jan 2002 10:46:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FP4413842 for ietf-calendar-bks; Thu, 3 Jan 2002 07:25:04 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FP3313837 for ; Thu, 3 Jan 2002 07:25:03 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26905; Thu, 3 Jan 2002 10:24:58 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FOvH25176; Thu, 3 Jan 2002 10:24:57 -0500 (EST) Message-ID: <3C34780D.9E3E1EB2@steltor.com> Date: Thu, 03 Jan 2002 11:26:05 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Delete old information. References: <3BF4645B.3ED5C9A2@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 Deleted. George Doug Royer wrote: > > The following can be delete? > > 9. Implementation Issues > > 1. What are the minimum component properties set required to create > a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and > UID. > > [EDITORS NOTE (dr): They MUST be the same as for iTIP] > > 2. What is the state of all undefined properties? PROPOSAL: Not > defined. So a query will not return them, if they are selected. > > [EDITORS NOTE (dr): Many have default values, a CS may return the > default values?] From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:47:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04323 for ; Thu, 3 Jan 2002 10:47:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FP2Z13833 for ietf-calendar-bks; Thu, 3 Jan 2002 07:25:02 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03FP1313827 for ; Thu, 3 Jan 2002 07:25:01 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26897; Thu, 3 Jan 2002 10:24:56 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FOtH25158; Thu, 3 Jan 2002 10:24:55 -0500 (EST) Message-ID: <3C347807.51D75D4D@steltor.com> Date: Thu, 03 Jan 2002 11:25:59 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Wildcard for componet name. References: <3BF43CCE.AA0655D2@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'll add it to the draft if there are no objections. George Doug Royer wrote: > > To allow for future components and remove an existing limitation. > > > 5.1.4 Example, Query by UID > > > This example would select the entire contents of the component with > > the UID property equal to "uid123" and not expand any multiple > > instances of the component. If the CUA does not know if "uid123" was > > a VEVENT, VTODO, VJOURNAL, or other component, then all components > > that the CUA supports MUST be supplied on the QUERY property. This > > example assumes the CUA only supports VTODO and VEVENT. > > I propose an addition that would allow CUAs the ability to > fetch components that it does not support, but the CU may wish > to view: > > Additionally a wild card ("*") value MAY BE be be supplied as > the component name that will cause the CS to search all components > even if the CUA does not understand all of the component types. > > I think this is simply removing a limitation, not adding any more > complexity. From owner-ietf-calendar@mail.imc.org Thu Jan 3 10:51:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04483 for ; Thu, 3 Jan 2002 10:51:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03FPe013866 for ietf-calendar-bks; Thu, 3 Jan 2002 07:25: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 g03FPd313858 for ; Thu, 3 Jan 2002 07:25:39 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA26916; Thu, 3 Jan 2002 10:25:34 -0500 Received: from steltor.com ([101.1.251.20]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03FPXH25206; Thu, 3 Jan 2002 10:25:33 -0500 (EST) Message-ID: <3C34782F.9BB1B683@steltor.com> Date: Thu, 03 Jan 2002 11:26:39 -0400 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: iTIP restriction tables in CAP References: <3BF4565D.783FA1CF@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I updated the draft to point out that the restriction tables in iTIP should be used, and that the METHOD must also be supplied. George Doug Royer wrote: > > 7.2.2 Scheduling Commands > > > [EDITORS NOTE: This section needs to be completed by adding the > > restriction tables for each of these iTIP methods. The basis for the > > text is to be taken from [iTIP].] > > I would disagree. We should point to the iTIP restrictions > tables and add only exceptions. The only exception that I > can think of is: > > In CAP all components MUST BE stored with their METHOD > property. The CAP restriction rules for iTIP METHODS > are the iTIP restriction tables. Plus each restriction > table would also include: > > METHOD '1' The METHOD MUST BE included > in the object. From owner-ietf-calendar@mail.imc.org Thu Jan 3 16:54:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12179 for ; Thu, 3 Jan 2002 16:54:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03LQod22750 for ietf-calendar-bks; Thu, 3 Jan 2002 13:26:50 -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 g03LQm322745 for ; Thu, 3 Jan 2002 13:26:48 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA01009; Thu, 3 Jan 2002 16:26:45 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g03LQiH20872; Thu, 3 Jan 2002 16:26:44 -0500 (EST) Message-ID: <3C34CC94.C8A56657@steltor.com> Date: Thu, 03 Jan 2002 16:26:44 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New Version Of CAP 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 CAP has been updated with many corrections as mentioned on the list. Furthermore, an "Extensions to iCalendar" section has been added. This new section defines all new properties, components, parameters, and value types that have been added to CAP. It contains the contents of the "iCal-updates" document (http://www.calsch.org/ietf/iCal-updates.html). The "iCal-updates" document is now obsolete. You can get the latest version of CAP at: http://www.calsch.org/ietf/drafts.html George From subs-reminder@imc.org Mon Jan 7 18:32:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00961 for ; Mon, 7 Jan 2002 18:32:36 -0500 (EST) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g07NWY211497; Mon, 7 Jan 2002 15:32:34 -0800 (PST) Date: Mon, 7 Jan 2002 15:32:34 -0800 (PST) Message-Id: <200201072332.g07NWY211497@above.proper.com> To: calsch-archive@ietf.org Subject: [[018428330]] Subscription to ietf-calendar for calsch-archive@lists.ietf.org Greetings. This message is a periodic reminder that calsch-archive@lists.ietf.org is subscribed to the ietf-calendar mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-calendar mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "calsch-archive@lists.ietf.org". If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-calendar@mail.imc.org Tue Jan 8 09:55:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24231 for ; Tue, 8 Jan 2002 09:55:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08Ecxq03973 for ietf-calendar-bks; Tue, 8 Jan 2002 06:38:59 -0800 (PST) Received: from ferrari.teamsoft ([209.47.3.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08Ecw303968 for ; Tue, 8 Jan 2002 06:38:58 -0800 (PST) Received: from [209.47.3.48] (209.47.3.48 [209.47.3.48]) by ferrari.teamsoft with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YH2XD7LB; Tue, 8 Jan 2002 09:47:04 -0500 X-Sender: Gilles Fortin@teamsoft.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Jan 2002 09:44:37 -0500 To: ietf-calendar@imc.org From: fortin@teamsoft.com (Gilles Fortin) Subject: Re: Proposed removal of hierarchy from CAP Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I do think that removing the hierarchical calendar feature would simplify the implementation of CAP, and certainly gain our endorsment as a group scheduling vendor. There are few cases where I see this feature useful, but many more cases where it becomes a nightmare... just imagine asking a user to specify where in the hierarchy he is entering a new appointment on his web phone!!! I hope common sense shall prevail. Gilles Fortin, Founder & President __________________________________ Teamsoft Inc. 50 Queen, #304 Montreal, Canada H3C 2N5 +514-875-2231x106 fax:+514-875-2401 Internet: fortin@teamsoft.com Web: http://www.teamsoft.com From owner-ietf-calendar@mail.imc.org Tue Jan 8 10:39:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25978 for ; Tue, 8 Jan 2002 10:39:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08FMpo06191 for ietf-calendar-bks; Tue, 8 Jan 2002 07:22:51 -0800 (PST) Received: from gate.incentivesystems.com ([216.57.133.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08FMn306184 for ; Tue, 8 Jan 2002 07:22:49 -0800 (PST) Received: from [10.10.30.8] by gate.incentivesystems.com for ietf-calendar@imc.org id KAA29722; Tue Jan 8 10:18:07 2002 Subject: Re: Proposed removal of hierarchy from CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 8 Jan 2002 10:27:23 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 01/08/2002 10:27:24 AM, Serialize complete at 01/08/2002 10:27:24 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: >certainly gain our endorsment as a group >scheduling vendor. Vendor endorsement is irrelevant in the IETF. /=======================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |=======================================================| |This sentance has threee errors. | \=======================================================/ From owner-ietf-calendar@mail.imc.org Tue Jan 8 11:24:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28270 for ; Tue, 8 Jan 2002 11:24:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08G2uL07982 for ietf-calendar-bks; Tue, 8 Jan 2002 08:02: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 g08G2s307978 for ; Tue, 8 Jan 2002 08:02: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 IAA28994 for ; Tue, 8 Jan 2002 08:02:54 -0800 (PST) Message-ID: <3C3B182B.5699B01F@Royer.com> Date: Tue, 08 Jan 2002 09:02:51 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-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="------------34E245ECDE8B5E44C548BDA8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------34E245ECDE8B5E44C548BDA8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gilles Fortin wrote: > > I do think that removing the hierarchical calendar feature would simplify > the implementation of CAP, and certainly gain our endorsment as a group > scheduling vendor. > > There are few cases where I see this feature useful, but many more cases > where it becomes a nightmare... just imagine asking a user to specify where > in the hierarchy he is entering a new appointment on his web phone!!! > > I hope common sense shall prevail. There was no requirement that you must implemnet this. As with IMAP, you don't have to have sub-folders. But you can. -Doug --------------34E245ECDE8B5E44C548BDA8 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 15:18:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08JjNg15632 for ietf-calendar-bks; Tue, 8 Jan 2002 11:45:23 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08JjM315628 for ; Tue, 8 Jan 2002 11:45: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 LAA29437 for ; Tue, 8 Jan 2002 11:45:23 -0800 (PST) Message-ID: <3C3B4C4E.E15D1C42@Royer.com> Date: Tue, 08 Jan 2002 12:45:18 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: RELATED-TO vs CHILD/PARENT Content-Type: multipart/mixed; boundary="------------9E7911B6A030B7821F286748" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9E7911B6A030B7821F286748 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I talked to Bruce the other day on the phone. We were trying to understand each others point. (1) Bruce wants to rename PARENT/CHILD to RELATED-TO just like in iCalendar. I don't see a problem with that. (2) People seem confused and think that you can not have parent child calendars without inherited VCARS. - they are wrong. So, I propose (I was expecting Bruce to do this - he is busy): We remove ALL words in CAP that are causing confusion. We remove the words 'hierarchy', 'parent' and 'child' and replace them with something like 'RELATED-TO' and tweak the text to make it understandable. Then, we delete the PARENT and CHILD calendar property and replace them with the multi instances property 'RELATED-TO' that can have the values 'PARENT', 'CHILD', and 'SIBLING' as defined in RFC-2445 section "4.8.4.5 Related To" and section "4.2.15 Relationship Type" and specify that it is how one calendar is tagged as relating to another calendar. Then when these other (not yet proposed) relationship types are defined, they can be added later. And CAP works now. I don't think this changes any of the implementation specifics from CHILD/PARENT, but it should clear up the confusion. Comments?  --------------9E7911B6A030B7821F286748 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 15:38:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08K51116216 for ietf-calendar-bks; Tue, 8 Jan 2002 12:05: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 g08K50316212 for ; Tue, 8 Jan 2002 12:05: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 MAA29564 for ; Tue, 8 Jan 2002 12:05:01 -0800 (PST) Message-ID: <3C3B50E7.D7D96690@Royer.com> Date: Tue, 08 Jan 2002 13:04:55 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (booked) - latest interm draft Content-Type: multipart/mixed; boundary="------------2827C2A079EC3788FCD3B814" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2827C2A079EC3788FCD3B814 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IN: > 1.3 Definitions > > Booked > > An entry in a calendar has one of two conceptual states. It is > scheduled or it is booked. A scheduled entry has been st > in the calendar store but has not been acted on by a calendar > user (CU) or calendar user agent (CUA). A scheduled entry > contains a METHOD property set to an [iTIP] method. > ... A booked entry is a component does not have a METHOD property. Should be: A booked entry is a component with a METHOD set to to the METHOD property value of 'CREATE'. --------------2827C2A079EC3788FCD3B814 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 15:39:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08K8YG16348 for ietf-calendar-bks; Tue, 8 Jan 2002 12:08:34 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08K8X316344 for ; Tue, 8 Jan 2002 12:08:33 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA29573 for ; Tue, 8 Jan 2002 12:08:34 -0800 (PST) Message-ID: <3C3B51BC.2D8C7E93@Royer.com> Date: Tue, 08 Jan 2002 13:08:28 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (related-to) latest interm draft Content-Type: multipart/mixed; boundary="------------FF23815FE8A8CBB3DAC0B858" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FF23815FE8A8CBB3DAC0B858 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IN 1.3: > ... > Calendar > > A collection of logically related objects or entities each of > which may be associated with a calendar date and possibly time > of day. These entities can include other calendar properties > or calendar components. In addition, a calendar might be > hierarchically related to other sub-calendars. A calendar is > identified by its unique calendar identifier. The [iCAL] > defines calendar properties, calendar components and component > properties that make up the content of a calendar. Replace: In addition, a calendar might be hierarchically related to other sub-calendars. With: In addition, a calendar might be related to other calendars by using the RELATED-TO calendar property. --------------FF23815FE8A8CBB3DAC0B858 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 15:45:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08KFrn16698 for ietf-calendar-bks; Tue, 8 Jan 2002 12:15:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08KFq316694 for ; Tue, 8 Jan 2002 12:15: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 MAA29582 for ; Tue, 8 Jan 2002 12:15:53 -0800 (PST) Message-ID: <3C3B5374.D5737CA6@Royer.com> Date: Tue, 08 Jan 2002 13:15:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (fan out) - latest intem draft Content-Type: multipart/mixed; boundary="------------AAFC6655069D4C811C599BD2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AAFC6655069D4C811C599BD2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In 1.3 > > Fan Out > > The calendaring and scheduling process by which a calendar > operation on one calendar is also performed on every other > calendar specified in the operation. Note that CAP does not > specify how fan out should be done. Not quite. Fan out is the ability for one CS to interact with another CS in order to appear to be one logical CS. That is: Linked calendars in one CS may be transparently acted on by the CS directly, without the CUA's knowledge. I propose it instead say: The calendaring and scheduling process by which one CS communicates to another CS on behalf of the CUA. This may be with or without the CUAs knowledge. Note that CAP does not specify how fan out should be done. --------------AAFC6655069D4C811C599BD2 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 15:51:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08KMst16984 for ietf-calendar-bks; Tue, 8 Jan 2002 12:22: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 g08KMr316974 for ; Tue, 8 Jan 2002 12:22:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA29594 for ; Tue, 8 Jan 2002 12:22:54 -0800 (PST) Message-ID: <3C3B5518.1D21C7E4@Royer.com> Date: Tue, 08 Jan 2002 13:22:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (Hierarchial calendars) - latest intem draft Content-Type: multipart/mixed; boundary="------------F72AC308D439F5050F8F73FA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F72AC308D439F5050F8F73FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In section 1.3 I propose we remove: > Hierarchical Calendars > > A CS feature where a calendar has a hierarchical relationship > with another calendar in the CS. The top-most calendars in the > hierarchical relationship have the CS as their parent. There > may be multiple top-most calendars in a given CS. Within a > given hierarchical relationship, all sub-calendars have a > calendar with a "parent" relationship. In addition, sub- > calendars may have a relationship with another calendar that > has a "child" relationship. 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 "CHILD" calendar properties. And replace it with something like: Related Calendars A CS feature where a calendar has a relationship with another calendar. The relationship is specified in the calendar with the RELATED-TO calendar property. This relationship has no predefined meaning to CAP. It is a convince for the CUA, CU, or CS administrator so that calendars may be organized and marked as relating to each other as specified in the implementation or administrative configuration of the CS or CUA. Any CUA with sufficient access permission may view these RELATED-TO properties. --------------F72AC308D439F5050F8F73FA Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 15:56:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08KReI17102 for ietf-calendar-bks; Tue, 8 Jan 2002 12:27: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 g08KRd317098 for ; Tue, 8 Jan 2002 12:27: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 MAA29608 for ; Tue, 8 Jan 2002 12:27:40 -0800 (PST) Message-ID: <3C3B5636.845ADAB4@Royer.com> Date: Tue, 08 Jan 2002 13:27:34 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (global uniq RELATIVE calid?) latest interm draft Content-Type: multipart/mixed; boundary="------------7732B80B96FF1DEC61C6B4EA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7732B80B96FF1DEC61C6B4EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In section 1.3: > Relative Calendar Identifier (Relative CalID) > > An identifier for an individual calendar in a calendar store. > It is unique within a calendar store. It is recommended to be > globally unique. A Relative CalID consists of the portion of > the "scheme part" of a Qualified CalID following the Calendar > Store Identifier. This is the same as the "URL path" of the > "Common Internet Scheme Syntax" portion of a URL, as defined by > [URL]. I propose we remove : It is recommended to be globally unique. There is NO reason that each CS could not have a relative CALID of 'Joe' or any other common name. A rel-calid only needs to be unique inside of its containing CS. --------------7732B80B96FF1DEC61C6B4EA Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:00:12 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08KUoe17215 for ietf-calendar-bks; Tue, 8 Jan 2002 12:30:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08KUn317211 for ; Tue, 8 Jan 2002 12:30:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA29617 for ; Tue, 8 Jan 2002 12:30:51 -0800 (PST) Message-ID: <3C3B56F5.8A4967BF@Royer.com> Date: Tue, 08 Jan 2002 13:30:45 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (sub-calednar) - in latest iterm draft Content-Type: multipart/mixed; boundary="------------A4BC5249EFDB630E3C0956D4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A4BC5249EFDB630E3C0956D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In section 1.3: I propose we remove in favor of the previous post on RELATED-TO calendars: > Sub-calendars > > Calendars that have a "child" hierarchical relationship with > another calendar, its "parent". --------------A4BC5249EFDB630E3C0956D4 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:00:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08KW4217304 for ietf-calendar-bks; Tue, 8 Jan 2002 12:32:04 -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 g08KW3317300 for ; Tue, 8 Jan 2002 12:32: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 g08KVux26934 for ; Tue, 8 Jan 2002 12:31:56 -0800 (PST) Received: from netscape.com ([10.2.109.12]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GPMZPA00.830; Tue, 8 Jan 2002 12:31:58 -0800 Message-ID: <3C3B56E5.ED58F3D7@netscape.com> Date: Tue, 08 Jan 2002 12:30:29 -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: Gilles Fortin CC: ietf-calendar@imc.org Subject: Re: Proposed removal of hierarchy from CAP References: Content-Type: multipart/alternative; boundary="------------74B20435A05C9B6BD42FD590" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------74B20435A05C9B6BD42FD590 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just so we're all on the same page, I believe the recommendation has boiled down to this: * We keep the calendar (or should I say: VAGENDA) properties, CHILDREN and PARENT * We specify that VCARs are not hierarchical. That is, there is no VCAR inheritance. Each calendar (VAGENDA) is self-contained with respect to its VCARs. There is one potential exception to this which is default VCARs which are specified at the data store root. This provides one level of hierarchic VCARs and it applies to *every* calendar (VAGENDA). * There is no "roll-up" of events or todos. That is, if calid abc123 has a child calendar def456, then a request for events from calid abc123 will not contain any events from def456. Doug, Bruce, George is this your understanding? Is this approach acceptable to all? -Steve Gilles Fortin wrote: > I do think that removing the hierarchical calendar feature would simplify > the implementation of CAP, and certainly gain our endorsment as a group > scheduling vendor. > > There are few cases where I see this feature useful, but many more cases > where it becomes a nightmare... just imagine asking a user to specify where > in the hierarchy he is entering a new appointment on his web phone!!! > > I hope common sense shall prevail. > > Gilles Fortin, Founder & President > __________________________________ > Teamsoft Inc. > 50 Queen, #304 > Montreal, Canada H3C 2N5 > +514-875-2231x106 fax:+514-875-2401 > Internet: fortin@teamsoft.com Web: http://www.teamsoft.com --------------74B20435A05C9B6BD42FD590 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Just so we're all on the same page, I believe the recommendation has boiled down to this:
  • We keep the calendar (or should I say: VAGENDA) properties, CHILDREN and PARENT
  • We specify that VCARs are not hierarchical.  That is, there is no VCAR inheritance. Each calendar (VAGENDA) is self-contained with respect to its VCARs. There is one potential exception to this which is default VCARs which are specified at the data store root.  This provides one level of hierarchic VCARs and it applies to *every* calendar (VAGENDA).
  • There is no "roll-up" of events or todos. That is, if calid abc123 has a child calendar def456, then a request for events from calid abc123 will not contain any events from def456.
Doug, Bruce, George is this your understanding?

Is this approach acceptable to all?

-Steve

Gilles Fortin wrote:

I do think that removing the hierarchical calendar feature would simplify
the implementation of CAP, and certainly gain our endorsment as a group
scheduling vendor.

There are few cases where I see this feature useful, but many more cases
where it becomes a nightmare... just imagine asking a user to specify where
in the hierarchy he is entering a new appointment on his web phone!!!

I hope common sense shall prevail.

Gilles Fortin, Founder & President
__________________________________
Teamsoft Inc.
50 Queen, #304
Montreal, Canada H3C 2N5
+514-875-2231x106    fax:+514-875-2401
Internet: fortin@teamsoft.com    Web: http://www.teamsoft.com

--------------74B20435A05C9B6BD42FD590-- From owner-ietf-calendar@mail.imc.org Tue Jan 8 16:00:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10374 for ; Tue, 8 Jan 2002 16:00:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08KTbr17167 for ietf-calendar-bks; Tue, 8 Jan 2002 12:29: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 g08KTa317163 for ; Tue, 8 Jan 2002 12:29: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 MAA29612 for ; Tue, 8 Jan 2002 12:29:38 -0800 (PST) Message-ID: <3C3B56AC.EE01DCE7@Royer.com> Date: Tue, 08 Jan 2002 13:29: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: CAP (CAR vs VCAR) latest intem draft Content-Type: multipart/mixed; boundary="------------53228E4F00AD9A4A7BDEC704" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------53228E4F00AD9A4A7BDEC704 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In section 1.3: > Session Identity > > A UPN associated with a CAP session. A session gains an > identity after successful authentication. The identity is used > in combination with CAR to determine access to data in the CS. Should it be 'VCAR' and not 'CAR' ? --------------53228E4F00AD9A4A7BDEC704 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:11:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08KgZX17601 for ietf-calendar-bks; Tue, 8 Jan 2002 12:42:35 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08KgY317597 for ; Tue, 8 Jan 2002 12:42: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 MAA29637 for ; Tue, 8 Jan 2002 12:42:36 -0800 (PST) Message-ID: <3C3B59B6.3D1F7964@Royer.com> Date: Tue, 08 Jan 2002 13:42:30 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (schedul command - redundent?) latest interm draft Content-Type: multipart/mixed; boundary="------------C39BF000C5F19E4CBFC6A596" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C39BF000C5F19E4CBFC6A596 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As the CREATE command can create any object including iTIP object. It looks to me if the 'schedule' command is redundant. Did I missing something? --------------C39BF000C5F19E4CBFC6A596 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:11:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08Kdgq17501 for ietf-calendar-bks; Tue, 8 Jan 2002 12:39: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 g08Kdf317496 for ; Tue, 8 Jan 2002 12:39: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 MAA29621 for ; Tue, 8 Jan 2002 12:39:42 -0800 (PST) Message-ID: <3C3B5909.79854088@Royer.com> Date: Tue, 08 Jan 2002 13:39: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: CAP (ICAL Version 2.0) - latest intem draft Content-Type: multipart/mixed; boundary="------------80569669B9C042FA5CD455FD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------80569669B9C042FA5CD455FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In 2.2 is says near the top: > [ICAL] Version 2.0 describes components such as events, todos, > alarms, and timezones. Version 2.0 is NOT the vesion of ICAL, it is the version of the data format. Replace with? : [ICAL] describes components such as events, todos, alarms, and timezones. --------------80569669B9C042FA5CD455FD Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:24:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08KrtM17912 for ietf-calendar-bks; Tue, 8 Jan 2002 12:53: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 g08Krr317908 for ; Tue, 8 Jan 2002 12:53:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA29650 for ; Tue, 8 Jan 2002 12:53:55 -0800 (PST) Message-ID: <3C3B5C5D.D1F76D8@Royer.com> Date: Tue, 08 Jan 2002 13:53:49 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (UPN ORGANIZER/ATTENDEE validation) - latest interm draft Content-Type: multipart/mixed; boundary="------------E4CBBD2DC1172D41BEC81FD0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E4CBBD2DC1172D41BEC81FD0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 2.4.1.1 UPNs and Certificates Near the end it says: > Note: If a CS or CUA is validating data received via iMIP, if the > "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe > Random User:MAILTO:juser@example.com" then the email address should > be checked against the UPN. This is so the "ATTENDEE" property > cannot be changed to something misleading like "ATTENDEE;CN=Joe > Rictus User:MAILTO:juser@example.com" and have it pass validation. > This validation will also defeat other attempts at confusion. This is confusing to me: I can get an iMIP message with multiple ATTENDEE entries, or one, or NONE of them might be me. There is NO requirement that the iMIP recipient be in the ATTENDEE list or that it be the ORGANIZER. I could send you an iMIP message informing you of an event that where I am not the organizer, and you are not an attendee. As I understand it, the CS MUST (Per iMIP) compare the ORGANIZER to the signature, and match that to the FROM line (S/MIME iMIP). But there is no way to know which ATTENDEE in a multiple ATTENDEE VEVENT should be compared. And a METHOD:PUBLISH iMIP message might have NO ATTENDEE properties. So what is the above Note saying? What would I compare to what? And when? --------------E4CBBD2DC1172D41BEC81FD0 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:30:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08KwFN18072 for ietf-calendar-bks; Tue, 8 Jan 2002 12:58: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 g08KwE318068 for ; Tue, 8 Jan 2002 12:58: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 MAA29667 for ; Tue, 8 Jan 2002 12:58:15 -0800 (PST) Message-ID: <3C3B5D61.496548E2@Royer.com> Date: Tue, 08 Jan 2002 13:58:09 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (access rights UPN not CU) - latest intem draft Content-Type: multipart/mixed; boundary="------------43A71EA5D83FF93B01FEA8BD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------43A71EA5D83FF93B01FEA8BD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In 2.4.2 Access Rights - Summary It starts off with: > Access rights are used to grant or deny access to a calendar > for a CU. No, it is for a UPN (not a CU). At no point does any VCAR refer to a CU. And: > All rights MUST be denied unless specifically granted; individual > VCARs MUST be specifically granted to an authenticated CU. Should end with: authenticated UPN (not authenticated CU) Correct? --------------43A71EA5D83FF93B01FEA8BD Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:30:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08L1IW18214 for ietf-calendar-bks; Tue, 8 Jan 2002 13:01: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 g08L1H318210 for ; Tue, 8 Jan 2002 13:01: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 NAA29683 for ; Tue, 8 Jan 2002 13:01:18 -0800 (PST) Message-ID: <3C3B5E18.A3A1884A@Royer.com> Date: Tue, 08 Jan 2002 14:01:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (inheritance) - latest interm draft Content-Type: multipart/mixed; boundary="------------5E59E3A9EC41782DAAD4E135" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5E59E3A9EC41782DAAD4E135 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think there is concensis to remove: > 2.4.3 Inheritance > > Calendars inherit VCARs from their parent calendar. Calendars whose > parent is the Calendar Store inherit VCARs from the Calendar Store. > > VCARs specified in a calendar or a sub-calendar override all > inherited VCARs. --------------5E59E3A9EC41782DAAD4E135 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:39:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08LAwC18692 for ietf-calendar-bks; Tue, 8 Jan 2002 13:10:58 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08LAv318686 for ; Tue, 8 Jan 2002 13:10:57 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA29699 for ; Tue, 8 Jan 2002 13:10:58 -0800 (PST) Message-ID: <3C3B605C.C076A3D@Royer.com> Date: Tue, 08 Jan 2002 14:10:52 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (global REL-CALID again) Content-Type: multipart/mixed; boundary="------------7921277E5BD381FC6821D514" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7921277E5BD381FC6821D514 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In: 2.6 Calendar Addresses It says in part: > .... > It is recommended that the Relative CALID be globally unique. Again, NO - A relative CALID only MUST be unique in the CS. Trying make it globally unique has no value and can not be guaranteed. I propose we remove that last sentence. --------------7921277E5BD381FC6821D514 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:39:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08L7rI18551 for ietf-calendar-bks; Tue, 8 Jan 2002 13:07:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08L7q318544 for ; Tue, 8 Jan 2002 13:07: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 NAA29695 for ; Tue, 8 Jan 2002 13:07:53 -0800 (PST) Message-ID: <3C3B5FA3.C7D24B3D@Royer.com> Date: Tue, 08 Jan 2002 14:07:47 -0700 From: Doug Royer 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: CAP (lower Port number?) Content-Type: multipart/mixed; boundary="------------8D68BCD5FD7E066B27864AD7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8D68BCD5FD7E066B27864AD7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 2.6 Calendar Addresses It says in part: > is optional. The port must be present in the URL if the > CAP server does not listen on the default port number (5229). > > [Editors Note: TODO - get the lower port number ] I have never heard of a 'lower port number' what is it? --------------8D68BCD5FD7E066B27864AD7 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:45:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08LEeU18857 for ietf-calendar-bks; Tue, 8 Jan 2002 13:14: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 g08LEd318853 for ; Tue, 8 Jan 2002 13:14: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 NAA29712 for ; Tue, 8 Jan 2002 13:14:40 -0800 (PST) Message-ID: <3C3B613A.6AD38FB0@Royer.com> Date: Tue, 08 Jan 2002 14:14:34 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (No Scheme in URL?) Content-Type: multipart/mixed; boundary="------------93A11C206FCBDB345C80CF15" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------93A11C206FCBDB345C80CF15 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Near the end of : 2.6 Calendar Addresses It says in part: > Examples of CAP URIs: > > cap://calendar.example.com/abcd1234QWER > ://calendar.example.com/abcd1234QWER > abcd1234QWER > cap://calendar.example.com/89798-098-zytytasd > > For a user currently authenticated to a CAP server on > calendar.example.com, the first three addresses refer to the same > calendar. I can see the need for a qualified (full) CAP address (example 1). I see NO need for a 'cap' less scheme (example 2). I can see the need for a relative address (example 3). What is the purpose of the second one? When would (could) it be used? Why would it be used? Please explain. --------------93A11C206FCBDB345C80CF15 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:51:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08LMvm19119 for ietf-calendar-bks; Tue, 8 Jan 2002 13:22:57 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08LMu319114 for ; Tue, 8 Jan 2002 13:22: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 NAA29744 for ; Tue, 8 Jan 2002 13:22:57 -0800 (PST) Message-ID: <3C3B632B.D14B7E79@Royer.com> Date: Tue, 08 Jan 2002 14:22:51 -0700 From: Doug Royer 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: CAP (schedule vs create again) Content-Type: multipart/mixed; boundary="------------C87630D529E1F3D80462C6A3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C87630D529E1F3D80462C6A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In 2.8 Relationship of RFC 2446 (ITIP) to CAP It says in part: > [iTIP] describes scheduling methods which result in indirect > manipulation of calendar components. In CAP, the "schedule" command > is used to submit scheduling requests. Other CAP commands such as > "create", "delete", "modify" and "move" provide direct manipulation > of calendar components. ... As the "create" command can do the same thing, I propose we drop the (never debated to exist?) "schedule" command and replace the text with something like: [iTIP] describes scheduling methods which result in indirect manipulation of calendar components. "create" is used to store scheduling requests and non scheduling booked entries. "create", "delete", "modify" and "move" provide direct manipulation of all calendar components including scheduling components. And where it says: > ...In the CAP calendar > store model, scheduling messages are conceptually kept separate > from other calendar components. I would like to weaken this to say: ... In the CAP calendar store mode, scheduling components can be viewed as separate from other calendar components. As they could also be viewed as together with other components. --------------C87630D529E1F3D80462C6A3 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 16:58:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08LT4c19338 for ietf-calendar-bks; Tue, 8 Jan 2002 13:29:04 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08LT3319334 for ; Tue, 8 Jan 2002 13:29: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 NAA29755 for ; Tue, 8 Jan 2002 13:28:59 -0800 (PST) Message-ID: <3C3B6494.AD5456A1@Royer.com> Date: Tue, 08 Jan 2002 14:28:52 -0700 From: Doug Royer 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: CAP (BOOKED and missing METHOD - again) Content-Type: multipart/mixed; boundary="------------50CCDB4ABBCF792CDD505875" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------50CCDB4ABBCF792CDD505875 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In 2.8 Relationship of RFC 2446 (ITIP) to CAP It says in part: > When scheduling is used, the METHOD is saved along with components. > A scheduled component becomes a booked component when its METHOD > property is removed. For example, a component whose METHOD is > "REQUEST" is scheduled. The component becomes booked when the METHOD > is set to "BOOKED". (1) Conflicts with itself - it is removed to be booked or it is set to BOOKED. So - REMOVE from the paragraph: A scheduled component becomes a booked component when its METHOD property is removed. (2) I could care less what name is booked. But I think the only WG proposal to change it from CREATE to BOOKED did not reach consensus. So - change 'METHOD BOOKED' back to 'METHOD CREATE' (3) This paragraph as it is written conflicts with the definition section of CAP and see my previous post today. --------------50CCDB4ABBCF792CDD505875 Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 17:02:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08LZoV19666 for ietf-calendar-bks; Tue, 8 Jan 2002 13:35:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08LZn319662 for ; Tue, 8 Jan 2002 13:35:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA29769 for ; Tue, 8 Jan 2002 13:35:50 -0800 (PST) Message-ID: <3C3B6630.8B6CAE24@Royer.com> Date: Tue, 08 Jan 2002 14:35: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: Proposed removal of hierarchy from CAP References: <3C3B56E5.ED58F3D7@netscape.com> Content-Type: multipart/mixed; boundary="------------F64044B2953F265971AE884E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F64044B2953F265971AE884E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > Just so we're all on the same page, I believe the recommendation has > boiled down to this: > > * We keep the calendar (or should I say: VAGENDA) properties, > CHILDREN and PARENT Or use RELATED-TO as proposed recently - acceptable? I think that its implementation is the same for CHILD/PARENT and adds the SIBLING that Bruce wants (A NOP as far as I am concerned). Plus it allows for other extensions in the future. > * We specify that VCARs are not hierarchical. That is, there is no > VCAR inheritance. Each calendar (VAGENDA) is self-contained with > respect to its VCARs. There is one potential exception to this > which is default VCARs which are specified at the data store > root. This provides one level of hierarchic VCARs and it applies > to *every* calendar (VAGENDA). And the default VCARS are copied to *each* new calendar? No matter how they are related to any other calendar - I agree. And the same with decreed VCARs, they in effect are now copied to every created calendar. > * There is no "roll-up" of events or todos. That is, if calid > abc123 has a child calendar def456, then a request for events > from calid abc123 will not contain any events from def456. Until I (we - calsch -we?) propose a SEPARATE roll up draft :-) Which several are interested in doing. --AFTER CAP--. --------------F64044B2953F265971AE884E Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 17:09:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08LoT220159 for ietf-calendar-bks; Tue, 8 Jan 2002 13:50: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 g08LoR320155 for ; Tue, 8 Jan 2002 13:50: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 NAA29813 for ; Tue, 8 Jan 2002 13:50:28 -0800 (PST) Message-ID: <3C3B699E.53730F46@Royer.com> Date: Tue, 08 Jan 2002 14:50:22 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (3.1 BEEP) Content-Type: multipart/mixed; boundary="------------EC7EDC15A4F9F026AA7D40FC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EC7EDC15A4F9F026AA7D40FC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 3.1 BEEP Exchange Styles > [BEEP] defines three styles of message exchange: > > MSG/ANS,ANS,...,NUL: for one-to-many exchanges. > > MSG/RPY: for one-to-one exchanges. > > MSG/ERR: for requests the cannot be processed due to an error. A little confusing to me, why not just quote BEEP: "2.1.1 Exchange Styles BEEP allows three styles of exchange: MSG/RPY: the client sends a "MSG" message asking the server to perform some task, the server performs the task and replies with a "RPY" message (termed a positive reply). MSG/ERR: the client sends a "MSG" message, the server does not perform any task and replies with an "ERR" message (termed a negative reply). MSG/ANS: the client sends a "MSG" message, the server, during the course of performing some task, replies with zero or more "ANS" messages, and, upon completion of the task, sends a "NUL" message, which signifies the end of the reply." > A CAP request, targeted at more than one containers, MUST use a one- > to-many exchange, with a distinct answer associated with each target. > CAP request targeted at a single container MAY use a one-to-one > exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when > an error condition prevents the execution of the request on all the > targeted calendars. It starts off with "A CAP request", however it is a "CS REPLY" true? So should it say? : When a CUA has targeted more than one container, the CS MUST use a one-to-many exchange when replying, with ... (I am still learning BEEP, but I don't think that the initiator side of the BEEP protocol can necessarily tell if it is going to get more than one answer. The CUA will know, but the BEEP protocol must be able to handle one-to-one or one-to-many at any time. Or am I just nit-picking?) --------------EC7EDC15A4F9F026AA7D40FC Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 17:30:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g08MCKA21203 for ietf-calendar-bks; Tue, 8 Jan 2002 14:12:20 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08MCJ321199 for ; Tue, 8 Jan 2002 14:12: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 OAA29851 for ; Tue, 8 Jan 2002 14:12:21 -0800 (PST) Message-ID: <3C3B6EBE.520D9CB3@Royer.com> Date: Tue, 08 Jan 2002 15:12:14 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP (TARGET moved out of CAP data?) Content-Type: multipart/mixed; boundary="------------8F72D16A5738A4D659AD52CA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8F72D16A5738A4D659AD52CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IN 3.3 Bounded Latency (1) The TARGET command is not in the CAP data, however the tag is in the BEEP data. Did we remove TARGET? Did we rename it to 'source'? When did we debate this? (2) The attributes MUST have quotes around them in XML. Typo? latency=3 -> latency="3" action=ask -> action="ask" ... (3) Why not just include the CAP data in the xml section? No CID needed. (3.1) Why do we need a xml tag? ... For the "search" command, construct is much cleaner. Doug Royer wrote: > > > 6.2.3.2 "select" Element > > > > Many calendaring commands can target several components stored on the > > CS (e.g., "search", "delete", "modify" and "move"). The "select" > > element is used to identify the targeted components. > > That is what TAGET does, why do we need 'select' ? From owner-ietf-calendar@mail.imc.org Tue Jan 8 20:18:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15660 for ; Tue, 8 Jan 2002 20:18:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0912Uw26646 for ietf-calendar-bks; Tue, 8 Jan 2002 17:02:30 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0912T326642 for ; Tue, 8 Jan 2002 17:02:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA00182 for ; Tue, 8 Jan 2002 17:02:31 -0800 (PST) Message-ID: <3C3B969F.BB56520@Royer.com> Date: Tue, 08 Jan 2002 18:02:23 -0700 From: Doug Royer 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" CC: "ietf-calendar@imc.org" Subject: Re: CAP (TARGET moved out of CAP data?) References: <3C3B6EBE.520D9CB3@Royer.com> <3C3B8B54.803E082@steltor.com> Content-Type: multipart/mixed; boundary="------------5996AD3353252E22A0221F3D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5996AD3353252E22A0221F3D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > Doug Royer wrote: > > > ... > > > > (3) Why not just include the CAP data in the xml section? > > No CID needed. > > > > A possible advantage of multiple mime parts is the > different header parameters (e.g., charset, encoding, ...). > > If we include both in the same section we must be careful > about characters with special meaning in XML (e.g. the <, > > used your example). > > Note that this could be resolved using the XML > construct. > > A good compromise would be to support both (similar to what is > done in the apex profile): > > 1. > > 2. > > BEGIN:VCALENDAR > ... > END:VCALENDAR > ]> > > > Note: If and when the XML mapping to iCalendar standardized it > could also be good candidate to the fill of the data element. I agree. > > > ... > > (3.1) Why do we need a may look superfluous, but > it also used in other commands: "modify", "delete" and "move". The > use of a single construct to select the targeted component seems > more consistent. I agree that it is used, I don't agree that it is needed :-) Without the tags, the CAP server still has the same information. I guess many of my posts boil down to the fact that we have to stop re-inventing the wheel. We needed to re-do the transport. But I think that almost all of the data portion had reached consensus, now we want to change that again. Please that will cost use a couple more years of debate as each and every nuance of the changes are debated, tried, rejected, and debated over and over again until some other transport or data model is presented and we do it all over again. Lets JUST alter the transport ONLY, and update the data portion when we get xml-ical. Otherwise - lets use the data model that has been debated over the last few years and had already reached consensus. Not to mention vendors were already coding to that data model. > > > > As is, this works: > > > > > > > > BEGIN:VCALENDAR > > TARGET:relcalid-20934 > > BEGIN:VQUERY > > QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT > > WHERE DTEND >= '19990714T080000Z' AND > > DTSTART <= '19990715T080000Z' > > END:VQUERY > > END:VCALENDAR > > > > --------------5996AD3353252E22A0221F3D Content-Type: text/x-vcard; charset=us-ascii; name="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, 8 Jan 2002 20:21:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0916VC26760 for ietf-calendar-bks; Tue, 8 Jan 2002 17:06:31 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0916U326756 for ; Tue, 8 Jan 2002 17:06:30 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id UAA22163 for ; Tue, 8 Jan 2002 20:06:28 -0500 Received: from steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0916RH03954 for ; Tue, 8 Jan 2002 20:06:27 -0500 (EST) Message-ID: <3C3B9985.6AE4494E@steltor.com> Date: Tue, 08 Jan 2002 20:14:45 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP (why 'source'?) References: <3C3B8CA9.23AC89E6@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 ... > Why? You can do EXACTLY the same thing with TARGET. > Multiple TARGETs can already be specified, Why is this needed? The "move" command uses "source" for the origin(s) and "target" for the destination. The two concepts are needed in the same command. Using the same property for the two concepts seems confusing. Another difference is that a single source can refer to many containers (e.g. search in all the VAGENDAs that I own), the always refer to a single container. If source is removed, then for each command we would have to document if the target(s) can refer to multiple containers. From owner-ietf-calendar@mail.imc.org Tue Jan 8 20:50:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16025 for ; Tue, 8 Jan 2002 20:50:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g091WPB27472 for ietf-calendar-bks; Tue, 8 Jan 2002 17:32:25 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g091WO327468 for ; Tue, 8 Jan 2002 17:32:24 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA00226 for ; Tue, 8 Jan 2002 17:32:26 -0800 (PST) Message-ID: <3C3B9DA2.BE9AC2E9@Royer.com> Date: Tue, 08 Jan 2002 18:32:18 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP (why 'select'?) References: <3C3B8C35.DFD876BC@Royer.com> <3C3B938D.7576BFF8@steltor.com> Content-Type: multipart/mixed; boundary="------------184F0E04AB4C017C47781B5D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------184F0E04AB4C017C47781B5D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > A problem with using only an iCalendar property > like TARGET would be to express the "move" operation. That was covered in the old (and removed without debate) modify operation. There is no need for an external tag. I believe the old MODIFY is coming back as it had already reached consensus and there have been no debate or even WG proposals to change it. There was a *LOT* of work put into the modify command, throwing it away without any debate is unacceptable. I ask the chairs now for a statement. I would really like them state that we have closed the CAP-REQUIREMENTs over a year ago, and we reached consensus to change the TRANSPORT ONLY - Not everything someone wants to change. > There are source target(s) needed to identify > the VAGENDA where to search for components > and a single destination target to identify the > destination. I don't understand. You VQUERY given a qualified CALID or a relative CALID. What can't you do with TARGET? You can name multiple TARGETS in a VQUERY - nothing new. > It would be possible to extend iCalendar to express > this (e.g, add new components/property, impose > restriction of the ordering of the TARGET properties, ...). > But it seems (at least to me) that the use the ;; Each time we tried to expand the above format, people kept saying "In sql I can ...". So we altered it to be SQL. In Oslo I again got the green light. People seemed to want it to be SQL if at all possible - but NOT require the CS to be an SQL database. And the quotes you point out I remember as being "Only if SQL does not work, will we consider SQL-like" - And that is exactly what we are doing now. Even now when we are trying to determine the exact features we want, people over time keep adding needs for the query language. This did not just spring up over night. It has been in process for about three years and only now are people *thankfully* giving it serious thought. The WG talked us into having it more like SQL. The IETF members that participated in other working groups, including LDAP and WebDav urged us to adopt a more SQL query language because of their experiences and the pain they went through to develop a query language. I know this because I networked at the IETF meeting and asked the people that had or were developing query languages what they thought. By searching those same archives for sender=kahn and body contains 'query' or 'sql', I can not find that you had any objections to the query language as proposed (until recently) and I looked back to March 26 1996. Not that you can't object. But that has been the proposal since about Orlando (Dec 1998). Often silence is the best indicator of consensus - and on the topic of query language - we had suggestions for improvement, and NO counter proposals for three years - looks like concenses to me :-) I think that the recent debates have resulted in a happy medium. And that we are getting closer to shipping CAP. --------------CF0C0C69BDE9A4934209EE0E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 17 Jan 2002 10:06:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HEmsd14904 for ietf-calendar-bks; Thu, 17 Jan 2002 06:48:54 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HEmq314900 for ; Thu, 17 Jan 2002 06:48:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA19897 for ; Thu, 17 Jan 2002 09:48:47 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0HEmlQ13323 for ; Thu, 17 Jan 2002 09:48:47 -0500 (EST) Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C45D581.8BB69AB6@Royer.com> References: <3C45D581.8BB69AB6@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 17 Jan 2002 09:57:13 -0500 Message-Id: <1011279434.21559.14.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wed, 2002-01-16 at 14:33, Doug Royer wrote: ... > (3) I PROPOSE the name change from SQL-MIN to CAP-QL. > Where CAP-QL stands for CAP QUERY LANGUAGE. > > PLEASE REVIEW. I also prefer "CAP-QL". > ... > > (2) ABNF is tricky stuff - PLEASE REVIEW. I included some corrections. > > (3) This proposes DOES NOT YET include the '(' ')' that > we talked about for grouping logical operators. For > two reasons: > > (a) Off of the top of my head, I did not know > where to put them in the ABNF. I think they could be added be replacing cap-cmps by cap-expr as follows: cap-expr = "(" cap-expr ")" / cap-term cap-term = cap-expr SP cap-logical SP cap-expr / cap-factor cap-factor = [ "NOT" SP ] "CONTAINS(" cap-lhs "," col-literal ")" / cap-lhs SP cap-oper SP col-literal / cal-lhs SP "IS" SP [ "NOT" SP ] "NULL" cap-logical = "AND" / "OR" cap-lhs = "PARAM(" cap-ucol "," cap-param ")" / cap-ucol cap-oper = ( "=" / "!=" / "<" / ">" / "<=" / ">=" / [ "NOT" SP ] "LIKE" ) NOTE: For completeness, I also added an optional "NOT" in front of CONTAINS, and LIKE. PLEASE REVIEW (I'm new to ABNF). > > (b) They were just seriously re-proposed and there > has been no explicit debate yet. > > ... > > 4.1.1.1 "VQUERY ABNF" > > search = "BEGIN:VQUERY" CRLF > [expand] querycomp > "END:VQUERY" CRLF > > # If not provided, EXPAND default to FALSE > expand = "EXPAND" ":" ( "TRUE" / "FALSE") CRLF I think that EXPAND and QUERY should include the X-PARAM. expand = "EXPAND" *(xparam) ":" ( "TRUE" / "FALSE") CRLF (xparam is defined in rfc445). > > comp-name = "VEVENT" / "VTODO" / "VJOURNAL" > / "VTIMEZONE" / "VALARM" / "VFREEBUSY" > / "VAGENDA" / "VCAR" / "CALSTORE" > / iana-name / x-name "comp-name" is not used in the ABNF. > > querycomp = ( query ) / ( queryname query ) / queryname > > queryname = "QUERYNAME:" text CRLF > queryname = "QUERYNAME" *(xparam) ":" text CRLF > query = "QUERY:" capselect CRLF > > # NOTE: There is exactly one space separating > # the various parts of capselect > # > capselect = ( "SELECT" " " cap-cols " " > "FROM" " " cap-tbl " " This is a detail, but I prefer the use of the core rule SP instead of " ". Also see comments on (1) and (2) bellow. e.g., pselect = ( "SELECT" SP cap-cols SP "FROM" SP cap-tbl SP > "WHERE" " " cap-cmps > > / "SELECT" " " cap-cols " " > "FROM" " " cap-tbl > > / "SELECT " " cap-cols " " > "FROM" " " cap-tbl " " > "USING_PROPERTIES" " " cap-col cap-local > "WHERE" " " cap-cmps ) > 1. The USING_PROPERTIES property clause should accept a list. 2. Missing space between in cal-col and cal-local ... USING_PROPERTIES" SP cap-local-decls ... cap-local-decls = cal-local-decl *( "," cap-local-decl ) > cap-col = # Any property name found in the component > # named in the comp-tbl used in the FROM clause. > # > # SELECT ORGANIZER FROM VEVENT ... > # > # OR > # > # A component name of an existing component contained > # inside of the cmp-tbl used in the FROM clause. > # > # SELECT VALARM FROM VEVENT ... > > cap-tbl = ( # Any known component type > / "CALSTORE" > / "VAGENDA" ) The avoid confusion supported element should be explicitly listed. "VQUERY" should also be included (not in comp-name above). > > # NOTE: there is NO space around the "," on > # the next line > cap-cols = ( cap-col / cap-col "," cap-cols ) > / "*" > > cap-param = # Any parameter that may be contained in the cap-col > # in the supplied PARM() function. > > cap-local = # Any string that is composed of the characters > # that could be a cap-col name, but is not any > # cap-col name. It is suggested that the > # string start with "x-" to ensure it does not > # conflict with any existing or future cap-col name. > # This name MUST BE defined in the cap-using and > # can only be used in cap-cmps of the same query. > # And this name is only known and valid for the > # provided query and only for the lifetime of > # the query. > > col-literal = "'" literal-data "'" > > literal-data= # Any data that matches the value type of the > # column that is being compared. That is you can > # not compare PRIORITY to "some string" because > # PRIORITY has a value type of integer. > # > # OR if the literal-data is proceeded by the LIKE > # element it may also contain the '%' and '_' > # wildcard characters. > > cap-ucol = cap-col / cap-local > > cap-cmp = ( cap-ucol cap-cmd-rhs > / cap-ucol cap-oper cap-literal > / "PARAM(" cap-col "," cap-param ")" cap-cmp-rhs First argument of PARAM should be cap-ucol: / "PARAM(" cap-ucol "," cap-param ")" cap-cmp-rhs > / "CONTAINS(" cap-col "," col-literal ")" 1. The first arg of CONTAINS should be cap-ucol + PARAM() (see suggested ABNF for sub-expressions). 2. For completeness "NOT CONTAINS" should probably by added. > / cap-logical ) Missing a closing ')'. > # NOTE: there is NO space around the "," on > # the next line > cap-cmps = cap-cmp > / cap-cmp "," cap-cmps > / cap-cmp cap-logical cap-cmps > cap-cmp is not defined (cmp-oper). > cap-cmp-rhs = ( cap-oper col-literal > / "IS NULL" ) > / "IS NOT NULL" > / "LIKE" " " col-literal ) # Where the SQL '%' and '_' > # Wildcard characters may > # be used in col-literal For completeness, "NOT LIKE" should probably by added. > > cmp-oper = ( " = " > / " != " > / " < " > / " > " > / " <= " > / " >= " ) "cmp-oper" is referred to as cap-oper above. > > cap-logical = ( " AND " / " OR " ) > > 4.1.2 CAP-QL notes > > (1) No in-lined spaces are allowed if not in the grammar above. > > (2) Note that cmp-oper and cap-logical elements are > surrounded by exactly one space. > > Use: "VEVENT,VTODO" > > Not: "VEVENT, VTODO" (Space before or after ',' not allowed) > > Use: "DTSTART <= '20000605T131313Z'" > > Not: "DTSTART<='20000605T131313Z'" (Exactly one space surrounds > compare operators) > > Use: " AND " and " OR " (Exactly one space surrounds > compare operators) > > Not: "AND" and not "OR" (Exactly one space surrounds > compare operators) I propose to remove (1) and (2) and to adjust the ABNF accordingly. It only seems to add complexity (~10 lines of descriptions and comments in ABNF). Some spaces are required (e.g., around AND, OR), but imposing exactly one is not needed. I also propose to support tabs. This could be achieve by replacing most " " in the ABNF with *WSP. WSP is defined in rfc2234 as: WSP = ( SP / HTAB ) SP = %x20 HTAB = %x09 From owner-ietf-calendar@mail.imc.org Thu Jan 17 10:41:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19217 for ; Thu, 17 Jan 2002 10:41:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HFPP015617 for ietf-calendar-bks; Thu, 17 Jan 2002 07:25:25 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HFPO315613 for ; Thu, 17 Jan 2002 07:25:24 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA21089 for ; Thu, 17 Jan 2002 10:25:20 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0HFPJQ16862 for ; Thu, 17 Jan 2002 10:25:19 -0500 (EST) Message-ID: <3C46ED36.87FD7EA6@steltor.com> Date: Thu, 17 Jan 2002 10:26:46 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: Questions concerning CALSTORE vs Capabilities References: <1011015568.23082.43.camel@c-1241.in.steltor.com> <3C432644.25F5B178@Royer.com> <3C434541.A71442D2@steltor.com> <3C4359B5.72ED64F@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: > > > > > > Patrice Lapierre wrote: > > > > > > > > 2. The concept of DEFAULT_VARDS is not explained at all in > > > > the draft. Is it necessary for a CUA to be able to set the > > > > DEFAULT_VARDS property, or could it be done it an implementation > > > > dependent manner? > > > > > > It is possible that both are true. > > > > > > Any implementation specific VCARs are known as decreed VCARs if > > > they are not changeable by a CUA. Thus by default they are defined > > > and are DEFAULT_VCARS. > > > > According to the draft, DEFAULT_VCARS contains the default > > VCARs for newly created top level calendars, that is, the > > VCARS automatically copied in VAGENDA at creation time. > > > > Given that decreed VCAR apply to all calendars on the server, > > I don't think it would be appropriate to have them copied in > > every VAGENDA by listing them in the DEFAULT_VCARS property. > > As we have done away with 'non-top' level calendars, they > do indeed apply to ALL calendars anyway. What I meant is that by listing decreed VCAR in DEFAULT_VCAR would imply that they would be copied in every calendar. > > Do you want to have two properties? As in: > > DECREED_VCARS one entry: CARID:decreed or EMPTY. Why can't we simply store the decreed VCAR under CALSTORE? No properties needed. > DEFAULT_VCARS multiple entries set by a CUA Where will the default VCARs be stored? That is, the actual VCARs that will be copied in newly created VAGENDA? In the CALSTORE? Furthermore, who is responsible for copying these VCARs in newly created VAGENDA? The CS? Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jan 17 10:44:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19299 for ; Thu, 17 Jan 2002 10:44:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HF3Kq15179 for ietf-calendar-bks; Thu, 17 Jan 2002 07:03:20 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HF3J315175 for ; Thu, 17 Jan 2002 07:03:19 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA20363 for ; Thu, 17 Jan 2002 10:03:15 -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 g0HF3EQ14674 for ; Thu, 17 Jan 2002 10:03:14 -0500 (EST) Message-ID: <3C46E808.3507AA1F@steltor.com> Date: Thu, 17 Jan 2002 10:04:40 -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> <3C2374F7.17093CD5@steltor.com> <3C435DE1.D7835285@steltor.com> <3C436764.39CA63F4@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > I would like to close this issue by proposing some changes to the > > text that was put back in the last interim draft which is available > > at the following URL: http://www.calsch.org/ietf/drafts.html. > > > > IS (Section 11.2, RIGHTS Value Type): > > > > > act-type = ("CREATE" / "MODIFY" / "DELETE" / "READ" / all) > > > > > ... > > > > > 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". > > > > PROPOSAL: > > > > act-type = ("WRITE" / "MODIFY" / "DELETE" / "READ" / all) > > > > ... > > > > The ACTION rule part defines one or more CAP actions that are allowed > > for the UPN. The valid values are WRITE, DELETE, MODIFY, READ, and > > '*', meaning all actions. 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 "WRITE,MODIFY,DELETE,READ". > > > > In brief, the iTIP METHODs as well as MOVE are no longer listed > > as valid ACTIONs in the text (they never were in the ABNF). The > > ACTION CREATE was renamed to WRITE to reduce confusion, which is > > consistent with the READ ACTION. > > The ACTIONS applies to the commands, when the commands were > renamed the ACTIONS were not - thus some of the confusion. > So you could grant or deny commands to a UPN. > > The METHOD: (or any other identifiable object) > was specified with: > > ...OBJECT=METHOD;VALUE=;... > > I would like the ACTION values to be exactly the same as > the commands as they were before these changes. And I don't > care what their name is as long as they are the same, otherwise > what are they? > > AND that would mean that act-type would be expanded to > mean ALL actions a CUA could take (as in ALL commands). The mapping between commands and ACTIONS is not 1:1. To be able to "move" a component from VAGENDA "a" to VAGENDA "b", I should be granted "READ" ACTION from VAGENDA "a", "WRITE" ACTION from VAGENDA "b", "DELETE" ACTION from VAGENDA "a". That is, all the actions that needs to happen whenever a "move" command is executed. > > > The following table shows my understanding of the relationship > > between the commands and the ACTIONs. > > > > +----------+--------+---------------+ > > | Command | Target | Source | > > +----------+--------+---------------+ > > | create | WRITE | n/a | > > | delete | n/a | DELETE | > > | modify | n/a | MODIFY | > > | move | WRITE | READ + DELETE | > > | search | n/a | READ | > > | schedule | WRITE | n/a | > > +----------+--------+---------------+ > > Sorry, I don't understand the table at all. Here's how this table was meant to be read: You can execute the command "create" only if you have the "WRITE" ACTION granted in the specified target. You can execute the command "delete" only if you have the "DELETE" ACTION granted in the specified source. You can execute the command "modify" only if you have the "MODIFY" ACTION granted in the specified source. You can execute the command "move" only if you have the "WRITE" ACTION granted in the specified target and the "READ" and "DELETE" ACTIONs granted in the specified source. You can execute the command "search" only if you have the "READ" ACTION granted in the specified source. You can execute the command "schedule" only if you have the "WRITE" ACTION granted in the specified target. 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 Jan 17 10:52:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19614 for ; Thu, 17 Jan 2002 10:52:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HFcrG15844 for ietf-calendar-bks; Thu, 17 Jan 2002 07:38:53 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HFcp315840 for ; Thu, 17 Jan 2002 07:38:51 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA21566 for ; Thu, 17 Jan 2002 10:38:47 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0HFclQ17965 for ; Thu, 17 Jan 2002 10:38:47 -0500 (EST) Subject: Re: CAP/BEEP content type. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C445E4A.A46D4D35@Royer.com> References: <3C408F1A.ED39E46D@Royer.com> <3C4305DF.367A133C@steltor.com> <3C433149.CE5268AE@Royer.com> <1011109191.22501.72.camel@c-1241.in.steltor.com> <3C445E4A.A46D4D35@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 17 Jan 2002 10:47:13 -0500 Message-Id: <1011282434.21559.64.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 2002-01-15 at 11:52, Doug Royer wrote: ... > > This seems extremely dangerous! And might be the best argument > > to keep the "schedule" command distinct from the "create". > > It is not only NOT dangerous, it IS going to be done. CUAs ARE > going to translate CAP information back to any iMIP path. That's > one of the reasons that TARGET goes into the existing 2445 object > model. > iTIP is designed to be transport independent, CAP is not. And AFAIK it's not a requirement for CAP. The email transport has limitations, handling these is beyond for scope of CAP. If 2 CUAs need to communicate by email, they must use iMIP. If more functionality is required, then iTIP should be extended, and the schedule command of CAP will accept the extensions. CAP is built on top of iTIP, not the other way around. > > If a naive iMIP implementation was to forward (i.e., "create") > > iCalendar objects with unknown METHOD or properties to a CAP > > server (e.g., simple bridge between your email and calendar > > account): > > > > Then a malicious person, could send you emails that: > > > - Book VEVENTs (as opposed to schedule). > > - Create new VALARMs. > > - Potentially modify VCARS? > > That is why we say use S/MIME in iMIP ? > > > In addition, if all cap operations used a meta command > > (e.g, SENDDATA of draft-05) then: > > > > - METHOD:MODIFY: VEVENTs, VCARs, ... > > - METHOD:DELETE: your agenda. > > > > YES!!! And that was one of the goals. If you don't trust > the S/MIME signature or the person sending the data - then don't. > But if you do - it works. That is one of the reasons that we > placed using the 2445 object model as a CAP requirement. > > At NO point is anyone saying that a CUA MUST honor all iMIP > requests. And NO ONE is saying that even if the S/MIME signature > is valid, known, and trusted, that the CUA MUST send it to > the CAP server. However - now you can IF you want to. From owner-ietf-calendar@mail.imc.org Thu Jan 17 11:49:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23856 for ; Thu, 17 Jan 2002 11:49:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HGdh718260 for ietf-calendar-bks; Thu, 17 Jan 2002 08:39:43 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HGdg318256 for ; Thu, 17 Jan 2002 08:39:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA17228 for ; Thu, 17 Jan 2002 08:39:42 -0800 (PST) Message-ID: <3C46FE4B.B26119EF@Royer.com> Date: Thu, 17 Jan 2002 09:39:39 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) 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> <3C17EE18.82517D1F@Royer.com> <3C2374F7.17093CD5@steltor.com> <3C435DE1.D7835285@steltor.com> <3C436764.39CA63F4@Royer.com> <3C46E808.3507AA1F@steltor.com> Content-Type: multipart/mixed; boundary="------------A25CD702D4AC6BF23AF56CA2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A25CD702D4AC6BF23AF56CA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > The mapping between commands and ACTIONS is not 1:1. Well it used to be :-) > To be able to "move" a component from VAGENDA "a" to > VAGENDA "b", I should be granted > > "READ" ACTION from VAGENDA "a", > "WRITE" ACTION from VAGENDA "b", > "DELETE" ACTION from VAGENDA "a". Why not just have a MOVE ACTION? And then there is no mapping? --------------A25CD702D4AC6BF23AF56CA2 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 17 Jan 2002 11:57:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HGldt18533 for ietf-calendar-bks; Thu, 17 Jan 2002 08:47:39 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HGlc318528 for ; Thu, 17 Jan 2002 08:47:38 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA23289 for ; Thu, 17 Jan 2002 11:47:34 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0HGlXQ23292 for ; Thu, 17 Jan 2002 11:47:33 -0500 (EST) Message-ID: <3C47007C.C458C824@steltor.com> Date: Thu, 17 Jan 2002 11:49:00 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> <3BFEBEE2.2F736E3D@Royer.com> <3C221F20.D92B2355@steltor.com> <3C238743.61387D6F@Royer.com> <3C433424.8CF1A158@steltor.com> <3C43521D.1FE2E412@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > I agree that we should allow multiple NAME properties, > > but I would leave it to the CUA to decide what to do > > when the NAME property is not specified. > > > > > (or if I understand you below, > > > if it is a CUA property only - it is out of scope for > > > CAP). > > > > The NAME property would be stored in the CS. Other than that > > it wouldn't impact CAP any more than, say, the LOCATION property > > of VEVENT! :-) > > > > > > > > > 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? > > > > No. I propose we get rid of the property CARID. > > And since the UID property is meant to uniquely > > identify components, ... > > The assumption is that if you have UID=1, that knowing > that tells you that the contents are consistent in the > world, and that those consistent contents are tied 1:1 > to the NAME? - That's just not true. > > > .. I propose that we store the > > CAR-MIN predefined names in the NAME property. > > If we go with that (UID): > > Are you saying that if I change the contents of a VCAR and you > have specified a UID, that I have to > COUNTER/DECLINE-COUNTER/REQUEST+new-SEQUENCE > in order for our VCAR's to be in sync? > > If no, how do you propose to keep the UID's uniquely > defining the contents when we are free to change the contents? What is different from VEVENT? To my knowledge, there is nothing that prevents me from modifying a VEVENT stored in one of my VAGENDA without telling anyone. VEVENTs with the same UID are not guaranteed to be identical. > > Are you specifying that if I change a VCAR that I got from you that > I MUST change the UID if I change the contents? > > If yes - then you are specifying that the ID of a VCAR > is local to the CS only. > > If yes - then why would they have to be "globally" unique IDs? > > If no - I can't change the contents of a globally identified > object without it being updated from the OWNER. And that > would mean that any VCAR you send is in effect a decreed > VCAR with in it scope. I wouldn't be allowed to add a VALARM in my own copy of a VEVENT? > > > > 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. > > > > The evaluation of VCARs can't work this way. With a default > > value of '0', no matter how many '1' you'll AND you'll always > > end up with 0! > > Your right - I used a bad analogy! > > > It is one thing to know whether your are granted a specific > > right or not, but another to get the stored value of a VCAR. > > The purpose of the "search" command is to get the value of > > stored components not a computed representation of them. > > Not true. Where is that in the draft? > > (1) If you don't have full access - your not going to see them. > That does not mean you don't have any rights, it means > your not allowed to look at what rights you do or don't have. > And therefore any non-OWNER UPN (#1) MAY see a set(UPN#1) > VCAR results and at the same time another non-OWNER UPN (#2) > will set a set(UPN#2) VCAR results where set(UPN#1) != set(UPN#2). > > (2) The CAR-MIN VCARs are by CARID name. The results of a VQUERY > on a CAR-MIN (or any VCAR) can change over time without > that specific named VCAR changing. The example I sent out > a week or so ago was like this: > > Using the CAR-MIN of 'REQUESTONLY' > > You can initially store the REQUESTONLY VCAR with: > > (WE NEED TO PUT GRANT/DENY and VCAR BACK INTO CAP, this example > is from memory!) > > BEGIN:VCAR > CARID:REQUESTONLY > GRANT:UPN=*;.... > END:VCAR > > Later you can say: > > BEGIN:VCAR > CARID:I do not want Doug to make requests on my calendar. > DENY:UPN=doug;ACTION=CREATE;OBJECT=METHOD;VALUE=REQUEST; > END:VCAR > > Now when I connect and do a VQUERY for REQUESTONLY, 'I' get: > > BEGIN:VCAR > CARID:REQUESTONLY > DENY:UPN=doug;ACTION=CREATE;OBJECT=METHOD;VALUE=REQUEST; > END:VCAR > > When someone other then the OWNER does a VQUERY, 'they' might get: > > BEGIN:VCAR > CARID:REQUESTONLY > GRANT:UPN= > END:VCAR > > The results of a VQUERY are most defiantly dynamic. > And not just because of the predefined VCARs, but becaue > each UPN could have different access rights to reading VCARs. > > > Although it may be acceptable for the "search" command to > > return computed values for special read-only properties > > (i.e., CURRENT_DATETIME) I don't think it is appropriate for > > read/write properties such as VCAR. > > It has to be. We had agreed that for security reasons, you > can't see what you don't have access to see. That includes VCARs. > It could be a security problem for you to let me see that > user 'joe', 'sam', and 'ted', do have permission. If I can't > do something - I get "permission denied" and there is NO > promise that I can fetch any VCAR to see why - thus I do > get different resutls from the same VCARs than another UPN. > > > If the "search" command always return a computed VCAR, then > > the "modify" command will also need to handle VCAR in a special > > way, that is, it will have to replace all the stored VCARs by > > the new VCAR being submitted. Otherwise, the CU will be shooting > > in the dark as he will have no mean of getting the stored value > > of his VCARs. > > I agree that OWNER MUST NOT issue a VCAR that would restrict > their rights to see everyting. They can stick it to themself > if they try hard. Another reason for decreed VCARs. The CS > implementation may implement decreed VCARs that prevent > the OWNER from restricting themself for just the reasons > you point out. > > But it can not be true for anyone else because they might > not have the access to see all of the VCARs and their full > contents. > > > Furthremore, what if someone created a new VCAR > > between the time you got your computed VCAR and you modified it? > > The same is true ether way. What would keep another authorized > CUA from changing the contents after you did a VQUERY and > before you applied any update? We had agreed not to have > the 'lock' command a long time ago. > > > Let's say my VAGENDA has two (2) VCARs that denies you access. > > How will I know that I need to modify 2 VCARs in order to grant > > you access, and not only the VCAR that was returned to me by the > > search command? > > SELECT * FROM VCAR > > Would yield everything OWNER can see. That means everything > including both deny properties. This assumes of course that > OWNER have not denied themself the rights to see these results. > > Note: not all VCARs need have names - so no matter what name or > non-name the VCAR exists in, you will have to get all of > them to know the net result of all of your VCARs. > > > While the "create" command will allow me to add new VCARs in my > > VAGENDA, the "search" command will be of no use when I'll want to > > delete the VCARs that I have created. > > You can MODIFY them into nothing-ness. (I will be posting the > return of the MODIFY command in a day or so). > > > As we all know, it will not always be possible for a CUA to get > > all the VCARs (computed or not) that applies to the UPN by using > > the search command. Maybe we should consider another command > > to let CUA query the CS to know whether a specific right has > > been granted to the UPN or not. > > I think that the only UPN that MUST BE able to fetch all > of the VCARs is the OWNER. Everyone else only sees what > they are allowed to see - as it applied to them at the > time they ask. > > I can't find the definition of the predefined VCARs anymore. > WOULD SOMEONE PLEASE PUT THEM BACK INTO CAP? This would clear > up a lot of debate. I just noticed that they have been removed. > That is probably why we are having this debate. I'm not sure these definitions were ever in the draft itself. As far as I know, VCAR were first proposed as VACL (vehicle?) http://www.imc.org/ietf-calendar/archive1/msg02819.html and then reviewed and renamed to VCAR (car!) http://www.imc.org/ietf-calendar/archive1/msg02880.html Then a modified version of this text appeared in "Proposed Changes To iCalendar Needed For CAP". http://calsch.org/ietf/iCal-updates.html Finally, on January 3rd 2002, George put the text in the latest interim versions of the draft. http://www.calsch.org/ietf/drafts.html As you'll noticed the text is still "half baked" and needs some work. > > They exist because this WG felt that CUA's need to be able to > find out if they can do basic things without having to perform > a SELECT * FROM VCAR each time they connected and compute the > results. They existed so that they could dynamically just find > out how any of the pre-defined VCARs applied to the currently > authenticated UPN. - exactly what you are asking for is the > reason the predefined VCARs exist. My point is that since VCARs are coalesced it will be hard to manage them. I propose we use the EXPAND property (or a new property with a more appropriate name) of the VQUERY component to specify whether we want the VCARs returned by the search command to be coalesced or not. By specifying EXPAND:TRUE in the VQUERY you would get the coalesced VCAR, by default you would get the VCAR exactly as they are stored in the CS. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jan 17 12:25:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27275 for ; Thu, 17 Jan 2002 12:25:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HHERE19571 for ietf-calendar-bks; Thu, 17 Jan 2002 09:14: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 g0HHEP319567 for ; Thu, 17 Jan 2002 09:14: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 JAA17298 for ; Thu, 17 Jan 2002 09:14:26 -0800 (PST) Message-ID: <3C47066E.4E190B64@Royer.com> Date: Thu, 17 Jan 2002 10:14:22 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: Questions concerning CALSTORE vs Capabilities References: <1011015568.23082.43.camel@c-1241.in.steltor.com> <3C432644.25F5B178@Royer.com> <3C434541.A71442D2@steltor.com> <3C4359B5.72ED64F@Royer.com> <3C46ED36.87FD7EA6@steltor.com> Content-Type: multipart/mixed; boundary="------------AC1F463BF50CF911DC924B59" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AC1F463BF50CF911DC924B59 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Doug Royer wrote: > > > > > > > > Patrice Lapierre wrote: > > > > > > > > > > 2. The concept of DEFAULT_VARDS is not explained at all in > > > > > the draft. Is it necessary for a CUA to be able to set the > > > > > DEFAULT_VARDS property, or could it be done it an implementation > > > > > dependent manner? > > > > > > > > It is possible that both are true. > > > > > > > > Any implementation specific VCARs are known as decreed VCARs if > > > > they are not changeable by a CUA. Thus by default they are defined > > > > and are DEFAULT_VCARS. > > > > > > According to the draft, DEFAULT_VCARS contains the default > > > VCARs for newly created top level calendars, that is, the > > > VCARS automatically copied in VAGENDA at creation time. > > > > > > Given that decreed VCAR apply to all calendars on the server, > > > I don't think it would be appropriate to have them copied in > > > every VAGENDA by listing them in the DEFAULT_VCARS property. > > > > As we have done away with 'non-top' level calendars, they > > do indeed apply to ALL calendars anyway. > > What I meant is that by listing decreed VCAR in DEFAULT_VCAR > would imply that they would be copied in every calendar. We did away with VCAR inheritance, so the implementation is free to optimize, but in effect they are copied to each new calendar created. So when the spec says COPY, it does not matter if the implementation is smart about how it does that. Why do we need to do this? (see below - DENY as default). > > > > Do you want to have two properties? As in: > > > > DECREED_VCARS one entry: CARID:decreed or EMPTY. > > Why can't we simply store the decreed VCAR under CALSTORE? > No properties needed. List all of the VCARs by CARID that all: Users Administrators (maybe decreed) Implementations (decreed) will want to have copied into newly created calendars. Then place those CARIDs into DEFAUTL_VCARS. Or predefine them in the spec. Don't forget that the CALSTORE may have VCARs for itself and you don't want (just those CALSTORE only VCARs) copied to all newly created calendars. Do we require all of the decreed VCARs be in one VCAR and have a CARID of 'decreed'? That only works when ONLY decreed VCARs are copied to new calendars. The DEFAULT_VCARS property specifies the entire list of VCARs (user, system admin, and decreed) VCARs that are to be copied to newly created calendars. Without requiring the name be something predefined (which people did not want and no one can name in advance), there has to be a property that tells you what they are - DEFAULT_VCARS. The CARIDs in DEFAULT_VCARS tells you which of all the VCARs that exist in the CALSTORE, which ones (by CARID)) to copy to newly created calendars. Remember that the default access is DENY. So if you were to create a calendar and not predefine some VCARs, no one has access in any way to that calendar. We could instead just mandate that all newly created calendars specify their own VCARs at creation time. But that can't work because if they tried to violate implementation specific restrictions, or site administrative restrictions, the create would fail. Then they would want to know why it failed. The answer would be the same result - look up the DEFAULT_VCARS and find out what are those restrictions. Ether way, we needed a way for a CUA to find the default VCARS and then it can adjust how it sets up a new calendar. > > DEFAULT_VCARS multiple entries set by a CUA > > Where will the default VCARs be stored? In the CALSTORE. > That is, the actual VCARs that will be copied in newly created > VAGENDA? The ones named in DEFAULT_VCARS will be copied to newly created calendars from the CALSTORE - to the new calendar. But only the ones listed in DEFAULT_VCARS - and no others. Plus any that are CUA lists when it creates a new calendar. > In the CALSTORE? Yes - if you mean where do they come from. > Furthermore, who is responsible for copying these VCARs in > newly created VAGENDA? The CS? Yes - the CS is responsible for copying them into new calendars when the new calendars are created and without specific intervention by the user or CUA. - AND WE STILL NEED TO ADD THE known predefined VCARs (REQUESTONLY...) back into CAP - does anyone have the deleted text? --------------AC1F463BF50CF911DC924B59 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 17 Jan 2002 12:33:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HHMp219937 for ietf-calendar-bks; Thu, 17 Jan 2002 09:22: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 g0HHMn319933 for ; Thu, 17 Jan 2002 09:22:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA17318 for ; Thu, 17 Jan 2002 09:22:50 -0800 (PST) Message-ID: <3C470866.2E8669B0@Royer.com> Date: Thu, 17 Jan 2002 10:22:46 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP/BEEP content type. References: <3C408F1A.ED39E46D@Royer.com> <3C4305DF.367A133C@steltor.com> <3C433149.CE5268AE@Royer.com> <1011109191.22501.72.camel@c-1241.in.steltor.com> <3C445E4A.A46D4D35@Royer.com> <1011282434.21559.64.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------58922B0B9447135EE5B142D6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------58922B0B9447135EE5B142D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > On Tue, 2002-01-15 at 11:52, Doug Royer wrote: > ... > > > This seems extremely dangerous! And might be the best argument > > > to keep the "schedule" command distinct from the "create". > > > > It is not only NOT dangerous, it IS going to be done. CUAs ARE > > going to translate CAP information back to any iMIP path. That's > > one of the reasons that TARGET goes into the existing 2445 object > > model. > > > > iTIP is designed to be transport independent, CAP is not. > And AFAIK it's not a requirement for CAP. > > The email transport has limitations, handling these > is beyond for scope of CAP. > > If 2 CUAs need to communicate by email, they must use iMIP. > If more functionality is required, then iTIP should be extended, > and the schedule command of CAP will accept the extensions. > > CAP is built on top of iTIP, not the other way around. NO - CAP is build on iCalendar, iTIP, and perhaps iMIP. iTIP is build on iCalendar CAP is extending iCalendar And it is most definitly a requirement that iTIP transport ANY VALID icalendar data, even if they were not defined at the time iTIP was written. (...or any iana ... is in iCalenar and in iTIP). It was designed so that we could extend it. We knew that iCalendar was going to be extended by CAP and the other proposals icap, hcap, irip, ... that evolved into CAP knew that and had plans to extend iCalendar also. It is iTIPs job to transport iCalendar objects. It is NOT limited to what existed in November 1998. Same for iMIP. If we extend iCalendar - we are extending iTIP and iMIP. Several of us went out of our way to make sure that those statements saying that components, properties, and paramaters were extendable. And this IS why. --------------58922B0B9447135EE5B142D6 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 17 Jan 2002 13:13:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HI3sb21879 for ietf-calendar-bks; Thu, 17 Jan 2002 10:03:54 -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 g0HI3q321875 for ; Thu, 17 Jan 2002 10:03:53 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA17965 for ; Thu, 17 Jan 2002 12:02:53 -0600 From: "Shannon J. Clark" To: Subject: RE: VCAR question Date: Thu, 17 Jan 2002 12:03:57 -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: <3C46FE4B.B26119EF@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, One reason might be that a "Move action" would really be "move from VAGENDA A to VAGENDA B" - so you would need to have a factorial number of actions assigned to you if you are to manage multiple VAGENDAs. i.e. in the case of VAGENDA "a" and "b" only two MOVE ACTIONS are required (Move from A to B - and Move from B to A) - note that they are not the same. but in the case of VAGENDA "a", "b", "c", "d", "f" ... "z" you would require 26! Move actions were you required to be able to move from each to each... this seems like a recipe for confusion and/or error. READ/WRITE/DELETE are far more general (and it could be argued whether DELETE is simply a limited sub-set of WRITE). Just an observation - apologies if I have missed something. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Thursday, January 17, 2002 10:40 AM To: ietf-calendar@imc.org Subject: Re: VCAR question Bernard Desruisseaux wrote: > The mapping between commands and ACTIONS is not 1:1. Well it used to be :-) > To be able to "move" a component from VAGENDA "a" to > VAGENDA "b", I should be granted > > "READ" ACTION from VAGENDA "a", > "WRITE" ACTION from VAGENDA "b", > "DELETE" ACTION from VAGENDA "a". Why not just have a MOVE ACTION? And then there is no mapping? From owner-ietf-calendar@mail.imc.org Thu Jan 17 13:20:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29066 for ; Thu, 17 Jan 2002 13:19:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HIB0J22211 for ietf-calendar-bks; Thu, 17 Jan 2002 10:11:00 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HIAw322206 for ; Thu, 17 Jan 2002 10:10:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA25100 for ; Thu, 17 Jan 2002 13:10:55 -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 g0HIAsQ29445 for ; Thu, 17 Jan 2002 13:10:54 -0500 (EST) Message-ID: <3C471405.170EFA39@steltor.com> Date: Thu, 17 Jan 2002 13:12:21 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCAR question References: <3C178F5F.1F85AF94@steltor.com> <3C17DBB4.9F9DF5CF@Royer.com> <3C17DF01.9166C3E@steltor.com> <3C17EE18.82517D1F@Royer.com> <3C2374F7.17093CD5@steltor.com> <3C435DE1.D7835285@steltor.com> <3C436764.39CA63F4@Royer.com> <3C46E808.3507AA1F@steltor.com> <3C46FE4B.B26119EF@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > The mapping between commands and ACTIONS is not 1:1. > > Well it used to be :-) > > > To be able to "move" a component from VAGENDA "a" to > > VAGENDA "b", I should be granted > > > > "READ" ACTION from VAGENDA "a", > > "WRITE" ACTION from VAGENDA "b", > > "DELETE" ACTION from VAGENDA "a". > > Why not just have a MOVE ACTION? Because to be allowed to move components from "a" to "b" you would need to have the ACTION MOVE granted in both "a" and "b", which would imply that you would also be allowed to move components from "b" to "a". But what if you only want to allow someone to move from "a" to "b" but not from "b" to "a"? Furthermore, it wouldn't make sense to have the ACTION MOVE granted in a VAGENDA but the ACTION DELETE denied. To delete a component I would simply have to move it into some other VAGENDA in which I'm granted the ACTION DELETE. 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 Jan 17 13:20:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29087 for ; Thu, 17 Jan 2002 13:20:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HI9Y422109 for ietf-calendar-bks; Thu, 17 Jan 2002 10:09:34 -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 g0HI9X322105 for ; Thu, 17 Jan 2002 10:09:33 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA17970; Thu, 17 Jan 2002 12:08:01 -0600 From: "Shannon J. Clark" To: "Bernard Desruisseaux" , Subject: RE: VCAR question Date: Thu, 17 Jan 2002 12:09:05 -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: <3C46E808.3507AA1F@steltor.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 Bernard, A question that I raised in a recent post - what is the difference between DELETE and WRITE i.e. is DELETE simply a limited sub-set of WRITE? - different security schemes consider the act of "negative" writing - i.e. deleting as being included or not in having "write" permissions (in Unix if you have write to a file or directory you can delete the file. So should all instances of "if only you have DELETE" be replaced with "if only you have DELETE or WRITE permissions to the target"? Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Bernard Desruisseaux Sent: Thursday, January 17, 2002 9:05 AM To: ietf-calendar@imc.org Subject: Re: VCAR question Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > I would like to close this issue by proposing some changes to the > > text that was put back in the last interim draft which is available > > at the following URL: http://www.calsch.org/ietf/drafts.html. > > > > IS (Section 11.2, RIGHTS Value Type): > > > > > act-type = ("CREATE" / "MODIFY" / "DELETE" / "READ" / all) > > > > > ... > > > > > 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". > > > > PROPOSAL: > > > > act-type = ("WRITE" / "MODIFY" / "DELETE" / "READ" / all) > > > > ... > > > > The ACTION rule part defines one or more CAP actions that are allowed > > for the UPN. The valid values are WRITE, DELETE, MODIFY, READ, and > > '*', meaning all actions. 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 "WRITE,MODIFY,DELETE,READ". > > > > In brief, the iTIP METHODs as well as MOVE are no longer listed > > as valid ACTIONs in the text (they never were in the ABNF). The > > ACTION CREATE was renamed to WRITE to reduce confusion, which is > > consistent with the READ ACTION. > > The ACTIONS applies to the commands, when the commands were > renamed the ACTIONS were not - thus some of the confusion. > So you could grant or deny commands to a UPN. > > The METHOD: (or any other identifiable object) > was specified with: > > ...OBJECT=METHOD;VALUE=;... > > I would like the ACTION values to be exactly the same as > the commands as they were before these changes. And I don't > care what their name is as long as they are the same, otherwise > what are they? > > AND that would mean that act-type would be expanded to > mean ALL actions a CUA could take (as in ALL commands). The mapping between commands and ACTIONS is not 1:1. To be able to "move" a component from VAGENDA "a" to VAGENDA "b", I should be granted "READ" ACTION from VAGENDA "a", "WRITE" ACTION from VAGENDA "b", "DELETE" ACTION from VAGENDA "a". That is, all the actions that needs to happen whenever a "move" command is executed. > > > The following table shows my understanding of the relationship > > between the commands and the ACTIONs. > > > > +----------+--------+---------------+ > > | Command | Target | Source | > > +----------+--------+---------------+ > > | create | WRITE | n/a | > > | delete | n/a | DELETE | > > | modify | n/a | MODIFY | > > | move | WRITE | READ + DELETE | > > | search | n/a | READ | > > | schedule | WRITE | n/a | > > +----------+--------+---------------+ > > Sorry, I don't understand the table at all. Here's how this table was meant to be read: You can execute the command "create" only if you have the "WRITE" ACTION granted in the specified target. You can execute the command "delete" only if you have the "DELETE" ACTION granted in the specified source. You can execute the command "modify" only if you have the "MODIFY" ACTION granted in the specified source. You can execute the command "move" only if you have the "WRITE" ACTION granted in the specified target and the "READ" and "DELETE" ACTIONs granted in the specified source. You can execute the command "search" only if you have the "READ" ACTION granted in the specified source. You can execute the command "schedule" only if you have the "WRITE" ACTION granted in the specified target. 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 Jan 17 13:43:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29829 for ; Thu, 17 Jan 2002 13:43:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HIXSP23030 for ietf-calendar-bks; Thu, 17 Jan 2002 10:33: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 g0HIXR323025 for ; Thu, 17 Jan 2002 10:33: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 NAA25872 for ; Thu, 17 Jan 2002 13:33:27 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0HIXRQ01506 for ; Thu, 17 Jan 2002 13:33:27 -0500 (EST) Message-ID: <3C47194D.E30B2787@steltor.com> Date: Thu, 17 Jan 2002 13:34:53 -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 "Shannon J. Clark" wrote: > > Bernard, > > A question that I raised in a recent post - what is the difference between > > DELETE > > and > > WRITE I might want to grant you the right to DELETE components for which you are the OWNER, but not necessarily grant you the right to WRITE new components. > > i.e. is DELETE simply a limited sub-set of WRITE? - different security > schemes consider the act of "negative" writing - i.e. deleting as being > included or not in having "write" permissions (in Unix if you have write to > a file or directory you can delete the file. > > So should all instances of "if only you have DELETE" be replaced with "if > only you have DELETE or WRITE permissions to the target"? > > Shannon 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 Jan 17 14:24:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01249 for ; Thu, 17 Jan 2002 14:24:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJB5U24209 for ietf-calendar-bks; Thu, 17 Jan 2002 11:11:05 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJB4324205 for ; Thu, 17 Jan 2002 11:11:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA17494 for ; Thu, 17 Jan 2002 11:11:04 -0800 (PST) Message-ID: <3C4721C3.D166648F@Royer.com> Date: Thu, 17 Jan 2002 12:10:59 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 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> <3C238743.61387D6F@Royer.com> <3C433424.8CF1A158@steltor.com> <3C43521D.1FE2E412@Royer.com> <3C47007C.C458C824@steltor.com> Content-Type: multipart/mixed; boundary="------------FB913DF1C64C47B3F1682738" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FB913DF1C64C47B3F1682738 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > ...I think that the only UPN that MUST BE able to fetch all > > of the VCARs is the OWNER. Everyone else only sees what > > they are allowed to see - as it applied to them at the > > time they ask. > > > > I can't find the definition of the predefined VCARs anymore. > > WOULD SOMEONE PLEASE PUT THEM BACK INTO CAP? This would clear > > up a lot of debate. I just noticed that they have been removed. > > That is probably why we are having this debate. > > I'm not sure these definitions were ever in the draft itself. > As far as I know, VCAR were first proposed as VACL (vehicle?) > > http://www.imc.org/ietf-calendar/archive1/msg02819.html > > and then reviewed and renamed to VCAR (car!) > > http://www.imc.org/ietf-calendar/archive1/msg02880.html > > Then a modified version of this text appeared in > "Proposed Changes To iCalendar Needed For CAP". > > http://calsch.org/ietf/iCal-updates.html > > Finally, on January 3rd 2002, George put the text in > the latest interim versions of the draft. > > http://www.calsch.org/ietf/drafts.html > > As you'll noticed the text is still "half baked" and > needs some work. Yes - I just repeated Bruce's argument (to George) that they have their name changed a bit. I am working with 'some' version of 06, but as they have the same name, I don't know which one. > > > > They exist because this WG felt that CUA's need to be able to > > find out if they can do basic things without having to perform > > a SELECT * FROM VCAR each time they connected and compute the > > results. They existed so that they could dynamically just find > > out how any of the pre-defined VCARs applied to the currently > > authenticated UPN. - exactly what you are asking for is the > > reason the predefined VCARs exist. > > My point is that since VCARs are coalesced it will be hard > to manage them. Yes - I like your EXPAND idea - I think it needs some more restrictions for security reasons. > I propose we use the EXPAND property (or a new property with > a more appropriate name) of the VQUERY component to specify > whether we want the VCARs returned by the search command to > be coalesced or not. Great idea - but only to OWNER. > By specifying EXPAND:TRUE in the VQUERY you would get the > coalesced VCAR, by default you would get the VCAR exactly > as they are stored in the CS. Only for OWNER. Otherwise I can pick apart you security by guessing at things. As in I do not want NON-OWNERS to know what the 'raw' VCARs are. So could you agree to: When performing a VQUERY on VCARs, for security reasons non-OWNERs only get the coalesced VCARs. That would mean that OWNERs might want to use EXPAND:TRUE when acting as any CU using a calendar. And MUST use EXPAND:FALSE when managing the VCARs. And it adds the requirement that a CS MUST store the raw VCARs and be able to reply with both raw and coalesced VCARs. The default for EXPAND is FALSE. -Doug --------------FB913DF1C64C47B3F1682738 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 17 Jan 2002 14:26:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJCvX24266 for ietf-calendar-bks; Thu, 17 Jan 2002 11:12:57 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJCu324262 for ; Thu, 17 Jan 2002 11:12: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 LAA17498 for ; Thu, 17 Jan 2002 11:12:56 -0800 (PST) Message-ID: <3C472234.E764CDD5@Royer.com> Date: Thu, 17 Jan 2002 12:12:52 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 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> <3C238743.61387D6F@Royer.com> <3C433424.8CF1A158@steltor.com> <3C43521D.1FE2E412@Royer.com> <3C47007C.C458C824@steltor.com> Content-Type: multipart/mixed; boundary="------------503CE3DDC639E26AC919591E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------503CE3DDC639E26AC919591E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ( I broke your reply into 2 separate messages) Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > I agree that we should allow multiple NAME properties, > > > but I would leave it to the CUA to decide what to do > > > when the NAME property is not specified. > > > > > > > (or if I understand you below, > > > > if it is a CUA property only - it is out of scope for > > > > CAP). > > > > > > The NAME property would be stored in the CS. Other than that > > > it wouldn't impact CAP any more than, say, the LOCATION property > > > of VEVENT! :-) > > > > > > > > > > > > 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? > > > > > > No. I propose we get rid of the property CARID. > > > And since the UID property is meant to uniquely > > > identify components, ... > > > > The assumption is that if you have UID=1, that knowing > > that tells you that the contents are consistent in the > > world, and that those consistent contents are tied 1:1 > > to the NAME? - That's just not true. > > > > > .. I propose that we store the > > > CAR-MIN predefined names in the NAME property. > > > > If we go with that (UID): > > > > Are you saying that if I change the contents of a VCAR and you > > have specified a UID, that I have to > > COUNTER/DECLINE-COUNTER/REQUEST+new-SEQUENCE > > in order for our VCAR's to be in sync? > > > > If no, how do you propose to keep the UID's uniquely > > defining the contents when we are free to change the contents? > > What is different from VEVENT? To my knowledge, there is > nothing that prevents me from modifying a VEVENT stored in > one of my VAGENDA without telling anyone. VEVENTs with > the same UID are not guaranteed to be identical. They are identical! That is a definition of them. Without them being identical it breaks iTIP - and badly. So each time the ORGANIZER pushes a new copy (SEQUENCE incremented) and changes something - it blows away your copy? I hope you are not doing that! I hope you meant 'what if'. Nothing can keep you from doing it, but that breaks iTIP. And I agree it is the same issue as far as UID goes, which is why I don't what it to be UID :-) I'll call "non-local" object changes anyting that changes any data from what was sent by the ORGANIZER in a way that any CUA can not distiguish it from the original without asking the ORGANIZER. Maybe we need to say that in CAP? If you tweak with "non-local" objects where you are not the ORGANIZER, you MUST change the UID? Otherwise we have an unmanageable mess. Which is why I made the proposal on how to update components and tag those changes as local - and NOT to propagate them to non-OWNERs. So that you can have local alarms and tag ORGANIZER alarms as not-enabled and do these things. Because if you just tweak with the objects, and there is no standard way to tweak with those object, UID:unique-id means NOTHING at all and is all I would have to do to blow away all your changes is send an updated object. > > > > Are you specifying that if I change a VCAR that I got from you that > > I MUST change the UID if I change the contents? > > > > If yes - then you are specifying that the ID of a VCAR > > is local to the CS only. > > > > If yes - then why would they have to be "globally" unique IDs? > > > > If no - I can't change the contents of a globally identified > > object without it being updated from the OWNER. And that > > would mean that any VCAR you send is in effect a decreed > > VCAR with in it scope. > > I wouldn't be allowed to add a VALARM in my own copy of a > VEVENT? Not currently without breaking iTIP, that is why I made the proposal. --------------503CE3DDC639E26AC919591E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 17 Jan 2002 15:18:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HK5TA25643 for ietf-calendar-bks; Thu, 17 Jan 2002 12: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 g0HK5R325639 for ; Thu, 17 Jan 2002 12: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 PAA28219 for ; Thu, 17 Jan 2002 15:05:24 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0HK5OQ09170 for ; Thu, 17 Jan 2002 15:05:24 -0500 (EST) Message-ID: <3C472EDA.3B1759D0@steltor.com> Date: Thu, 17 Jan 2002 15:06:50 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCAR: CARID Property References: <3BFAD13A.4AF1B800@steltor.com> <3BFC3CC5.35DA5A2E@Royer.com> <3BFD1911.C0FF7D79@steltor.com> <3BFEBEE2.2F736E3D@Royer.com> <3C221F20.D92B2355@steltor.com> <3C238743.61387D6F@Royer.com> <3C433424.8CF1A158@steltor.com> <3C43521D.1FE2E412@Royer.com> <3C47007C.C458C824@steltor.com> <3C4721C3.D166648F@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: > > > My point is that since VCARs are coalesced it will be hard > > to manage them. > > Yes - I like your EXPAND idea - I think it needs some more > restrictions for security reasons. > > > I propose we use the EXPAND property (or a new property with > > a more appropriate name) of the VQUERY component to specify > > whether we want the VCARs returned by the search command to > > be coalesced or not. > > Great idea - but only to OWNER. > > > By specifying EXPAND:TRUE in the VQUERY you would get the > > coalesced VCAR, by default you would get the VCAR exactly > > as they are stored in the CS. > > Only for OWNER. Otherwise I can pick apart you security > by guessing at things. As in I do not want NON-OWNERS to > know what the 'raw' VCARs are. > > So could you agree to: > > When performing a VQUERY on VCARs, for security reasons > non-OWNERs only get the coalesced VCARs. I agree as a MAY. > > That would mean that OWNERs might want to use EXPAND:TRUE > when acting as any CU using a calendar. And MUST use EXPAND:FALSE > when managing the VCARs. > > And it adds the requirement that a CS MUST store the raw > VCARs and be able to reply with both raw and coalesced VCARs. > > The default for EXPAND is FALSE. I agree, but I really think we should come up with a better property name than EXPAND. Specifying EXPAND:TRUE to get coalesced VCARs sounds strange to me! How about COALESCE? :-) 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 Jan 17 17:47:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14822 for ; Thu, 17 Jan 2002 17:47:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HMRYE29248 for ietf-calendar-bks; Thu, 17 Jan 2002 14:27:34 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HMRX329243 for ; Thu, 17 Jan 2002 14:27:33 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA17766 for ; Thu, 17 Jan 2002 14:27:35 -0800 (PST) Message-ID: <3C474FD0.5130587A@Royer.com> Date: Thu, 17 Jan 2002 15:27:28 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 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> <3C238743.61387D6F@Royer.com> <3C433424.8CF1A158@steltor.com> <3C43521D.1FE2E412@Royer.com> <3C47007C.C458C824@steltor.com> <3C4721C3.D166648F@Royer.com> <3C472EDA.3B1759D0@steltor.com> Content-Type: multipart/mixed; boundary="------------47719238FFBC0E30434351DE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------47719238FFBC0E30434351DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > My point is that since VCARs are coalesced it will be hard > > > to manage them. > > > > Yes - I like your EXPAND idea - I think it needs some more > > restrictions for security reasons. > > > > > I propose we use the EXPAND property (or a new property with > > > a more appropriate name) of the VQUERY component to specify > > > whether we want the VCARs returned by the search command to > > > be coalesced or not. > > > > Great idea - but only to OWNER. > > > > > By specifying EXPAND:TRUE in the VQUERY you would get the > > > coalesced VCAR, by default you would get the VCAR exactly > > > as they are stored in the CS. > > > > Only for OWNER. Otherwise I can pick apart you security > > by guessing at things. As in I do not want NON-OWNERS to > > know what the 'raw' VCARs are. > > > > So could you agree to: > > > > When performing a VQUERY on VCARs, for security reasons > > non-OWNERs only get the coalesced VCARs. > > I agree as a MAY. > > > > > That would mean that OWNERs might want to use EXPAND:TRUE > > when acting as any CU using a calendar. And MUST use EXPAND:FALSE > > when managing the VCARs. > > > > And it adds the requirement that a CS MUST store the raw > > VCARs and be able to reply with both raw and coalesced VCARs. > > > > The default for EXPAND is FALSE. > > I agree, but I really think we should come up with > a better property name than EXPAND. Specifying > EXPAND:TRUE to get coalesced VCARs sounds strange > to me! How about COALESCE? :-) COALESCE sounds good to me. --------------47719238FFBC0E30434351DE Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 18 Jan 2002 09:29:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IEBo824999 for ietf-calendar-bks; Fri, 18 Jan 2002 06:11:50 -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 g0IEBm324990 for ; Fri, 18 Jan 2002 06:11:48 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA04899 for ; Fri, 18 Jan 2002 09:11:44 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IEBgQ03976 for ; Fri, 18 Jan 2002 09:11:43 -0500 (EST) Message-Id: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Jan 2002 09:08:34 -0500 To: ietf-calendar@imc.org From: Mark Paterson Subject: Fwd: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need Volunteers!] Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe:
For some  reason this didn't seem to ever show up on the list. Take II.

Date: Thu, 17 Jan 2002 13:04:03 -0500
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
From: Mark Paterson <markp@steltor.com>
Subject: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need  Volunteers!]

At 02:11 PM 1/16/2002 -0500, George Babics wrote:


Doug Royer wrote:
>
> > >
> > > > 5) Synchronization:
> > > > -------------------
> > > >
> > > >   Investigate if there is enough in CAP to allow for synchronization?
> > > >  I believe this is in the requirements doc.
> > >
> > > It is. I think it does meet the synchronization requirements.
> > > And we limited synchronization to a bare minimum. That is
> > > that you must be able to upload and download an entire calendar
> > > and what ever it takes to make two calendars look the same.
> >
> >   Have we gone through the exercise of making sure that we
> > support synchronization? If we limit support to a bare minimum
> > can it hurt performance of synchronization?
> >
> >   A CUA is able to query on the last modified LAST-MODIFIED
> > property to find all the components that have changed the last
> > time a sync was done. Using the METHOD:DELETE it can find all
> > components that have been deleted. Is this sufficient?
> >
> >   Should we add a small section or sub-section on CAP
> > describing how synchronization can be done?
>
> I think that we had agreed that this was an implementation
> specific thing for now. At the very least we specified that
> a CUA must be able to upload an entire calendar and do the
> diff work it self.
>
> No one has opposed a synchronization specification. I say we
> need one - AS A SEPARATE DRAFT. For now a CUA can get it done
> by uploading the entire calendar - or by guessing from any
> VQUERYs it can make.
>

  However, if there is something that we can easily add to
CAP that can help synchronization, we may want to add it. On the
other hand, what I described earlier, on how a CUA can have
basic synchronization, by using query on last modified time
and METHOD:DELETE, should be enough.

  Thus, if there are no objections, I will close the issue.

I think there are a few issues to consider before closing this.

The key paragraph from the CAP Requirements document is as follows:

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

In other words it must be possible for a sync engine (client, server, whatever) to be able to get the answers to the following three questions.

1) Within the given date range what entries are new?
2) Within the given date range what entries have changed?
3) Within the given date range what entries have been deleted?

Using a query on last modified time with a date range should allow you to gain answers to 1) and 2). The sync engine just needs to keep track of the time stamp from the last time they asked. Most sync solutions today have a sync context or anchor (or some other fancy name) but when dive in you'll find they all pretty much are just exactly that, the time stamp from the last successful sync. The sync engine need merely enumerate through the results and all the IDs it recognizes are changes and all the ones it doesn't are new.

The only problem I can foresee has to do with instances of recurring entries. If I change the time of an instance of a meeting or delete an instance this will change the recurrence rule for this entry and consequently the last modified time but if I am doing a query over a specific time period  the first instance of the repeating may not be in this time period so will I get it? What does DTSTART and DTEND mean in this case? I think this is a basic problem that the people discussing the CAP-QL need to address. If I am trying to get all the entries in a week to populate a week view for example, I need some guarantee that I will get the entries with recurrence rules that cause instances to fall within my range. If the CAP-QL addresses this then I guess the issue for sync will be taken care of as well.

Now we get to question 3). You suggest that we query for the method DELETE within a date range. Combined with the last modified time I'll get all the newly marked DELETE entries since the last time I sync'd. This all seems great but is assumes that all CUAs will use a MODIFY command with the DELETE method. The problem is that there is also a command (CANCEL or is it DELETE??) that can wipe out an entry completely. If one CUA does it one way and another the other then how can the sync engine be sure that it is really being told about everything that has been deleted? You don't want the sync engine having to query for ever entry ID it knows about to see if it still there. Is there some guarantee that CAP compliant CUAs will use the MODIFY command?

One last issue with deletes has to do with recurring entries. If I delete an instance then there is now an exception in my rule that would keep an instance from falling within my interested range. Even if the above failing of CAP-QL is resolved I may not be able to get this? Is there a way to query using a range and the last modified time combined with a search for an EXDATE?


George

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


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



 From owner-ietf-calendar@mail.imc.org Fri Jan 18 11:58:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18664 for ; Fri, 18 Jan 2002 11:58:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IGfAI28152 for ietf-calendar-bks; Fri, 18 Jan 2002 08:41:10 -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 g0IGf7328148 for ; Fri, 18 Jan 2002 08:41:08 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id KAA19026; Fri, 18 Jan 2002 10:38:37 -0600 From: "Shannon J. Clark" To: "Mark Paterson" , Subject: RE: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need Volunteers!] Date: Fri, 18 Jan 2002 10:40:35 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C1A00C.8FC83940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.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: This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C1A00C.8FC83940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just a few comments: 1 - in looking at Sync it is probably very valuable to look at the work of the SyncML Consortium - it includes most of the software companies building products that require sync functionality and they have resolved many of these issues. 2 - generally the best practice is NOT for the server (or sync engine) to track the "last sync" - this does not scale very gracefully. Rather the client application should send a request of the format "I'm current as of THISDATE - what does it take to make me current?" - note that the actions and issues are different in a SERVER --> CLIENT sync vs. a SERVER <--> CLIENT two-way sync. - in the later case there is the real possibility that the client is more current than the server. 3 - thus for clean sync functionality a Calendar server should be able to answer the following question(s): A. What has changed since DATE? (in the context of a given user and specific VCALENDAR (or VAGENDA?) Changed includes - NEW entries, MODIFIED entries, DELETED entries - all have been "written" - if you look at "DELETE" as a special case of "writing" - and if you are using TOMBSTONE it is. B (optional?) What is "different" between CUA's copy of a VCALENDAR and CS's copy. Hope this helps, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Mark Paterson Sent: Friday, January 18, 2002 8:09 AM To: ietf-calendar@imc.org Subject: Fwd: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need Volunteers!] For some reason this didn't seem to ever show up on the list. Take II. Date: Thu, 17 Jan 2002 13:04:03 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need Volunteers!] At 02:11 PM 1/16/2002 -0500, George Babics wrote: Doug Royer wrote: > > > > > > > > 5) Synchronization: > > > > ------------------- > > > > > > > > Investigate if there is enough in CAP to allow for synchronization? > > > > I believe this is in the requirements doc. > > > > > > It is. I think it does meet the synchronization requirements. > > > And we limited synchronization to a bare minimum. That is > > > that you must be able to upload and download an entire calendar > > > and what ever it takes to make two calendars look the same. > > > > Have we gone through the exercise of making sure that we > > support synchronization? If we limit support to a bare minimum > > can it hurt performance of synchronization? > > > > A CUA is able to query on the last modified LAST-MODIFIED > > property to find all the components that have changed the last > > time a sync was done. Using the METHOD:DELETE it can find all > > components that have been deleted. Is this sufficient? > > > > Should we add a small section or sub-section on CAP > > describing how synchronization can be done? > > I think that we had agreed that this was an implementation > specific thing for now. At the very least we specified that > a CUA must be able to upload an entire calendar and do the > diff work it self. > > No one has opposed a synchronization specification. I say we > need one - AS A SEPARATE DRAFT. For now a CUA can get it done > by uploading the entire calendar - or by guessing from any > VQUERYs it can make. > However, if there is something that we can easily add to CAP that can help synchronization, we may want to add it. On the other hand, what I described earlier, on how a CUA can have basic synchronization, by using query on last modified time and METHOD:DELETE, should be enough. Thus, if there are no objections, I will close the issue. I think there are a few issues to consider before closing this. The key paragraph from the CAP Requirements document is as follows: "CAP MUST allow synchronization, meaning at a minimum that the CUA is able to find and retrieve new, modified or deleted entries for a given time period. The CUA MUST be able to find out which entries have been added, modified or deleted since it last synchronized, in order to operate in disconnected mode. This requirement may be satisfied using the query requirements already defined." In other words it must be possible for a sync engine (client, server, whatever) to be able to get the answers to the following three questions. 1) Within the given date range what entries are new? 2) Within the given date range what entries have changed? 3) Within the given date range what entries have been deleted? Using a query on last modified time with a date range should allow you to gain answers to 1) and 2). The sync engine just needs to keep track of the time stamp from the last time they asked. Most sync solutions today have a sync context or anchor (or some other fancy name) but when dive in you'll find they all pretty much are just exactly that, the time stamp from the last successful sync. The sync engine need merely enumerate through the results and all the IDs it recognizes are changes and all the ones it doesn't are new. The only problem I can foresee has to do with instances of recurring entries. If I change the time of an instance of a meeting or delete an instance this will change the recurrence rule for this entry and consequently the last modified time but if I am doing a query over a specific time period the first instance of the repeating may not be in this time period so will I get it? What does DTSTART and DTEND mean in this case? I think this is a basic problem that the people discussing the CAP-QL need to address. If I am trying to get all the entries in a week to populate a week view for example, I need some guarantee that I will get the entries with recurrence rules that cause instances to fall within my range. If the CAP-QL addresses this then I guess the issue for sync will be taken care of as well. Now we get to question 3). You suggest that we query for the method DELETE within a date range. Combined with the last modified time I'll get all the newly marked DELETE entries since the last time I sync'd. This all seems great but is assumes that all CUAs will use a MODIFY command with the DELETE method. The problem is that there is also a command (CANCEL or is it DELETE??) that can wipe out an entry completely. If one CUA does it one way and another the other then how can the sync engine be sure that it is really being told about everything that has been deleted? You don't want the sync engine having to query for ever entry ID it knows about to see if it still there. Is there some guarantee that CAP compliant CUAs will use the MODIFY command? One last issue with deletes has to do with recurring entries. If I delete an instance then there is now an exception in my rule that would keep an instance from falling within my interested range. Even if the above failing of CAP-QL is resolved I may not be able to get this? Is there a way to query using a range and the last modified time combined with a search for an EXDATE? George -- Mark Paterson Director, Client R&D Steltor mailto:markp@steltor.com http://www.steltor.com -- Mark Paterson Director, Client R&D Steltor mailto:markp@steltor.com http://www.steltor.com ------=_NextPart_000_0001_01C1A00C.8FC83940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just a = few=20 comments:
 
1 - in = looking at=20 Sync it is probably very valuable to look at the work of the SyncML = Consortium -=20 it includes most of the software companies building products that = require sync=20 functionality and they have resolved many of these = issues.
 
2 - = generally the=20 best practice is NOT for the server (or sync engine) to track the "last = sync" -=20 this does not scale very gracefully. Rather the client application = should send a=20 request of the format "I'm current as of THISDATE - what does it take to = make me=20 current?" - note that the actions and issues are different in a SERVER = -->=20 CLIENT sync vs. a SERVER <--> CLIENT two-way sync. - in the later = case=20 there is the real possibility that the client is more current than the=20 server.
 
3 - = thus for clean=20 sync functionality a Calendar server should be able to answer the = following=20 question(s):
 
   =20 A. What has changed since DATE? (in the context of a given user and = specific=20 VCALENDAR (or VAGENDA?)
 
        = Changed=20 includes - NEW entries, MODIFIED entries, DELETED entries - all have = been=20 "written" - if you look at "DELETE" as a special case of "writing" - and = if you=20 are using TOMBSTONE it is.
 
    B=20 (optional?) What is "different" between CUA's copy of a VCALENDAR and = CS's=20 copy.
 
Hope = this=20 helps,
 
Shannon
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Mark=20 Paterson
Sent: Friday, January 18, 2002 8:09 = AM
To:=20 ietf-calendar@imc.org
Subject: Fwd: Re: Synchronization = [Was: Re:=20 CAP: Last Call By March IETF: Need = Volunteers!]


For=20 some  reason this didn't seem to ever show up on the list. Take=20 II.

Date: Thu, 17 Jan 2002 = 13:04:03=20 -0500
To: "ietf-calendar@imc.org" = <ietf-calendar@imc.org>
From:=20 Mark Paterson <markp@steltor.com>
Subject: Re: = Synchronization=20 [Was: Re: CAP: Last Call By March IETF: Need  = Volunteers!]

At=20 02:11 PM 1/16/2002 -0500, George Babics wrote:


Doug Royer = wrote:
>
>=20 > >
> > > > 5) Synchronization:
> > = >=20 > -------------------
> > > >
> > >=20 >   Investigate if there is enough in CAP to allow = for=20 synchronization?
> > > >  I believe this is in = the=20 requirements doc.
> > >
> > > It is. I = think it=20 does meet the synchronization requirements.
> > > And = we=20 limited synchronization to a bare minimum. That is
> > = > that=20 you must be able to upload and download an entire calendar
> = >=20 > and what ever it takes to make two calendars look the = same.
>=20 >
> >   Have we gone through the exercise of = making=20 sure that we
> > support synchronization? If we limit = support to=20 a bare minimum
> > can it hurt performance of=20 synchronization?
> >
> >   A CUA is = able to=20 query on the last modified LAST-MODIFIED
> > property to = find all=20 the components that have changed the last
> > time a sync = was=20 done. Using the METHOD:DELETE it can find all
> > = components that=20 have been deleted. Is this sufficient?
> >
>=20 >   Should we add a small section or sub-section on=20 CAP
> > describing how synchronization can be = done?
>=20
> I think that we had agreed that this was an=20 implementation
> specific thing for now. At the very least = we=20 specified that
> a CUA must be able to upload an entire = calendar and=20 do the
> diff work it self.
>
> No one has = opposed a=20 synchronization specification. I say we
> need one - AS A = SEPARATE=20 DRAFT. For now a CUA can get it done
> by uploading the = entire=20 calendar - or by guessing from any
> VQUERYs it can = make.
>=20

  However, if there is something that we can easily = add=20 to
CAP that can help synchronization, we may want to add it. On = the
other hand, what I described earlier, on how a CUA can=20 have
basic synchronization, by using query on last modified = time
and=20 METHOD:DELETE, should be enough.

  Thus, if there are = no=20 objections, I will close the issue.

I think there = are a few=20 issues to consider before closing this.

The key paragraph = from the=20 CAP Requirements document is as follows:

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

In other words it must be possible for a sync = engine=20 (client, server, whatever) to be able to get the answers to the = following=20 three questions.

1) Within the given date range what entries = are=20 new?
2) Within the given date range what entries have = changed?
3)=20 Within the given date range what entries have been = deleted?

Using a=20 query on last modified time with a date range should allow you to = gain=20 answers to 1) and 2). The sync engine just needs to keep track of = the time=20 stamp from the last time they asked. Most sync solutions today have = a sync=20 context or anchor (or some other fancy name) but when dive in you'll = find=20 they all pretty much are just exactly that, the time stamp from the = last=20 successful sync. The sync engine need merely enumerate through the = results=20 and all the IDs it recognizes are changes and all the ones it = doesn't are=20 new.

The only problem I can foresee has to do with instances = of=20 recurring entries. If I change the time of an instance of a meeting = or=20 delete an instance this will change the recurrence rule for this = entry and=20 consequently the last modified time but if I am doing a query over a = specific time period  the first instance of the repeating may = not be in=20 this time period so will I get it? What does DTSTART and DTEND mean = in this=20 case? I think this is a basic problem that the people discussing the = CAP-QL=20 need to address. If I am trying to get all the entries in a week to = populate=20 a week view for example, I need some guarantee that I will get the = entries=20 with recurrence rules that cause instances to fall within my range. = If the=20 CAP-QL addresses this then I guess the issue for sync will be taken = care of=20 as well.

Now we get to question 3). You suggest that we query = for the=20 method DELETE within a date range. Combined with the last modified = time I'll=20 get all the newly marked DELETE entries since the last time I = sync'd. This=20 all seems great but is assumes that all CUAs will use a MODIFY = command with=20 the DELETE method. The problem is that there is also a command = (CANCEL or is=20 it DELETE??) that can wipe out an entry completely. If one CUA does = it one=20 way and another the other then how can the sync engine be sure that = it is=20 really being told about everything that has been deleted? You don't = want the=20 sync engine having to query for ever entry ID it knows about to see = if it=20 still there. Is there some guarantee that CAP compliant CUAs will = use the=20 MODIFY command?

One last issue with deletes has to do with = recurring=20 entries. If I delete an instance then there is now an exception in = my rule=20 that would keep an instance from falling within my interested range. = Even if=20 the above failing of CAP-QL is resolved I may not be able to get = this? Is=20 there a way to query using a range and the last modified time = combined with=20 a search for an EXDATE?


George

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

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



<= /P>

------=_NextPart_000_0001_01C1A00C.8FC83940-- From owner-ietf-calendar@mail.imc.org Fri Jan 18 12:30:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19832 for ; Fri, 18 Jan 2002 12:30:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IH9MX28942 for ietf-calendar-bks; Fri, 18 Jan 2002 09:09:22 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IH9K328938 for ; Fri, 18 Jan 2002 09:09:20 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA09606; Fri, 18 Jan 2002 12:09:13 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IH9CQ18409; Fri, 18 Jan 2002 12:09:13 -0500 (EST) Message-Id: <5.1.0.14.0.20020118114738.00aea840@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Jan 2002 12:06:04 -0500 To: "Shannon J. Clark" , From: Mark Paterson Subject: RE: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need Volunteers!] In-Reply-To: References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:40 AM 1/18/2002 -0600, Shannon J. Clark wrote:
Just a few comments:
 
1 - in looking at Sync it is probably very valuable to look at the work of the SyncML Consortium - it includes most of the software companies building products that require sync functionality and they have resolved many of these issues.

I am quite familiar with the SyncML specs and yes they have solved lots of Sync Issues but none of these are of any consequence to this group. To do a sync, whether it is with SyncML or not, you need to be able to get the answers to the 3 questions I listed. We simply need to resolve whether or not we feel the CAP draft lives up to the sync requirements listed within the CAP requirements document. I brought a couple of things that worry me in the hopes that the gang who know the CAP draft off by heart (George, Doug, John, etc...) will reply and convince me that my worries are covered, in which case the issue can be considered closed.

 
2 - generally the best practice is NOT for the server (or sync engine) to track the "last sync" - this does not scale very gracefully. Rather the client application should send a request of the format "I'm current as of THISDATE - what does it take to make me current?" - note that the actions and issues are different in a SERVER --> CLIENT sync vs. a SERVER <--> CLIENT two-way sync. - in the later case there is the real possibility that the client is more current than the server.

I used the term "sync engine" to mean where ever the sync smarts are located. It could be in a client or on a server. It is implementation specific. Using the SyncML model it would be on the server. SyncML also has a "Sync Anchor" and yes using the SyncML model the SyncML client is responsible for saving it.

However none of this matters to this group. It is out of scope.

 
3 - thus for clean sync functionality a Calendar server should be able to answer the following question(s):
 
    A. What has changed since DATE? (in the context of a given user and specific VCALENDAR (or VAGENDA?)
 
        Changed includes - NEW entries, MODIFIED entries, DELETED entries - all have been "written" - if you look at "DELETE" as a special case of "writing" - and if you are using TOMBSTONE it is.

Your A is simply my 3 questions rolled into one.

 
    B (optional?) What is "different" between CUA's copy of a VCALENDAR and CS's copy.

You can always do a sync this way. Download a users whole agenda and compare it yourself against what you have and figure out the changes yourself. I wasn't around when the CAP requirements docs was first written but from what I've read I am certain they were striving for A since any sync solution based on your B approach is very slow and would be very demanding on the CS.

 
Hope this helps,
 
Shannon
-----Original Message-----
From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Mark Paterson
Sent: Friday, January 18, 2002 8:09 AM
To: ietf-calendar@imc.org
Subject: Fwd: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need Volunteers!]
For some  reason this didn't seem to ever show up on the list. Take II.

Date: Thu, 17 Jan 2002 13:04:03 -0500
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
From: Mark Paterson <markp@steltor.com>
Subject: Re: Synchronization [Was: Re: CAP: Last Call By March IETF: Need  Volunteers!]

At 02:11 PM 1/16/2002 -0500, George Babics wrote:



Doug Royer wrote:
>
> > >
> > > > 5) Synchronization:
> > > > -------------------
> > > >
> > > >   Investigate if there is enough in CAP to allow for synchronization?
> > > >  I believe this is in the requirements doc.
> > >
> > > It is. I think it does meet the synchronization requirements.
> > > And we limited synchronization to a bare minimum. That is
> > > that you must be able to upload and download an entire calendar
> > > and what ever it takes to make two calendars look the same.
> >
> >   Have we gone through the exercise of making sure that we
> > support synchronization? If we limit support to a bare minimum
> > can it hurt performance of synchronization?
> >
> >   A CUA is able to query on the last modified LAST-MODIFIED
> > property to find all the components that have changed the last
> > time a sync was done. Using the METHOD:DELETE it can find all
> > components that have been deleted. Is this sufficient?
> >
> >   Should we add a small section or sub-section on CAP
> > describing how synchronization can be done?
>
> I think that we had agreed that this was an implementation
> specific thing for now. At the very least we specified that
> a CUA must be able to upload an entire calendar and do the
> diff work it self.
>
> No one has opposed a synchronization specification. I say we
> need one - AS A SEPARATE DRAFT. For now a CUA can get it done
> by uploading the entire calendar - or by guessing from any
> VQUERYs it can make.
>

  However, if there is something that we can easily add to
CAP that can help synchronization, we may want to add it. On the
other hand, what I described earlier, on how a CUA can have
basic synchronization, by using query on last modified time
and METHOD:DELETE, should be enough.

  Thus, if there are no objections, I will close the issue.
I think there are a few issues to consider before closing this.

The key paragraph from the CAP Requirements document is as follows:

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

In other words it must be possible for a sync engine (client, server, whatever) to be able to get the answers to the following three questions.

1) Within the given date range what entries are new?
2) Within the given date range what entries have changed?
3) Within the given date range what entries have been deleted?

Using a query on last modified time with a date range should allow you to gain answers to 1) and 2). The sync engine just needs to keep track of the time stamp from the last time they asked. Most sync solutions today have a sync context or anchor (or some other fancy name) but when dive in you'll find they all pretty much are just exactly that, the time stamp from the last successful sync. The sync engine need merely enumerate through the results and all the IDs it recognizes are changes and all the ones it doesn't are new.

The only problem I can foresee has to do with instances of recurring entries. If I change the time of an instance of a meeting or delete an instance this will change the recurrence rule for this entry and consequently the last modified time but if I am doing a query over a specific time period  the first instance of the repeating may not be in this time period so will I get it? What does DTSTART and DTEND mean in this case? I think this is a basic problem that the people discussing the CAP-QL need to address. If I am trying to get all the entries in a week to populate a week view for example, I need some guarantee that I will get the entries with recurrence rules that cause instances to fall within my range. If the CAP-QL addresses this then I guess the issue for sync will be taken care of as well.

Now we get to question 3). You suggest that we query for the method DELETE within a date range. Combined with the last modified time I'll get all the newly marked DELETE entries since the last time I sync'd. This all seems great but is assumes that all CUAs will use a MODIFY command with the DELETE method. The problem is that there is also a command (CANCEL or is it DELETE??) that can wipe out an entry completely. If one CUA does it one way and another the other then how can the sync engine be sure that it is really being told about everything that has been deleted? You don't want the sync engine having to query for ever entry ID it knows about to see if it still there. Is there some guarantee that CAP compliant CUAs will use the MODIFY command?

One last issue with deletes has to do with recurring entries. If I delete an instance then there is now an exception in my rule that would keep an instance from falling within my interested range. Even if the above failing of CAP-QL is resolved I may not be able to get this? Is there a way to query using a range and the last modified time combined with a search for an EXDATE?



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

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



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



 From owner-ietf-calendar@mail.imc.org Fri Jan 18 12:59:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21131 for ; Fri, 18 Jan 2002 12:59:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IHY0c29429 for ietf-calendar-bks; Fri, 18 Jan 2002 09:34:00 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IHXw329425 for ; Fri, 18 Jan 2002 09:33:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA19069 for ; Fri, 18 Jan 2002 09:33:58 -0800 (PST) Message-ID: <3C485C82.B998E02D@Royer.com> Date: Fri, 18 Jan 2002 10:33:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: Last Call By MarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------66B74DC8FDAA25BD579F595F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------66B74DC8FDAA25BD579F595F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > > >> > >> However, if there is something that we can easily add to > >> CAP that can help synchronization, we may want to add it. On the > >> other hand, what I described earlier, on how a CUA can have > >> basic synchronization, by using query on last modified time > >> and METHOD:DELETE, should be enough. > >> > >> Thus, if there are no objections, I will close the issue. > > > > > > I think there are a few issues to consider before closing this. > > > > The key paragraph from the CAP Requirements document is as follows: > > > > "CAP MUST allow synchronization, meaning at a minimum that the CUA > > is able to find and retrieve new, modified or deleted entries for a > > given time period. The CUA MUST be able to find out which entries > > have been added, modified or deleted since it last synchronized, in > > order to operate in disconnected mode. This requirement may be > > satisfied using the query requirements already defined." > > > > In other words it must be possible for a sync engine (client, > > server, whatever) to be able to get the answers to the following > > three questions. > > > > 1) Within the given date range what entries are new? > > 2) Within the given date range what entries have changed? > > 3) Within the given date range what entries have been deleted? > > > > Using a query on last modified time with a date range should allow > > you to gain answers to 1) and 2). The sync engine just needs to keep > > track of the time stamp from the last time they asked. Most sync > > solutions today have a sync context or anchor (or some other fancy > > name) but when dive in you'll find they all pretty much are just > > exactly that, the time stamp from the last successful sync. The sync > > engine need merely enumerate through the results and all the IDs it > > recognizes are changes and all the ones it doesn't are new. > > The only problem I can foresee has to do with instances of recurring > > entries. If I change the time of an instance of a meeting or delete > > an instance this will change the recurrence rule for this entry and > > consequently the last modified time but if I am doing a query over a > > specific time period the first instance of the repeating may not be > > in this time period so will I get it? Change the RRULE? If you add an EXDATE or EXRULE, it will change the VEVENT, but not the RRULE. Or if an instance at the beginning or end is deleted - then, yes - you could change the RRULE. Both will change the DTSTAMP. This is also why the EXPAND property exists. EXPAND:FALSE - yes, because it is part of the VEVENT and part of the VEVENT falls within that range. EXPAND:TRUE - no, you will only get the instances of that VEVENT that fall in that range. > > What does DTSTART and DTEND > > mean in this case? I think this is a basic problem that the people > > discussing the CAP-QL need to address. If I am trying to get all the > > entries in a week to populate a week view for example, I need some > > guarantee that I will get the entries with recurrence rules that > > cause instances to fall within my range. If the CAP-QL addresses > > this then I guess the issue for sync will be taken care of as well. I think it does with RRULE. > > ...What does DTSTART and DTEND > > mean in this case?... I do think that we need to add another note to VQUERY, this point was brought up before, I don't recall if it was ever in any version of a draft. When performing VQUERYs that use DTEND, the CS MUST calculate: The effective DTEND for all components that have a DURATION property and match on those if they fall into the range supplied by DTEND. When performing VQUERYs that use DURATION, the CS MUST calculate: The effective DURATION for all components that have a DTEND property and match on those if they fall into the range supplied by DURATION. Above when you sent: > > In other words it must be possible for a sync engine (client, > > server, whatever) to be able to get the answers to the following > > three questions. > > > > ... > > > > 3) Within the given date range what entries have been deleted? It is possible for the CUA to calculate the differences given the current state of any component in the CUA and the result of a VQUERY to the CS. So I think the requirement is met. And we need to add text about METHOD:DELETE and how that is the way to mark somehting as deleted. --------------66B74DC8FDAA25BD579F595F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 18 Jan 2002 15:35:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IKGBb03090 for ietf-calendar-bks; Fri, 18 Jan 2002 12:16:11 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IKG9303086 for ; Fri, 18 Jan 2002 12:16:09 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA13937 for ; Fri, 18 Jan 2002 15:16:06 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IKG5Q02388 for ; Fri, 18 Jan 2002 15:16:05 -0500 (EST) Message-Id: <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Jan 2002 15:00:33 -0500 To: ietf-calendar@imc.org From: Mark Paterson Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: Last Call By MarchIETF: Need Volunteers!] In-Reply-To: <3C485C82.B998E02D@Royer.com> References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:33 AM 1/18/2002 -0700, you wrote:

Mark Paterson wrote:
>
> >>
> >>   However, if there is something that we can easily add to
> >> CAP that can help synchronization, we may want to add it. On the
> >> other hand, what I described earlier, on how a CUA can have
> >> basic synchronization, by using query on last modified time
> >> and METHOD:DELETE, should be enough.
> >>
> >>   Thus, if there are no objections, I will close the issue.
> >
> >
> > I think there are a few issues to consider before closing this.
> >
> > The key paragraph from the CAP Requirements document is as follows:
> >
> > "CAP MUST allow synchronization, meaning at a minimum that the CUA
> > is able to find and retrieve new, modified or deleted entries for a
> > given time period. The CUA MUST be able to find out which entries
> > have been added, modified or deleted since it last synchronized, in
> > order to operate in disconnected mode. This requirement may be
> > satisfied using the query requirements already defined."
> >
> > In other words it must be possible for a sync engine (client,
> > server, whatever) to be able to get the answers to the following
> > three questions.
> >
> > 1) Within the given date range what entries are new?
> > 2) Within the given date range what entries have changed?
> > 3) Within the given date range what entries have been deleted?
> >
> > Using a query on last modified time with a date range should allow
> > you to gain answers to 1) and 2). The sync engine just needs to keep
> > track of the time stamp from the last time they asked. Most sync
> > solutions today have a sync context or anchor (or some other fancy
> > name) but when dive in you'll find they all pretty much are just
> > exactly that, the time stamp from the last successful sync. The sync
> > engine need merely enumerate through the results and all the IDs it
> > recognizes are changes and all the ones it doesn't are new.


> > The only problem I can foresee has to do with instances of recurring
> > entries. If I change the time of an instance of a meeting or delete
> > an instance this will change the recurrence rule for this entry and
> > consequently the last modified time but if I am doing a query over a
> > specific time period  the first instance of the repeating may not be
> > in this time period so will I get it?

Change the RRULE? If you add an EXDATE or EXRULE, it will change
the VEVENT, but not the RRULE. Or if an instance at the beginning
or end is deleted - then, yes - you could change the RRULE.
Both will change the DTSTAMP.

I think you are reading more into what I wrote then I meant. When I stated that the recurrence rule (not the RRULE) would change I simply meant something within everything that went into deciding where instances would end up would change and thus the entry. I should have said recurrence set as is used in the iCalendar RFC. Sorry for the confusion. I'm pretty sure I mean the same thing as you.


This is also why the EXPAND property exists.

EXPAND:FALSE - yes, because it is part of the VEVENT and part of
               the VEVENT falls within that range.

EXPAND:TRUE  - no, you will only get the instances of that VEVENT
               that fall in that range.

Either way it sounds like a properly tailored CAP-QL query will take care of what I was worried about. Good.


> > What does DTSTART and DTEND
> > mean in this case? I think this is a basic problem that the people
> > discussing the CAP-QL need to address. If I am trying to get all the
> > entries in a week to populate a week view for example, I need some
> > guarantee that I will get the entries with recurrence rules that
> > cause instances to fall within my range. If the CAP-QL addresses
> > this then I guess the issue for sync will be taken care of as well.

I think it does with RRULE.

> > ...What does DTSTART and DTEND
> > mean in this case?...

I do think that we need to add another note to VQUERY,
this point was brought up before, I don't recall if it was
ever in any version of a draft.

   When performing VQUERYs that use DTEND, the CS MUST calculate:
        
        The effective DTEND for all components that have a DURATION
        property and match on those if they fall into the range
        supplied by DTEND.

   When performing VQUERYs that use DURATION, the CS MUST calculate:

        The effective DURATION for all components that have a DTEND
        property and match on those if they fall into the range
        supplied by DURATION.

Above when you sent:

> > In other words it must be possible for a sync engine (client,
> > server, whatever) to be able to get the answers to the following
> > three questions.
> >
> > ...
> >
> > 3) Within the given date range what entries have been deleted?

It is possible for the CUA to calculate the differences given
the current state of any component in the CUA and the result
of a VQUERY to the CS. So I think the requirement is met.

You don't want the Sync CUA asking the CS about each component it knows about to see if it has been deleted. This would be a very heavy operation. You want one call to tell you what's been deleted and I think it can be done if Calendar CUAs all properly use the METHOD DELETE to delete things.


And we need to add text about METHOD:DELETE and how that is
the way to mark somehting as deleted.

It really needs to be a MUST for CUAs.

OK. I think my 1st and 2nd issues have been dealt with here. The only one remaining is the last one about deleting an instance of a recurring entry.If the Sync CUA is making a query over a date range how can it be sure to catch this? It should be able to do something combining the DTSTAMP and EXDATE I think?

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



 From owner-ietf-calendar@mail.imc.org Fri Jan 18 17:08:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28911 for ; Fri, 18 Jan 2002 17:08:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ILvqV05712 for ietf-calendar-bks; Fri, 18 Jan 2002 13:57: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 g0ILvp305708 for ; Fri, 18 Jan 2002 13:57: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 NAA19544 for ; Fri, 18 Jan 2002 13:57:52 -0800 (PST) Message-ID: <3C489A57.B836C9AD@Royer.com> Date: Fri, 18 Jan 2002 14:57:43 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: Last Call ByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------0FF6A520E66B7CB08D3FE187" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0FF6A520E66B7CB08D3FE187 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > ... > > > > Above when you sent: > > > > > > In other words it must be possible for a sync engine (client, > > > > server, whatever) to be able to get the answers to the following > > > > three questions. > > > > > > > > ... > > > > > > > > 3) Within the given date range what entries have been deleted? > > > > It is possible for the CUA to calculate the differences given > > the current state of any component in the CUA and the result > > of a VQUERY to the CS. So I think the requirement is met. > > You don't want the Sync CUA asking the CS about each component it > knows about to see if it has been deleted. This would be a very heavy > operation. You want one call to tell you what's been deleted and I > think it can be done if Calendar CUAs all properly use the METHOD > DELETE to delete things. Good thing you raised more issues, I forgot ... The LAST-MODIFIED property is the date-time the object was modified. It DOES NOT mean the it is the newest authoritative data. If the SEQUENCE number is greater in one of the objects, it does not matter what the LAST-MODIFIED says, for the same UID, and SEQUENCE set, the larger SEQUENCE number is the newest object. When this happens, it only means that the older data was updated more recently and that is why the LAST-MODIFIED on older data may be newer. Use SEQUENCE. Only the ORGANIZER can update the SEQUENCE number. From iTIP: . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property value is incremented according to the rules defined in [iCAL]. . The "SEQUENCE" property value MUST be incremented each time the "Organizer" uses the "ADD" or "CANCEL" methods. . The "SEQUENCE" property value MUST NOT be incremented when using "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a delegation "REQUEST". So, if the data is updated, the SEQUENCE MUST BE incremented. Do we need to specify this is how you tell in CAP? So for cap, METHOD:CREATE (or BOOKED or whatever it is), the SEQUENCE will be greater in the newest object controlled by the ORGANIZER. > > And we need to add text about METHOD:DELETE and how that is > > the way to mark somehting as deleted. > > It really needs to be a MUST for CUAs. > > OK. I think my 1st and 2nd issues have been dealt with here. The only > one remaining is the last one about deleting an instance of a > recurring entry.If the Sync CUA is making a query over a date range > how can it be sure to catch this? It should be able to do something > combining the DTSTAMP and EXDATE I think? If you update a component, it's SEQUENCE number will be larger in the newer data. LAST-MODIFIED will just tell you when the CUA or CS last modified the (possibly old) data. For components marked METHOD:DELETE, they exist so a CUA knows that the CS does (did) in fact know about the object, and which ever has the larger SEQUENCE wins. If the CUA has a SEQUENCE of 10, METHOD:REQUEST and the CS SEQUENCE of 11, METHOD:DELETE, then the CUA can delete the component from the CUA. And we do not specify how the CUA or CS knows to delete the entry from the CS because you may have more than one CUA or CUA-bot that does that kind of thing for you. --------------0FF6A520E66B7CB08D3FE187 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 21 Jan 2002 11:48:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0LGWp610689 for ietf-calendar-bks; Mon, 21 Jan 2002 08:32:51 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LGWo310685 for ; Mon, 21 Jan 2002 08:32:50 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA03307 for ; Mon, 21 Jan 2002 11:32:46 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0LGWjQ10333 for ; Mon, 21 Jan 2002 11:32:45 -0500 (EST) Message-ID: <3C4C4308.4B0C2881@steltor.com> Date: Mon, 21 Jan 2002 11:34:16 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: VCAR: RIGHTS Value Type Ambiguous 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 semantic of OBJECT and VALUE rule parts is ambiguous. To illustrate this fact, here's possible interpretations of two very simple VCARs. Example 1: BEGIN:VCAR CARID:UPDATEPARTSTATUS GRANT:UPN=*;ACTION=MODIFY ;OBJECT=PARTSTAT:VALUE=* ;OBJECT=ATTENDEE;VALUE=SELF END:VCAR (a) Anybody is granted the right to modify, to any value, the PARTSTAT parameter of ATTENDEE properties set to himself; (b) Anybody is granted the right to modify, to any value, the PARTSTAT parameter of any ATTENDEE properties, as long as there is one ATTENDEE property set to himself in the component; (c) Anybody is granted the right to modify, to any value, the PARTSTAT parameter, as long as he modifies the ATTENDEE property to himself as well; (d) Anybody is granted the right to modify the value of any ATTENDEE property to himself, regardless of the stored value of the parameter PARTSTAT. Example 2: BEGIN:VCAR GRANT:UPN=*;ACTION=READ;OBJECT=*; ;OBJECT=ORGANIZER;VALUE=SELF END:VCAR (a) Anybody is granted the right to read everything in components for which he is the ORGANIZER; (b) Anybody is granted the right to read the ORGANIZER property of components for which he is the ORGANIZER. The problems lies in the fact that the OBJECT and VALUE rule parts have been overloaded to allow us to specify all of the following: (1) The set of stored objects on which the specified ACTION is granted or denied (i.e., the selected objects). For instance, you are granted the right to READ objects for which you are the ORGANIZER (which does not imply that you are granted the right to read the ORGANIZER property); (2) The part of the selected objects on which the specified ACTION is granted or denied. For instance, you are granted the right to READ the ORGANIZER property of the selected objects (which does not imply that you can only read objects that have an ORGANIZER property); (3) Restrictions on the submitted objects. For instance, you are granted the right to WRITE new objects with the METHOD property set to REQUEST only. The OBJECT and VALUE rule parts introduce an additional selection mechanism which is less flexible than the much debated CAP-QL. IMHO, using CAP-QL to specify the selected object and potentially the part of the selected objects on which the ACTION is granted or denied would get us closer to shipping CAP. If the WG agrees, I volunteer to send a proposal to the list. 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 Jan 21 11:50:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16408 for ; Mon, 21 Jan 2002 11:49:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0LGYU310738 for ietf-calendar-bks; Mon, 21 Jan 2002 08:34: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 g0LGYT310733 for ; Mon, 21 Jan 2002 08:34: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 LAA03345 for ; Mon, 21 Jan 2002 11:34:25 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0LGYOQ10439 for ; Mon, 21 Jan 2002 11:34:24 -0500 (EST) Message-ID: <3C4C436B.F53DD1B4@steltor.com> Date: Mon, 21 Jan 2002 11:35:55 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: VCAR: RIGHTS Value Type : UPN 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 UPN rule part doesn't need the special value "ANONYMOUS". The UPN "@" should be used instead. 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 Jan 21 12:55:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18644 for ; Mon, 21 Jan 2002 12:55:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LHfQF12250 for ietf-calendar-bks; Mon, 21 Jan 2002 09:41: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 g0LHfP312246 for ; Mon, 21 Jan 2002 09:41: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 JAA25083 for ; Mon, 21 Jan 2002 09:41:25 -0800 (PST) Message-ID: <3C4C52C0.4777AE92@Royer.com> Date: Mon, 21 Jan 2002 10:41:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: RIGHTS Value Type : UPN rule part References: <3C4C436B.F53DD1B4@steltor.com> Content-Type: multipart/mixed; boundary="------------4A7E770EA95775A84C4DC795" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4A7E770EA95775A84C4DC795 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The UPN rule part doesn't need the special value > "ANONYMOUS". The UPN "@" should be used instead. The problem is what if you want to say I will grant access to anyone but only in , use: GRANT:...:@domain or ONLY anonymous within , use: GRANT:...:anonymouns@ Or anyone anonymous from any domain: GRANT:...:anonymous Just using '@' does not cover all three. I am open. --------------4A7E770EA95775A84C4DC795 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 21 Jan 2002 12:55:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LHaus12135 for ietf-calendar-bks; Mon, 21 Jan 2002 09:36: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 g0LHas312131 for ; Mon, 21 Jan 2002 09:36: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 JAA25069 for ; Mon, 21 Jan 2002 09:36:55 -0800 (PST) Message-ID: <3C4C51B2.BC17E727@Royer.com> Date: Mon, 21 Jan 2002 10:36:50 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: RIGHTS Value Type Ambiguous References: <3C4C4308.4B0C2881@steltor.com> Content-Type: multipart/mixed; boundary="------------EC93D17BCAFAF409E2EEE35D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EC93D17BCAFAF409E2EEE35D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The semantic of OBJECT and VALUE rule parts is ambiguous. > > To illustrate this fact, here's possible interpretations > of two very simple VCARs. > > Example 1: > > BEGIN:VCAR > CARID:UPDATEPARTSTATUS > GRANT:UPN=*;ACTION=MODIFY > ;OBJECT=PARTSTAT:VALUE=* > ;OBJECT=ATTENDEE;VALUE=SELF > END:VCAR Read it as, for each object that you are checking, if the rule matches - then the GRANT or DENY applies. And the result MUST match the GRANT or DENY. For example (1) this GRANT would apply to you if: you wanted to MODIFY And the PARTSTAT object had any valule. and ATTENDEE is . So for a VEVENT with with UPN 'x': BEGIN:VEVENT ... ATTENDEE;PARTSTAT=NEEDS-ACTION:Z ATTENDEE;PARTSTAT=NEEdS-ACTION:x ... END:VEVENT The VCAR allows you to modify ONLY the one that matches. BEFORE AND AFTER. > (a) Anybody is granted the right to modify, to any value, the > PARTSTAT parameter of ATTENDEE properties set to himself; > > (b) Anybody is granted the right to modify, to any value, the > PARTSTAT parameter of any ATTENDEE properties, as long as > there is one ATTENDEE property set to himself in the > component; NOT true as only ONE of them match, if is not 'Z' it does not match the first one. > (c) Anybody is granted the right to modify, to any value, the > PARTSTAT parameter, as long as he modifies the ATTENDEE > property to himself as well; NOT true as it is only true IF he is the ATTENDEE, else he can not modify it. And yep - your VCAR allows them to modify the value of the ATTENDEE, as long as it is already set to 'x'. And you could modify the value, as long as the rule still was valid - so the only thing you could modify it to is 'x' > (d) Anybody is granted the right to modify the value of any > ATTENDEE property to himself, regardless of the stored > value of the parameter PARTSTAT. They could modify all ATTENDEEs from UPN 'x' to UPN 'x'. All other ATTENDEE values don't match. > Example 2: > > BEGIN:VCAR > GRANT:UPN=*;ACTION=READ;OBJECT=*; > ;OBJECT=ORGANIZER;VALUE=SELF > END:VCAR > > (a) Anybody is granted the right to read everything in > components for which he is the ORGANIZER; > > (b) Anybody is granted the right to read the ORGANIZER > property of components for which he is the ORGANIZER. 'property of components' ? I read (a) and (b) as the same. If the VALUE of ORGANIZER is 'x', you can read it. I don't see your points. --------------EC93D17BCAFAF409E2EEE35D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 21 Jan 2002 15:34:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LKFEh15982 for ietf-calendar-bks; Mon, 21 Jan 2002 12:15:14 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LKFD315977 for ; Mon, 21 Jan 2002 12:15:13 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA08910 for ; Mon, 21 Jan 2002 15:15:09 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0LKF8Q28251 for ; Mon, 21 Jan 2002 15:15:08 -0500 (EST) Message-ID: <3C4C7728.424E2E13@steltor.com> Date: Mon, 21 Jan 2002 15:16:40 -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: RIGHTS Value Type Ambiguous References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > The semantic of OBJECT and VALUE rule parts is ambiguous. > > > > To illustrate this fact, here's possible interpretations > > of two very simple VCARs. > > > > Example 1: > > > > BEGIN:VCAR > > CARID:UPDATEPARTSTATUS > > GRANT:UPN=*;ACTION=MODIFY > > ;OBJECT=PARTSTAT:VALUE=* > > ;OBJECT=ATTENDEE;VALUE=SELF > > END:VCAR > > Read it as, for each object that you are checking, if the > rule matches - then the GRANT or DENY applies. > And the result MUST match the GRANT or DENY. > > For example (1) this GRANT would apply to you if: > > you wanted to MODIFY > And the PARTSTAT object had any valule. > and ATTENDEE is . Given that the semantics of OBJECT and VALUE is not defined anywhere, you can only claim that this is YOUR interpretation of this VCAR. Furthermore, given that this VCAR's CARID is UPDATEPARTSTATUS (taken from section 11.2 of the latest interim version of the draft) I have big doubts that your interpretation matches the intent of the author of this VCAR. Why would he have specify "And the PARTSTAT object had any valule"? This would be useless. It is clear, to me at least, that the author's intent was to specify that you were only allowed to MODIFY PARTSTAT. As I mentionned in my previous post, the OBJECT and VALUE rule parts are trying to specify too many things at once. For instance, this VCAR is trying to restrict the stored objects you are allowed to MODIFY (ATTENDEE set to in our case), and to specify restriction on the submitted object (the submitted object can only change the value of PARTSTAT in our case). Trying to specify both together with OBJECT and VALUE rule parts causes confusion. > > So for a VEVENT with with UPN 'x': > > BEGIN:VEVENT > ... > ATTENDEE;PARTSTAT=NEEDS-ACTION:Z > ATTENDEE;PARTSTAT=NEEdS-ACTION:x > ... > END:VEVENT > > The VCAR allows you to modify ONLY the one that matches. > BEFORE AND AFTER. BEFORE AND AFTER? Where is that specified? How would I be able to say that you are only allowed to modify PARTSTAT from NEEDS-ACTION to ACCEPTED? You could propably argue that it's not a requirement, but then Access Rights as a whole is marked as "deferred" in the CAP requirements document. > > > (a) Anybody is granted the right to modify, to any value, the > > PARTSTAT parameter of ATTENDEE properties set to himself; > > > > (b) Anybody is granted the right to modify, to any value, the > > PARTSTAT parameter of any ATTENDEE properties, as long as > > there is one ATTENDEE property set to himself in the > > component; > > NOT true as only ONE of them match, if > is not 'Z' it does not match the first one. > > > (c) Anybody is granted the right to modify, to any value, the > > PARTSTAT parameter, as long as he modifies the ATTENDEE > > property to himself as well; > > NOT true as it is only true IF he is the ATTENDEE, > else he can not modify it. And yep - your VCAR allows them to > modify the value of the ATTENDEE, as long as it is already > set to 'x'. And you could modify the value, as long as the > rule still was valid - so the only thing you could modify > it to is 'x' > > > (d) Anybody is granted the right to modify the value of any > > ATTENDEE property to himself, regardless of the stored > > value of the parameter PARTSTAT. > > They could modify all ATTENDEEs from UPN 'x' to UPN 'x'. > All other ATTENDEE values don't match. If you think OBJECT and VALUE rule parts are not ambiguous, can you propose a different VCAR for each of the four interpretations that I wrote? > > > Example 2: > > > > BEGIN:VCAR > > GRANT:UPN=*;ACTION=READ;OBJECT=*; > > ;OBJECT=ORGANIZER;VALUE=SELF > > END:VCAR > > > > (a) Anybody is granted the right to read everything in > > components for which he is the ORGANIZER; > > > > (b) Anybody is granted the right to read the ORGANIZER > > property of components for which he is the ORGANIZER. > > 'property of components' ? > > I read (a) and (b) as the same. If the VALUE of ORGANIZER > is 'x', you can read it. > > I don't see your points. How would I write a VCAR to grant you the right to read everything, that is, not only the ORGANIZER property, in components that have the ORGANIZER property set to yourself? After all the energy that was spent in this WG to define CAP-QL, I think it would be a big mistake to use a different selection mechanism in VCARs. Do you really want to go over all the same issues again? 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 Jan 21 15:36:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23277 for ; Mon, 21 Jan 2002 15:36:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0LKPZt16205 for ietf-calendar-bks; Mon, 21 Jan 2002 12:25:35 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LKPY316197 for ; Mon, 21 Jan 2002 12:25:34 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA09286 for ; Mon, 21 Jan 2002 15:25:30 -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 g0LKPUQ29329 for ; Mon, 21 Jan 2002 15:25:30 -0500 (EST) Message-ID: <3C4C7995.F7B520D5@steltor.com> Date: Mon, 21 Jan 2002 15:27:01 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCAR: RIGHTS Value Type : UPN rule part References: <3C4C436B.F53DD1B4@steltor.com> <3C4C52C0.4777AE92@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > The UPN rule part doesn't need the special value > > "ANONYMOUS". The UPN "@" should be used instead. > > The problem is what if you want to say I will grant > access to anyone but only in , use: > > GRANT:...:@domain > > or ONLY anonymous within , use: > > GRANT:...:anonymouns@ > > Or anyone anonymous from any domain: > > GRANT:...:anonymous > > Just using '@' does not cover all three. > I am open. I'm missing your point. You can write: GRANT:UPN=@;... and: GRANT:UPN=@example.com;... The draft doesn't say anything about "anonymous" in UPN. It simply states that the special UPN "@" is used to represent anonymous users. 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 Jan 21 17:03:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26496 for ; Mon, 21 Jan 2002 17:03:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LLqMN18747 for ietf-calendar-bks; Mon, 21 Jan 2002 13:52:22 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LLqK318743 for ; Mon, 21 Jan 2002 13:52:20 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA25891 for ; Mon, 21 Jan 2002 13:52:11 -0800 (PST) Message-ID: <3C4C8D85.7EC613C8@Royer.com> Date: Mon, 21 Jan 2002 14:52:05 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: RIGHTS Value Type Ambiguous References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> Content-Type: multipart/mixed; boundary="------------21E88EEC5690EF98AA667A1A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------21E88EEC5690EF98AA667A1A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > The semantic of OBJECT and VALUE rule parts is ambiguous. > > > > > > To illustrate this fact, here's possible interpretations > > > of two very simple VCARs. > > > > > > Example 1: > > > > > > BEGIN:VCAR > > > CARID:UPDATEPARTSTATUS > > > GRANT:UPN=*;ACTION=MODIFY > > > ;OBJECT=PARTSTAT:VALUE=* > > > ;OBJECT=ATTENDEE;VALUE=SELF > > > END:VCAR > > > > Read it as, for each object that you are checking, if the > > rule matches - then the GRANT or DENY applies. > > And the result MUST match the GRANT or DENY. > > > > For example (1) this GRANT would apply to you if: > > > > you wanted to MODIFY > > And the PARTSTAT object had any valule. > > and ATTENDEE is . > > Given that the semantics of OBJECT and VALUE is not defined > anywhere, you can only claim that this is YOUR interpretation > of this VCAR. As I wrote VCARs, I guess I can :-) > Furthermore, given that this VCAR's CARID is UPDATEPARTSTATUS > (taken from section 11.2 of the latest interim version of the > draft) I have big doubts that your interpretation matches the > intent of the author of this VCAR. Why would he have specify > "And the PARTSTAT object had any valule"? This would be useless. > It is clear, to me at least, that the author's intent was to > specify that you were only allowed to MODIFY PARTSTAT. I am the author of VCAR - and my intent was to show that you can restrict them to only be able to modify the PARTSTAT. > As I mentionned in my previous post, the OBJECT and VALUE rule > parts are trying to specify too many things at once. For instance, > this VCAR is trying to restrict the stored objects you are allowed > to MODIFY (ATTENDEE set to in our case), and to specify > restriction on the submitted object (the submitted object can > only change the value of PARTSTAT in our case). Trying to specify > both together with OBJECT and VALUE rule parts causes confusion. Why? Your previous post did not seem make that point. It only shows me that there needs to be more text and examples. > > > > So for a VEVENT with with UPN 'x': > > > > BEGIN:VEVENT > > ... > > ATTENDEE;PARTSTAT=NEEDS-ACTION:Z > > ATTENDEE;PARTSTAT=NEEdS-ACTION:x > > ... > > END:VEVENT > > > > The VCAR allows you to modify ONLY the one that matches. > > BEFORE AND AFTER. > > BEFORE AND AFTER? Where is that specified? It applies to the ACTION, where does it say that it only applies to half of an ACTION? Remember - ACTION means command, so in that context, why would you think that it would not apply to all of the command? > How would I be able to say that you are only allowed to > modify PARTSTAT from NEEDS-ACTION to ACCEPTED? No such requirement exists. It does not seem to be a reasonable need. An ATTENDEE can not chagne from ACCPTED to DECLINED? Plus they still have to follow the rules of iTIP. > You could propably argue that it's not a requirement, but > then Access Rights as a whole is marked as "deferred" in > the CAP requirements document. And it was later un-deferred by this WG. Do you want NO access control in CAP? Or are you proposing that it needs to be added as a requirement? > > > > > (a) Anybody is granted the right to modify, to any value, the > > > PARTSTAT parameter of ATTENDEE properties set to himself; > > > > > > (b) Anybody is granted the right to modify, to any value, the > > > PARTSTAT parameter of any ATTENDEE properties, as long as > > > there is one ATTENDEE property set to himself in the > > > component; > > > > NOT true as only ONE of them match, if > > is not 'Z' it does not match the first one. > > > > > (c) Anybody is granted the right to modify, to any value, the > > > PARTSTAT parameter, as long as he modifies the ATTENDEE > > > property to himself as well; > > > > NOT true as it is only true IF he is the ATTENDEE, > > else he can not modify it. And yep - your VCAR allows them to > > modify the value of the ATTENDEE, as long as it is already > > set to 'x'. And you could modify the value, as long as the > > rule still was valid - so the only thing you could modify > > it to is 'x' > > > > > (d) Anybody is granted the right to modify the value of any > > > ATTENDEE property to himself, regardless of the stored > > > value of the parameter PARTSTAT. > > > > They could modify all ATTENDEEs from UPN 'x' to UPN 'x'. > > All other ATTENDEE values don't match. > > If you think OBJECT and VALUE rule parts are not ambiguous, > can you propose a different VCAR for each of the four > interpretations that I wrote? I don't think I understand your question. (b) Not reasonable, why would you want anyone that is also an ATTENDEE to be able to modify anyones elses PARTSTAT? (c) Not reasonable, why would you want anyone to modify the value another ATTENDEE to themselves? (d) Same as (c). > > > > > Example 2: > > > > > > BEGIN:VCAR > > > GRANT:UPN=*;ACTION=READ;OBJECT=*; > > > ;OBJECT=ORGANIZER;VALUE=SELF > > > END:VCAR > > > > > > (a) Anybody is granted the right to read everything in > > > components for which he is the ORGANIZER; > > > > > > (b) Anybody is granted the right to read the ORGANIZER > > > property of components for which he is the ORGANIZER. > > > > 'property of components' ? > > > > I read (a) and (b) as the same. If the VALUE of ORGANIZER > > is 'x', you can read it. > > > > I don't see your points. > > How would I write a VCAR to grant you the right to read > everything, that is, not only the ORGANIZER property, in > components that have the ORGANIZER property set to yourself? If you mean you want to be able to read anything? GRANT:UPN=*;ACTION=READ;OBJECT=* Or you want to be able to ONLY read components that have yourself as organizer? GRANT:UPN=*;ACTION=READ;OBJECT=VEVENT,VTODO ;OBJECT=ORGANIZER;VALUE=self > After all the energy that was spent in this WG to define > CAP-QL, I think it would be a big mistake to use a different > selection mechanism in VCARs. Do you really want to go over > all the same issues again? They are different issues, there is NO ACL of any kind in CAP-QL. Using CAP-QL won't work, You would have to define a way to have component.property.paramater component.property.paramater.value component.component.property.paramater component.component.property.paramater.value It's not the same model because querying for something is not the same problem as listing what they have access to. --------------21E88EEC5690EF98AA667A1A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 21 Jan 2002 17:14:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LM4AJ18988 for ietf-calendar-bks; Mon, 21 Jan 2002 14:04:10 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LM48318984 for ; Mon, 21 Jan 2002 14:04:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA25910 for ; Mon, 21 Jan 2002 14:04:10 -0800 (PST) Message-ID: <3C4C9053.788CCDAA@Royer.com> Date: Mon, 21 Jan 2002 15:04:03 -0700 From: Doug Royer 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" CC: ietf-calendar@imc.org Subject: Re: VCAR: RIGHTS Value Type : UPN rule part References: <3C4C436B.F53DD1B4@steltor.com> <3C4C52C0.4777AE92@Royer.com> <3C4C7995.F7B520D5@steltor.com> Content-Type: multipart/mixed; boundary="------------8CB2B6D608A9A444EA5D7145" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8CB2B6D608A9A444EA5D7145 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > The UPN rule part doesn't need the special value > > > "ANONYMOUS". The UPN "@" should be used instead. > > > > The problem is what if you want to say I will grant > > access to anyone but only in , use: > > > > GRANT:...:@domain > > > > or ONLY anonymous within , use: > > > > GRANT:...:anonymouns@ > > > > Or anyone anonymous from any domain: > > > > GRANT:...:anonymous > > > > Just using '@' does not cover all three. > > I am open. > > I'm missing your point. You can write: > > GRANT:UPN=@;... > > and: > > GRANT:UPN=@example.com;... > > The draft doesn't say anything about "anonymous" in UPN. > It simply states that the special UPN "@" is used to > represent anonymous users. (1) VCAR was added before UPN, so the text in VCAR may need to be updated. (2) SESSION - ID does not specify how to ONLY allow ANONYMOUS@realm. Maybe we need to add anonymous to 2.4.4? : anonymous@realm 2.4.4 CAP Session identity For anonymous access the identity of the session is "@", a UPN with a null Username and null Realm. A UPN with a null Username, but non- null Realm, such as "@foo.com" may be used to mean any identity from that Realm, which is useful to grant access rights to all users in a given Realm. A UPN with a non-null Username and null Realm, such as "bob@" could be a security risk and MUST NOT be used. It covered what the above text did not cover: How to say ANONYMOUS@ (vs. any anonymous?)  '@' is any anonymous at any realm. '@' is ANY user from that realm. Looks to me as if we need to update 2.4.4, not remove anonymous from VCAR. Or perhaps add it to 2.4.4 and update the text in VCAR?  --------------8CB2B6D608A9A444EA5D7145 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 21 Jan 2002 17:25:22 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0LMGhs19427 for ietf-calendar-bks; Mon, 21 Jan 2002 14:16:43 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LMGg319423 for ; Mon, 21 Jan 2002 14:16:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA25928 for ; Mon, 21 Jan 2002 14:16:44 -0800 (PST) Message-ID: <3C4C9345.C298F5D1@Royer.com> Date: Mon, 21 Jan 2002 15:16: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: 05 sendata -> beep. Content-Type: multipart/mixed; boundary="------------6545FE8A75830AF4F36D1E7A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6545FE8A75830AF4F36D1E7A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In order to get things back to the way they were in 05, PLUS add BEEP. I propose we replace the beep-cap-commands with then restore all of the existing agreed on objects. Where has an optional argument of 'letency' who's value is in seconds. Example: C: MSG 1 8 . 124 234 C: Content-Type: application/cap+xml C: C: C: ]]> --------------6545FE8A75830AF4F36D1E7A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 21 Jan 2002 20:06:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0M0tCd23328 for ietf-calendar-bks; Mon, 21 Jan 2002 16:55:12 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0M0tB323324 for ; Mon, 21 Jan 2002 16:55: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 TAA14416 for ; Mon, 21 Jan 2002 19:55:09 -0500 Received: from c1271 (c-1271.in.steltor.com [101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id g0M0t9Q17841 for ; Mon, 21 Jan 2002 19:55:09 -0500 (EST) Message-ID: <101001c1a2df$8b5191b0$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> Subject: Re: VCAR: RIGHTS Value Type Ambiguous Date: Mon, 21 Jan 2002 19:55:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Royer" To: Sent: Monday, January 21, 2002 4:52 PM Subject: Re: VCAR: RIGHTS Value Type Ambiguous > > Given that the semantics of OBJECT and VALUE is not defined > > anywhere, you can only claim that this is YOUR interpretation > > of this VCAR. > > As I wrote VCARs, I guess I can :-) Perhaps; but it needs to be explicit in the draft for EVERYONE to have the same interpretation, else interoperability will be next to impossible. If I follow this debate correctly (and no guarantees there ;), Bernard says : "The problems lies in the fact that the OBJECT and VALUE rule parts have been overloaded to allow us to specify all of the following: (1) The set of stored objects on which the specified ACTION is granted or denied (i.e., the selected objects). (2) The part of the selected objects on which the specified ACTION is granted or denied. (3) Restrictions on the submitted objects." Where the assumption is that the OBJECT and VALUE rule parts each have ONE of the listed meanings. (Feel free to correct me if I'm wrong here, Bernard) You seem to be saying that, Yes, OBJECT and VALUE rule parts can have all of those meanings; in fact they have ALL of those meanings, at the same time, always. (Again, feel free to correct me if I'm interpreting your intention poorly) Example 1: BEGIN:VCAR CARID:UPDATEPARTSTATUS GRANT:UPN=*;ACTION=MODIFY ;OBJECT=PARTSTAT:VALUE=* ;OBJECT=ATTENDEE;VALUE=SELF END:VCAR So, in this example, the OBJECT and VALUE rule parts specify (1) The target of the VCAR, that is, the PARTSTAT parameter (with any value) combined with an ATTENDEE value of SELF, (2) The parts of the selected objects that can be modified, that is, the CU/CUA can modify a PARTSTAT with any value, and any ATTENDEE with a value of SELF, and (3) The restrictions on the final submitted objects, that is, after modifying the object it must have a PARTSTAT of any value and an ATTENDEE value of SELF. The only thing that remains confusing is, how can one be sure that the PARTSTAT in the VCAR applies (as is presumably the intention) to the ATTENDEE property whose value is SELF? This implicit link between the two OBJECTs isn't expressed anywhere in the VCAR. As an example, suppose I want to DENY READ rights for everybody on events whose DTSTART TZID and DTEND TZID are EST and PST respectively, and vice versa (for example, an organization is very security-conscious and doesn't want to permit the viewing of any events corresponding to business flights of its executives). (pardon my poor VCAR grammar if there are any mistakes, but I'm sure you'll get the drift) BEGIN:VCAR DENY:UPN=NONOWNER;ACTION=READ ;OBJECT=DTSTART:VALUE=* ;OBJECT=TZID;VALUE=EST5EDT ;OBJECT=DTEND:VALUE=* ;OBJECT=TZID;VALUE=PST8PDT END:VCAR How would a CUA or CS be able to figure out which TZID goes with which property? Graham From owner-ietf-calendar@mail.imc.org Mon Jan 21 21:55:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01462 for ; Mon, 21 Jan 2002 21:55:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0M2few25513 for ietf-calendar-bks; Mon, 21 Jan 2002 18:41: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 g0M2fc325509 for ; Mon, 21 Jan 2002 18:41: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 SAA26246 for ; Mon, 21 Jan 2002 18:41:41 -0800 (PST) Message-ID: <3C4CD15B.6E1C6D1D@Royer.com> Date: Mon, 21 Jan 2002 19:41:31 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: RIGHTS Value Type Ambiguous References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <101001c1a2df$8b5191b0$092e0165@in.steltor.com> Content-Type: multipart/mixed; boundary="------------968DBB784B74C52105D1FE6F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------968DBB784B74C52105D1FE6F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Graham Gilmore wrote: > > ----- Original Message ----- > From: "Doug Royer" > To: > Sent: Monday, January 21, 2002 4:52 PM > Subject: Re: VCAR: RIGHTS Value Type Ambiguous > > > > Given that the semantics of OBJECT and VALUE is not defined > > > anywhere, you can only claim that this is YOUR interpretation > > > of this VCAR. > > > > As I wrote VCARs, I guess I can :-) > > Perhaps; but it needs to be explicit in the draft for EVERYONE to have > the same interpretation, else interoperability will be next to impossible. I HAVE NO problem debating the contents, or adding / deleted text, or being shown I am wrong. But the email point I was responding to said in effect "that I did not know what the 'intent' was". And I do as I wrote it - and evidently badly :-) > The only thing that remains confusing is, how can one be sure > that the PARTSTAT in the VCAR applies (as is presumably the intention) > to the ATTENDEE property whose value is SELF? This implicit link > between the two OBJECTs isn't expressed anywhere in the VCAR. Because that is what it means. Lets update the text. For each object you are thinking about giving access to: If your object is 'a' and your object is 'b' and your object is 'c', and if the GRANT/DENY line is for object 'a' and object 'b' and object 'c' then it matches the object your are testing, then it applies. (1) ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:user-1 (2) ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:user-2 (3) ATTENDEE;PARTSTAT=ACCEPTED;RSVP=TRUE:user-3 BEGIN:VCAR GRANT:UPN=user-2;ACTION=MODIFY ;OBJECT=VEVENT ;OBJECT=ATTENDEE;VALUE=user-2 ;OBJECT=PARTSTAT END:VCAR (If you replace 'user-2' with '*' and SELF, then the same rule applied, just to every UPN.) And then if the MODIFY request from the CUA using UPN 'user-2' to the ORGANIZERS calendar contains: ATTENDEE;PARTSTAT=ACCEPTED;RSVP=FALSE:user-2 So, the OBJECT set the user is attempting to modify is VEVENT, ATTENDEE, {PARTSTAT and RSVP} where ATTENDEE VALUE is 'user-2': Now for EACH object they are attempting to modify: UPN=user-2 yes - so far. ACTION=MODIFY yes - so far. OBJECT=VEVENT yes - so far. OBJECT=ATTENDEE yes - so far. OBJECT=PARTSTAT yes for the PARTSTAT object UPN=user-2 yes - so far. ACTION=MODIFY yes - so far. OBJECT=VEVENT yes - so far. OBJECT=ATTENDEE yes - so far. OBJECT=RSVP Nope - not in list. So, reject the MODIFY. Feel free to optimize the above in your implementation. > As an example, suppose I want to DENY READ rights for everybody on > events whose DTSTART TZID and DTEND TZID are EST and PST respectively, and > vice versa (for example, an organization is very security-conscious and > doesn't want to permit the viewing of any events corresponding to business > flights of its executives). > > BEGIN:VCAR > DENY:UPN=NONOWNER;ACTION=READ > ;OBJECT=DTSTART:VALUE=* > ;OBJECT=TZID;VALUE=EST5EDT > ;OBJECT=DTEND:VALUE=* > ;OBJECT=TZID;VALUE=PST8PDT > END:VCAR > > How would a CUA or CS be able to figure out which TZID goes with which > property? Your example above (I think) means 'NONOWNER' can not see any (VEVENT?) where the DTSTART TZID is EST5EDT .OR. where the DTEND TZID is PST8PDT. Do this, it solves the ambiguity. You are not comparing the value of DTSTART or DTEND, so the VALUE=* for them is not needed: BEGIN:VCAR DENY:UPN=NONOWNER;ACTION=READ ;OBJECT=VEVENT ;OBJECT=DTSTART ;OBJECT=TZID;VALUE=EST5EDT DENY:UPN=NONOWNER;ACTION=READ ;OBJECT=VEVENT ;OBJECT=DTEND ;OBJECT=TZID=VALUE=PST8PDT END:VCAR For .AND. you you are right, but you don't need the VALUE parameter to the DTSTART and DTEND because you are not comparing to the value of DTSTART or DTEND, you are comparing to the VALUE of the TZID. Plus the OBJECT and VALUE parameters are multi-valued: BEGIN:VCAR DENY:UPN=NONOWNER;ACTION=READ ;OBJECT=VEVENT ;OBJECT=DTSTART,DTEND ;OBJECT=TZID;VALUE=EST5EDT,PST8DT END:VCAR So the target of the compare is TZID is for both DTSTART and DTEND, for each TZID VALUE named. If is what you want to do is limit who can see the entries based on who they are, then do it by UPN. BEGIN:VCAR GRANT:UPN=;.... DENY:UPN=;... END:VCAR We could expand VCAR to allow named: (from CAP) User Group (UG) A collection of Calendar Users and/or User Groups. These groups are expanded by the CS and may reside either locally or in an external database or directory. The group membership may be fixed or dynamic over time. Then we could do something like allow UG or UPN in the GRANT / DENY properties: DENY;UPN=named;... DEBY:UG=named;... The only ambiguity I see is that the TZID is both a parameter in VEVENT and VTODO (and VJOURNAL?) and a property in VTIMEZONE. However that really is not a problem because it would be impossible to create a cross component compare both in CAP-QL and using a VCAR. So any VCAR provided could not be in the same object set. They could exist in separate object sets and they would not interfere with each other. --------------968DBB784B74C52105D1FE6F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 22 Jan 2002 11:36:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0MGCaL23678 for ietf-calendar-bks; Tue, 22 Jan 2002 08:12:36 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0MGCY323673 for ; Tue, 22 Jan 2002 08:12:34 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA22320 for ; Tue, 22 Jan 2002 11:12:30 -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 g0MGCUQ04538 for ; Tue, 22 Jan 2002 11:12:30 -0500 (EST) Message-ID: <3C4D8FCA.CF98FE20@steltor.com> Date: Tue, 22 Jan 2002 11:14:02 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCAR: RIGHTS Value Type Ambiguous References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@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: > > > > > > > > The semantic of OBJECT and VALUE rule parts is ambiguous. > > > > > > > > To illustrate this fact, here's possible interpretations > > > > of two very simple VCARs. > > > > > > > > Example 1: > > > > > > > > BEGIN:VCAR > > > > CARID:UPDATEPARTSTATUS > > > > GRANT:UPN=*;ACTION=MODIFY > > > > ;OBJECT=PARTSTAT:VALUE=* > > > > ;OBJECT=ATTENDEE;VALUE=SELF > > > > END:VCAR Unless I'm missing something, your first interpretation of this VCAR: > > > For example (1) this GRANT would apply to you if: > > > > > > you wanted to MODIFY > > > And the PARTSTAT object had any valule. > > > and ATTENDEE is . is different from your original intent: > I am the author of VCAR - and my intent was to show that > you can restrict them to only be able to modify the PARTSTAT. Your first interpretation was basically saying that OBJECT=PARTSTAT:VALUE=* meant that we don't care what the value of PARTSTAT is, but your intent was to say that the user is only allowed to modify the PARTSTAT. What would be the VCAR that would translate your intent clearly? > > > As I mentionned in my previous post, the OBJECT and VALUE rule > > parts are trying to specify too many things at once. For instance, > > this VCAR is trying to restrict the stored objects you are allowed > > to MODIFY (ATTENDEE set to in our case), and to specify > > restriction on the submitted object (the submitted object can > > only change the value of PARTSTAT in our case). Trying to specify > > both together with OBJECT and VALUE rule parts causes confusion. > > Why? Your previous post did not seem make that point. > It only shows me that there needs to be more text and examples. > > > > > > > So for a VEVENT with with UPN 'x': > > > > > > BEGIN:VEVENT > > > ... > > > ATTENDEE;PARTSTAT=NEEDS-ACTION:Z > > > ATTENDEE;PARTSTAT=NEEdS-ACTION:x > > > ... > > > END:VEVENT > > > > > > The VCAR allows you to modify ONLY the one that matches. > > > BEFORE AND AFTER. > > > > BEFORE AND AFTER? Where is that specified? > > It applies to the ACTION, where does it say that it only > applies to half of an ACTION? > > Remember - ACTION means command, so in that context, why > would you think that it would not apply to all of the command? BTW, the mapping between ACTION and command is NOT 1:1. See my post on why we can't have a MOVE ACTION: http://www.imc.org/ietf-calendar/mail-archive/msg03230.html > > > How would I be able to say that you are only allowed to > > modify PARTSTAT from NEEDS-ACTION to ACCEPTED? > > No such requirement exists. It does not seem to be a reasonable > need. An ATTENDEE can not chagne from ACCPTED to DECLINED? > Plus they still have to follow the rules of iTIP. That's beside the point. More generally: How would I be able to say that you are only allowed to modify property P from value V1 to value V2? In the case of the create command we can easily set restrictions on the new values, but it doesn't seem to be the case with the modify command. That doesn't make sense. > > You could propably argue that it's not a requirement, but > > then Access Rights as a whole is marked as "deferred" in > > the CAP requirements document. > > And it was later un-deferred by this WG. Do you want > NO access control in CAP? Or are you proposing that > it needs to be added as a requirement? > > > > > > > > (a) Anybody is granted the right to modify, to any value, the > > > > PARTSTAT parameter of ATTENDEE properties set to himself; > > > > > > > > (b) Anybody is granted the right to modify, to any value, the > > > > PARTSTAT parameter of any ATTENDEE properties, as long as > > > > there is one ATTENDEE property set to himself in the > > > > component; > > > > > > NOT true as only ONE of them match, if > > > is not 'Z' it does not match the first one. > > > > > > > (c) Anybody is granted the right to modify, to any value, the > > > > PARTSTAT parameter, as long as he modifies the ATTENDEE > > > > property to himself as well; > > > > > > NOT true as it is only true IF he is the ATTENDEE, > > > else he can not modify it. And yep - your VCAR allows them to > > > modify the value of the ATTENDEE, as long as it is already > > > set to 'x'. And you could modify the value, as long as the > > > rule still was valid - so the only thing you could modify > > > it to is 'x' > > > > > > > (d) Anybody is granted the right to modify the value of any > > > > ATTENDEE property to himself, regardless of the stored > > > > value of the parameter PARTSTAT. > > > > > > They could modify all ATTENDEEs from UPN 'x' to UPN 'x'. > > > All other ATTENDEE values don't match. > > > > If you think OBJECT and VALUE rule parts are not ambiguous, > > can you propose a different VCAR for each of the four > > interpretations that I wrote? > > I don't think I understand your question. > > (b) Not reasonable, why would you want anyone that is also > an ATTENDEE to be able to modify anyones elses PARTSTAT? > > (c) Not reasonable, why would you want anyone to modify the > value another ATTENDEE to themselves? > > (d) Same as (c). That's beside the point. We are not here to judge whether specific VCARs are reasonable or not. We simply have to make sure that VCARs are flexible enough to allow users to specify their access rights the way they want regardless if it seems reasonable to you or not. I still don't see how I could write a VCAR for the following statement: Anybody is granted the right to read all the ATTENDEE properties of VEVENT components for which he is the ORGANIZER. (1) The set of stored objects on which the specified ACTION is granted or denied: VEVENT components that have the ORGANIZER property set to SELF. (2) The part of the selected objects on which the specified ACTION is granted or denied. All ATTENDEE properties only (i.e., we are not granting the right to read the ORGANIZER property). > > > > > > > > Example 2: > > > > > > > > BEGIN:VCAR > > > > GRANT:UPN=*;ACTION=READ;OBJECT=*; > > > > ;OBJECT=ORGANIZER;VALUE=SELF > > > > END:VCAR > > > > > > > > (a) Anybody is granted the right to read everything in > > > > components for which he is the ORGANIZER; > > > > > > > > (b) Anybody is granted the right to read the ORGANIZER > > > > property of components for which he is the ORGANIZER. > > > > > > 'property of components' ? > > > > > > I read (a) and (b) as the same. If the VALUE of ORGANIZER > > > is 'x', you can read it. > > > > > > I don't see your points. > > > > How would I write a VCAR to grant you the right to read > > everything, that is, not only the ORGANIZER property, in > > components that have the ORGANIZER property set to yourself? > > If you mean you want to be able to read anything? > > GRANT:UPN=*;ACTION=READ;OBJECT=* > > Or you want to be able to ONLY read components that have > yourself as organizer? > > GRANT:UPN=*;ACTION=READ;OBJECT=VEVENT,VTODO > ;OBJECT=ORGANIZER;VALUE=self Now, how would I write a VCAR that only grants me the right to read the ORGANIZER property of VEVENT only, but only when ORGANIZER is set to myself? > > After all the energy that was spent in this WG to define > > CAP-QL, I think it would be a big mistake to use a different > > selection mechanism in VCARs. Do you really want to go over > > all the same issues again? > > They are different issues, there is NO ACL of any kind in CAP-QL. Of course there is no ACL in CAP-QL. It's a query language. All I'm saying is that we should be using the same query language to specify the object to which a given access right applies. > Using CAP-QL won't work, You would have to define a way > to have > > component.property.paramater > component.property.paramater.value > component.component.property.paramater > component.component.property.paramater.value Sorry, I don't understand what you are saying. CAP-QL shouldn't have any problem defining "the set of stored objects on which the specified ACTION is granted or denied". Otherwise, we need to fix it. > > It's not the same model because querying for something is not > the same problem as listing what they have access to. I agree it's not the same problem. But why are VCARs trying to solve different problems all at once? Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 22 16:38:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11574 for ; Tue, 22 Jan 2002 16:38:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0MLMYM01768 for ietf-calendar-bks; Tue, 22 Jan 2002 13:22: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 g0MLMX301764 for ; Tue, 22 Jan 2002 13:22: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 QAA30028 for ; Tue, 22 Jan 2002 16:22:30 -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 g0MLMTQ28858 for ; Tue, 22 Jan 2002 16:22:29 -0500 (EST) Message-ID: <3C4DD871.F352665@steltor.com> Date: Tue, 22 Jan 2002 16:24:01 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > In order to get things back to the way they were in 05, PLUS add BEEP. > > I propose we replace the beep-cap-commands with > then restore all of the existing agreed on objects. Where > has an optional argument of 'letency' who's value > is in seconds. > > Example: > > C: MSG 1 8 . 124 234 > C: Content-Type: application/cap+xml > C: > C: > C: C: BEGIN:VCALENDAR > C: METHOD:CREATE > C: TARGET:target... > C: ... > C: END:VCALENDAR > C: />]]> Which problems in the current draft are you trying to 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 Tue Jan 22 17:35:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13420 for ; Tue, 22 Jan 2002 17:35:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0MMODr03007 for ietf-calendar-bks; Tue, 22 Jan 2002 14:24: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 g0MMOC303003 for ; Tue, 22 Jan 2002 14:24: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 RAA31256 for ; Tue, 22 Jan 2002 17:24: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 g0MMO9Q03363 for ; Tue, 22 Jan 2002 17:24:09 -0500 (EST) Message-ID: <3C4DE6E6.F0D36AE4@steltor.com> Date: Tue, 22 Jan 2002 17:25:42 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: VCARs are ambiguous Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have questions on the interpretation of 2 VCARs taken from the latest interim version of draft. Does the following VCAR grants me the right to read the DTSTART, DTEND and CLASS properties when the CLASS property is set to PUBLIC? If so, how would I write a VCAR that would only grant me the right to read DTSTART and DTEND (and not CLASS) when the CLASS property is set to PUBLIC? BEGIN:VCAR CARID:"View PUBLIC Start and End Times" GRANT:UPN=*;ACTION=READ;OBJECT=DTSTART,DTEND ;OBJECT=CLASS;VALUE=PUBLIC END:VCAR Does the following VCAR grants me the right to modify the CLASS property to "PRIVATE" for any object that has the CLASS value set to PUBLIC? If not, how would I write a VCAR that would allow me to do so? BEGIN:VCAR CARID:"Read and Modify PUBLIC Calendar Entries" GRANT:UPN=*;ACTION=READ,MODIFY;OBJECT=* ;OBJECT=CLASS;VALUE=PUBLIC END:VCAR Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 22 17:49:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13645 for ; Tue, 22 Jan 2002 17:49:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0MMdCm03245 for ietf-calendar-bks; Tue, 22 Jan 2002 14:39:12 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0MMdB303241 for ; Tue, 22 Jan 2002 14:39:11 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA27624 for ; Tue, 22 Jan 2002 14:39:08 -0800 (PST) Message-ID: <3C4DEA05.9A255134@Royer.com> Date: Tue, 22 Jan 2002 15:39:01 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> Content-Type: multipart/mixed; boundary="------------9665055568320E8B49419FC3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9665055568320E8B49419FC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > In order to get things back to the way they were in 05, PLUS add BEEP. > > > > I propose we replace the beep-cap-commands with > > then restore all of the existing agreed on objects. Where > > has an optional argument of 'letency' who's value > > is in seconds. > > > > Example: > > > > C: MSG 1 8 . 124 234 > > C: Content-Type: application/cap+xml > > C: > > C: > > C: > C: BEGIN:VCALENDAR > > C: METHOD:CREATE > > C: TARGET:target... > > C: ... > > C: END:VCALENDAR > > C: />]]> > > Which problems in the current draft are you trying > to address? The task for 06 was to move the old CAP transport commands to BEEP. However more than that was done. The problem I am addressing is fixing that so that is all that was done. So the objects are again 2445 compliant and can again (as was in 05) be sent via iMIP. --------------9665055568320E8B49419FC3 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 22 Jan 2002 18:32:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0MNI7K04243 for ietf-calendar-bks; Tue, 22 Jan 2002 15:18:07 -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 g0MNI5304238 for ; Tue, 22 Jan 2002 15:18:05 -0800 (PST) To: ietf-calendar@imc.org Subject: RFC 2739 needs 2 corrections MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01172002 January 17, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 22 Jan 2002 18:16:21 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/22/2002 06:18:09 PM, Serialize complete at 01/22/2002 06:18:09 PM Content-Type: multipart/alternative; boundary="=_alternative 007FF42A85256B49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007FF42A85256B49_= Content-Type: text/plain; charset="US-ASCII" In reviewing RFC 2739 internally it was discovered that there are 2 groups of problems in the RFC. The updates are easily applied but Im not certain if they classify as RFC Errata or what the proper course is to correct them. The corrections are: In Section "2.4.3.1 calEntry" the list of allowed attributes is incomplete. The RFC defines 8 attributes under Section 2.4.4 but only 6 are listed in 2.4.3.1. The calCalAdrURI and calOtherCalAdrURIs attributes were accidentally left off the definition for calEntry. They simply need to be added. Several attribute definitions use the keyword MULTI-VALUE to indicate a multi-valued attribute (and others implicitly omit this to mean single-valued. This is actually the inverse behaviour expected for RFC 2252 compliance. RFC 2252 defines SINGLE-VALUE as a tag to mean an attribute can only be single valued since multi-valued is assumed otherwise. RFC 2739 needs to have the schema updated to reflect this. Otherwise the schema, while valid from a parsing standpoint, is not fully recognizable when actually being used by a RFC 2252 compliant engine. Ive asked for some guidance on the proper way to get the RFC corrected (Im guessing a new RFC may need to be issued thru the CalSched WG) Ill take the task of making sure the changes get properly applied or published. In the mean time, are there any comments about this revision? Bruce PS: The contact vCard for Pat contains some minor mistakes that should also be corrected too... =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007FF42A85256B49_= Content-Type: text/html; charset="US-ASCII"
  In reviewing RFC 2739 internally it was discovered that there are 2 groups of problems in the RFC.  The updates are easily applied but Im not certain if they classify as RFC Errata or what the proper course is to correct them.

  The corrections are:

  1. In Section "2.4.3.1  calEntry" the list of allowed attributes is incomplete.  The RFC defines 8 attributes under Section 2.4.4 but only 6 are listed in 2.4.3.1.   The calCalAdrURI and  calOtherCalAdrURIs attributes were accidentally left off the definition for calEntry.  They simply need to be added.
  2. Several attribute definitions use the keyword MULTI-VALUE to indicate a multi-valued attribute (and others implicitly omit this to mean single-valued.  This is actually the inverse behaviour expected for RFC 2252 compliance.  RFC 2252 defines SINGLE-VALUE as a tag to mean an attribute can only be single valued since multi-valued is assumed otherwise.  RFC 2739 needs to have the schema updated to reflect this.  Otherwise the schema, while valid from a parsing standpoint, is not fully recognizable when actually being used by a RFC 2252 compliant engine.

    Ive asked for some guidance on the proper way to get the RFC corrected (Im guessing a new RFC may need to be issued thru the CalSched WG) Ill take the task of making sure the changes get properly applied or published.  In the mean time, are there any comments about this revision?

    Bruce
    PS: The contact vCard for Pat contains some minor mistakes that should also be corrected too...
    ===========================================================================
    Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
    Messaging & Collaboration                 Phone: 978.399.6496
    IBM Software Group                         FAX: and nothing but the FAX...
    Standard disclaimers apply, even where prohibited by law...
--=_alternative 007FF42A85256B49_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 22 18:54:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14749 for ; Tue, 22 Jan 2002 18:54:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0MNF3t04066 for ietf-calendar-bks; Tue, 22 Jan 2002 15:15:03 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0MNF2304062 for ; Tue, 22 Jan 2002 15:15: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 PAA27663; Tue, 22 Jan 2002 15:15:02 -0800 (PST) Message-ID: <3C4DF26F.3A1394A9@Royer.com> Date: Tue, 22 Jan 2002 16:14:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: RIGHTS Value Type Ambiguous References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <3C4D8FCA.CF98FE20@steltor.com> Content-Type: multipart/mixed; boundary="------------FB1568E43F15B67092AFFF51" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FB1568E43F15B67092AFFF51 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > Remember - ACTION means command, so in that context, why > > would you think that it would not apply to all of the command? > > BTW, the mapping between ACTION and command is NOT 1:1. It was when it was written :-) When the draft was updated some time in the past, the VCAR text did not keep up. They should be mapped 1:1 to commands/METHOD as that is a complete list of what the CU can do to any object. > See my post on why we can't have a MOVE ACTION: > > http://www.imc.org/ietf-calendar/mail-archive/msg03230.html Yes we can have an action MOVE - we just have to define it as that is what it means. See my reply to that post. We just define MOVE to mean: It means it gives you ... access. > How would I be able to say that you are only allowed to > modify property P from value V1 to value V2? No such requirement exists. Why would you want it? CAP is not designed to replace the iTIP rules. So what iTIP operation would allow it to be set to an invalid value? If you want to restrict it for other reasons, then please provide specific needs. I am not sure I understand your needs, will this do it? DENY:...OBJECT=PARTSTAT;VALUE= > > I don't think I understand your question. > > > > (b) Not reasonable, why would you want anyone that is also > > an ATTENDEE to be able to modify anyones elses PARTSTAT? > > > > (c) Not reasonable, why would you want anyone to modify the > > value another ATTENDEE to themselves? > > > > (d) Same as (c). > > That's beside the point. We are not here to judge whether > specific VCARs are reasonable or not. True - unless you want me to understand your point:-) Changing some one elses ATTENDEE value (for non-owner) is not a reasonable need and I can think of no reason to allow it. If it does not already exist in 2445-2447, then lets just state that in CAP: You can't change components for iTIP generated objects unless you are the ORGANIZER or OWNER. And the OWNER is limited to local changes only when the OWNER is not the ORGANIZER. The only time any OWNER can modify the objects in an iTIP generated object is when it comes from the ORGANIZER. This applies even if there is no specific VCAR. If you do, iTIP breaks. Any UPN that is granted access to modify any iTIP originated object is in effect given proxy OWNERship access as far as the VCAR specifies. And that UPN is limited to the same restrictions as the OWNER even if there is not a specific VCAR. If you do, iTIP breaks. > We simply have to make > sure that VCARs are flexible enough to allow users to specify > their access rights the way they want regardless if it seems > reasonable to you or not. Then please specify one that really can be used or needed. iTIP does not allow it - we don't need a VCAR to define iTIP rules. And CAP does not extend the scheduling functionallity, it simplyly allows a CUA to store iTIP objects and their final state in the CS. We are extending iCalendar by allowing new kinds of objects, but we have not added, removed, or modified any iTIP operations. > I still don't see how I could write a VCAR for the following > statement: > > Anybody is granted the right to read all the ATTENDEE > properties of VEVENT components for which he is the > ORGANIZER. > > (1) The set of stored objects on which the specified > ACTION is granted or denied: > > VEVENT components that have the ORGANIZER > property set to SELF. (They are never "set to 'SELF'" if that is what you mean. SELF is a value that is only used in the VCAR to mean the currently authenticated UPN) If you mean you want ORGANIZERS to have access to their own components? GRANT:UPN=*;ACTION= ;OBJECT=VEVENT;VALUE=* ;OBJEFT=ORGANIZER;VALUE=SELF For each object you are determining if you want to give access: Is this object a: VEVENT yes - so far any VEVENT.* yes - so far ORGANIZER == SELF (true - applies, false - does not apply) > (2) The part of the selected objects on which the > specified ACTION is granted or denied. > > All ATTENDEE properties only (i.e., we > are not granting the right to read the > ORGANIZER property). I'll assume you ONLY want them to have access to the ATTENDEE property? BEGIN:VCAR DENY:UPN=NONOWNER;ACTION=...;OBJECT=* GRANT;UPN=*;ACTION=...;OBJECT=VEVENT;OBJECT=ATTENDEE END:VCAR > > > How would I write a VCAR to grant you the right to read > > > everything, that is, not only the ORGANIZER property, in > > > components that have the ORGANIZER property set to yourself? > > > > If you mean you want to be able to read anything? > > > > GRANT:UPN=*;ACTION=READ;OBJECT=* > > > > Or you want to be able to ONLY read components that have > > yourself as organizer? > > > > GRANT:UPN=*;ACTION=READ;OBJECT=VEVENT,VTODO > > ;OBJECT=ORGANIZER;VALUE=self > > Now, how would I write a VCAR that only grants me the > right to read the ORGANIZER property of VEVENT only, > but only when ORGANIZER is set to myself? Do you mean set to 'OWNER'? VEVENT only - remove VTODO from the above example and replace self with OWNER. > > > After all the energy that was spent in this WG to define > > > CAP-QL, I think it would be a big mistake to use a different > > > selection mechanism in VCARs. Do you really want to go over > > > all the same issues again? > > > > They are different issues, there is NO ACL of any kind in CAP-QL. > > Of course there is no ACL in CAP-QL. It's a query language. > All I'm saying is that we should be using the same query > language to specify the object to which a given access right > applies. Why? > > Using CAP-QL won't work, You would have to define a way > > to have > > > > component.property.paramater > > component.property.paramater.value > > component.component.property.paramater > > component.component.property.paramater.value > > Sorry, I don't understand what you are saying. > > CAP-QL shouldn't have any problem defining "the set of stored > objects on which the specified ACTION is granted or denied". > Otherwise, we need to fix it. Then how can it be as you say above "...using the same query language to specify the object to which a given access right applied." ? > > > > It's not the same model because querying for something is not > > the same problem as listing what they have access to. > > I agree it's not the same problem. But why are VCARs trying > to solve different problems all at once? "All at once"? --------------FB1568E43F15B67092AFFF51 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 22 Jan 2002 19:08:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0MNlUk04720 for ietf-calendar-bks; Tue, 22 Jan 2002 15:47: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 g0MNlT304716 for ; Tue, 22 Jan 2002 15:47: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 SAA32251 for ; Tue, 22 Jan 2002 18:47:27 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0MNlQQ08101 for ; Tue, 22 Jan 2002 18:47:26 -0500 (EST) Message-ID: <3C4DFA6B.9B1B1A11@steltor.com> Date: Tue, 22 Jan 2002 18:48:59 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCAR: RIGHTS Value Type Ambiguous References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <3C4D8FCA.CF98FE20@steltor.com> <3C4DF26F.3A1394A9@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: > > > > See my post on why we can't have a MOVE ACTION: > > > > http://www.imc.org/ietf-calendar/mail-archive/msg03230.html > > Yes we can have an action MOVE - we just have to define it > as that is what it means. See my reply to that post. You did not reply to this message, or else it never made it to the list. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 22 19:55:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15834 for ; Tue, 22 Jan 2002 19:55:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0N0gUf05812 for ietf-calendar-bks; Tue, 22 Jan 2002 16:42:30 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0N0gS305808 for ; Tue, 22 Jan 2002 16:42:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA27829 for ; Tue, 22 Jan 2002 16:42:31 -0800 (PST) Message-ID: <3C4E06EF.6E4EBBAB@Royer.com> Date: Tue, 22 Jan 2002 17:42:23 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VCARs - any other specific proposals? Content-Type: multipart/mixed; boundary="------------11DD5961B91C6637D72F0335" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------11DD5961B91C6637D72F0335 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit VCARs - any other specific 2445 object complient proposals? --------------11DD5961B91C6637D72F0335 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 23 Jan 2002 10:15:26 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0NExW001897 for ietf-calendar-bks; Wed, 23 Jan 2002 06:59:32 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NExV301892 for ; Wed, 23 Jan 2002 06:59:32 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA05920 for ; Wed, 23 Jan 2002 09:59:27 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NExRQ22314 for ; Wed, 23 Jan 2002 09:59:27 -0500 (EST) Message-ID: <3C4ED02C.948B2E61@steltor.com> Date: Wed, 23 Jan 2002 10:01:00 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCARs - any other specific proposals? References: <3C4E06EF.6E4EBBAB@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: > > VCARs - any other specific 2445 object complient proposals? I am going to send, by Monday, a proposal that will address the issues that were recently brought to the attention of the list. 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 Jan 23 13:14:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19071 for ; Wed, 23 Jan 2002 13:14:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0NHlqV06769 for ietf-calendar-bks; Wed, 23 Jan 2002 09:47: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 g0NHlp306765 for ; Wed, 23 Jan 2002 09:47: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 JAA29526 for ; Wed, 23 Jan 2002 09:47:52 -0800 (PST) Message-ID: <3C4EF743.F33D73C3@Royer.com> Date: Wed, 23 Jan 2002 10:47:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VCAR to seperate draft? Content-Type: multipart/mixed; boundary="------------A9D92BC30FB52FC275F64369" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A9D92BC30FB52FC275F64369 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit VCAR to seperate draft? Do we want VCAR's to go into a seperate draft? If we do, then CAP with some tweaks and LOTS of minor edits is much closer. --------------A9D92BC30FB52FC275F64369 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 23 Jan 2002 15:26:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NK6a210110 for ietf-calendar-bks; Wed, 23 Jan 2002 12:06:36 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NK6Y310105 for ; Wed, 23 Jan 2002 12:06:35 -0800 (PST) To: ietf-calendar@imc.org Subject: Internet-Draft Cutoff Dates for Minneapolis, MN MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 23 Jan 2002 15:06:34 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/23/2002 03:06:37 PM, Serialize complete at 01/23/2002 03:06:37 PM Content-Type: multipart/alternative; boundary="=_alternative 006E771385256B4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E771385256B4A_= Content-Type: text/plain; charset="us-ascii" FYI - below are dates for cutoff of draft submission for Minn. ----- Forwarded by Pat R Egen/Egen Consulting/01 on 01/23/02 15:06 ----- Internet-Drafts Administrator Sent by: nsyracus@cnri.reston.va.us 01/23/02 14:32 To: IETF-Announce: ; cc: Subject: Internet-Draft Cutoff Dates for Minneapolis, MN NOTE: There are two (2) Internet-Draft Cutoff dates February 22nd: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Friday, February 22nd, 17:00 US-EST. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, February 25th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of February 22nd will NOT be accepted. March 1st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Friday, March 1st, 2002 at 17:00 US-EST. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_53.html --=_alternative 006E771385256B4A_= Content-Type: text/html; charset="us-ascii"
FYI - below are dates for cutoff of draft submission for Minn.

----- Forwarded by Pat R Egen/Egen Consulting/01 on 01/23/02 15:06 -----
Internet-Drafts Administrator <internet-drafts@ietf.org>
Sent by: nsyracus@cnri.reston.va.us

01/23/02 14:32

       
        To:        IETF-Announce: ;
        cc:        
        Subject:        Internet-Draft Cutoff Dates for Minneapolis, MN




NOTE: There are two (2) Internet-Draft Cutoff dates

February 22nd: Cutoff for Initial Submissions (new documents)

All initial submissions(-00) must be submitted by Friday,
February 22nd, 17:00 US-EST. Initial submissions received after this time
will NOT be made available in the Internet-Drafts directory, and will have
to be resubmitted.

As before, all initial submissions (-00.txt) with a filename beginning
with a draft-ietf MUST be approved by the appropriate WG Chair prior to
processing and announcing. WG Chair approval must be received by
Monday, February 25th.

Please do NOT wait until the last minute to submit.

Be advised: NO placeholders. Updates to initial submissions received
           the week of February 22nd will NOT be accepted.

March 1st: FINAL Internet-Draft Cutoff

All revised Internet-Draft submissions must be submitted by Friday,
March 1st, 2002 at 17:00 US-EST. Internet-Drafts received after this time
will NOT be announced NOR made available in the Internet-Drafts
Directories.

We will begin accepting Internet-Draft submissions the week of the
meeting, though announcements will NOT be sent until the IETF meeting
is over.

Thank you for your understanding and cooperation. Please do not hesitate
to contact us if you have any questions or concenrs.

FYI: These and other significant dates can be found at
     http://www.ietf.org/meetings/cutoff_dates_53.html
--=_alternative 006E771385256B4A_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 23 16:03:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25280 for ; Wed, 23 Jan 2002 16:03:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NKlDV11001 for ietf-calendar-bks; Wed, 23 Jan 2002 12:47: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 g0NKlC310997 for ; Wed, 23 Jan 2002 12:47: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 PAA02213; Wed, 23 Jan 2002 15:47:08 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NKl8Q18722; Wed, 23 Jan 2002 15:47:08 -0500 (EST) Message-ID: <3C4F214B.28860C2E@steltor.com> Date: Wed, 23 Jan 2002 15:47:07 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@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: > > > > > > In order to get things back to the way they were in 05, PLUS add BEEP. > > > > > > I propose we replace the beep-cap-commands with > > > then restore all of the existing agreed on objects. Where > > > has an optional argument of 'letency' who's value > > > is in seconds. > > > > > > Example: > > > > > > C: MSG 1 8 . 124 234 > > > C: Content-Type: application/cap+xml > > > C: > > > C: > > > C: > > C: BEGIN:VCALENDAR > > > C: METHOD:CREATE > > > C: TARGET:target... > > > C: ... > > > C: END:VCALENDAR > > > C: />]]> > > > > Which problems in the current draft are you trying > > to address? > > The task for 06 was to move the old CAP transport commands to > BEEP. However more than that was done. The problem I am addressing > is fixing that so that is all that was done. So the objects > are again 2445 compliant and can again (as was in 05) be sent > via iMIP. The task for draft-06 was to change CAP into a BEEP profile. And it is what was done. Certainly there are many ways of doing it. The way that was chosen is in line with most of the BEEP profiles that we looked at, that is, they all separate the commands from the data. George From owner-ietf-calendar@mail.imc.org Wed Jan 23 16:10:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25509 for ; Wed, 23 Jan 2002 16:10:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NKrZq11131 for ietf-calendar-bks; Wed, 23 Jan 2002 12:53:35 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NKrY311127 for ; Wed, 23 Jan 2002 12:53:34 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA02291 for ; Wed, 23 Jan 2002 15:53:31 -0500 Received: from c1271 (c-1271.in.steltor.com [101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id g0NKrVQ19046 for ; Wed, 23 Jan 2002 15:53:31 -0500 (EST) Message-ID: <133401c1a450$1f530d00$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <101001c1a2df$8b5191b0$092e0165@in.steltor.com> <3C4CD15B.6E1C6D1D@Royer.com> Subject: Re: VCAR: RIGHTS Value Type Ambiguous Date: Wed, 23 Jan 2002 15:54:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Royer" To: Sent: Monday, January 21, 2002 9:41 PM Subject: Re: VCAR: RIGHTS Value Type Ambiguous > Graham Gilmore wrote: > > As an example, suppose I want to DENY READ rights for everybody on > > events whose DTSTART TZID and DTEND TZID are EST and PST respectively, and > > vice versa (for example, an organization is very security-conscious and > > doesn't want to permit the viewing of any events corresponding to business > > flights of its executives). > > > > BEGIN:VCAR > > DENY:UPN=NONOWNER;ACTION=READ > > ;OBJECT=DTSTART:VALUE=* > > ;OBJECT=TZID;VALUE=EST5EDT > > ;OBJECT=DTEND:VALUE=* > > ;OBJECT=TZID;VALUE=PST8PDT > > END:VCAR > > > > How would a CUA or CS be able to figure out which TZID goes with which > > property? > > Your example above (I think) means 'NONOWNER' can not see > any (VEVENT?) where the DTSTART TZID is EST5EDT > .OR. where the DTEND TZID is PST8PDT. I meant the .AND. case (see the descriptive text above the example). > For .AND. you you are right, but you don't need the VALUE parameter > to the DTSTART and DTEND because you are not comparing to the > value of DTSTART or DTEND, you are comparing to the VALUE > of the TZID. Plus the OBJECT and VALUE parameters are > multi-valued: > > BEGIN:VCAR > DENY:UPN=NONOWNER;ACTION=READ > ;OBJECT=VEVENT > ;OBJECT=DTSTART,DTEND > ;OBJECT=TZID;VALUE=EST5EDT,PST8DT > END:VCAR Alright, ignoring the extraneous DTSTART/DTEND values in my example (which are really beside the point in any case), this new example still doesn't seem to be very clear. How could a VCAR interpreter be sure the creator of the VCAR didn't mean to DENY READ rights for all meetings either beginning or ending in EST or PST (which was not the original intention)? There seems to be no way to say target events that look like this (events representing flights, for example): DTSTART;TZID=EST: DTEND;TZID=PST: without also filtering out events that start AND end in one of EST or PST (regular events that don't span timezones). This is one concrete example of the larger problem that the VCAR grammar implicitly mandates a particular relationship between OBJECTs (which covers the large majority of cases, granted, but not everything a user might -- reasonably -- want to do). > We could expand VCAR to allow named: > > (from CAP) > User Group (UG) > > A collection of Calendar Users and/or User Groups. These groups > are expanded by the CS and may reside either locally or in an > external database or directory. The group membership may be fixed > or dynamic over time. > > Then we could do something like allow UG or UPN in > the GRANT / DENY properties: > > DENY;UPN=named;... > DEBY:UG=named;... Sounds like a useful thing to include. Graham From owner-ietf-calendar@mail.imc.org Wed Jan 23 16:26:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26113 for ; Wed, 23 Jan 2002 16:26:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NL4oi11339 for ietf-calendar-bks; Wed, 23 Jan 2002 13:04:50 -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 g0NL4m311335 for ; Wed, 23 Jan 2002 13:04:48 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA02506 for ; Wed, 23 Jan 2002 16:04:45 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0NL4jQ19786 for ; Wed, 23 Jan 2002 16:04:45 -0500 (EST) Subject: Re: 05 sendata -> beep. From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C4DEA05.9A255134@Royer.com> References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 23 Jan 2002 16:12:57 -0500 Message-Id: <1011820377.6289.37.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 2002-01-22 at 17:39, Doug Royer wrote: > Bernard Desruisseaux wrote: ... > > Which problems in the current draft are you trying > > to address? > > The task for 06 was to move the old CAP transport commands to > BEEP. However more than that was done. The problem I am addressing > is fixing that so that is all that was done. So the objects > are again 2445 compliant and can again (as was in 05) be sent > via iMIP. As far as I know CAP extensions to iCalendar, as defined in draft-05, could not be included in a valid iTIP objects, and this is not a requirement. ITIP supports a finite set of methods, and RFC2446 provides restriction tables for them. The restriction tables in iTIP do allow additional X-PROPERTYs and X-COMPONENTs, but do not seem to allow the addition of new iana properties or components. As such in iTIP: - A TARGET property cannot be part of a METHOD:REQUEST. - VQUERYs or VAGENDAs cannot be included in a METHOD:PUBLISH. Furthermore naively sending the calendaring commands of CAP through email would not work. Email has limitations that are not present in a connection oriented protocol such as BEEP. The limitations includes: lost of messages and messages arriving in incorrect order. iTIP was design with these limitations in mind, the calendaring commands of CAP were not. From owner-ietf-calendar@mail.imc.org Wed Jan 23 17:28:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28057 for ; Wed, 23 Jan 2002 17:28:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NMFo312842 for ietf-calendar-bks; Wed, 23 Jan 2002 14:15:50 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NMFn312838 for ; Wed, 23 Jan 2002 14:15:49 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP by Minneapolis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 23 Jan 2002 17:16:51 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/23/2002 05:15:52 PM, Serialize complete at 01/23/2002 05:15:52 PM Content-Type: multipart/alternative; boundary="=_alternative 007A649385256B4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A649385256B4A_= Content-Type: text/plain; charset="us-ascii" I think from all the notes flying by that we seem to have resolved the topic of SQL statements. Correct? Do I hear that we have what we need to make the CAP draft reflect what everyone agreed upon? George/Editors, do you have enough text to do this? The reason I am asking this is we have a charter date to go for last call by March. AT the rate the notes are going, we won't make that. I see lots of dialog going back and forth between what constitutes two factions. I don't see much else from anyone else. I also don't see much in the way of concensus except on SQL text. Everyone agree? What I do see are questions going back and forth. For all of you who are actively participating - and participation is goodness! - what we need to see is proposals. If you state that something is wrong - your comment should include a "here's what's right" statement or text to that effect. Questions going back and forth don't result in a written draft. They just cause more questions. Also, may I make a suggestion that the notes be a bit smaller. Instead of burying ALL the text in a note, do some judicious "snipping" and make it easier on the rest of us. This may be one reason we are not getting anyone else to respond. They probably are too tired from all the reading. ;-) Ok, that's my bandbox for now. I like seeing all the activity - however, I'd like to see it from some other names (meaning other organizations). 5 people from the same group does not mean 5 different groups. If I am to try to call concensus on anything I need to read "noise" that sounds like it. Again, thanks for the efforts of everyone. And for the rest of you, are you there? Is anyone listening? ....;-) ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 007A649385256B4A_= Content-Type: text/html; charset="us-ascii"
I think from all the notes flying by that we seem to have resolved the topic of SQL statements. Correct? Do I hear that we have what we need to make the CAP draft reflect what everyone agreed upon?  George/Editors, do you have enough text to do this?  The reason I am asking this is we have a charter date to go for last call by March.  AT the rate the notes are going, we won't make that.  I see lots of dialog going back and forth between what constitutes two factions.  I don't see much else from anyone else.  I also don't see much in the way of concensus except on SQL text.  Everyone agree?  What I do see are questions going back and forth.  For all of you who are actively participating - and participation is goodness! - what we need to see is proposals.  If you state that something is wrong - your comment should include a "here's what's right" statement or text to that effect. &nbs! p;Questions going back and forth don't result in a written draft. They just cause more questions.  Also, may I make a suggestion that the notes be a bit smaller.  Instead of burying ALL the text in a note, do some judicious "snipping" and make it easier on the rest of us.  This may be one reason we are not getting anyone else to respond.  They probably are too tired from all the reading.  ;-)

Ok, that's my bandbox for now.  I like seeing all the activity - however, I'd like to see it from some other names (meaning other organizations).  5 people from the same group does not mean 5 different groups.  If I am to try to call concensus on anything I need to read "noise" that sounds like it.  

Again, thanks for the efforts of everyone.

And for the rest of you, are you there? Is anyone listening? ....;-)
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 007A649385256B4A_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 23 17:28:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28070 for ; Wed, 23 Jan 2002 17:28:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NMEVF12803 for ietf-calendar-bks; Wed, 23 Jan 2002 14:14:31 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NMEU312798 for ; Wed, 23 Jan 2002 14:14:30 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA00125 for ; Wed, 23 Jan 2002 14:14:31 -0800 (PST) Message-ID: <3C4F35C0.C91ACFC7@Royer.com> Date: Wed, 23 Jan 2002 15:14:24 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> <1011820377.6289.37.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------B7F2A7A827656CE82BF403A4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B7F2A7A827656CE82BF403A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > On Tue, 2002-01-22 at 17:39, Doug Royer wrote: > > Bernard Desruisseaux wrote: > ... > > > Which problems in the current draft are you trying > > > to address? > > > > The task for 06 was to move the old CAP transport commands to > > BEEP. However more than that was done. The problem I am addressing > > is fixing that so that is all that was done. So the objects > > are again 2445 compliant and can again (as was in 05) be sent > > via iMIP. > > As far as I know CAP extensions to iCalendar, as defined in > draft-05, could not be included in a valid iTIP objects, and > this is not a requirement. Not true on both. All of the METHOD objects can be transported in iTIP (METHOD was invented for iTIP - not CAP). Which is why they were METHOD's and not CAP commands. And the requirements doc DOES specify that the objects are to be 2445 compliant. Same with TARGET, it is a PROPERTY and NOT a CAP transport command so that it could be transported via iTIP. And same with CMDID - and I just noticed that it is also gone from 06, which was how you tied the object replies back to the source (iTIP or CUA). > ITIP supports a finite set of methods, and RFC2446 provides > restriction tables for them. The restriction tables in iTIP > do allow additional X-PROPERTYs and X-COMPONENTs, but do not > seem to allow the addition of new iana properties or components. NO - iTIP like iCalendar specified a specific set of components, properties, and parameters. And the CAP requirements document DOES specify that CAP may extend those objects. We separated the CAP transport commands from the 2445 objects using METHOD, TARGET, and CMDID. > As such in iTIP: > > - A TARGET property cannot be part of a METHOD:REQUEST. > - VQUERYs or VAGENDAs cannot be included in a METHOD:PUBLISH. > > Furthermore naively sending the calendaring commands of CAP > through email would not work. Email has limitations that are > not present in a connection oriented protocol such as BEEP. > The limitations includes: lost of messages and messages arriving > in incorrect order. iTIP was design with these limitations in > mind, the calendaring commands of CAP were not. Loss of messages: If the CUA did not get them, the CS is not going to get them - your CS better be able to handle that anyway. Incorrect order: If the CUA gets them out of order, they may be deposited out of order into the CS. If you CS can not handle that it is going to be busted. CAP supports iTIP, so an implementation that supports iTIP and CAP, MUST support those features. The objects are stored by the CS, the 'CUA' does the processing of the objects - not the CS. So if the messages are lost or out of order it has NO effect on a CS. The CUA decides when the iTIP objects will be processed and collapsed or deleted from the CS. Not there may be a CUA-bot that does it for a CU, but that is still a CUA. --------------B7F2A7A827656CE82BF403A4 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 23 Jan 2002 17:29:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NM9c712569 for ietf-calendar-bks; Wed, 23 Jan 2002 14:09:38 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NM9a312565 for ; Wed, 23 Jan 2002 14:09:36 -0800 (PST) To: George Babics Cc: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 23 Jan 2002 17:10:38 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/23/2002 05:09:39 PM, Serialize complete at 01/23/2002 05:09:39 PM Content-Type: multipart/alternative; boundary="=_alternative 0079D2C885256B4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079D2C885256B4A_= Content-Type: text/plain; charset="us-ascii" Hi George, point of clarification here. I'm not sure if what I say is the same as what you stated - if so, slap me down. I thought what we were told to do was remove transport from CAP and to use BEEP instead. That does not sound the same as "was to change CAP into a BEEP profile." I may be wrong. George Babics Sent by: owner-ietf-calendar@mail.imc.org 01/23/02 15:47 To: ietf-calendar@imc.org cc: Subject: Re: 05 sendata -> beep. Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > Doug Royer wrote: > > > > > > In order to get things back to the way they were in 05, PLUS add BEEP. > > > > > > I propose we replace the beep-cap-commands with > > > then restore all of the existing agreed on objects. Where > > > has an optional argument of 'letency' who's value > > > is in seconds. > > > > > > Example: > > > > > > C: MSG 1 8 . 124 234 > > > C: Content-Type: application/cap+xml > > > C: > > > C: > > > C: > > C: BEGIN:VCALENDAR > > > C: METHOD:CREATE > > > C: TARGET:target... > > > C: ... > > > C: END:VCALENDAR > > > C: />]]> > > > > Which problems in the current draft are you trying > > to address? > > The task for 06 was to move the old CAP transport commands to > BEEP. However more than that was done. The problem I am addressing > is fixing that so that is all that was done. So the objects > are again 2445 compliant and can again (as was in 05) be sent > via iMIP. The task for draft-06 was to change CAP into a BEEP profile. And it is what was done. Certainly there are many ways of doing it. The way that was chosen is in line with most of the BEEP profiles that we looked at, that is, they all separate the commands from the data. George --=_alternative 0079D2C885256B4A_= Content-Type: text/html; charset="us-ascii"

Hi George, point of clarification here.  I'm not sure if what I say is the same as what you stated - if so, slap me down.  I thought what we were told to do was remove transport from CAP and to use BEEP instead.  That does not sound the same as "was to change CAP into a BEEP profile."  I may be wrong.


George Babics <georgeb@steltor.com>
Sent by: owner-ietf-calendar@mail.imc.org

01/23/02 15:47

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: 05 sendata -> beep.





Doug Royer wrote:
>
> Bernard Desruisseaux wrote:
> >
> > Doug Royer wrote:
> > >
> > > In order to get things back to the way they were in 05, PLUS add BEEP.
> > >
> > > I propose we replace the beep-cap-commands with <senddata/>
> > > then restore all of the existing agreed on objects. Where
> > > <senddata/> has an optional argument of 'letency' who's value
> > > is in seconds.
> > >
> > > Example:
> > >
> > > C: MSG 1 8 . 124 234
> > > C: Content-Type: application/cap+xml
> > > C:
> > > C: <senddata/>
> > > C: <![CDATA[
> > > C: BEGIN:VCALENDAR
> > > C: METHOD:CREATE
> > > C: TARGET:target...
> > > C: ...
> > > C: END:VCALENDAR
> > > C: />]]>
> >
> > Which problems in the current draft are you trying
> > to address?
>
> The task for 06 was to move the old CAP transport commands to
> BEEP. However more than that was done. The problem I am addressing
> is fixing that so that is all that was done. So the objects
> are again 2445 compliant and can again (as was in 05) be sent
> via iMIP.

 The task for draft-06 was to change CAP into a BEEP profile.

 And it is what was done. Certainly there are many ways of doing it.
The way that was chosen is in line with most of the BEEP profiles that
we looked at, that is, they all separate the commands from the data.

George

--=_alternative 0079D2C885256B4A_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 23 17:30:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28177 for ; Wed, 23 Jan 2002 17:30:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NMJsK12933 for ietf-calendar-bks; Wed, 23 Jan 2002 14:19: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 g0NMJq312928 for ; Wed, 23 Jan 2002 14:19:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA00135 for ; Wed, 23 Jan 2002 14:19:54 -0800 (PST) Message-ID: <3C4F3703.3BD7DD41@Royer.com> Date: Wed, 23 Jan 2002 15:19:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> <3C4F214B.28860C2E@steltor.com> Content-Type: multipart/mixed; boundary="------------E033EB99D4DD1229F79324CA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E033EB99D4DD1229F79324CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > > Which problems in the current draft are you trying > > > to address? > > > > The task for 06 was to move the old CAP transport commands to > > BEEP. However more than that was done. The problem I am addressing > > is fixing that so that is all that was done. So the objects > > are again 2445 compliant and can again (as was in 05) be sent > > via iMIP. > > The task for draft-06 was to change CAP into a BEEP profile. > > And it is what was done. Certainly there are many ways of doing it. > The way that was chosen is in line with most of the BEEP profiles that > we looked at, that is, they all separate the commands from the data. 06 BREAKS iMIP as it is written. The instructions were to take TRANSPORT out of CAP and make it BEEP. It was NOT to make iCalendar objects into Beep objects (new METHOD values, TARGET, and CMDID were iCalendar objects - not CAP transport commands). The CAP 'COMMANDS' were (05): ABORT - now in CAP-BEEP - GREAT AUTHENTICATE - part of BEEP - EASY CALIDEXPAND - NOT in 06 at all - and I don't care :-) CAPABILITY - now in CAP-BEEP - GREAT CONTINUE - now in CAP-BEEP - GREAT DISCONNECT - part of BEEP - or is it MISSING? IDENTIFY - now in CAP-BEEP - GREAT SENDDATA - NOT in 06 at all - MISSING STARTTLS - part of BEEP - EASY UPNEXPAND - NOT in 06 at all - The was determined needed as viewed by the WG as a way to expand a group-UPN into its list of users so the CUA could determine who (non-group UPN) the command would effect. NOOP - now in CAP-BEEP GENERATEUID Which was called a METHOD, but all of the examples show that it was in fact a COMMAND as it was NOT a valid value for METHOD, and was not used inside any 2445 object. So I suspect the title of the 05 section that was: 7.2.1.4 GENERATEUID Method should have been called: 7.2.1.4 GENERATEUID Command And the CAP 0X-05 'METHOD's were (and need to be METHODs again so the OBJECTS are 2445 compliant and can be iMIP'd) These were all sent with the 'SENDDATA' CAP transport command inside of 2445 objects: CREATE - REMOVED in 06 as a value to METHOD MODIFY - REMOVED in 06 as a value to METHOD MOVE - REMOVED in 06 as a value to METHOD READ - REMOVED in 06 as a value to METHOD TARGET - REMOVED in 06 as a PROPERTY CMDID - REMOVED in 06 as a PROPERTY These were not accidentally placed into 2445 objects, it was the result of a lot of debate and meetings. They need to be moved back into 2445 objects. Please note that METHOD's are NOT CAP TRANSPORT commands and there was over a YEAR's worth of debate and agreements between many to separate the TRANSPORT from the iCalendar objects data. The net result of that LONG debate that took place on the list and in several interim meetings was - that they would be separate. Prior to 06, I could iMIP the objects to another CUA/CS and things worked. I'll be sending out this weekend text proposals that keep the CAP-BEEP commands (+ some suggested tweaks that will reduce the byte overhead for slow connections - using CDATA) PLUS text proposals for how to reinstate the CAP METHODS back into the objects so that iTIP/iMIP again works. Now I think that what I am proposing will not change anything other than the CAP transport commands will be BEEP transport commands. If I suspect otherwise - I'll specifically tag it. -Doug --------------E033EB99D4DD1229F79324CA Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 23 Jan 2002 17:37:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NMR1C13082 for ietf-calendar-bks; Wed, 23 Jan 2002 14:27:01 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NMQx313078 for ; Wed, 23 Jan 2002 14:26:59 -0800 (PST) To: "Graham Gilmore" Cc: ietf-calendar@imc.org Subject: Re: VCAR: RIGHTS Value Type Ambiguous MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 23 Jan 2002 17:28:02 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/23/2002 05:27:02 PM, Serialize complete at 01/23/2002 05:27:02 PM Content-Type: multipart/alternative; boundary="=_alternative 007B6A9F85256B4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B6A9F85256B4A_= Content-Type: text/plain; charset="us-ascii" On the topics of VCAR's I'd like to hear from people on the list (Paul Hill, where are you!) who are familiar with authentication and access controls. Also, for those of you are users not developers, you should also be looking at the VCAR notes. I believe what VCAR's control is who has access to the calendars on the server store. If you administer servers, than I think you understand what that means and that you care. My two cents... --=_alternative 007B6A9F85256B4A_= Content-Type: text/html; charset="us-ascii"
On the topics of VCAR's I'd like to hear from people on the list (Paul Hill, where are you!) who are familiar with authentication and access controls.  Also, for those of you are users not developers, you should also be looking at the VCAR notes.  I believe what VCAR's control is who has access to the calendars on the server store.  If you administer servers, than I think you understand what that means and that you care.  My two cents... --=_alternative 007B6A9F85256B4A_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 23 17:41:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28372 for ; Wed, 23 Jan 2002 17:41:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NMU3c13175 for ietf-calendar-bks; Wed, 23 Jan 2002 14:30:03 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NMU1313162 for ; Wed, 23 Jan 2002 14:30:01 -0800 (PST) To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: VCAR to seperate draft? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 23 Jan 2002 17:29:57 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/23/2002 05:30:04 PM Content-Type: multipart/mixed; boundary="=_mixed 007BB13A85256B4A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 007BB13A85256B4A_= Content-Type: multipart/alternative; boundary="=_alternative 007BB13A85256B4A_=" --=_alternative 007BB13A85256B4A_= Content-Type: text/plain; charset="us-ascii" Doug, if we do this, and the draft is tied to CAP, it could possibly delay CAP. When you separate drafts and they are "linked" they need to move up the internet food chain as a group. Only if the VCAR draft would stand alone would it make sense to have it in a separate document. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 01/23/02 12:47 Please respond to "ietf-calendar@imc.org" To: "ietf-calendar@imc.org" cc: Subject: VCAR to seperate draft? VCAR to seperate draft? Do we want VCAR's to go into a seperate draft? If we do, then CAP with some tweaks and LOTS of minor edits is much closer. --=_alternative 007BB13A85256B4A_= Content-Type: text/html; charset="us-ascii"
Doug, if we do this, and the draft is tied to CAP, it could possibly delay CAP.  When you separate drafts and they are "linked" they need to move up the internet food chain as a group.  Only if the VCAR draft would stand alone would it make sense to have it in a separate document.  
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

01/23/02 12:47
Please respond to "ietf-calendar@imc.org"

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        VCAR to seperate draft?




VCAR to seperate draft?

Do we want VCAR's to go into a seperate draft? If we do, then
CAP with some tweaks and LOTS of minor edits is much closer.

--=_alternative 007BB13A85256B4A_=-- --=_mixed 007BB13A85256B4A_= Content-Type: application/octet-stream; name="Doug.vcf" Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOlJveWVyO0RvdWcNCnRlbDtwYWdlcjpwYWdlckByb3llci5jb20NCnRl bDtjZWxsOjIwOC01MjAtNDA0NA0KdGVsO2ZheDo4NjYtNTk0LTg1NzQNCnRlbDt3b3JrOjg2Ni01 OTQtODU3NA0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vUm95ZXIuY29tL1Blb3Bs ZS9Eb3VnDQpvcmc6SU5FVC1Db25zdWx0aW5nIExMQyA8aHR0cDovL0lORVQtQ29uc3VsdGluZy5j b20NCmFkcjo7OzE3OTUgVy4gQnJvYWR3YXkgIzI2NjtJZGFobyBGYWxscztJRDs4MzQwMjsNCnZl cnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpEb3VnQFJveWVyLmNvbQ0KdGl0bGU6Q2hpZWYgRXhl Y3V0aXZlIE1hbmFnZXINCngtbW96aWxsYS1jcHQ6Oy0xMDQwMA0KZm46RG91ZyBSb3llcg0KZW5k OnZjYXJkDQo= --=_mixed 007BB13A85256B4A_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 23 18:13:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28972 for ; Wed, 23 Jan 2002 18:13:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0NN2HE13815 for ietf-calendar-bks; Wed, 23 Jan 2002 15:02:17 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NN2F313810 for ; Wed, 23 Jan 2002 15:02:15 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA00224 for ; Wed, 23 Jan 2002 15:02:17 -0800 (PST) Message-ID: <3C4F40F2.45E3A8BF@Royer.com> Date: Wed, 23 Jan 2002 16:02:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCAR: RIGHTS Value Type Ambiguous References: Content-Type: multipart/mixed; boundary="------------5ECEB0B47F0931452568CF03" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5ECEB0B47F0931452568CF03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > On the topics of VCAR's I'd like to hear from people on the list (Paul > Hill, where are you!) who are familiar with authentication and access > controls. Also, for those of you are users not developers, you should > also be looking at the VCAR notes. I believe what VCAR's control is > who has access to the calendars on the server store. If you > administer servers, than I think you understand what that means and > that you care. My two cents... Thanks! Pat. In my opinion VCARs are going to be a *LARGE* debate - and that is good! In a previous email, someone asked something LIKE (not a quote): Do you really want that kind of debate over VCARS like we had over CAL-QL/SQL-MIN YES!!!!! If we did not have that debate over CAP-QL, we would not have resolved the issues. Ignoring an issue on an IETF WG list only results in a busted RFC or the WG exploding. Debate is HOW THE IETF WORKS! Please participate! I think we MUST do one of the following two things: (1) MOVE VCAR's into a separate draft. OR (2) Understand that it is going to be a long debate and that CAP is going to be delayed. So, I again propose: Lets do (1), move VCARs into a separate draft and we can work on it at the same time if we want, and not slow down CAP. In cap requirements we specified that VCARs would be deferred. I can live with that to get CAP out the door. It means that for now in CAP we can call access control a administrative function to be defined at some later time. If we were to assume that Bernards proposal was perfect and solved all the issues. It's still not going to make MARCH. And that is because it is going to take a month or two before those of us that implement and read it to understand if it meets all of the needs. There are going to be questions and misunderstandings. That's part of the IETF. --------------5ECEB0B47F0931452568CF03 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 23 Jan 2002 18:33:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NNLQG14125 for ietf-calendar-bks; Wed, 23 Jan 2002 15:21: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 g0NNLO314121 for ; Wed, 23 Jan 2002 15:21:24 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA00264 for ; Wed, 23 Jan 2002 15:21:26 -0800 (PST) Message-ID: <3C4F456F.BC5A8E31@Royer.com> Date: Wed, 23 Jan 2002 16:21:19 -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: VCAR to seperate draft? References: Content-Type: multipart/mixed; boundary="------------9D1DD655C06141CCC240E53C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9D1DD655C06141CCC240E53C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > Doug, if we do this, and the draft is tied to CAP, it could possibly > delay CAP. When you separate drafts and they are "linked" they need > to move up the internet food chain as a group. Only if the VCAR draft > would stand alone would it make sense to have it in a separate > document. I just sent out another email that included this topic. Addressing it specifically: I think we can do this if in CAP we call access control an administrative function to be defined later. This would not 'link' them. But allow the reader to implement a CS. I think we all agree we want access control. And I think that we all agree that we want CAP. But for now, why can't we say in CAP: Here is how you store objects in the CS, subject to administrative restrictions. And in CAP Access control is an administrative function of a CS and CAP does not specify how a CS determines when a CU/CUA has or does not have permission to perform an operation. So the CUA must be able to deal with ";permission denied". We keep the framework for errors that VCAR-draft will use without specifying that it is designed for VCAR. And that's easy because the text is already in CAP - we just have to remove the VCAR specifics and say this it what the CS MUST return for permission denied. And that you won't get XXX if YYY. And defer how you tell the CS until a VCAR draft. -AND- At the same time that CAP is being worked on, and independently (not linked) work on draft...calsch-vcar- ? Why do we want access control to be defined in this WG? Because we want to have our implementations CUA's talk AND control the other implementations CS. Because large sites have administrators that do not want X number of ways to control access. At this point in time no CUA can do access control with any other implementations CS because there is no standard way to do that. So can we please settle to baby step this interoperability by doing access control as step number two ? Will this require a tweak to the charter - yep - lets do it. --------------9D1DD655C06141CCC240E53C Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 23 Jan 2002 23:27:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0O4GQM21668 for ietf-calendar-bks; Wed, 23 Jan 2002 20:16:26 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0O4GP321664 for ; Wed, 23 Jan 2002 20:16:25 -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 XAA07530; Wed, 23 Jan 2002 23:16:23 -0500 Received: from steltor.com ([101.0.0.6]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0O4GMQ14224; Wed, 23 Jan 2002 23:16:22 -0500 (EST) Message-ID: <3C4F8AE3.F825DB0B@steltor.com> Date: Wed, 23 Jan 2002 23:17:39 -0500 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCAR to seperate draft? References: <3C4F456F.BC5A8E31@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 VCARs are very important for group scheduling, and CAP in general. Without them one can not easily share one's agenda with others. It may hurt interoperability. VCARs are not that far from being completed. All they need are a few adjustments. Bernard seems to be willing to come up with a proposal very soon. Lets see if we can resolve the issues with the current VCARs. George Doug Royer wrote: > > pregen@egenconsulting.com wrote: > > > > Doug, if we do this, and the draft is tied to CAP, it could possibly > > delay CAP. When you separate drafts and they are "linked" they need > > to move up the internet food chain as a group. Only if the VCAR draft > > would stand alone would it make sense to have it in a separate > > document. > > I just sent out another email that included this topic. > Addressing it specifically: > > I think we can do this if in CAP we call access control an > administrative function to be defined later. This would > not 'link' them. But allow the reader to implement a CS. > > I think we all agree we want access control. And I think > that we all agree that we want CAP. But for now, why can't > we say in CAP: > > Here is how you store objects in the CS, subject > to administrative restrictions. > > And in CAP > > Access control is an administrative function of a CS > and CAP does not specify how a CS determines when > a CU/CUA has or does not have permission to perform > an operation. So the CUA must be able to deal with > ";permission denied". > > We keep the framework for errors that VCAR-draft will use without > specifying that it is designed for VCAR. And that's easy because > the text is already in CAP - we just have to remove the VCAR specifics > and say this it what the CS MUST return for permission denied. > And that you won't get XXX if YYY. And defer how you tell > the CS until a VCAR draft. > > -AND- At the same time that CAP is being worked on, and > independently (not linked) work on draft...calsch-vcar- ? > > Why do we want access control to be defined in this WG? > > Because we want to have our implementations CUA's talk > AND control the other implementations CS. > > Because large sites have administrators that do not > want X number of ways to control access. > > At this point in time no CUA can do access control with any > other implementations CS because there is no standard way > to do that. So can we please settle to baby step this interoperability > by doing access control as step number two ? > > Will this require a tweak to the charter - yep - lets do it. From owner-ietf-calendar@mail.imc.org Wed Jan 23 23:47:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06112 for ; Wed, 23 Jan 2002 23:47:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0O4atm22101 for ietf-calendar-bks; Wed, 23 Jan 2002 20:36:55 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0O4as322096 for ; Wed, 23 Jan 2002 20:36:54 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id XAA07594; Wed, 23 Jan 2002 23:36:52 -0500 Received: from steltor.com ([101.0.0.6]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0O4apQ15138; Wed, 23 Jan 2002 23:36:52 -0500 (EST) Message-ID: <3C4F8FB0.D5A564D2@steltor.com> Date: Wed, 23 Jan 2002 23:38:08 -0500 From: George Babics X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: pregen@egenconsulting.com CC: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. 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 When an application protocol, e.g., CAP, uses BEEP for transport, it becomes a BEEP profile. George pregen@egenconsulting.com wrote: > > Hi George, point of clarification here. I'm not sure if what I say is the same as what you stated > - if so, slap me down. I thought what we were told to do was remove transport from CAP and to use > BEEP instead. That does not sound the same as "was to change CAP into a BEEP profile." I may be > wrong. > > George Babics > Sent by: owner-ietf-calendar@mail.imc.org To: ietf-calendar@imc.org > cc: > 01/23/02 15:47 Subject: Re: 05 sendata -> beep. > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Doug Royer wrote: > > > > > > > > In order to get things back to the way they were in 05, PLUS add BEEP. > > > > > > > > I propose we replace the beep-cap-commands with > > > > then restore all of the existing agreed on objects. Where > > > > has an optional argument of 'letency' who's value > > > > is in seconds. > > > > > > > > Example: > > > > > > > > C: MSG 1 8 . 124 234 > > > > C: Content-Type: application/cap+xml > > > > C: > > > > C: > > > > C: > > > C: BEGIN:VCALENDAR > > > > C: METHOD:CREATE > > > > C: TARGET:target... > > > > C: ... > > > > C: END:VCALENDAR > > > > C: />]]> > > > > > > Which problems in the current draft are you trying > > > to address? > > > > The task for 06 was to move the old CAP transport commands to > > BEEP. However more than that was done. The problem I am addressing > > is fixing that so that is all that was done. So the objects > > are again 2445 compliant and can again (as was in 05) be sent > > via iMIP. > > The task for draft-06 was to change CAP into a BEEP profile. > > And it is what was done. Certainly there are many ways of doing it. > The way that was chosen is in line with most of the BEEP profiles that > we looked at, that is, they all separate the commands from the data. > > George From owner-ietf-calendar@mail.imc.org Thu Jan 24 00:50:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07331 for ; Thu, 24 Jan 2002 00:50:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0O5a9723468 for ietf-calendar-bks; Wed, 23 Jan 2002 21:36:09 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0O5a6323457 for ; Wed, 23 Jan 2002 21:36:06 -0800 (PST) To: George Babics Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: 05 sendata -> beep. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 24 Jan 2002 00:37:12 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/24/2002 12:36:11 AM, Serialize complete at 01/24/2002 12:36:11 AM Content-Type: multipart/alternative; boundary="=_alternative 001EDF3485256B4B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 001EDF3485256B4B_= Content-Type: text/plain; charset="us-ascii" Ok, got it. Just wanted to make sure what we did matched my notes. George Babics Sent by: owner-ietf-calendar@mail.imc.org 01/23/02 23:38 To: pregen@egenconsulting.com cc: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. When an application protocol, e.g., CAP, uses BEEP for transport, it becomes a BEEP profile. George pregen@egenconsulting.com wrote: > > Hi George, point of clarification here. I'm not sure if what I say is the same as what you stated > - if so, slap me down. I thought what we were told to do was remove transport from CAP and to use > BEEP instead. That does not sound the same as "was to change CAP into a BEEP profile." I may be > wrong. > > --=_alternative 001EDF3485256B4B_= Content-Type: text/html; charset="us-ascii"
Ok, got it.  Just wanted to make sure what we did matched my notes.




George Babics <georgeb@steltor.com>
Sent by: owner-ietf-calendar@mail.imc.org

01/23/02 23:38

       
        To:        pregen@egenconsulting.com
        cc:        ietf-calendar@imc.org
        Subject:        Re: 05 sendata -> beep.





When an application protocol, e.g., CAP, uses BEEP for transport,
it becomes a BEEP profile.

George

pregen@egenconsulting.com wrote:
>
> Hi George, point of clarification here.  I'm not sure if what I say is the same as what you stated
> - if so, slap me down.  I thought what we were told to do was remove transport from CAP and to use
> BEEP instead.  That does not sound the same as "was to change CAP into a BEEP profile."  I may be
> wrong.
>
>



--=_alternative 001EDF3485256B4B_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 24 09:25:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22134 for ; Thu, 24 Jan 2002 09:25:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0OE2pI15620 for ietf-calendar-bks; Thu, 24 Jan 2002 06:02:51 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OE2n315616 for ; Thu, 24 Jan 2002 06:02:50 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA11272 for ; Thu, 24 Jan 2002 09:02:45 -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 g0OE2jQ11490 for ; Thu, 24 Jan 2002 09:02:45 -0500 (EST) Message-ID: <3C501463.897B093@steltor.com> Date: Thu, 24 Jan 2002 09:04:19 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> <3C4F214B.28860C2E@steltor.com> <3C4F3703.3BD7DD41@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: > > 06 BREAKS iMIP as it is written. But this is not a requirement. Here's what the requirements document says: > 3. Relationship To iCalendar, iTIP and iMIP/iRIP > > The CAP data elements MUST be based on the calendar architecture set > forth in [ICAL]. More precisely, CAP will define an Internet protocol > for accessing a CS that consists of one or more calendars, each > consisting of numerous [ICAL] components. The definition of CAP might > necessitate adding components, properties, parameters and other > elements beyond those defined in [ICAL]. These additions MUST be > defined in a manner consistent with and upwards compatible to the > data model defined by [ICAL]. > > Where it makes practical sense, CAP SHOULD make use of the scheduling > workflow defined by [ITIP]. > > CAP will not require that [IMIP] or [IRIP] MUST be used to > communicate with other calendar users. CAP does not require that iMIP be used, and CAP already makes use of iTIP where it makes sense (i.e., scheduling). 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 Jan 24 09:27:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22170 for ; Thu, 24 Jan 2002 09:27:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OEGJv16508 for ietf-calendar-bks; Thu, 24 Jan 2002 06:16:19 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OEGI316502 for ; Thu, 24 Jan 2002 06:16:18 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA11674; Thu, 24 Jan 2002 09:16:13 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0OEGDQ12558; Thu, 24 Jan 2002 09:16:13 -0500 (EST) Message-ID: <3C50172C.1CEBE63D@steltor.com> Date: Thu, 24 Jan 2002 09:16:12 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> <3C4F214B.28860C2E@steltor.com> <3C4F3703.3BD7DD41@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 CAP 'COMMANDS' were (05): > > ABORT - now in CAP-BEEP - GREAT > AUTHENTICATE - part of BEEP - EASY > CALIDEXPAND - NOT in 06 at all - and I don't care :-) > CAPABILITY - now in CAP-BEEP - GREAT > CONTINUE - now in CAP-BEEP - GREAT > DISCONNECT - part of BEEP - or is it MISSING? > IDENTIFY - now in CAP-BEEP - GREAT > SENDDATA - NOT in 06 at all - MISSING > STARTTLS - part of BEEP - EASY > > UPNEXPAND - NOT in 06 at all - > The was determined needed as viewed by the WG as a > way to expand a group-UPN into its list of users so > the CUA could determine who (non-group UPN) the command > would effect. Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG. See: http://www.imc.org/ietf-calendar/mail-archive/msg02128.html George From owner-ietf-calendar@mail.imc.org Thu Jan 24 11:32:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26162 for ; Thu, 24 Jan 2002 11:32:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0OGKZk25656 for ietf-calendar-bks; Thu, 24 Jan 2002 08:20:35 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OGKY325651 for ; Thu, 24 Jan 2002 08:20:34 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA01541 for ; Thu, 24 Jan 2002 08:20:34 -0800 (PST) Message-ID: <3C50344F.E0C4DA5@Royer.com> Date: Thu, 24 Jan 2002 09:20:31 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> <3C4F214B.28860C2E@steltor.com> <3C4F3703.3BD7DD41@Royer.com> <3C501463.897B093@steltor.com> Content-Type: multipart/mixed; boundary="------------D2188ECF2126785B42BABF45" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D2188ECF2126785B42BABF45 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > 06 BREAKS iMIP as it is written. > > But this is not a requirement. Here's what the requirements > document says: > > > 3. Relationship To iCalendar, iTIP and iMIP/iRIP > > > > The CAP data elements MUST be based on the calendar architecture set > > forth in [ICAL]. More precisely, CAP will define an Internet protocol > > for accessing a CS that consists of one or more calendars, each > > consisting of numerous [ICAL] components. The definition of CAP might > > necessitate adding components, properties, parameters and other > > elements beyond those defined in [ICAL]. These additions MUST be > > defined in a manner consistent with and upwards compatible to the > > data model defined by [ICAL]. > > > > Where it makes practical sense, CAP SHOULD make use of the scheduling > > workflow defined by [ITIP]. > > > > CAP will not require that [IMIP] or [IRIP] MUST be used to > > communicate with other calendar users. > > CAP does not require that iMIP be used, and CAP already > makes use of iTIP where it makes sense (i.e., scheduling). I strongly disagree. Several of us fought very hard to make sure that CAP is 2445 compliant. They must go back in to the objects. As I said earlier - it is NOT an accident that the TARGET, CMDID, and CAP - METHOD values were inside of the 2445 object. And it was not an accident that sendata, generateuid, and the others were cap-transport commands. --------------D2188ECF2126785B42BABF45 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 24 Jan 2002 11:49:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OGN0v25824 for ietf-calendar-bks; Thu, 24 Jan 2002 08:23:00 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OGMx325818 for ; Thu, 24 Jan 2002 08:22:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA01545 for ; Thu, 24 Jan 2002 08:22:59 -0800 (PST) Message-ID: <3C5034E0.A46AE5B4@Royer.com> Date: Thu, 24 Jan 2002 09:22:56 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> <3C4F214B.28860C2E@steltor.com> <3C4F3703.3BD7DD41@Royer.com> <3C50172C.1CEBE63D@steltor.com> Content-Type: multipart/mixed; boundary="------------5629D8FD165AD5695AFB75F0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5629D8FD165AD5695AFB75F0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > Doug Royer wrote: > > > The CAP 'COMMANDS' were (05): > > > > ABORT - now in CAP-BEEP - GREAT > > AUTHENTICATE - part of BEEP - EASY > > CALIDEXPAND - NOT in 06 at all - and I don't care :-) > > > CAPABILITY - now in CAP-BEEP - GREAT > > CONTINUE - now in CAP-BEEP - GREAT > > DISCONNECT - part of BEEP - or is it MISSING? > > IDENTIFY - now in CAP-BEEP - GREAT > > SENDDATA - NOT in 06 at all - MISSING > > STARTTLS - part of BEEP - EASY > > > > UPNEXPAND - NOT in 06 at all - > > The was determined needed as viewed by the WG as a > > way to expand a group-UPN into its list of users so > > the CUA could determine who (non-group UPN) the command > > would effect. > > Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG. > See: > > http://www.imc.org/ietf-calendar/mail-archive/msg02128.html First - I really don't care if they are gone. I never saw that they were needed. Second - one company agreeing with itself it not really that impressive of a reason :-) --------------5629D8FD165AD5695AFB75F0 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 24 Jan 2002 11:53:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0OGhku27014 for ietf-calendar-bks; Thu, 24 Jan 2002 08:43: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 g0OGhj327008 for ; Thu, 24 Jan 2002 08:43:45 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA16164; Thu, 24 Jan 2002 11:43:40 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0OGheQ25663; Thu, 24 Jan 2002 11:43:40 -0500 (EST) Message-ID: <3C5039BB.18BC8339@steltor.com> Date: Thu, 24 Jan 2002 11:43:39 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> <3C4F214B.28860C2E@steltor.com> <3C4F3703.3BD7DD41@Royer.com> <3C50172C.1CEBE63D@steltor.com> <3C5034E0.A46AE5B4@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > George Babics wrote: > > > > Doug Royer wrote: > > > > > The CAP 'COMMANDS' were (05): > > > > > > ABORT - now in CAP-BEEP - GREAT > > > AUTHENTICATE - part of BEEP - EASY > > > CALIDEXPAND - NOT in 06 at all - and I don't care :-) > > > > > CAPABILITY - now in CAP-BEEP - GREAT > > > CONTINUE - now in CAP-BEEP - GREAT > > > DISCONNECT - part of BEEP - or is it MISSING? > > > IDENTIFY - now in CAP-BEEP - GREAT > > > SENDDATA - NOT in 06 at all - MISSING > > > STARTTLS - part of BEEP - EASY > > > > > > UPNEXPAND - NOT in 06 at all - > > > The was determined needed as viewed by the WG as a > > > way to expand a group-UPN into its list of users so > > > the CUA could determine who (non-group UPN) the command > > > would effect. > > > > Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG. > > See: > > > > http://www.imc.org/ietf-calendar/mail-archive/msg02128.html > > First - I really don't care if they are gone. I never saw that > they were needed. > > Second - one company agreeing with itself it not really that > impressive of a reason :-) This was agreed to, in a CAP conference call, by many people. It was posted on the list to see if anyone else had objections to removing them. No one else commented. George From owner-ietf-calendar@mail.imc.org Thu Jan 24 13:04:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29753 for ; Thu, 24 Jan 2002 13:04:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0OHdPD00382 for ietf-calendar-bks; Thu, 24 Jan 2002 09:39:25 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OHdO300378 for ; Thu, 24 Jan 2002 09:39:24 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA01732; Thu, 24 Jan 2002 09:39:24 -0800 (PST) Message-ID: <3C5046C8.C2CDDE33@Royer.com> Date: Thu, 24 Jan 2002 10:39:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 05 sendata -> beep. References: <3C4C9345.C298F5D1@Royer.com> <3C4DD871.F352665@steltor.com> <3C4DEA05.9A255134@Royer.com> <3C4F214B.28860C2E@steltor.com> <3C4F3703.3BD7DD41@Royer.com> <3C50172C.1CEBE63D@steltor.com> <3C5034E0.A46AE5B4@Royer.com> <3C5039BB.18BC8339@steltor.com> Content-Type: multipart/mixed; boundary="------------15712C176A6035D55C8F017B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------15712C176A6035D55C8F017B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG. > > > See: > > > > > > http://www.imc.org/ietf-calendar/mail-archive/msg02128.html > > > > First - I really don't care if they are gone. I never saw that > > they were needed. > > > > Second - one company agreeing with itself it not really that > > impressive of a reason :-) > > This was agreed to, in a CAP conference call, by many people. My apologies. It was not my intention to say that it was not. It was my intention to say that the email you pointed me to was that way :-) --------------15712C176A6035D55C8F017B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 24 Jan 2002 13:43:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OIUKl03964 for ietf-calendar-bks; Thu, 24 Jan 2002 10:30:20 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OIUH303953 for ; Thu, 24 Jan 2002 10:30:18 -0800 (PST) To: George Babics Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: 05 sendata -> beep. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 24 Jan 2002 13:31:24 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/24/2002 01:30:20 PM, Serialize complete at 01/24/2002 01:30:20 PM Content-Type: multipart/alternative; boundary="=_alternative 0065C0A285256B4B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065C0A285256B4B_= Content-Type: text/plain; charset="us-ascii" George, in your reply to Doug you reference a conference call. The agreement in a conference call must also be an agreement on the list. I'm not sure we do have agreement on this topic. Can you repost it to the list - I know this sounds redundant. But I want to ensure we know the list reads the item "explicitly" and we are sure everyone agrees. If no one comes back and says that what you posted is wrong does not necessarily make it right. If one person comes back and says it is wrong, first off, that person must defend why they believe that and then offer text or explanations to prove that belief. Therefore, I really want to make sure we review what Doug has said. I too remember that we wanted to ensure that CAP objects remained iCalendar objects so they can be passed around via other methods if your calendar product does not have access to a CAP server. Otherwise, no one will use the product. If I can not be assured that my calendar request makes it to everyone I invite - why would I use the product. Or am I missing something here. I really wish some other folks would comment on these topics. It would help the chairs and editors come to conclusions and resolutions. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 George Babics Sent by: owner-ietf-calendar@mail.imc.org 01/24/02 11:43 To: ietf-calendar@imc.org cc: Subject: Re: 05 sendata -> beep. Doug Royer wrote: > > George Babics wrote: > > > > Doug Royer wrote: > > > > > The CAP 'COMMANDS' were (05): > > > > > > ABORT - now in CAP-BEEP - GREAT > > > AUTHENTICATE - part of BEEP - EASY > > > CALIDEXPAND - NOT in 06 at all - and I don't care :-) > > > > > CAPABILITY - now in CAP-BEEP - GREAT > > > CONTINUE - now in CAP-BEEP - GREAT > > > DISCONNECT - part of BEEP - or is it MISSING? > > > IDENTIFY - now in CAP-BEEP - GREAT > > > SENDDATA - NOT in 06 at all - MISSING > > > STARTTLS - part of BEEP - EASY > > > > > > UPNEXPAND - NOT in 06 at all - > > > The was determined needed as viewed by the WG as a > > > way to expand a group-UPN into its list of users so > > > the CUA could determine who (non-group UPN) the command > > > would effect. > > > > Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG. > > See: > > > > http://www.imc.org/ietf-calendar/mail-archive/msg02128.html > > First - I really don't care if they are gone. I never saw that > they were needed. > > Second - one company agreeing with itself it not really that > impressive of a reason :-) This was agreed to, in a CAP conference call, by many people. It was posted on the list to see if anyone else had objections to removing them. No one else commented. George --=_alternative 0065C0A285256B4B_= Content-Type: text/html; charset="us-ascii"
George, in your reply to Doug you reference a conference call.  The agreement in a conference call must also be an agreement on the list.  I'm not sure we do have agreement on this topic.  Can you repost it to the list - I know this sounds redundant.  But I want to ensure we know the list reads the item "explicitly" and we are sure everyone agrees.  If no one comes back and says that what you posted is wrong does not necessarily make it right.  If one person comes back and says it is wrong, first off, that person must defend why they believe that and then offer text or explanations to prove that belief.  Therefore, I really want to make sure we review what Doug has said.  I too remember that we wanted to ensure that CAP objects remained iCalendar objects so they can be passed around via other methods if your calendar product does not have access to a CAP server.  Otherwise, no one will ! use the product.  If I can not be assured that my calendar request makes it to everyone I invite - why would I use the product.  Or am I missing something here.  I really wish some other folks would comment on these topics.  It would help the chairs and editors come to conclusions and resolutions.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


George Babics <georgeb@steltor.com>
Sent by: owner-ietf-calendar@mail.imc.org

01/24/02 11:43

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: 05 sendata -> beep.





Doug Royer wrote:
>
> George Babics wrote:
> >
> > Doug Royer wrote:
> >
> > > The CAP 'COMMANDS' were (05):
> > >
> > >         ABORT                   - now in CAP-BEEP   - GREAT
> > >         AUTHENTICATE            - part of BEEP      - EASY
> > >         CALIDEXPAND             - NOT in 06 at all  - and I don't care :-)
> >
> > >         CAPABILITY              - now in CAP-BEEP   - GREAT
> > >         CONTINUE                - now in CAP-BEEP   - GREAT
> > >         DISCONNECT              - part of BEEP - or is it MISSING?
> > >         IDENTIFY                - now in CAP-BEEP   - GREAT
> > >         SENDDATA                - NOT in 06 at all  - MISSING
> > >         STARTTLS                - part of BEEP      - EASY
> > >
> > >         UPNEXPAND               - NOT in 06 at all  -
> > >                 The was determined needed as viewed by the WG as a
> > >                 way to expand a group-UPN into its list of users so
> > >                 the CUA could determine who (non-group UPN) the command
> > >                 would effect.
> >
> >   Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG.
> >   See:
> >
> >     http://www.imc.org/ietf-calendar/mail-archive/msg02128.html
>
> First - I really don't care if they are gone. I never saw that
> they were needed.
>
> Second - one company agreeing with itself it not really that
> impressive of a reason :-)

This was agreed to, in a CAP conference call, by many people.
It was posted on the list to see if anyone else had objections
to removing them. No one else commented.

George

--=_alternative 0065C0A285256B4B_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 24 13:49:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01969 for ; Thu, 24 Jan 2002 13:49:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OIdSN04471 for ietf-calendar-bks; Thu, 24 Jan 2002 10:39: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 g0OIdR304464; Thu, 24 Jan 2002 10:39: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 NAA18540; Thu, 24 Jan 2002 13:39:23 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0OIdMQ03989; Thu, 24 Jan 2002 13:39:22 -0500 (EST) Message-ID: <3C5054DA.41C18BCB@steltor.com> Date: Thu, 24 Jan 2002 13:39:22 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: pregen@egenconsulting.com CC: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: 05 sendata -> beep. 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 Hi Pat, What I said in the e-mail was that during a CAP editors conference call, it was suggested we remove the UPNEXPAND and CALIDEXPAND commands. This suggestion was posted to the list, and no one objected removing them. Thus, we removed them from CAP. If someone does feel that the commands are necessary, please speak up and let us know! George pregen@egenconsulting.com wrote: > > George, in your reply to Doug you reference a conference call. The agreement in a conference call > must also be an agreement on the list. I'm not sure we do have agreement on this topic. Can you > repost it to the list - I know this sounds redundant. But I want to ensure we know the list reads > the item "explicitly" and we are sure everyone agrees. If no one comes back and says that what > you posted is wrong does not necessarily make it right. If one person comes back and says it is > wrong, first off, that person must defend why they believe that and then offer text or > explanations to prove that belief. Therefore, I really want to make sure we review what Doug has > said. I too remember that we wanted to ensure that CAP objects remained iCalendar objects so they > can be passed around via other methods if your calendar product does not have access to a CAP > server. Otherwise, no one will us! e the product. If I can not be assured that my calendar > request makes it to everyone I invite - why would I use the product. Or am I missing something > here. I really wish some other folks would comment on these topics. It would help the chairs and > editors come to conclusions and resolutions. > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 > > George Babics > Sent by: owner-ietf-calendar@mail.imc.org To: ietf-calendar@imc.org > cc: > 01/24/02 11:43 Subject: Re: 05 sendata -> beep. > > Doug Royer wrote: > > > > George Babics wrote: > > > > > > Doug Royer wrote: > > > > > > > The CAP 'COMMANDS' were (05): > > > > > > > > ABORT - now in CAP-BEEP - GREAT > > > > AUTHENTICATE - part of BEEP - EASY > > > > CALIDEXPAND - NOT in 06 at all - and I don't care :-) > > > > > > > CAPABILITY - now in CAP-BEEP - GREAT > > > > CONTINUE - now in CAP-BEEP - GREAT > > > > DISCONNECT - part of BEEP - or is it MISSING? > > > > IDENTIFY - now in CAP-BEEP - GREAT > > > > SENDDATA - NOT in 06 at all - MISSING > > > > STARTTLS - part of BEEP - EASY > > > > > > > > UPNEXPAND - NOT in 06 at all - > > > > The was determined needed as viewed by the WG as a > > > > way to expand a group-UPN into its list of users so > > > > the CUA could determine who (non-group UPN) the command > > > > would effect. > > > > > > Both UPNEXPAND and CALIDEXPAND were determined not to be needed, as viewed by the WG. > > > See: > > > > > > http://www.imc.org/ietf-calendar/mail-archive/msg02128.html > > > > First - I really don't care if they are gone. I never saw that > > they were needed. > > > > Second - one company agreeing with itself it not really that > > impressive of a reason :-) > > This was agreed to, in a CAP conference call, by many people. > It was posted on the list to see if anyone else had objections > to removing them. No one else commented. > > George From owner-ietf-calendar@mail.imc.org Thu Jan 24 14:59:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03925 for ; Thu, 24 Jan 2002 14:59:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0OJYeU06882 for ietf-calendar-bks; Thu, 24 Jan 2002 11:34: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 g0OJYd306877 for ; Thu, 24 Jan 2002 11:34: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 LAA01973 for ; Thu, 24 Jan 2002 11:34:40 -0800 (PST) Message-ID: <3C5061CB.2CC169A4@Royer.com> Date: Thu, 24 Jan 2002 12:34:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: 05 sendata -> beep. References: <3C5054DA.41C18BCB@steltor.com> Content-Type: multipart/mixed; boundary="------------3F16F1E166D6CF8358E61EC9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3F16F1E166D6CF8358E61EC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > If someone does feel that the commands are necessary, please speak up > and let us know! This is not an intent to agree or disagree. It is my intention to understand. After re-reading the email sent by Patrice, it appears that he was reading bogus text that was placed in 05. In Montreal we invented the 'USER GROUP' idea that is in CAP: User Group (UG) A collection of Calendar Users and/or User Groups. These groups are expanded by the CS and may reside either locally or in an external database or directory. The group membership may be fixed or dynamic over time. Then there was debate over how that effected UPNs and VCARs. Someone in effect asked: If a UPN is in fact a UG, how will I ever be able to manage my VCARs if I don't know who is in the UPN (UG) ?] How can I decide IF I want a UG in the list of CUs that I wish to restrict or allow if I don't know who is 'random-ug-name' ? So UPNEXPAND was invented. Now re-reading the 05 draft, the person that ADDED UPNEXPAND added the WRONG TEXT! They seem to have added the CALIDEXPAND text to the UPNEXPANT section - that was a large TYPO that seems to have never been caught until now. The UPNEXPAND command was a command to be handed any UPN. The results would be: (1) That UPN (if not a UG) OR (2) A list of UPNs that belonged to that list. So - the real question needs to be: DOES ANYONE CARE THAT A CUA CAN NOT FIND THE UPNs THAT ARE UG's ? Without UPNEXPAND - we should remove UG from CAP as there is no way to manage or know who they (UG's) are. As I recall, Bruce, Stelcor (then CS&T), Paul, and others wanted that feature. Those that wanted to do what is commonly called 'group calendaring' will care the most. Patrice Lapierre wrote in part ...: > > If that is the case, aren't the command CALIDEXPAND > and UPNEXPAND redundant. It seems that similar results > could be obtained by using a READ method combined with > a VQUERY that performs a selection on respectively > the PARENT and OWNER properties. > --------------3F16F1E166D6CF8358E61EC9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 24 Jan 2002 15:59:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0OKjc708184 for ietf-calendar-bks; Thu, 24 Jan 2002 12:45:38 -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 g0OKjb308179 for ; Thu, 24 Jan 2002 12:45:37 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA22015 for ; Thu, 24 Jan 2002 15:45:34 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0OKjYQ14539 for ; Thu, 24 Jan 2002 15:45:34 -0500 (EST) Message-ID: <3C5072CC.CD781807@steltor.com> Date: Thu, 24 Jan 2002 15:47:08 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 05 sendata -> beep. References: <3C5054DA.41C18BCB@steltor.com> <3C5061CB.2CC169A4@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: > > DOES ANYONE CARE THAT A CUA CAN NOT FIND THE UPNs THAT ARE UG's ? > > Without UPNEXPAND - we should remove UG from CAP as there > is no way to manage or know who they (UG's) are. I disagree. A calendar store is not a directory. CAP doesn't need to provide a way to find the members of calendar user groups, anymore than it needs to provide a way to get the list of users (i.e., UPNs) of a given CS. CUAs will simply have to query a directory service to find these information. It is already given that CUA will need to query a directory service to find the common name matching a given UPN (who's that guy with the UPN toto@example.com?). We need to keep UG in CAP. UGs greatly simplify access rights administration. 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 Jan 25 11:55:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07240 for ; Fri, 25 Jan 2002 11:55:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PGQa812766 for ietf-calendar-bks; Fri, 25 Jan 2002 08:26:36 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PGQZ312761 for ; Fri, 25 Jan 2002 08:26: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 IAA03529 for ; Fri, 25 Jan 2002 08:26:35 -0800 (PST) Message-ID: <3C518737.38596E8@Royer.com> Date: Fri, 25 Jan 2002 09:26:31 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: VCAR related proposal (off list)] Content-Type: multipart/mixed; boundary="------------9EFB330DBEE347A343DA2AB8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9EFB330DBEE347A343DA2AB8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I received a private reply from someone that wished to express a view about VCARs... I really understand his view, hopefully he will feel free and be enchouraged to post to the list. Doug Royer wrote: > > VCARs - any other specific 2445 object complient proposals? I think access rights should be associated with the session rather than with the user. It is simpler to implement them if they are done that way, and the by-user semantics are easier to implement in terms of by-session semantics than the other way around. I don't have the time to try to belabor this view on the list however. --------------9EFB330DBEE347A343DA2AB8 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Fri, 25 Jan 2002 12:14:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PGlmG13319 for ietf-calendar-bks; Fri, 25 Jan 2002 08:47:48 -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 g0PGll313313 for ; Fri, 25 Jan 2002 08:47:47 -0800 (PST) To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: Re: CAP by Minneapolis MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 25 Jan 2002 11:49:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/25/2002 11:47:49 AM, Serialize complete at 01/25/2002 11:47:49 AM Content-Type: multipart/alternative; boundary="=_alternative 005C2C4185256B4C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C2C4185256B4C_= Content-Type: text/plain; charset="US-ASCII" Pat wrote: >I think from all the notes flying by that we seem to have resolved the topic of SQL statements. Correct? Im not sure we do. I for one have been overwhelmed by the sheer volume of the threads in the last 2 weeks. Perhaps it would help if the combatants, err, posters could summarize whats still standing now that the dust is settled. > I also don't see much in the way of concensus except on SQL text. This is definitely NOT a concensus on SQL or SQL-like! As Ive noted at least 2 times in the past couple of weeks the WG _never_ agreed to use SQL as the query lingua. Search for my more recent postings or to a full text index of the archives. Perhaps some folks think we will change our minds after 2 years (see the 3 1999 WG minutes previously cited) if they perisist on claiming so... Bruce =========================================================================== New unit designation follows: Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005C2C4185256B4C_= Content-Type: text/html; charset="US-ASCII"
Pat wrote:
>I think from all the notes flying by that we seem to have resolved the topic of SQL statements. Correct?

Im not sure we do.  I for one have been overwhelmed by the sheer volume of the threads in the last 2 weeks.  Perhaps it would help if the combatants, err, posters could summarize whats still standing now that the dust is settled.

> I also don't see much in the way of concensus except on SQL text.

This is definitely NOT a concensus on SQL or SQL-like!  

As Ive noted at least 2 times in the past couple of weeks the WG _never_ agreed to use SQL as the query lingua.  Search for my more recent postings or to a full text index of the archives.  Perhaps some folks think we will change our minds after 2 years (see the 3 1999 WG minutes previously cited) if they perisist on claiming so...

Bruce
===========================================================================
New unit designation follows:
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005C2C4185256B4C_=-- From owner-ietf-calendar@mail.imc.org Fri Jan 25 12:16:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07997 for ; Fri, 25 Jan 2002 12:16:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PGuHd13575 for ietf-calendar-bks; Fri, 25 Jan 2002 08:56:17 -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 g0PGuG313571 for ; Fri, 25 Jan 2002 08:56:16 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: VCAR to seperate draft? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 25 Jan 2002 11:58:07 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/25/2002 11:56:18 AM, Serialize complete at 01/25/2002 11:56:18 AM Content-Type: multipart/alternative; boundary="=_alternative 005CF25585256B4C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CF25585256B4C_= Content-Type: text/plain; charset="US-ASCII" Doug replied: >I just sent out another email that included this topic. Ok, I know I've had some problems of late getting mail to/from the list due to the recent IBM assimilation but I dont see anything from Doug that looks like a new proposal. I waited a couple days but still nothing... Nothing in the archives either so could you please repost it? Bruce =========================================================================== New unit designation follows: Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005CF25585256B4C_= Content-Type: text/html; charset="US-ASCII"
Doug replied:
>I just sent out another email that included this topic.

Ok, I know I've had some problems of late getting mail to/from the list due to the recent IBM assimilation but I dont see anything from Doug that looks like a new proposal.  I waited a couple days but still nothing...  Nothing in the archives either so could you please repost it?

Bruce
===========================================================================
New unit designation follows:
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005CF25585256B4C_=-- From owner-ietf-calendar@mail.imc.org Fri Jan 25 12:42:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08836 for ; Fri, 25 Jan 2002 12:42:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PHNIo14395 for ietf-calendar-bks; Fri, 25 Jan 2002 09:23: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 g0PHNG314391 for ; Fri, 25 Jan 2002 09:23: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 MAA03644; Fri, 25 Jan 2002 12:23:12 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0PHNCQ25745; Fri, 25 Jan 2002 12:23:12 -0500 (EST) Message-ID: <3C51947F.95530CE6@steltor.com> Date: Fri, 25 Jan 2002 12:23:11 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: January 25th Editors Conference Call Summary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here is the summary of the editors conference call that took place on the 25th of January: Bob: The conference calls should be for "wordsmitting" and not to discuss design. The chair may decide to appoint a design team to tackle a particular problem. The design team, after finishing its work, would then make its proposal to the list. The posts to the list should be more readable to facilitate the participation of others. We do not want to lose our audience. George: We may want to follow Bruce's suggestion on always having an agenda for each conference call. Doug: We need to bring METHOD and TARGET back into the iCalendar object. George: We can keep the draft as it is, and in addition, add the METHOD and TARGET to the iCalendar objects. Doug: Will make such a proposal to the list. Doug: Need to bring down the byte overhead in CAP. It can be reduced by one third if we use CDATA rather than the "cids" (separate MIME objects). Will make a proposal to the list. From owner-ietf-calendar@mail.imc.org Sun Jan 27 16:33:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03658 for ; Sun, 27 Jan 2002 16:33:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0RLFOB06308 for ietf-calendar-bks; Sun, 27 Jan 2002 13:15: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 g0RLFM306303 for ; Sun, 27 Jan 2002 13:15: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 NAA06856 for ; Sun, 27 Jan 2002 13:15:22 -0800 (PST) Message-ID: <3C546DE4.94064E6B@Royer.com> Date: Sun, 27 Jan 2002 14:15:16 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: (#3) 4.1.1 Grammar for Search Mechanism Content-Type: multipart/mixed; boundary="------------FCDA7247679C1A3439456C4E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FCDA7247679C1A3439456C4E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attempt #3, PLEASE REVIEW o I added the '(' ')' expressions. o I changed the NOTES - PLEASE READ. o One of the notes that is NEW is how to compare DURATION and DTEND values and the fact that they are ONE SECOND off from each other. I thin that I have entered what the WG has had on this list on and off for over a year on this - PLEASE REVIEW. o Fixed typo's sent to me. -------------------------------------------------------------------------- 4.1.1 Grammar for Search Mechanism (1) All components look like tables for the purpose of a VQUERY including VALARM. And their contained properties looked like columns in those tables. (2) All VAGENDAs and CS's look like tables for the purpose of a VQUERY. And all of their properties look like columns in those tables. (3) You CAN NOT do any cross component-type joins. And that means you can ONLY have one component, OR one VAGENDA OR one CALSTORE in the the FROM clause. (4) Everything in the SELECT and WHERE clauses MUST be from the component type, or VAGENDA OR CALSTORE in the FROM clause. (5) The '.' means . when needed for contained properties or their associated contained components. As long as all were contained (as defined by iCalendar or CAP) in the SINGLE component type named in the FROM clause OR its contained component. (6) A contained component without a '.' it is the same as .* with the result being a properly formatted (s) in the data stream, and correctly formatted in the contained component(s) in iCalendar (RFC2445) format. VALID: (a) SELECT VEVENT. FROM VEVENT (b) SELECT VEVENT.VALARM FROM VEVENT (c) SELECT VALARM FROM VEVENT (d) SELECT VEVENT.* FROM VEVENT (e) SELECT * FROM VEVENT (f) SELECT * FROM VEVENT WHERE VALARM.TRIGGER < 20020201T000000Z AND VALARM.TRIGGER > 20020101T000000Z Note: (a) Selects all instances of from all VEVENTs. That (b), and (c) yield the same results. And that is select all VALARMS from all VEVENTS. Note that (d) does not enclose them in BEGIN/END VALARM because you selected the properties from the VALARM and not the VALARM. (e) Selects every property and every component that is in any VEVENTs. (f) Selects all properties and all contained components in all VEVENTS that have a VALARM with a TRIGGER property value between the provided dates and times. NOT VALID: (g) SELECT VEVENET.VALARM.TRIGGER FROM VEVENT (h) SELECT DTSTART,UID FROM VEVENT WHERE VTODO.SUMMERY = "Fix typo in CAP" Note: (g) Is NOT valid because it contains two '.' characters in the SELECT clause. (h) Is NOT valid because it mixes VEVENT and VTODO properties in the same VQUERY. 4.1.1.1 "VQUERY ABNF" NOTE: Properties in iCalendar objects can be in any order. This ABNF below specifies the valid contents of a BEGIN/END VQUERY. The ordering of the properties is not important. Any two VQUERY components that contain exactly the same properties in any random order are equivalent. search = "BEGIN:VQUERY" CRLF [expand] querycomp "END:VQUERY" CRLF # If not provided, EXPAND default to FALSE expand = "EXPAND" *(xparam) ":" ( "TRUE" / "FALSE") CRLF comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VAGENDA" / "VCAR" / "CALSTORE" / "VQUERY" / iana-name / x-name querycomp = queries / ( queryname queries) / queryname queryname = "QUERYNAME" *(xparam) ":" text CRLF queries = query / queries "," query query = "QUERY" *(xparam) ":" capselect CRLF # NOTE: There is exactly one space separating # the various parts of capselect # capselect = "SELECT" SP cap-cols SP "FROM" SP comp-name SP "WHERE" SP cap-expr / "SELECT" SP cap-cols SP "FROM" SP comp-name / "SELECT SP cap-cols SP "FROM" SP comp-name SP cap-uselist "WHERE" SP cap-expr cap-uselist = cap-using / cap-uselist "," cap-using cap-using = "USING_PROPERTIES" SP cap-col SP cap-local cap-col = # Any property name found in the component # named in the comp-tbl used in the FROM clause. # # SELECT ORGANIZER FROM VEVENT ... # # OR # # A component name of an existing component contained # inside of the cmp-tbl used in the FROM clause. # # SELECT VALARM FROM VEVENT ... # NOTE: there is NO space around the "," on # the next line cap-cols = ( cap-col / cap-col "," cap-cols ) / "*" cap-param = # Any parameter that may be contained in the cap-col # in the supplied PARM() function cap-local = # Any string that is composed of the characters # that could be a cap-col name, but is not any # cap-col name. It is suggested that the # string start with "x-" to ensure it does not # conflict with any existing or future cap-col name. # This name MUST BE defined in the cap-using and # can only be used in cap-expr of the same query. # And this name is only known and valid for the # provided query and only for the lifetime of # the query. If multiple QUERY properties exist # in the same VQUERY, it is only valid and usable # in the same QUERY property where it was supplied. col-literal = "'" literal-data "'" literal-data = # Any data that matches the value type of the # column that is being compared. That is you can # not compare PRIORITY to "some string" because # PRIORITY has a value type of integer. If it is # not preceded by the LIKE element, any '%' and '_' # characters in the literal data are not treated as # wildcard characters and do not have to be backslash # escaped. # # OR # # If the literal-data is preceded by the LIKE # element it may also contain the '%' and '_' # wildcard characters. And if the literal data # that is comparing contains any '%' or '_' characters, # they MUST BE backslash escaped as described in # the notes below in order for them not to be # treated as wildcard characters. cap-ucol = cap-col / cap-local cap-expr = "(" cap-expr ")" / cap-term cap-term = cap-expr SP cap-logical SP cap-expr / cap-factor cap-factor = cap-lhs SP cap-oper SP col-literal / cap-lhs SP "NOT LIKE" SP col-literal / cap-lhs SP "LIKE" SP col-literal / cap-lhs SP "IS NULL" / cap-lhs SP "IS NOT NULL" / "NOT CONTAINS(" cap-lhs "," col-literal ")" / "CONTAINS(" cap-lhs "," col-literal ")" cap-lhs = cap-ucol / "PARAM(" cap-ucol "," cap-param ")" cap-oper = "=" / "!=" / "<" / ">" / "<=" / ">=" cap-logical = "AND" / "OR" SP = # A single white space ascii character (value in HEX 0x20). 4.1.2 CAP-QL notes (1) There is no ORDERBY. Sorting will take place in the order the columns are supplied in the command. Float and integer values MUST BE sorted by their numeric value. This means the result of a sort on an integer value type will be: 1, 2, 100, 1000 and not 1, 100, 1000, 2 This means the result of a sort on an float value type will be: 1.1, 2.23, 100.332, 1000.12 and not 1.1, 100.332, 1000.12, 2.23 Date and date time values will be sorted by their equivalent value in UTC. No matter what the returned time zone in the result set returns. This is so that if multiple components are returned each in a unique time zone, the results will be sorted in UTC. This does not mean the values must be converted to UTC in the data returned to the CUA. It means the CS must do the sort in UTC. All other values are sorted according to the locale sorting order as specified in the calendar. Or the CS locale if the calendar does not have any locale set, or the host operating system locale if the CS does not specify a locale. And the locale to use for the sort is determined in that order. (2) The CS MUST sort at least the first column. The CS MAY sort additional columns. (3) If the cap-cols is only "*" and nothing else, then: If EXPAND=FALSE sorting will be by the DTSTART value ascending. If EXPAND=TRUE sorting will be by the RECURRENCE-ID value ascending. If one or more DTSTART or RECURRENCE-ID components have exactly the same value, the order for those matching components is unspecified. (4) All literal values are surrounded by single quotes ('), not double quotes ("), and not without any quotes. If the value contains quotes or any other ESCAPED-CHAR, they must be backslash escaped as described in section "4.3.11 Text" of RFC2445. Any LIKE wildcard characters that are part of any literal data that is preceded by a LIKE clause and is not intended to mean wildcard search, MUST BE escaped as described in not (7) below. (5) When comparing DATE-TIME to DATE value types and when comparing DATE to DATE-TIME value types, the result will be true if the DATE value is on the same day as the DATE-TIME value. And they are compared in UTC no matter what time zone the data may actual have been stored in. VALUE-1 VALUE-2 Compare Results 20020304 20020304T123456 TRUE (in UTC-3) (in UTC-3) 20020304 20020304T003456 FALSE (in UTC-4) (in UTC-4) 20020304T003456Z 20020205T003456 FALSE (in UTC-0) (in UTC-7) When comparing DATE and DATE-TIME values with the LIKE clause the comparison will be done as if the value is a RFC2445 DATE or DATE-TIME string value. LIKE '2002%' will match anything in the year 2002. LIKE '200201%' will match anything in January 2002. LIKE '%T000000' will match anything at midnight. LIKE '____01__T%' will match anything for any year or time that is in January. (Four '_', '01', two '_' 'T%'). Again all comparisons will be done in UTC. Using a LIKE value of "%00%, would return any value that contained two consecutive zeros. (6) DTEND and DURATION. When a VQUERY contains a DTEND value, then the CS MUST also evaluate any existing DURATION property value and determine if it has an effective end time that matches the VQUERY supplied DTEND value or any range of values supplied by the VQUERY. When a VQUERY contains a DURATION value, then the CS MUST also evaluate any existing DTEND property value and determine if it has an effective duration that matches the VQUERY supplied DURATION value or any range of values supplied by the VQUERY. As DTEND is the first time that is excluded from a components time range, any DURATION supplied by the VQUERY that is exactly one second less than DTEND MUST match the VQUERY. And if the DURATION ends exactly at the computed DTEND it MUST NOT match. Any DTEND supplied by the VQUERY that is exactly one second more than an end time computed from a DURATION MUST match the VQUERY. Any end time that is computed from a DURATION that exactly matches the supplied DTEND MUST NOT match. (6.1) Given a meeting room reserved with a component that contains: DTSTART:20020127T000000Z DTEND:20020127T010000Z The reservation is really from January 27th, 2002 00:00:00 to January 27th, 2002,00:59:59 (6.2) Given another meeting room reserved with a component that contains: DTSTART:20020127T000000Z DURATION:P59M59S The reservation is really from January 27th, 2002 00:00:00 to January 27th, 2002,00:59:59 (6.3) A VQUERY that contains: ... VEVENT.DTSTART = '20020127T00000' AND VEVENT.DTEND = '20020127T010000' MUST match both (6.1) and (6.2). (6.4) A VQUERY that contains: ... VEVENT.DTSTART = '20020127T00000' AND DURATION = 'P59M59S' MUST match both (6.1) and (6.2). (7) [NOT] LIKE notes: The pattern matching characters is the '%' that matches zero or more characters, and '_' that matches exactly one character (where character does not always mean octet). LIKE pattern matches always cover the entire string. To match a pattern anywhere within a string, the pattern must start and end with a percent sign. To match a '%' or '_' in the data and not have it interpreted as a wildcard character, they must be backslash escaped. That is to search for a '%' or '_' in the string: LIKE '%\%%' Matches any string with a '%' in it. LIKE '%\_%' Matches any string with a '_' in it. Strings compared using the LIKE clause MUST BE performed using case in-sensitive comparisons. ('a' = 'A'). If LIKE is preceded by 'NOT' then there is a match when the string compare fails. (8) [NOT] "CONTAINS(" cap-lhs "," col-literal ")" This is similar to the LIKE element, except it does value matching and not string comparison matches. property:value1,value2 CONTAINS(property, 'value1') would match CONTAINS(property, 'value') would NOT match LIKE(property, 'value%') would match The CS must understand the objects being compared and understand how to determine how any multi valued property or parameter values are separated, quoted, and backslash escaped and perform the comparisons as if each value existed by itself and not quoted or backslash escaped when comparing using the CONTAINS() element. If CONTAINS() is preceded by 'NOT' then there is a match when the value does not exist in the property or parameter value. --------------FCDA7247679C1A3439456C4E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 10:46:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SFTeO06971 for ietf-calendar-bks; Mon, 28 Jan 2002 07:29: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 g0SFTc306967 for ; Mon, 28 Jan 2002 07:29:38 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA28853 for ; Mon, 28 Jan 2002 10:29:34 -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 g0SFTXQ26634 for ; Mon, 28 Jan 2002 10:29:33 -0500 (EST) Message-ID: <3C556EAA.F182BB60@steltor.com> Date: Mon, 28 Jan 2002 10:30:50 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCARs - any other specific proposals? References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@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 As promised, here's my proposal that addresses the issues that were recently brought to the attention of the list. Highlight of changes: - Changed the GRANT and DENY properties to only specify the CUs and UGs to which the specified access right applies. - Added new property PERMISSION to specify the permissions being granted or denied. - Added new property SCOPE to specify the objects in the CS to which the access right applies by using CAP-QL as the selection mechanism. - Added new property RESTRICTION to specify restrictions on the submitted values. - Added new property NAME to specify a localizable display name for VCAR components. This was already proposed and agreed on the list. - Multiple instances of the properties GRANT, DENY, PERMISSION, SCOPE, and RESTRICTION may be present in VCAR components. - A VCAR component, as defined in this proposal, can only define a single access right. If there is a need to group multiple access rights in a single VCAR (e.g., to share the same CARID and/or NAME properties) we could always group the properties GRANT, DENY, PERMISSION, SCOPE, and RESTRICTION in a component (e.g., VRIGHT). --------------------------------------------------------------------- 11.3 VCAR Calendar Component Component Name: "VCAR" Purpose: Provide a grouping of component properties that describe an access right. Format Definition: A "VCAR" calendar component is defined by the following notation: carc = "BEGIN" ":" "VCAR" CRLF carprop "END" ":" "VCAR" CRLF carprop = 1*( ; the following are optional, ; but MUST NOT occur more than once carid / name / ; permission MUST occur at least once ; and MAY occur more than once permission / ; the following are optional, ; and MAY occur more than once grant / deny / scope / restriction / x-prop ) Description: A "VCAR" calendar component is a grouping of calendar access rights component properties. The "CARID" property specifies the local identifier for the "VCAR" calendar component. The "NAME" property specifies a localizable display name. The "GRANT" property specifies the UPN to whom a calendar access right is granted. The "DENY" property specifies the UPN to whom a calendar access right is denied. The "PERMISSION" property specifies the actual permission being set. The "SCOPE" property identifies the calendar store properties, calendar properties, calendar components, component properties to which the access right applies. The "RESTRICTION" property specifies restrictions on the submitted values. Example: In the following example, the UPN "foo@host.com" is given read access to the "DTSTART" and "DTEND" calendar properties. No othe access is specified: BEGIN:VCAR NAME:"View Start and End Times" GRANT:foo@host.com PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VCAR In this example, all UPNs are given read access to "DTSTART" and "DTEND". "All CUs and UGs" are specified by the UPN value "*". Note that this enumerated UPN value is not in quotes: BEGIN:VCAR NAME:"View Start and End Times 2" GRANT:* PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT END:VCAR In this example, rights are specified for all UPNs to read components classified as PUBLIC: BEGIN:VCAR NAME:"View PUBLIC Start and End Times" GRANT:* PERMISSION:READ SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' END:VCAR In this example, rights are specified for all UPNs to read or modify existing components classified as PUBLIC: BEGIN:VCAR NAME:"Read and Modify PUBLIC Calendar Entries" GRANT:* PERMISSION:READ PERMISSION:MODIFY SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC' END:VCAR In these examples, full calendar access rights are given to the OWNER and a hypothetical administrator is given access rights to specify calendar access rights. If no other rights are specified, only these two UPNs can specify calendar access rights: BEGIN:VCAR NAME:"Owner full calendar access rights" GRANT:OWNER PERMISSION:* SCOPE:SELECT * FROM VEVENT SCOPE:SELECT * FROM VTODO SCOPE:SELECT * FROM VJOURNAL SCOPE:SELECT * FROM VTIMEZONE SCOPE:SELECT * FROM VALARM SCOPE:SELECT * FROM VFREEBUSY SCOPE:SELECT * FROM VAGENDA SCOPE:SELECT * FROM VQUERY SCOPE:SELECT * FROM VCAR END:VCAR BEGIN:VCAR NAME:"ADMIN Settable CARs" GRANT:cal-admin@host.com PERMISSION:* SCOPE:SELECT * FROM VCAR END:VCAR In this example, rights to write, read, modify or delete calendar access rights are denied to all UPNs. This example would disable providing different access rights to the calendar store or calendar. This calendar access rights should not be specified, as they the ability to change calendar access; even for the owner or administrator: BEGIN:VCAR NAME:"No CAR At All" DENY:* SCOPE:SELECT * FROM VCAR END:VCAR 11.4 VCAR Grant Component Property Property Name: GRANT Purpose: This property identifies the CU or UG being granted access in the VCAR object. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VCAR" calendar components. Description: This property is used in the "VCAR" calendar component to specify the CU or UG being granted access. Format Definition: The property is defined by the following notation: grant = "GRANT" upnparam ":" upnvalue CRLF upnparam = *( ";" xparam ) upnvalue = ( "OWNER" / "NONOWNER" / text / all ) all = "*" Example: The following are examples of this property: GRANT:* GRANT:bob@example.com 11.5 VCAR Deny Component Property Property Name: DENY Purpose: This property identifies the CU or UG being denied access in the VCAR object. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VCAR" calendar components. Description: This property is used in the "VCAR" calendar component to define the CU or UG being denied access. Format Definition: The property is defined by the following notation: deny = "DENY" upnparam ":" upnvalue CRLF Example: The following are examples of this property: DENY:* DENY:bob@example.com 11.6 VCAR Identifier Component Property Property Name: CARID Purpose: This property specifies the identifier for a "VCAR" calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VCAR" calendar components. Description: This property is used in the "VCAR" calendar component to specify an identifier. Format Definition: The property is defined by the following notation: carid = "CARID" textparam ":" text CRLF Example: The following is an example of this property: CARID:REQUESTONLY 11.6 VCAR Name Component Property Property Name: NAME Purpose: This property provides a localizable display name for a "VCAR" calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VCAR" calendar components. Description: This property is used in the "VCAR" calendar component to specify a localizable display name. Format Definition: The property is defined by the following notation: name = "NAME" nameparam ":" text CRLF nameparam = *( ; the following is optional, ; but MUST NOT occur more than once ( ";" languageparam ) / ; the following is optional, ; and MAY occur more than once ( ";" xparam ) ) Example: The following is an example of this property: NAME:"Restrict Guests From Creating ALARMs On Events" 11.7 VCAR Permission Component Property Property Name: PERMISSION Purpose: This property defines a permission that is granted or denied in a VCAR component. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VCAR" calendar components. Description: This property is used in the "VCAR" calendar component to define a permission that is granted or denied. Format Definition: The property is defined by the following notation: perm = "PERMISSION" permparam ":" permvalue CRLF permparam = *( ";" xparam ) permvalue = ( "READ" / "WRITE" / "DELETE" / "MODIFY" / all ) all = "*" Example: The following is an example of this property: PERMISSION:READ 11.8 VCAR Scope Component Property Property Name: SCOPE Purpose: This property identifies the objects to which the access rights applies. Value Type: capselect Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VCAR" calendar components. Description: This property is used in the "VCAR" calendar component to define the set of objects subject to the access right being defined. Format Definition: The property is defined by the following notation: scope = "SCOPE" scopeparam ":" capselect CRLF scopeparam = *( ";" xparam ) Example: The following is an example of this property: SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' 11.9 VCAR Restrictions Component Property Property Name: RESTRICTION Purpose: This property defines restrictions on the submitted values for objects. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VCAR" calendar components. Description: This property is used in the "VCAR" calendar component to define restrictions on the submitted values. Format Definition: The property is defined by the following notation: restrict = "RESTRICTION" restrictparam ":" restrictvalue CRLF restrictparam = *( ";" xparam ) restrictvalue = [ cap-uselist "WHERE" SP ] cap-expr Example: The following are examples of this property: RESTRICTION:METHOD = 'REQUEST' RESTRICTION:ORGANIZER = SELF() RESTRICTION:CONTAINS(CATEGORIES,'BUSINESS') ------------------------------------------------------------------------ [Editor's Note: The purpose of predefined CARID needs to be specified. ] Predefined calendar access CARIDs that MUST be implemented (CAR-MIN) are: CARID:READBUSYTIMEINFO - grants all authenticated users the right to read VFREEBUSY components. BEGIN:VCAR CARID:READBUSYTIMEINFO GRANT:* PERMISSION:READ SCOPE:SELECT * FROM VFREEBUSY END:VCAR CARID:REQUESTONLY - grants to users other than the owner of the calendar the right to write new events with the property METHOD set to REQUEST. BEGIN:VCAR CARID:REQUESTONLY GRANT:NONOWNER PERMISSION:WRITE RESTRICTION:METHOD = 'REQUEST' END:VCAR CARID:UPDATEPARTSTATUS - grants all authenticated users the right to modify the PARTSTAT parameter of ATTENDEE property set to themselves. BEGIN:VCAR CARID:UPDATEPARTSTATUS GRANT:* PERMISSION:MODIFY SCOPE:SELECT ATTENDEE FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() RESTRICTION:ATTENDEE = SELF() END:VCAR CARID:DEFAULTOWNER - grants to the owner all permissions on all the objects in the calendar. BEGIN:VCAR CARID:DEFAULTOWNER GRANT:OWNER PERMISSION:* SCOPE:SELECT * FROM VEVENT SCOPE:SELECT * FROM VTODO SCOPE:SELECT * FROM VJOURNAL SCOPE:SELECT * FROM VTIMEZONE SCOPE:SELECT * FROM VALARM SCOPE:SELECT * FROM VFREEBUSY SCOPE:SELECT * FROM VAGENDA SCOPE:SELECT * FROM VQUERY SCOPE:SELECT * FROM VCAR END:VCAR --------------------------------------------------------------------- Restriction table Component/Property Presence Comment ------------------- -------- ------------------------- . . VCAR 0+ . . . CARID 0 or 1 . . . NAME 0 or 1 . . . PERMISSION 1+ . . . DENY 0+ Note, there must be at least one GRANT or DENY within the VCAR. . . . GRANT 0+ Note, there must be at least one GRANT or DENY within the VCAR. . . . SCOPE 0+ Note, there must be at least one SCOPE if PERMISSION:READ or PERMISSION:DELETE is specified . . . RESTRICTION 0 or 0+ Note, allowed only if PERMISSION:WRITE and/or PERMISSION:MODIFY are/is present. . . . X-PROPERTY 0+ . . . [IANA-PROP] 0+ any IANA registered property --------------------------------------------------------------------- Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Mon Jan 28 11:23:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01346 for ; Mon, 28 Jan 2002 11:23:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SG61k11016 for ietf-calendar-bks; Mon, 28 Jan 2002 08:06:01 -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 g0SG5u311009 for ; Mon, 28 Jan 2002 08:06:00 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Jan 2002 11:12:40 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/28/2002 11:04:39 AM, Serialize complete at 01/28/2002 11:04:39 AM Content-Type: multipart/alternative; boundary="=_alternative 0058464685256B4F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058464685256B4F_= Content-Type: text/plain; charset="US-ASCII" Doug posited: > (1) All components look like tables for the purpose of > a VQUERY including VALARM. And their contained properties > looked like columns in those tables. Just how are property parameters (ie: PART-STAT=Declined, X-LDC-BLECH=ALWAYS or SENT-BY="mailto:Bruce@fizbin.com") to be organized / treated? Its not unlikely that querying on a property parameter is going to be desireable / necessary so the spec / model needs to be to address it. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0058464685256B4F_= Content-Type: text/html; charset="US-ASCII"
Doug posited:
>  (1) All components look like tables for the purpose of
>      a VQUERY including VALARM. And their contained properties
>      looked like columns in those tables.
Just how are property parameters (ie: PART-STAT=Declined, X-LDC-BLECH=ALWAYS or SENT-BY="mailto:Bruce@fizbin.com") to be organized / treated?  

Its not unlikely that querying on a property parameter is going to be desireable / necessary so the spec / model needs to be to address it.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0058464685256B4F_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 28 11:25:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01412 for ; Mon, 28 Jan 2002 11:25:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SGCKa11344 for ietf-calendar-bks; Mon, 28 Jan 2002 08:12:20 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SGCI311340 for ; Mon, 28 Jan 2002 08:12:19 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA29858 for ; Mon, 28 Jan 2002 11:12:15 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0SGCEQ00507 for ; Mon, 28 Jan 2002 11:12:14 -0500 (EST) Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C546DE4.94064E6B@Royer.com> References: <3C546DE4.94064E6B@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 28 Jan 2002 11:20:15 -0500 Message-Id: <1012234815.2000.41.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Sun, 2002-01-27 at 16:15, Doug Royer wrote: > Attempt #3, PLEASE REVIEW Looks good, I think we are not far from a working proposition. I included some suggestions and corrections in the text below. >... > > (4) Everything in the SELECT and WHERE clauses MUST be from the > component type, or VAGENDA OR CALSTORE in the FROM clause. I don't think this point is necessary, the ABNF should be enough. The word "everything" also seems too strong, the WHERE clause accepts expressions and its elements can also include identifiers from the USING_PROPERTIES clause. > (f) SELECT * FROM VEVENT WHERE > VALARM.TRIGGER < 20020201T000000Z > AND VALARM.TRIGGER > 20020101T000000Z 1. According to ABNF cap-literal must be quoted: (f) SELECT * FROM VEVENT WHERE VALARM.TRIGGER < '20020201T000000Z' AND VALARM.TRIGGER > '20020101T000000Z' 2. As mentioned previously be Alan, I think that the example is ambiguous, we don't know that the two sub-expressions refers to the same VALARM. It was recommended that a new USING_COMPONENTS could be used to address this issue (I included the construct in the ABNF below). I would also suggest that the "SELECT" clause should accept identifiers from USING_COMPONENTS and USING_PROPERTIES. e.g., To return only the matching VALARM of a VEVENT: SELECT alarm FROM VEVENT USING_COMPONENTS VALARM alarm WHERE alarm.TRIGGER < '20020201T000000Z' AND alarm.TRIGGER > '20020101T000000Z' To return only the matching ATTENDEE SELECT att, DTSTART, DTEND FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = 'relcalid@example.com' >... > NOT VALID: > > (g) SELECT VEVENET.VALARM.TRIGGER FROM VEVENT Typo: should be VEVENT (not VEVENET). > > (h) SELECT DTSTART,UID FROM VEVENT WHERE > VTODO.SUMMERY = "Fix typo in CAP" Typo: should be SUMMARY. > > 4.1.1.1 "VQUERY ABNF" ... > queryname = "QUERYNAME" *(xparam) ":" text CRLF Should be: queryname = "QUERYNAME" *(";" xparam) ":" text CRLF > > queries = query > / queries "," query The "," makes it invalid iCalendar. queries = 1*( query ) *** NOTE *** : Multiple QUERY properties in a VQUERY is a new addition. I'm not opposed, however I can see some potential side effects that were not mentioned: - Are the result of different QUERYs returned in the same VCALENDAR? - What is the orderings of the returned components? > capselect = "SELECT" SP cap-cols SP Must also support: SELECT VEVENT.VALARM SELECT VEVENT.* > "FROM" SP comp-name SP comp-name won't accept VEVENT.VALARM. > ... > > cap-uselist = cap-using > / cap-uselist "," cap-using > > cap-using = "USING_PROPERTIES" SP cap-col SP cap-local To be consistent with other SQL clauses the proposition was: USING_PROPERTIES ATTENDEE att1, ATTENDEE att1 not USING_PROPERTIES ATTENDEE att1, USING_PROPERTIES ATTENDEE att2 >... > cap-param = # Any parameter that may be contained in the cap-col > # in the supplied PARM() function Typo: should be PARAM() not PARM() > cap-local = # Any string that is composed of the characters > # that could be a cap-col name, but is not any > # cap-col name. It is suggested that the > # string start with "x-" to ensure it does not > # conflict with any existing or future cap-col name. > # This name MUST BE defined in the cap-using and > # can only be used in cap-cmps of the same query. > # And this name is only known and valid for the > # provided query and only for the lifetime of > # the query. Local identifiers prefixed with "x-" won't ensure that there is no conflict. The simplest way to resolve this issue is simply stating the local identifiers introduced in the USING_PROPERTIES clause have precedence over the other properties. ------------------------------------------------------------ Here's the ABNF with the modifications mentioned above and following additions: - Support for an arbitrary number of spaces between tokens. - Add the USING_COMPONENTS clause. - SELECT clause can accept identifiers declared in USING_PROPERTIES and USING_COMPONENTS - Use ';' instead of '#' for comments (to conform to RFC2234). - cap-col was used both rhs the WHERE and the SELECT clause. However in the WHERE clause component should not be accepted. - Add definitions to elements that contained only comments (reuse definitions found in RFC2445). search = "BEGIN:VQUERY" CRLF [ expand ] querycomp "END:VQUERY" CRLF ; If not provided, EXPAND default to FALSE expand = "EXPAND" *( ";" xparam) ":" ( "TRUE" / "FALSE" ) CRLF comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VAGENDA" / "VCAR" / "CALSTORE" / "VQUERY" / iana-name / x-name querycomp = queries / ( queryname queries ) / queryname queryname = "QUERYNAME" *(";" xparam) ":" text CRLF queries = query *( "," query ) query = "QUERY" *(";" xparam) ":" capselect CRLF capselect = "SELECT" 1*WSP cap-select-elems 1*WSP "FROM" 1*WSP cap-from-elem 1*WSP [ cap-using-components 1*WSP ] [ cap-using-properties 1*WSP ] "WHERE" 1*WSP cap-expr / "SELECT" 1*WSP cap-select-elems 1*WSP "FROM" 1*WSP cap-from-elem cap-using-components = "USING_COMPONENTS" 1*WSP cap-local-comps cap-local-comps = cap-local-comp *( *WSP "," *WSP cap-local-comp ) cap-local-comp = comp-name 1*WSP cap-comp-identifier cap-comp-identifier = iana-token / x-token ; identifier declared in the USING_COMPONENTS clause cap-using-properties = "USING_PROPERTIES" 1*WSP cap-local-props cap-local-props = cap-local-prop *( *WSP "," *WSP cap-local-prop ) cap-local-prop = cap-prop 1*WSP cap-prop-identifier cap-prop-identifier = iana-token / x-token ; identifier declared in the USING_PROPERTIES clauses. cap-comp = comp-name *( "." comp-name ) ; component name (e.g., VEVENT.VALARM) / cap-comp-identifier ; Identifier declared in the USING_COMPONENTS clause. ; NOTE: when an identifier of the USING_COMPONENTS has ; the same name as a component, the identifier has ; precedence and hides the components name in the ; query. cap-select-elems = cap-select-elem *( *WSP "," *WSP cap-select-elem ) cap-select-elem = cap-col / "*" / cap-comp [ ".*" ] ; A component name of an existing component ; contained inside of the cap-comp used in the ; FROM clause. ; ; e.g., SELECT VALARM FROM VEVENT ... name = x-name / iana-token ; name of a property as defined in RFC2445 cap-prop = [ cap-comp "." ] name ; Any property name found in the component ; named in the cap-from-elem used in the FROM clause. cap-col = [ cap-comp "." ] name / cap-prop-identifier ; Identifier defined in the USING_PROPERTIES clause. ; NOTE: The identifiers of the USING_PROPERTIES clause ; have precedence over the property name. cap-from-elem = comp-name *( "." comp-name ) col-literal = "'" literal-data "'" literal-data = text ; Any data that matches the value type of the ; column that is being compared. That is you can ; not compare PRIORITY to "some string" because ; PRIORITY has a value type of integer. ; like-expr = "'" text "'" ; The characters '%' and '_' are wildcard characters. ; To match literally match '%' or '_', they ; MUST BE backslash escaped as described in ; the notes below in order for them not to be ; treated as wildcard characters. cap-expr = "(" *WSP cap-expr *WSP ")" / cap-term cap-term = cap-expr 1*WSP cap-logical 1*WSP cap-expr / cap-factor cap-factor = cap-lhs 1*WSP cap-oper 1*WSP col-literal / cap-lhs 1*WSP [ "NOT" 1*WSP ] "LIKE" 1*WSP like-expr / cap-lhs 1*WSP "IS" [ 1*WSP "NOT" ] 1*WSP "NULL" / [ "NOT" 1*WSP ] "CONTAINS" *WSP "(" *WSP cap-lhs *WSP "," *WSP col-literal *WSP ")" cap-lhs = cap-col / "PARAM" *WSP "(" *WSP cap-col *WSP "," *WSP param-name *WSP ")" param-name = iana-token / x-token cap-oper = "=" / "!=" / "<" / ">" / "<=" / ">=" cap-logical = "AND" / "OR" SP = %x20 ; space HTAB = %x09 ; horizontal tab WSP = SP / HTAB From owner-ietf-calendar@mail.imc.org Mon Jan 28 11:30:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01633 for ; Mon, 28 Jan 2002 11:30:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SGFwt11434 for ietf-calendar-bks; Mon, 28 Jan 2002 08:15:58 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SGFv311430 for ; Mon, 28 Jan 2002 08:15:58 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Jan 2002 11:22:45 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/28/2002 11:14:36 AM, Serialize complete at 01/28/2002 11:14:36 AM Content-Type: multipart/alternative; boundary="=_alternative 005932A185256B4F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005932A185256B4F_= Content-Type: text/plain; charset="US-ASCII" Doug proposed: > (6) A contained component without a '.' it is the same as > .* with the result being a properly formatted > (s) in the data stream, and correctly formatted > in the contained component(s) in iCalendar (RFC2445) format. [Snip, snip] > (b) SELECT VEVENT.VALARM FROM VEVENT > > (c) SELECT VALARM FROM VEVENT > > (d) SELECT VEVENT.* FROM VEVENT [Snip, snip] > That (b), (c), and (d) yield the same results. > And that is select all VALARMS from all VEVENTS. Hmm, I was following this up until that last bit but I disagree w/it. (b) and (c) are equivalent but (d) is not. I see (d) as returning all properties of the VEVENT AND any associated VALARMs contained on the VEVENT. That means that the ATTENDEE list, SUMMARY, DTSTART, etc of the VEVENT are also returned, not just the contained VALARM. Or am I just misreading the text for (6) somehow?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005932A185256B4F_= Content-Type: text/html; charset="US-ASCII"
Doug proposed:
>  (6) A contained component without a '.' it is the same as
>      <component>.* with the result being a properly formatted
>      <component>(s) in the data stream, and correctly formatted
>      in the contained component(s) in iCalendar (RFC2445) format.
[Snip, snip]
>                (b) SELECT VEVENT.VALARM FROM VEVENT
>
>                (c) SELECT VALARM FROM VEVENT
>
>                (d) SELECT VEVENT.* FROM VEVENT
[Snip, snip]
>                      That (b), (c), and (d) yield the same results.
>                      And that is select all VALARMS from all VEVENTS.
Hmm, I was following this up until that last bit but I disagree w/it.  (b) and (c) are equivalent but (d) is not.  I see (d) as returning all properties of the VEVENT AND any associated VALARMs contained on the VEVENT.  That means that the ATTENDEE list, SUMMARY, DTSTART, etc of the VEVENT are also returned, not just the contained VALARM.  Or am I just misreading the text for (6) somehow??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005932A185256B4F_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 28 11:37:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01869 for ; Mon, 28 Jan 2002 11:37:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SGOGp11670 for ietf-calendar-bks; Mon, 28 Jan 2002 08:24: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 g0SGOF311665 for ; Mon, 28 Jan 2002 08:24: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 LAA30229 for ; Mon, 28 Jan 2002 11:24:11 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0SGOAQ01519 for ; Mon, 28 Jan 2002 11:24:10 -0500 (EST) Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 28 Jan 2002 11:32:11 -0500 Message-Id: <1012235531.2000.54.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The proposition includes the PARAM() function for this purpose: e.g., SELECT * FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE PARAM( att, 'PARTSTAT' ) = 'DECLINED' On Mon, 2002-01-28 at 11:12, Bruce_Kahn@notesdev.ibm.com wrote: > Doug posited: > > (1) All components look like tables for the purpose of > > a VQUERY including VALARM. And their contained properties > > looked like columns in those tables. > > Just how are property parameters (ie: PART-STAT=Declined, > X-LDC-BLECH=ALWAYS or SENT-BY="mailto:Bruce@fizbin.com") to be organized / > treated? > > Its not unlikely that querying on a property parameter is going to be > desireable / necessary so the spec / model needs to be to address it. > > Bruce > ps. Bruce, sorry for involuntarily replying to your mailbox instead of the list. From owner-ietf-calendar@mail.imc.org Mon Jan 28 12:10:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02793 for ; Mon, 28 Jan 2002 12:10:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SGsZ812413 for ietf-calendar-bks; Mon, 28 Jan 2002 08:54:35 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SGsY312403 for ; Mon, 28 Jan 2002 08:54: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 IAA07879 for ; Mon, 28 Jan 2002 08:54:34 -0800 (PST) Message-ID: <3C558246.6A61F95B@Royer.com> Date: Mon, 28 Jan 2002 09:54:30 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 CC: "ietf-calendar@imc.org" Subject: Re: (RESTRICTION) VCARs - any other specific proposals? References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> Content-Type: multipart/mixed; boundary="------------F9059C93B7E2A4DCDB26287A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F9059C93B7E2A4DCDB26287A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I don't understand the RESTRICTION property. Bernard Desruisseaux wrote: > 11.9 VCAR Restrictions Component Property > > Property Name: RESTRICTION > > Purpose: This property defines restrictions on the submitted > values for objects. As in "restrict them - and they must match" ? Or "restrict them - and they must NOT match" ? > Example: The following are examples of this property: So the restriction is that these must match ? Or is the restruction is that they must not match? > RESTRICTION:METHOD = 'REQUEST' > > RESTRICTION:ORGANIZER = SELF() > > RESTRICTION:CONTAINS(CATEGORIES,'BUSINESS') In this example, it seems to be saying that METHOD MUST equal REQUEST. > CARID:REQUESTONLY - grants to users other than the owner of > the calendar the right to write new events with the property > METHOD set to REQUEST. BEGIN:VCAR CARID:REQUESTONLY GRANT:NONOWNER PERMISSION:WRITE RESTRICTION:METHOD = 'REQUEST' END:VCAR Below the RESTRICTION property seems to duplicate the SCOPE, the results of the SELECT would only return SELF, so what does the RESTRICTION property do here? > CARID:UPDATEPARTSTATUS - grants all authenticated users the > right to modify the PARTSTAT parameter of ATTENDEE property > set to themselves. > > BEGIN:VCAR > CARID:UPDATEPARTSTATUS > GRANT:* > PERMISSION:MODIFY > SCOPE:SELECT ATTENDEE FROM VEVENT > USING_PROPERTIES ATTENDEE att > WHERE att = SELF() > RESTRICTION:ATTENDEE = SELF() > END:VCAR --------------F9059C93B7E2A4DCDB26287A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 12:42:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SHQnb13335 for ietf-calendar-bks; Mon, 28 Jan 2002 09:26:49 -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 g0SHQm313331 for ; Mon, 28 Jan 2002 09:26:48 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Jan 2002 12:33:32 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/28/2002 12:25:27 PM, Serialize complete at 01/28/2002 12:25:27 PM Content-Type: multipart/alternative; boundary="=_alternative 005FAD7885256B4F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005FAD7885256B4F_= Content-Type: text/plain; charset="US-ASCII" Doug wrote: > (f) SELECT * FROM VEVENT WHERE > TRIGGER < 20020201T000000Z > AND TRIGGER > 20020101T000000Z A couple of things. First, you should have text in the Note section that follows the example describing what case (f) is trying to do (esp. since it relates to the NOT VALID case (h) below it). Second, if the example is corrected to be: (f) SELECT * FROM VEVENT WHERE VALARM.TRIGGER < 20020201T000000Z AND VALARM.TRIGGER > 20020101T000000Z as previously noted then there appears to be an implicit assumption in the query that anything in the WHERE clause is contained w/in the entity given in the FROM clause. That is, a VALARM is contained w/in a VEVENT. Is this a correct assumption? Item (4)is not 100% clear on the issue of containment but I suspect it was intended to include it (by deriving it by applying (1) to the logic). It has an impact on how future expansion of the model goes as well as how the CS handles data scoping of the query. That is, if someone adds a new VWHIZBANG component that is contained w/in a VEVENT then a CUA could easly query based on its values by simply substituting VWHIZBANG for VALARM in the example above. All is just happy and fine. However when I want to do something like search for RELATED-TO entities, it is murky as to how I would query a VAGENDA for any entry w/a "UID:ABCDEF12345". That is, I perform the search in (f) and I find that it has a RELATED-TO property on it. I now want to find the related entity for any one of a number of reasons.. The related component may be a VEVENT, VTODO, VJOURNAL or some as yet defined entity (ie: VFUBAR). The simplest approach is to do multiple searches, 1 for each entity type but that assumes the CUA knows about every available entity. However, I would expect that because of the containment design of VAGENDA->(VEVENT / VTODO / VJOURNAL / VFUBAR) that I could specify a search much like (f) but its not clear if I can wildcard the component type. Would: (x) SELECT * FROM VAGENDA WHERE *.UID = "ABCDEF12345" be doable / legal?? Alternately my CUA could try to find the component that the VEVENT is RELATED-TO by making multiple queries like: (x1) SELECT * FROM VEVENT WHERE UID = "ABCDEF12345" if that fails to find a result then try: (x2) SELECT * FROM VTODO WHERE UID = "ABCDEF12345" if that fails to find a result then try: (x3) SELECT * FROM VJOURNAL WHERE UID = "ABCDEF12345" if that fails to find a result then tell the user that the RELATED-TO component is not found (when in fact it does exist but the CUA does not know to check for VFUBAR components in the VAGENDA). Granted my CUA my not grok whats in a VFUBAR but if it follows the RFC 2445 formatting convention it should be able to at least parse and identify its properties, parameters, etc. This is different from claiming that "the RELATED-TO link is 'broken' because no linked entry can be found." Just a thought about future possible crocs. Im not sure the best way to address this yet but perhaps others do... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005FAD7885256B4F_= Content-Type: text/html; charset="US-ASCII"
Doug wrote:
>                (f) SELECT * FROM VEVENT WHERE
>                     TRIGGER < 20020201T000000Z
>                     AND TRIGGER > 20020101T000000Z
A couple of things.  First, you should have text in the Note section that follows the example describing what case (f) is trying to do (esp. since it relates to the NOT VALID case (h) below it).  Second, if the example is corrected to be:

                (f) SELECT * FROM VEVENT WHERE
                    VALARM.TRIGGER < 20020201T000000Z
                    AND VALARM.TRIGGER > 20020101T000000Z
as previously noted then there appears to be an implicit assumption in the query that anything in the WHERE clause is contained w/in the entity given in the FROM clause.  That is, a VALARM is contained w/in a VEVENT.  Is this a correct assumption?  Item (4)is not 100% clear on the issue of containment but I suspect it was intended to include it (by deriving it by applying (1) to the logic).

It has an impact on how future expansion of the model goes as well as how the CS handles data scoping of the query.  That is, if someone adds a new VWHIZBANG component that is contained w/in a VEVENT then a CUA could easly query based on its values by simply substituting VWHIZBANG for VALARM in the example above.  All is just happy and fine.

However when I want to do something like search for RELATED-TO entities, it is murky as to how I would query a VAGENDA for any entry w/a "UID:ABCDEF12345".  That is, I perform the search in (f) and I find that it has a RELATED-TO property on it.  I now want to find the related entity for any one of a number of reasons..  The related component may be a VEVENT, VTODO, VJOURNAL or some as yet defined entity (ie: VFUBAR).  

The simplest approach is to do multiple searches, 1 for each entity type but that assumes the CUA knows about every available entity.  However, I would expect that because of the containment design of VAGENDA->(VEVENT / VTODO / VJOURNAL / VFUBAR) that I could specify a search much like (f) but its not clear if I can wildcard the component type.  Would:

                (x) SELECT * FROM VAGENDA WHERE
                    *.UID = "ABCDEF12345"
be doable / legal??  Alternately my CUA could try to find the component that the VEVENT is RELATED-TO by making multiple queries like:

                (x1) SELECT * FROM VEVENT WHERE
                    UID = "ABCDEF12345"
if that fails to find a result then try:

                (x2) SELECT * FROM VTODO WHERE
                    UID = "ABCDEF12345"
if that fails to find a result then try:

                (x3) SELECT * FROM VJOURNAL WHERE
                    UID = "ABCDEF12345"
if that fails to find a result then tell the user that the RELATED-TO component is not found (when in fact it does exist but the CUA does not know to check for VFUBAR components in the VAGENDA).  

Granted my CUA my not grok whats in a VFUBAR but if it follows the RFC 2445 formatting convention it should be able to at least parse and identify its properties, parameters, etc.  This is different from claiming that "the RELATED-TO link is 'broken' because no linked entry can be found."

Just a thought about future possible crocs.  Im not sure the best way to address this yet but perhaps others do...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005FAD7885256B4F_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 28 12:47:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03806 for ; Mon, 28 Jan 2002 12:47:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SHPMK13290 for ietf-calendar-bks; Mon, 28 Jan 2002 09:25:22 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SHPL313286 for ; Mon, 28 Jan 2002 09:25:21 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA31680 for ; Mon, 28 Jan 2002 12:25:17 -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 g0SHPGQ07053 for ; Mon, 28 Jan 2002 12:25:17 -0500 (EST) Message-ID: <3C5589EC.BD82855@steltor.com> Date: Mon, 28 Jan 2002 12:27:08 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (RESTRICTION) VCARs - any other specific proposals? References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C558246.6A61F95B@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > I don't understand the RESTRICTION property. > > Bernard Desruisseaux wrote: > > > 11.9 VCAR Restrictions Component Property > > > > Property Name: RESTRICTION > > > > Purpose: This property defines restrictions on the submitted > > values for objects. > > As in "restrict them - and they must match" ? > Or "restrict them - and they must NOT match" ? As in "restrict them - and they must match". > > > Example: The following are examples of this property: > > So the restriction is that these must match ? > Or is the restruction is that they must not match? That these must match. > > > RESTRICTION:METHOD = 'REQUEST' > > > > RESTRICTION:ORGANIZER = SELF() > > > > RESTRICTION:CONTAINS(CATEGORIES,'BUSINESS') > > In this example, it seems to be saying that METHOD MUST equal REQUEST. > > > CARID:REQUESTONLY - grants to users other than the owner of > > the calendar the right to write new events with the property > > METHOD set to REQUEST. > > BEGIN:VCAR > CARID:REQUESTONLY > GRANT:NONOWNER > PERMISSION:WRITE > RESTRICTION:METHOD = 'REQUEST' > END:VCAR Non-owner are only granted the right to write objects that have the property METHOD set to REQUEST. > > Below the RESTRICTION property seems to duplicate the SCOPE, the > results of the SELECT would only return SELF, so what does the > RESTRICTION property do here? > > > CARID:UPDATEPARTSTATUS - grants all authenticated users the > > right to modify the PARTSTAT parameter of ATTENDEE property > > set to themselves. > > > > BEGIN:VCAR > > CARID:UPDATEPARTSTATUS > > GRANT:* > > PERMISSION:MODIFY > > SCOPE:SELECT ATTENDEE FROM VEVENT > > USING_PROPERTIES ATTENDEE att > > WHERE att = SELF() > > RESTRICTION:ATTENDEE = SELF() > > END:VCAR Here, the SCOPE property specifies that you are allowed to modify the ATTENDEE property that matches SELF. While the RESTRICTION property simply ensure that you are not going to change the value of the ATTENDEE property to some other value than SELF, that is, you'll be allowed to change the value of the parameter of the property but not its value. If the CAP-QL change previously proposed by Alan, and mentionned by Patrice today, is adopted, we could also improve the definition of our SCOPE property as follows : SCOPE:SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() 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 Jan 28 12:52:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03950 for ; Mon, 28 Jan 2002 12:52:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SHdBa13664 for ietf-calendar-bks; Mon, 28 Jan 2002 09:39:11 -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 g0SHdA313659 for ; Mon, 28 Jan 2002 09:39:10 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA30721; Mon, 28 Jan 2002 11:35:54 -0600 From: "Shannon J. Clark" To: "Bernard Desruisseaux" , Subject: RE: VCARs - any other specific proposals? Date: Mon, 28 Jan 2002 11:38:50 -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: <3C556EAA.F182BB60@steltor.com> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bernard, Thanks. Just a minor suggestion to make sorting and locating documents easier - we should all probably be in the habit of including in our subject line (and probably in the body text as well) the specific document to which we are suggesting making changes - this way it will be easier for editors and interested parties to locate all the letters dealing with CAP. In fact if we were to somewhere make note of the version of the document we were either editing (or quoting from) this would also help everyone keep track of the conversations. Again thanks for all of your efforts - when I get some free time in the next few weeks I plan on reviewing the current draft of CAP to see how I would go about implementing it. thanks, Shannon From owner-ietf-calendar@mail.imc.org Mon Jan 28 13:20:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04917 for ; Mon, 28 Jan 2002 13:20:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SI4pn14305 for ietf-calendar-bks; Mon, 28 Jan 2002 10:04: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 g0SI4n314301 for ; Mon, 28 Jan 2002 10:04:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA07966 for ; Mon, 28 Jan 2002 10:04:49 -0800 (PST) Message-ID: <3C5592BC.6DEA8E2A@Royer.com> Date: Mon, 28 Jan 2002 11:04:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: incomplete UPN restrictions in VCARs References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> Content-Type: multipart/mixed; boundary="------------ED31C3729759A84781961CCA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ED31C3729759A84781961CCA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (1) I noticed Bernard called SELF a function 'SELF()' and not 'SELF'. Are you proposing a change, or is this a typo? I like the idea, but lets do it to all of the non-literal values if we do it for any: OWNER() NONOWNER() SELF() Anything else? (1.1) For clarification, do we want to rename SELF() to AUTHENTICATED(), CURRENT-UPN(), or sometning? (2) And perhaps the anonymous - (and without much thought). After trying to specify some non-local-domain restrictions this weekend, the existing ANONYMOUS value is difficult to restrict local and non-local UPNs (anonymous or not) From the UPN section, a CU can login as anonymous and it says what their UPN is. @domain Anonymous from named domain only. @ Anonymous from any domain. And VCAR allows: * Any UPN - does that include anonymous? And how do you specify in a VCAR that you will only allow UPN's *connecting from* a specific domain? As in: I want UPN 'DEMO@ROYER.COM' to have FULL access if "connecting from inside of" ROYER.COM, but read only access (or no-access) when 'connecting from' outside the named domain. A UPN name is an authentication 'ID' but it makes no assertion about where it is coming *from* at the time it is connecting. This is NOT a proposal for the login ID's in the UPN section. This is a proposal for how to specify the UPN restrictions IN A VCAR. Below I'll use 'Cdomain' to mean the domain they are connecting from (that that has nothing to do with their UPN-domain or UPN-realm): Where DELETE means remove it from the VCAR section. And ADD means add it to the VCAR section. Meaning -- ---- DELETE * Any UPN - anonymous or not connecting from any domain. DELETE @ anonymous connecting from any domain. DELETE @domain anonymous@domain connecting from any domain. ADD ANY() Any known non-anonymous UPN connecting from any domain. GRANT:ANY() DENY:ANY() ADD ANY(@Cdomain) Any known non-anonymous UPN BUT ONLY IF connecting from the named domain. GRANT:ANY(@local-sub-net) DENY:ANY(@hacked-me.com) ADD ANONYMOUS() Any anonymous UPN that is connecting from any domain. GRANT:ANONYMOUS() DENY:ANONYMOUS() ADD ANONYMOUS(@Cdomain) Any anonymous UPN that is connecting from the NAMED domain. Allow anonymous from my-domain.com, but not from bogus.my-domain.com. GRANT:ANONYMOUS(@royer.com) DENY:ANONYOMUS(@bogus.royer.com) GRANT:ANONYMOUS(@trusted-domain.com) So, if I authenticate with: @royer.com But I am connecting from 'bogus.royer.com, I will have less access based on the contents of the entire VCAR. ADD UPN(named, @Cdomain) Known UPN, But only of connecting from domain. As in: Allow UPN doug@royer.com, but only if connecting from the named domains. GRANT:UPN(doug@royer.com, royer.com) GRANT:UPN(doug@royer.com, inet-consulting.com) DENY:UPN(doug@royer.com, tried-to-hack-me.com) no-change As before, allow named UPN: GRANT:doug@royer.com DENY:NOT doug@royer.com ADD NOT And allow 'NOT' to be placed in front of any of them. (3) Our VCARs did not allow us to specify an action of LOGIN: So do we want to allow something like this to be specified in a VCAR? (note new 'LOGIN' pseudo table who's contents is simply a list of UPN's): (And Bernard forgive me and correct me if I have not got all of the proposals syntax correct): BEGIN:VCAR NAME:"Named UPS that can log in to this system" GRANT:ANY(@local-domain.com) GRANT:ANONYMOUS() PERMISSION:* SCOPE:SELECT * LOGIN WHERE UPN=SELF(); END:VCAR --------------ED31C3729759A84781961CCA Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 16:50:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SLa4K19762 for ietf-calendar-bks; Mon, 28 Jan 2002 13:36:04 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SLa2319757 for ; Mon, 28 Jan 2002 13:36: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 QAA04745 for ; Mon, 28 Jan 2002 16:35:59 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0SLZxQ29019 for ; Mon, 28 Jan 2002 16:35:59 -0500 (EST) Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 28 Jan 2002 16:43:59 -0500 Message-Id: <1012254239.2000.109.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Mon, 2002-01-28 at 12:33, Bruce_Kahn@notesdev.ibm.com wrote: > ... > However when I want to do something like search for RELATED-TO entities, > it is murky as to how I would query a VAGENDA for any entry w/a > "UID:ABCDEF12345". That is, I perform the search in (f) and I find that > it has a RELATED-TO property on it. I now want to find the related entity > for any one of a number of reasons.. The related component may be a > VEVENT, VTODO, VJOURNAL or some as yet defined entity (ie: VFUBAR). > > The simplest approach is to do multiple searches, 1 for each entity type > but that assumes the CUA knows about every available entity. However, I > would expect that because of the containment design of VAGENDA->(VEVENT / > VTODO / VJOURNAL / VFUBAR) that I could specify a search much like (f) but > its not clear if I can wildcard the component type. Would: > > (x) SELECT * FROM VAGENDA WHERE > *.UID = "ABCDEF12345" > > be doable / legal?? AFAIK it's not currently legal with the current proposition. > Alternately my CUA could try to find the component > that the VEVENT is RELATED-TO by making multiple queries like: > > (x1) SELECT * FROM VEVENT WHERE > UID = "ABCDEF12345" > > if that fails to find a result then try: > > (x2) SELECT * FROM VTODO WHERE > UID = "ABCDEF12345" > > if that fails to find a result then try: > > (x3) SELECT * FROM VJOURNAL WHERE > UID = "ABCDEF12345" > Another alternative (not currently legal) would be to allow a wildcard (*) in the FROM clause. e.g, SELECT * FROM * WHERE UID = "ABCDEF12345" Such a construct could also be useful for Bernard's proposition for VCARs (i.e., single SCOPE properties for many component types). > ... From owner-ietf-calendar@mail.imc.org Mon Jan 28 17:43:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10411 for ; Mon, 28 Jan 2002 17:43:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SMOr921034 for ietf-calendar-bks; Mon, 28 Jan 2002 14:24:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SMOp321029 for ; Mon, 28 Jan 2002 14:24: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 OAA08327 for ; Mon, 28 Jan 2002 14:24:51 -0800 (PST) Message-ID: <3C55CFAC.27D0F1A7@Royer.com> Date: Mon, 28 Jan 2002 15:24:44 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism References: <1012254239.2000.109.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------D5EC7D31BFBED0631C599460" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D5EC7D31BFBED0631C599460 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > Another alternative (not currently legal) would be to allow a > wildcard (*) in the FROM clause. > > e.g, SELECT * FROM * WHERE UID = "ABCDEF12345" > > Such a construct could also be useful for Bernard's proposition > for VCARs (i.e., single SCOPE properties for many component types). One of the debates over the last proposal was (just over the last few weeks) is that people did NOT wat to have to figure out how to do cross-component joins. Now you are proposing them again? If so, stay with SQL-MIN - it allowed them, well just add the PARAM() funciton and we are back were we started. -Doug --------------D5EC7D31BFBED0631C599460 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 17:45:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SMXDG21356 for ietf-calendar-bks; Mon, 28 Jan 2002 14:33:13 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SMXC321349 for ; Mon, 28 Jan 2002 14:33: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 OAA08338 for ; Mon, 28 Jan 2002 14:33:13 -0800 (PST) Message-ID: <3C55D1A2.695569A2@Royer.com> Date: Mon, 28 Jan 2002 15:33:06 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (RESTRICTION) VCARs - any other specific proposals? References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C558246.6A61F95B@Royer.com> <3C5589EC.BD82855@steltor.com> Content-Type: multipart/mixed; boundary="------------02C978DCCC968F27E0C75DC5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------02C978DCCC968F27E0C75DC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Here, the SCOPE property specifies that you are allowed > to modify the ATTENDEE property that matches SELF. While > the RESTRICTION property simply ensure that you are not > going to change the value of the ATTENDEE property to > some other value than SELF, that is, you'll be allowed > to change the value of the parameter of the property but > not its value. So you are saying that RESTRICTION only applied to WRITE? > If the CAP-QL change previously proposed by Alan, and > mentionned by Patrice today, is adopted, we could also > improve the definition of our SCOPE property as follows : Why is this improved? It looks the same to me except it require more code. I see no advantage at all. > SCOPE:SELECT att FROM VEVENT > USING_PROPERTIES ATTENDEE att > WHERE att = SELF() > --------------02C978DCCC968F27E0C75DC5 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 18:02:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SMmlj21807 for ietf-calendar-bks; Mon, 28 Jan 2002 14:48: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 g0SMmj321803 for ; Mon, 28 Jan 2002 14:48:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA08362 for ; Mon, 28 Jan 2002 14:48:47 -0800 (PST) Message-ID: <3C55D548.CC26FAA4@Royer.com> Date: Mon, 28 Jan 2002 15:48:40 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism References: Content-Type: multipart/mixed; boundary="------------D8BC1216CBFF936B40D0A21F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D8BC1216CBFF936B40D0A21F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > The simplest approach is to do multiple searches, 1 for each entity > type but that assumes the CUA knows about every available entity. > However, I would expect that because of the containment design of > VAGENDA->(VEVENT / VTODO / VJOURNAL / VFUBAR) that I could specify a > search much like (f) but its not clear if I can wildcard the component > type. Would: > > (x) SELECT * FROM VAGENDA WHERE > *.UID = "ABCDEF12345" > be doable / legal?? This WG seems to have opted out for cross component joins. So, no; not doable. > Alternately my CUA could try to find the > component that the VEVENT is RELATED-TO by making multiple queries > like: > > (x1) SELECT * FROM VEVENT WHERE > UID = "ABCDEF12345" > > if that fails to find a result then try: > > (x2) SELECT * FROM VTODO WHERE > UID = "ABCDEF12345" > > if that fails to find a result then try: > > (x3) SELECT * FROM VJOURNAL WHERE > UID = "ABCDEF12345" Or do them in ONE VQUERY: BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = 'ABCDEF12345' QUERY:SELECT * FROM VTODO WHERE UID = 'ABCDEF12345' QUERY:SELECT * FROM VJOURNAL WHERE UID = 'ABCDEF12345' END:VQUERY > if that fails to find a result then tell the user that the RELATED-TO > component is not found (when in fact it does exist but the CUA does > not know to check for VFUBAR components in the VAGENDA). Or the data provieded is bogus in the original component. Or perhaps you don't have access to that UID and the VCARs don't even allow you to know that it is there. > Granted my CUA my not grok whats in a VFUBAR but if it follows the RFC > 2445 formatting convention it should be able to at least parse and > identify its properties, parameters, etc. This is different from > claiming that "the RELATED-TO link is 'broken' because no linked entry > can be found." Unless is does not exist, how would you ever know if we don't require that they be valid? What if the RELATED-TO component has been deleted? --------------D8BC1216CBFF936B40D0A21F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 19:04:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SNqDo23299 for ietf-calendar-bks; Mon, 28 Jan 2002 15:52: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 g0SNqC323295 for ; Mon, 28 Jan 2002 15:52: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 SAA06708 for ; Mon, 28 Jan 2002 18:52:10 -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 g0SNq9Q09073 for ; Mon, 28 Jan 2002 18:52:09 -0500 (EST) Message-Id: <5.1.0.14.0.20020128184823.01a9e678@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Jan 2002 18:55:46 -0500 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism In-Reply-To: <3C55D548.CC26FAA4@Royer.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:48 PM 28/01/2002 -0700, Doug Royer wrote: >Bruce_Kahn@notesdev.ibm.com wrote: > > search much like (f) but its not clear if I can wildcard the component > > type. Would: > > > > (x) SELECT * FROM VAGENDA WHERE > > *.UID = "ABCDEF12345" > > be doable / legal?? > >This WG seems to have opted out for cross component joins. >So, no; not doable. I don't see that that's an example of a cross-component join; it's really just misuse of the "*", which should only be used as part of the SELECT clause. There aren't really any common operations that need cross-component joins, and the few half sensible ones could be completed with multiple queries anyway (e.g. "find all of the Events whose Attendees are also Attendees of a given Event"). >Or do them in ONE VQUERY: > > BEGIN:VQUERY > QUERY:SELECT * FROM VEVENT WHERE UID = 'ABCDEF12345' > QUERY:SELECT * FROM VTODO WHERE UID = 'ABCDEF12345' > QUERY:SELECT * FROM VJOURNAL WHERE UID = 'ABCDEF12345' > END:VQUERY This seemed a much clearer and more flexible way to specify the "select from whichever component matches" type of operation. --Alan From owner-ietf-calendar@mail.imc.org Mon Jan 28 19:05:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11648 for ; Mon, 28 Jan 2002 19:05:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SNpSm23275 for ietf-calendar-bks; Mon, 28 Jan 2002 15:51:28 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SNpR323271 for ; Mon, 28 Jan 2002 15:51: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 PAA08451 for ; Mon, 28 Jan 2002 15:51:28 -0800 (PST) Message-ID: <3C55E3F8.D7BB794D@Royer.com> Date: Mon, 28 Jan 2002 16:51:20 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Byte reduction in BEEP commands. Content-Type: multipart/mixed; boundary="------------B92A8FF57AE724FF99597F89" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B92A8FF57AE724FF99597F89 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When NOT synching calendars, the command byte overhead used in draft 06 exceeds the size of the data. If we switch to CDATA and eliminate what I will call a couple of "wrapper tag"s, the byte count goes way down. (And I thought that XML (or XSL, XSLT...) reserved the 'id' tag) Just as an example, I'll use "3.3 Bounded Latency ", followed by brief examples of the other commands. I also propose changing the REPLY from the CS to be an EMPTY BEEP reply for success. Eliminating the the not needed 2.0 success code. If the BEEP reply contains any data, then parse that iCalendar data. THIS IS JUST A PROPOSAL FOR THE *IDEA*, PLEASE DO NOT PICK APART ALL OF THE SYNTAX. IF THERE ARE NO SERIOUS PROBLEMS, I'LL SPEND TIME TO MAKE A FULL PROPOSAL! - Thanks! Put the METHOD, TARGET, and optional CMDID back into the data. (Assume they are in these brief examples). Change the command in the existing example: FROM: C: Content-Type: multipart/related; boundary="boundary-zxy123"; C: start="1@cal.example.com"; C: type="application/beep+xml" C: C: --boundary-zxy123 C: Content-Type: application/beep+xml C: Content-ID: 1@cal.example.com C: C: C: C: C: C: --boundary-zxy123 C: Content-Type: text/calendar C: Content-ID: 2@cal.example.com C: C: BEGIN:VCALENDAR C: BEGIN:VQUERY C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT C: WHERE DTEND >= '19990714T080000Z' AND C: DTSTART <= '19990715T080000Z' C: END:VQUERY C: END:VCALENDAR TO: C:Content-Type: application/...beep... C: C: C: = '19990714T080000' AND C: DTSTART <= '19990715T080000' C: END:VQUERY C: END:VCALENDAR C: ]]> ----------------------------------------------------------- [ Assume all of the following examples have the MIME and BEEP MIME headers...] ----------------------------------------------------------- 6.1.1 "generate-uid" Command [remove the and tags> in the reply. TO: C: S: 20011121T120000Z-12342@cal.example.com S: 20011121T120000Z-12343@cal.example.com S: 20011121T120000Z-12344@cal.example.com -------------------------------------------------------------- And I changed the names to MATCH (case) the iCalendar objects. As iCalendar objects are upper case, the same named objects should be here. And I upper cased the new ones in CAP to be consistent with iCalendar. And I changed the names of the CAPABILITY replies to be the same as the PROPERTY names they map to (same case). There is a typo in 06 on the name of date max and date min. 6.1.2 "get-capability" Command C: S:1.0 S:bla bla bla S:... S:CAR-FULL-1 S:00000101T000000Z S:99991231T235959Z S:0 S:1.0 ----------------------------------------------------------------- 6.1.3 "identify" Command There was NO example for IDENTIFY, so I propose: C: S: ...empty BEEP RPY is success... S: ...else CAP error message in BEEP CDATA reply... 6.1.4 "noop" Command C: S: ...empty BEEP RPY is success... S: ...else CAP error message in BEEP CDATA reply... ------------------------------------------------------------------- 6.2.4.1 "create" Command C: S: ...empty BEEP RPY is success... S: ...else CAP error message in BEEP CDATA reply... ------------------------------------------------------------------- 6.2.4.2 "delete" Command C: S: ...empty BEEP RPY is success... S: ...else CAP error message in BEEP CDATA reply... ------------------------------------------------------------------- Plus change the MODIFY iCalendar objects back to the way they were in the 05 draft. C: S: ...empty BEEP RPY is success... S: ...else CAP error message in BEEP CDATA reply... ------------------------------------------------------------------- 6.2.4.4 "move" Command C: S: ...empty BEEP RPY is success... S: ...else CAP error message in BEEP CDATA reply... ------------------------------------------------------------------- 6.2.4.5 "search" Command C: S: ... the reply data in BEEP CDATA... ------------------------------------------------------------------- Drop this section entirely. As the METHOD is now back in the iCalendar objects, just deposit them with the command into the CS. 6.3 Scheduling Commands 6.3.1 "schedule" Command 6.3.2 Processing Scheduling Components A CUA processes iTIP data, the CS just stores them. Change to description on how the CUA performs VQUERY to get the data that has been deposited. Drop the command. ------------------------------------------------------------------- --------------B92A8FF57AE724FF99597F89 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 19:16:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T03UJ23596 for ietf-calendar-bks; Mon, 28 Jan 2002 16:03:30 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T03T323592 for ; Mon, 28 Jan 2002 16:03:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA08473 for ; Mon, 28 Jan 2002 16:03:31 -0800 (PST) Message-ID: <3C55E6CB.42D5E1A9@Royer.com> Date: Mon, 28 Jan 2002 17:03:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCARs - any other specific proposals? References: Content-Type: multipart/mixed; boundary="------------7D864EF70B95305F92CD4FD6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7D864EF70B95305F92CD4FD6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > Bernard, > > Thanks. Just a minor suggestion to make sorting and locating documents > easier - we should all probably be in the habit of including in our subject > line (and probably in the body text as well) the specific document to which > we are suggesting making changes What other document contains VCARs? --------------7D864EF70B95305F92CD4FD6 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 19:26:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0T0BlD23965 for ietf-calendar-bks; Mon, 28 Jan 2002 16:11: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 g0T0Bi323955 for ; Mon, 28 Jan 2002 16:11:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA08495 for ; Mon, 28 Jan 2002 16:11:46 -0800 (PST) Message-ID: <3C55E8BA.623748AC@Royer.com> Date: Mon, 28 Jan 2002 17:11:38 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------EC214798B7E6C288B8855323" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EC214798B7E6C288B8855323 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > queries = query > > / queries "," query > > The "," makes it invalid iCalendar. > > queries = 1*( query ) > > > *** NOTE *** : Multiple QUERY properties in a VQUERY is a new addition. > > I'm not opposed, however I can see some potential side effects that > were not mentioned: It was discussed - just never made it into the ABNF before. > - Are the result of different QUERYs returned in the same VCALENDAR? As if two seperate VQUERYs had been submitted. > - What is the orderings of the returned components? Same as if two seperate VQUERYs had been submitted. --------------EC214798B7E6C288B8855323 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 19:30:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T0GJT24137 for ietf-calendar-bks; Mon, 28 Jan 2002 16:16: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 g0T0GI324133 for ; Mon, 28 Jan 2002 16:16:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA08499 for ; Mon, 28 Jan 2002 16:16:20 -0800 (PST) Message-ID: <3C55E9CC.1F209DE5@Royer.com> Date: Mon, 28 Jan 2002 17:16:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------3D0C1B1D5EAF308907C1F67D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3D0C1B1D5EAF308907C1F67D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > >... > > cap-param = # Any parameter that may be contained in the cap-col > > # in the supplied PARM() function > > Typo: should be PARAM() not PARM() > > > cap-local = # Any string that is composed of the characters > > # that could be a cap-col name, but is not any > > # cap-col name. It is suggested that the > > # string start with "x-" to ensure it does not > > # conflict with any existing or future cap-col name. > > # This name MUST BE defined in the cap-using and > > # can only be used in cap-cmps of the same query. > > # And this name is only known and valid for the > > # provided query and only for the lifetime of > > # the query. > > Local identifiers prefixed with "x-" won't ensure that there is no > conflict. The simplest way to resolve this issue is simply stating the > local identifiers introduced in the USING_PROPERTIES clause have > precedence over the other properties. That will not work. What if: SELECT * FROM VEVENT USING_PROPERTIES ATTENDEE att1, ATTENDEE att1 And what if 'att1' is a (future) valid PROPERTY name? We need to make sure that they are not valid future IANA names. If not with 'X-', then how about 'L-' for LOCAL names? And we reserve L- names to be local to VQUERY only? --------------3D0C1B1D5EAF308907C1F67D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 19:51:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T0dZr24621 for ietf-calendar-bks; Mon, 28 Jan 2002 16:39: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 g0T0dX324616 for ; Mon, 28 Jan 2002 16:39:33 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA31312 for ; Mon, 28 Jan 2002 18:36:41 -0600 From: "Shannon J. Clark" To: Subject: RE: VCARs - any other specific proposals? Date: Mon, 28 Jan 2002 18:39:47 -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: <3C55E6CB.42D5E1A9@Royer.com> Importance: Normal 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 Well there was a proposal back a while ago to consider making it a separate document, and there was some discussion back and forth about whether the new structure (VCAR) meant that changes needed to be made to 2445 - this was resolved by agreeing not to make changes to the core iCalendar standard but rather to have the changes documented in CAP as extensions that CAP requires - but my overall point is that some clarity and search capabilities are lost when we don't document which document our discussions are covering. i.e. if you were a developer implementing CAP in an ideal world you should be able to get to all of the threads that cover CAP related items with a search for CAP (or iCalendar/2445 or iMIP etc) overall the level of posts in the past few weeks is quite impressive - thanks to everyone who are rapidly documenting and ironing out the unclear areas. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Monday, January 28, 2002 6:03 PM To: ietf-calendar@imc.org Subject: Re: VCARs - any other specific proposals? "Shannon J. Clark" wrote: > > Bernard, > > Thanks. Just a minor suggestion to make sorting and locating documents > easier - we should all probably be in the habit of including in our subject > line (and probably in the body text as well) the specific document to which > we are suggesting making changes What other document contains VCARs? From owner-ietf-calendar@mail.imc.org Mon Jan 28 19:56:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12379 for ; Mon, 28 Jan 2002 19:56:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0T0in424768 for ietf-calendar-bks; Mon, 28 Jan 2002 16:44:49 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T0il324763 for ; Mon, 28 Jan 2002 16:44:47 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id TAA07221 for ; Mon, 28 Jan 2002 19:44:45 -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 g0T0ijQ12293; Mon, 28 Jan 2002 19:44:45 -0500 (EST) Message-Id: <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Jan 2002 19:48:21 -0500 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" From: Alan Davies Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism In-Reply-To: <3C55E9CC.1F209DE5@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:16 PM 28/01/2002 -0700, Doug Royer wrote: >Patrice Lapierre wrote: > > Local identifiers prefixed with "x-" won't ensure that there is no > > conflict. The simplest way to resolve this issue is simply stating the > > local identifiers introduced in the USING_PROPERTIES clause have > > precedence over the other properties. > >That will not work. What if: > > SELECT * FROM VEVENT > USING_PROPERTIES ATTENDEE att1, ATTENDEE att1 > >And what if 'att1' is a (future) valid PROPERTY name? Then the att1 property would be ignored in this query, because "local identifiers introduced in the USING_PROPERTIES clause have precedence over the other properties". If the creator of the query wanted to refer to the "att1" property, they could just use different USING_PROPERTIES identifier names for the ATTENDEEs. Why won't it work? --Alan From owner-ietf-calendar@mail.imc.org Mon Jan 28 20:09:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12564 for ; Mon, 28 Jan 2002 20:09:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T0qnd25074 for ietf-calendar-bks; Mon, 28 Jan 2002 16:52:49 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T0qm325069 for ; Mon, 28 Jan 2002 16:52:48 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id TAA07258 for ; Mon, 28 Jan 2002 19:52:46 -0500 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0T0qjQ12838 for ; Mon, 28 Jan 2002 19:52:45 -0500 (EST) Message-Id: <5.1.0.14.0.20020128195027.0354b098@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Jan 2002 19:56:22 -0500 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism In-Reply-To: <3C546DE4.94064E6B@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:15 PM 27/01/2002 -0700, Doug Royer wrote: > capselect = "SELECT" SP cap-cols SP > "FROM" SP comp-name SP > "WHERE" SP cap-expr > > / "SELECT" SP cap-cols SP > "FROM" SP comp-name > > / "SELECT SP cap-cols SP > "FROM" SP comp-name SP > cap-uselist > "WHERE" SP cap-expr > > cap-uselist = cap-using > / cap-uselist "," cap-using > > cap-using = "USING_PROPERTIES" SP cap-col SP cap-local I think this would be clearer, and correct an error in cap-using: capselect = "SELECT" SP cap-cols SP "FROM" SP comp-name / "SELECT" SP cap-cols SP "FROM" SP comp-name SP "WHERE" SP cap-expr / "SELECT SP cap-cols SP "FROM" SP comp-name SP "USING_PROPERTIES" SP cap-uselist SP "WHERE" SP cap-expr cap-uselist = cap-using / cap-uselist "," cap-using cap-using = cap-col SP cap-local --Alan From owner-ietf-calendar@mail.imc.org Mon Jan 28 20:44:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13384 for ; Mon, 28 Jan 2002 20:44:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T1WqS26001 for ietf-calendar-bks; Mon, 28 Jan 2002 17:32: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 g0T1Wp325997 for ; Mon, 28 Jan 2002 17:32: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 RAA08612 for ; Mon, 28 Jan 2002 17:32:54 -0800 (PST) Message-ID: <3C55FBBD.66357702@Royer.com> Date: Mon, 28 Jan 2002 18:32:45 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------3025CF0C337C9AAC2BDE21BE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3025CF0C337C9AAC2BDE21BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > > At 05:16 PM 28/01/2002 -0700, Doug Royer wrote: > >Patrice Lapierre wrote: > > > Local identifiers prefixed with "x-" won't ensure that there is no > > > conflict. The simplest way to resolve this issue is simply stating the > > > local identifiers introduced in the USING_PROPERTIES clause have > > > precedence over the other properties. > > > >That will not work. What if: > > > > SELECT * FROM VEVENT > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att1 > > > >And what if 'att1' is a (future) valid PROPERTY name? > > Then the att1 property would be ignored in this query, because "local > identifiers introduced in the USING_PROPERTIES clause have precedence > over the other properties". > > If the creator of the query wanted to refer to the "att1" property, they > could just use different USING_PROPERTIES identifier names for the > ATTENDEEs. > > Why won't it work? Because if the 'att1' property was added to the component, you can no longer get '*' without re-compiling your CUA with a new VQUERY command. --------------3025CF0C337C9AAC2BDE21BE Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Mon, 28 Jan 2002 21:00:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T1mkj26372 for ietf-calendar-bks; Mon, 28 Jan 2002 17:48:46 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T1mj326368 for ; Mon, 28 Jan 2002 17:48:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id RAA08632 for ; Mon, 28 Jan 2002 17:48:47 -0800 (PST) Message-ID: <3C55FF76.91361161@Royer.com> Date: Mon, 28 Jan 2002 18:48:38 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------7DF7D57704BB3546B6997E4E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7DF7D57704BB3546B6997E4E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > To be consistent with other SQL clauses the proposition was: > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att1 Did you mean (two '1's): USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 If so, yes - I misunderstood. > not > > USING_PROPERTIES ATTENDEE att1, USING_PROPERTIES ATTENDEE att2 And as to WSP vs SP. No - we are not pretty printing the data, it is for computer processing, not humans. Even the BEEP protocol uses exactly one SPACE between elements. --------------7DF7D57704BB3546B6997E4E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 08:49:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TDaIg15629 for ietf-calendar-bks; Tue, 29 Jan 2002 05:36: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 g0TDaG315620 for ; Tue, 29 Jan 2002 05:36: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 IAA12157 for ; Tue, 29 Jan 2002 08:36:12 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TDaBQ26367 for ; Tue, 29 Jan 2002 08:36:11 -0500 (EST) Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C55FBBD.66357702@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <3C55FBBD.66357702@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 29 Jan 2002 08:44:10 -0500 Message-Id: <1012311850.2269.129.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Mon, 2002-01-28 at 20:32, Doug Royer wrote: > Alan Davies wrote: > > > > At 05:16 PM 28/01/2002 -0700, Doug Royer wrote: > > > > > >And what if 'att1' is a (future) valid PROPERTY name? > > > > Then the att1 property would be ignored in this query, because "local > > identifiers introduced in the USING_PROPERTIES clause have precedence > > over the other properties". > > > > If the creator of the query wanted to refer to the "att1" property, they > > could just use different USING_PROPERTIES identifier names for the > > ATTENDEEs. > > > > Why won't it work? > > Because if the 'att1' property was added to the component, > you can no longer get '*' without re-compiling your > CUA with a new VQUERY command. I don't understand, if you do the following: SELECT * FROM VEVENT USING_PROPERTIES ATTENDEE UID WHERE UID = 'recal1@example.com' The query means: return all the properties of the VEVENTs with an ATTENDEE property having the value 'recal1@example.com' There is not substitution of property names in the returned elements. Only in the search condition. i.e, In the returned VEVENTs the UID property will still be an unique identifier, not an attendee. From owner-ietf-calendar@mail.imc.org Tue Jan 29 09:40:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04456 for ; Tue, 29 Jan 2002 09:40:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TERLJ17991 for ietf-calendar-bks; Tue, 29 Jan 2002 06:27:21 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TERK317986 for ; Tue, 29 Jan 2002 06:27:20 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA13713 for ; Tue, 29 Jan 2002 09:27:16 -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 g0TERFQ01043 for ; Tue, 29 Jan 2002 09:27:15 -0500 (EST) Message-ID: <3C56B1A7.695267DF@steltor.com> Date: Tue, 29 Jan 2002 09:28:55 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: SELF or SELF() (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [ I've replied to your 3 points in separate messages. ] Doug Royer wrote: > > (1) I noticed Bernard called SELF a function 'SELF()' and not 'SELF'. > Are you proposing a change, or is this a typo? > > I like the idea, but lets do it to all of the non-literal values > if we do it for any: > > OWNER() > NONOWNER() > SELF() > Anything else? > OWNER and NONOWNER are not in the same name space as SELF (or SELF()). OWNER and NONOWNER are valid values for the GRANT and DENY properties, while SELF (or SELF()) will need to be added to the CAP-QL ABNF. > (1.1) For clarification, do we want to rename SELF() to > AUTHENTICATED(), CURRENT-UPN(), or sometning? SELF() is used in comparisons with the properties ATTENDEE and ORGANIZER which hold "calendar addresses" and not UPNs. So it may not be a good idea to use the equality operator after all (type mismatch). We should probably come up with a better way to express the following: The value of ATTENDEE is the address of a calendar owned by the currently authenticated calendar user. What about a OWNED_BY() function? SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE OWNED_BY( att, SELF() ) Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 10:02:30 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05084 for ; Tue, 29 Jan 2002 10:02:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TEkXP18337 for ietf-calendar-bks; Tue, 29 Jan 2002 06:46: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 g0TEkW318333 for ; Tue, 29 Jan 2002 06:46:32 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA14324 for ; Tue, 29 Jan 2002 09:46:28 -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 g0TEkRQ03089 for ; Tue, 29 Jan 2002 09:46:27 -0500 (EST) Message-Id: <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jan 2002 09:50:03 -0500 To: "ietf-calendar@imc.org" From: Alan Davies Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism In-Reply-To: <3C55FBBD.66357702@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:32 PM 28/01/2002 -0700, you wrote: >Alan Davies wrote: > > > > At 05:16 PM 28/01/2002 -0700, Doug Royer wrote: > > >Patrice Lapierre wrote: > > > > Local identifiers prefixed with "x-" won't ensure that there is no > > > > conflict. The simplest way to resolve this issue is simply stating the > > > > local identifiers introduced in the USING_PROPERTIES clause have > > > > precedence over the other properties. > > > > > >That will not work. What if: > > > > > > SELECT * FROM VEVENT > > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att1 > > > > > >And what if 'att1' is a (future) valid PROPERTY name? > > > > Then the att1 property would be ignored in this query, because "local > > identifiers introduced in the USING_PROPERTIES clause have precedence > > over the other properties". > > > > If the creator of the query wanted to refer to the "att1" property, they > > could just use different USING_PROPERTIES identifier names for the > > ATTENDEEs. > > > > Why won't it work? > >Because if the 'att1' property was added to the component, >you can no longer get '*' without re-compiling your >CUA with a new VQUERY command. I still don't see why it won't work; if my CUA sends a "SELECT * FROM..." query to a CS that supports the new "att1" property, is should recieve the att1 property no matter when it was 'compiled'. The "*" is expanded by the CS, and has nothing to do with the CUA. --Alan From owner-ietf-calendar@mail.imc.org Tue Jan 29 10:42:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06498 for ; Tue, 29 Jan 2002 10:42:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TFPxb21487 for ietf-calendar-bks; Tue, 29 Jan 2002 07:25: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 g0TFPv321478 for ; Tue, 29 Jan 2002 07:25: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 KAA15427 for ; Tue, 29 Jan 2002 10:25: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 g0TFPqQ06723 for ; Tue, 29 Jan 2002 10:25:52 -0500 (EST) Message-ID: <3C56BF65.930583E3@steltor.com> Date: Tue, 29 Jan 2002 10:27:33 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@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: > > (2) And perhaps the anonymous - (and without much thought). > After trying to specify some non-local-domain > restrictions this weekend, the existing ANONYMOUS value is > difficult to restrict local and non-local UPNs (anonymous or not) > > From the UPN section, a CU can login as anonymous and it says > what their UPN is. > > @domain Anonymous from named domain only. > @ Anonymous from any domain. > > And VCAR allows: > > * Any UPN - does that include anonymous? From the previous proposal: If the value is the keyword is *, then the rule applies to all authenticated calendar users (i.e., all UPNs). Since anonymous users are authenticated (anonymously), then I would say that '*' includes anonymous users. This information is missing from my proposal. > > And how do you specify in a VCAR that you will only allow > UPN's *connecting from* a specific domain? As in: > > I want UPN 'DEMO@ROYER.COM' to have FULL access if > "connecting from inside of" ROYER.COM, but read only > access (or no-access) when 'connecting from' outside the > named domain. > > A UPN name is an authentication 'ID' but it makes no assertion > about where it is coming *from* at the time it is connecting. > > This is NOT a proposal for the login ID's in the UPN section. > This is a proposal for how to specify the UPN restrictions IN A > VCAR. Below I'll use 'Cdomain' to mean the domain they are > connecting from (that that has nothing to do with their > UPN-domain or UPN-realm): > > Where DELETE means remove it from the VCAR section. > And ADD means add it to the VCAR section. > > Meaning > -- ---- > DELETE * Any UPN - anonymous or not > connecting from any domain. > > DELETE @ anonymous connecting from any > domain. > > DELETE @domain anonymous@domain connecting > from any domain. > > ADD ANY() Any known non-anonymous UPN > connecting from any domain. > > GRANT:ANY() > DENY:ANY() > > ADD ANY(@Cdomain) Any known non-anonymous UPN > BUT ONLY IF connecting from > the named domain. > > GRANT:ANY(@local-sub-net) > DENY:ANY(@hacked-me.com) > > ADD ANONYMOUS() Any anonymous UPN that is > connecting from any domain. > > GRANT:ANONYMOUS() > DENY:ANONYMOUS() > > ADD ANONYMOUS(@Cdomain) Any anonymous UPN that is > connecting from the NAMED domain. > > Allow anonymous from my-domain.com, > but not from bogus.my-domain.com. > > GRANT:ANONYMOUS(@royer.com) > DENY:ANONYOMUS(@bogus.royer.com) > GRANT:ANONYMOUS(@trusted-domain.com) > > So, if I authenticate with: > > @royer.com > > But I am connecting from 'bogus.royer.com, > I will have less access based on the contents > of the entire VCAR. > > ADD UPN(named, @Cdomain) Known UPN, But only of connecting > from domain. As in: > > Allow UPN doug@royer.com, but only if > connecting from the named domains. > > GRANT:UPN(doug@royer.com, royer.com) > GRANT:UPN(doug@royer.com, inet-consulting.com) > DENY:UPN(doug@royer.com, tried-to-hack-me.com) > > no-change As before, allow named UPN: > > GRANT:doug@royer.com > DENY:NOT doug@royer.com Couldn't we simply allow the '*' character before and after the '@' character? GRANT:* Grant anybody (including anonymous) GRANT:@ Grant anonymous only GRANT:*@* Grant named from any realm only GRANT:@example.com Grant anonymous from example.com only GRANT:*@example.com Grant named from example.com GRANT:doug@* Grant doug from any realm GRANT:doug@example.com Grant doug@example.com > ADD NOT And allow 'NOT' to be placed in front of > any of them. Do we really need a NOT operator? I can grant everybody but you this way: GRANT:* DENY:doug@royer.com and I can grant you but nobody else this way (DENY:* is implicit): GRANT:doug@royer.com Perhaps I'm missing something. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 10:43:46 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06570 for ; Tue, 29 Jan 2002 10:43:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TFTnh21558 for ietf-calendar-bks; Tue, 29 Jan 2002 07:29:49 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TFTl321554 for ; Tue, 29 Jan 2002 07:29:48 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA15539 for ; Tue, 29 Jan 2002 10:29:43 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TFThQ07154 for ; Tue, 29 Jan 2002 10:29:43 -0500 (EST) Message-ID: <3C56C04B.7BFBEC9@steltor.com> Date: Tue, 29 Jan 2002 10:31: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: incomplete UPN restrictions in VCARs References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@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: > > (3) Our VCARs did not allow us to specify an action of LOGIN: > > So do we want to allow something like this to be specified > in a VCAR? (note new 'LOGIN' pseudo table who's contents > is simply a list of UPN's): (And Bernard forgive me and > correct me if I have not got all of the proposals syntax > correct): > > > BEGIN:VCAR > NAME:"Named UPS that can log in to this system" > GRANT:ANY(@local-domain.com) > GRANT:ANONYMOUS() > PERMISSION:* > SCOPE:SELECT * LOGIN WHERE UPN=SELF(); > END:VCAR The SCOPE property is used to define a set of calendar objects. I don't think it would be acceptable to overload the SCOPE property to affect the meaning of the GRANT and DENY properties. I don't think this administrative task is within the scope of the CAP protocol. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 11:07:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07537 for ; Tue, 29 Jan 2002 11:07:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TFrJw22105 for ietf-calendar-bks; Tue, 29 Jan 2002 07:53:19 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TFrI322101 for ; Tue, 29 Jan 2002 07:53:18 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA16481 for ; Tue, 29 Jan 2002 10:53:14 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TFrDQ09945 for ; Tue, 29 Jan 2002 10:53:13 -0500 (EST) Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C55FF76.91361161@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <3C55FF76.91361161@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 29 Jan 2002 11:01:11 -0500 Message-Id: <1012320072.30940.10.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Mon, 2002-01-28 at 20:48, Doug Royer wrote: > Patrice Lapierre wrote: > > > To be consistent with other SQL clauses the proposition was: > > > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att1 > > Did you mean (two '1's): > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > > If so, yes - I misunderstood. You are correct, I meant att1 and att2. >... > And as to WSP vs SP. > > No - we are not pretty printing the data, it is for > computer processing, not humans. Even the BEEP protocol > uses exactly one SPACE between elements. BEEP use exactly one space only in frame header (a low-level construct visible only to the transport layer), no such limitation is present in the payload where all CAP elements reside. CAP-QL is closer to SQL, which does allow more than one spaces. I don't see the arm in permitting an arbitrary number of spaces. It's not harder to implement, and queries can still be as compact when generated by a machine. From owner-ietf-calendar@mail.imc.org Tue Jan 29 11:46:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08911 for ; Tue, 29 Jan 2002 11:46:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TGV1823141 for ietf-calendar-bks; Tue, 29 Jan 2002 08:31:01 -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 g0TGUw323133 for ; Tue, 29 Jan 2002 08:31:00 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Jan 2002 11:37:12 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/29/2002 11:31:02 AM, Serialize complete at 01/29/2002 11:31:02 AM Content-Type: multipart/alternative; boundary="=_alternative 005A7EE485256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A7EE485256B50_= Content-Type: text/plain; charset="US-ASCII" Doug wrote: > (2) ABNF is tricky stuff - PLEASE REVIEW. Well, I did find 1 small glitch in at least one part of the ABNF: cap-cmp-rhs = ( cap-oper col-literal / "IS NULL" ) / "IS NOT NULL" / "LIKE" " " col-literal ) # Where the SQL '%' and '_' # Wildcard characters may # be used in col-literal has mismatching parens. I believe it should just be: cap-cmp-rhs = ( cap-oper col-literal / "IS NULL" / "IS NOT NULL" / "LIKE" " " col-literal ) # Where the SQL '%' and '_' # Wildcard characters may # be used in col-literal otherwise you're gonna get some funky querys... Also, should cmp-oper actually be cap-oper? I cant find cmp-oper used in any ABNF nor can I find cap-oper defined in the ABNF... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005A7EE485256B50_= Content-Type: text/html; charset="US-ASCII"
Doug wrote:
>      (2) ABNF is tricky stuff - PLEASE REVIEW.
Well, I did find 1 small glitch in at least one part of the ABNF:

    cap-cmp-rhs = ( cap-oper col-literal
                 / "IS NULL" )
                 / "IS NOT NULL"
                 / "LIKE" " " col-literal ) # Where the SQL '%' and '_'
                                            # Wildcard characters may
                                            # be used in col-literal

has mismatching parens.  I believe it should just be:

    cap-cmp-rhs = ( cap-oper col-literal
                 / "IS NULL"
                 / "IS NOT NULL"
                 / "LIKE" " " col-literal ) # Where the SQL '%' and '_'
                                            # Wildcard characters may
                                            # be used in col-literal
otherwise you're gonna get some funky querys...

Also, should cmp-oper actually be cap-oper?  I cant find cmp-oper used in any ABNF nor can I find cap-oper defined in the ABNF...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005A7EE485256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 11:55:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09139 for ; Tue, 29 Jan 2002 11:55:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TGXRC23230 for ietf-calendar-bks; Tue, 29 Jan 2002 08:33:27 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TGXP323226 for ; Tue, 29 Jan 2002 08:33:25 -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 LAA17593 for ; Tue, 29 Jan 2002 11:33:21 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TGXKQ13720 for ; Tue, 29 Jan 2002 11:33:20 -0500 (EST) Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C55E8BA.623748AC@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <3C55E8BA.623748AC@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 29 Jan 2002 11:41:18 -0500 Message-Id: <1012322479.32660.5.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Mon, 2002-01-28 at 19:11, Doug Royer wrote: ... > > *** NOTE *** : Multiple QUERY properties in a VQUERY is a new addition. > > > > I'm not opposed, however I can see some potential side effects that > > were not mentioned: > > It was discussed - just never made it into the ABNF before. > > > - Are the result of different QUERYs returned in the same VCALENDAR? > > As if two seperate VQUERYs had been submitted. > > > - What is the orderings of the returned components? > > Same as if two seperate VQUERYs had been submitted. OK great, this would work. A note should be added to the search command to indicate that distinct "ANS" messages will be received for each QUERY (not just for different targets). From owner-ietf-calendar@mail.imc.org Tue Jan 29 11:56:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09158 for ; Tue, 29 Jan 2002 11:56:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TGhFd23422 for ietf-calendar-bks; Tue, 29 Jan 2002 08:43:15 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TGhE323417 for ; Tue, 29 Jan 2002 08:43:14 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Jan 2002 11:50:04 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/29/2002 11:43:17 AM, Serialize complete at 01/29/2002 11:43:17 AM Content-Type: multipart/alternative; boundary="=_alternative 005BACC685256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005BACC685256B50_= Content-Type: text/plain; charset="US-ASCII" Doug wrote: > (2) ABNF is tricky stuff - PLEASE REVIEW. There _may_ be a small problem w/the ABNF snippet: cap-cols = ( cap-col / cap-col "," cap-cols ) / "*" It may or may not be what you want, depending on the answer to this: Is it correct / valid / acceptable to have a query like: SELECT VALARM,DTSTART,DTEND,UID,* FROM VEVENT According to the ABNF, this is strictly legal (the last instance of a cap-cols instances as "*" instead of cap-col) but Im not sure thats what you wanted since it has the side effect of making the rest of the values superfluous/redundant. After all, why say give me "DTSTART, DTEND and _all_ the properties of the VEVENT" when the 1st 2 phrases are just clutter... If this is NOT what you wanted then you need to define cap-cols more like (and this is not 100% baked but you get the idea): cap-cols = cap-col-wildcard / cap-col-explicit cap-col-explicit = ( cap-col / cap-col "," cap-col-explicit ) cap-col-wildcard = "*" Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005BACC685256B50_= Content-Type: text/html; charset="US-ASCII"
Doug wrote:
>      (2) ABNF is tricky stuff - PLEASE REVIEW.
There _may_ be a small problem w/the ABNF snippet:

    cap-cols    = ( cap-col / cap-col "," cap-cols )
                 / "*"
It may or may not be what you want, depending on the answer to this:  Is it correct / valid / acceptable to have a query like:

        SELECT VALARM,DTSTART,DTEND,UID,* FROM VEVENT

According to the ABNF, this is strictly legal (the last instance of a cap-cols instances as "*" instead of cap-col) but Im not sure thats what you wanted since it has the side effect of making the rest of the values superfluous/redundant.  After all, why say give me "DTSTART, DTEND and _all_ the properties of the VEVENT" when the 1st 2 phrases are just clutter...

If this is NOT what you wanted then you need to define cap-cols more like (and this is not 100% baked but you get the idea):

        cap-cols        = cap-col-wildcard / cap-col-explicit
        cap-col-explicit = ( cap-col / cap-col "," cap-col-explicit )
        cap-col-wildcard = "*"

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005BACC685256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 12:09:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09630 for ; Tue, 29 Jan 2002 12:09:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TGtRK23799 for ietf-calendar-bks; Tue, 29 Jan 2002 08:55:27 -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 g0TGtQ323795 for ; Tue, 29 Jan 2002 08:55:26 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Jan 2002 12:01:17 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/29/2002 11:55:29 AM, Serialize complete at 01/29/2002 11:55:29 AM Content-Type: multipart/alternative; boundary="=_alternative 005CB34B85256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005CB34B85256B50_= Content-Type: text/plain; charset="US-ASCII" One more ABNF comment for now. Given the ABNF: cap-col = # Any property name found in the component # named in the comp-tbl used in the FROM clause. # # SELECT ORGANIZER FROM VEVENT ... # # OR # # A component name of an existing component contained # inside of the cmp-tbl used in the FROM clause. # # SELECT VALARM FROM VEVENT ... then it appears as if (corrected) example (f): (f) SELECT * FROM VEVENT WHERE VALARM.TRIGGER < 20020201T000000Z AND VALARM.TRIGGER > 20020101T000000Z is not allowed. The "OR" part says "existing component contained" so that precludes accessing / referencing the property values (or property parameter values) of the contained components. The prose needs to be adjusted to allow this. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005CB34B85256B50_= Content-Type: text/html; charset="US-ASCII"
One more ABNF comment for now.  Given the ABNF:

    cap-col     = # Any property name found in the component
                 # named in the comp-tbl used in the FROM clause.
                 #
                 #   SELECT ORGANIZER FROM VEVENT ...
                                   #
                 # OR
                 #
                 # A component name of an existing component contained
                 # inside of the cmp-tbl used in the FROM clause.
                 #
                 #   SELECT VALARM FROM VEVENT ...

then it appears as if (corrected) example (f):

                (f) SELECT * FROM VEVENT WHERE
                    VALARM.TRIGGER < 20020201T000000Z
                    AND VALARM.TRIGGER > 20020101T000000Z
is not allowed.  The "OR" part says "existing component contained" so that precludes accessing / referencing the property values (or property parameter values) of the contained components.  The prose needs to be adjusted to allow this.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005CB34B85256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 12:15:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09837 for ; Tue, 29 Jan 2002 12:15:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TGmsD23572 for ietf-calendar-bks; Tue, 29 Jan 2002 08:48:54 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TGmr323568 for ; Tue, 29 Jan 2002 08:48:53 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Jan 2002 11:55:41 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/29/2002 11:48:56 AM, Serialize complete at 01/29/2002 11:48:56 AM Content-Type: multipart/alternative; boundary="=_alternative 005C302A85256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C302A85256B50_= Content-Type: text/plain; charset="US-ASCII" Yet another ANBF comment. I think the ABNF is not complete (or technically a valid ABNF) due definitions like: cap-col = # Any property name found in the component # named in the comp-tbl used in the FROM clause. # # SELECT ORGANIZER FROM VEVENT ... # # OR # # A component name of an existing component contained # inside of the cmp-tbl used in the FROM clause. # # SELECT VALARM FROM VEVENT ... [Snip] cap-local = # Any string that is composed of the characters # that could be a cap-col name, but is not any # cap-col name. It is suggested that the # string start with "x-" to ensure it does not # conflict with any existing or future cap-col name. # This name MUST BE defined in the cap-using and # can only be used in cap-cmps of the same query. # And this name is only known and valid for the # provided query and only for the lifetime of # the query. and so forth. The ABNF MUST contain terminals for all definitions (or weasle out and say "See RFC xxxx" for the ABNF for a URI" like we did in RFC 2445 so we did not have to include their ABNF in our RFCs). Otherwise its simply not possible to build an ABNF that can be parsed and validated for correctness / conflicts / accuracy. The solution is to keep the current prose and simply put in the ABNF elements that the prose is describing. When ti comes to "either ... or..." cases then the standard ABNF formatting is used. Its not always simple but it is a must for the ABNF to be of any use at all. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005C302A85256B50_= Content-Type: text/html; charset="US-ASCII"
Yet another ANBF comment.  I think the ABNF is not complete (or technically a valid ABNF) due definitions like:

    cap-col     = # Any property name found in the component
                 # named in the comp-tbl used in the FROM clause.
                 #
                 #   SELECT ORGANIZER FROM VEVENT ...
                                   #
                 # OR
                 #
                 # A component name of an existing component contained
                 # inside of the cmp-tbl used in the FROM clause.
                 #
                 #   SELECT VALARM FROM VEVENT ...
[Snip]
    cap-local   = # Any string that is composed of the characters
                 # that could be a cap-col name, but is not any
                 # cap-col name. It is suggested that the
                 # string start with "x-" to ensure it does not
                 # conflict with any existing or future cap-col name.
                 # This name MUST BE defined in the cap-using and
                 # can only be used in cap-cmps of the same query.
                 # And this name is only known and valid for the
                 # provided query and only for the lifetime of
                 # the query.

and so forth.  The ABNF MUST contain terminals for all definitions (or weasle out and say "See RFC xxxx" for the ABNF for a URI" like we did in RFC 2445 so we did not have to include their ABNF in our RFCs).  Otherwise its simply not possible to build an ABNF that can be parsed and validated for correctness / conflicts / accuracy.  

The solution is to keep the current prose and simply put in the ABNF elements that the prose is describing.  When ti comes to "either ... or..." cases then the standard ABNF formatting is used.

Its not always simple but it is a must for the ABNF to be of any use at all.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005C302A85256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 12:23:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10117 for ; Tue, 29 Jan 2002 12:23:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TH9Rm24066 for ietf-calendar-bks; Tue, 29 Jan 2002 09:09:27 -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 g0TH9P324062 for ; Tue, 29 Jan 2002 09:09:25 -0800 (PST) To: Patrice Lapierre Cc: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Jan 2002 12:16:14 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/29/2002 12:09:28 PM, Serialize complete at 01/29/2002 12:09:28 PM Content-Type: multipart/alternative; boundary="=_alternative 005E120C85256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E120C85256B50_= Content-Type: text/plain; charset="US-ASCII" Patrice Lapierre thoughtfully replied on 01/28/2002 11:24:03 AM: > > Just how are property parameters (ie: PART-STAT=Declined, > > X-LDC-BLECH=ALWAYS or SENT-BY="mailto:Bruce@fizbin.com") to be organized / > > treated? > > The proposition includes the PARAM() function for this purpose: > > e.g., > > SELECT * FROM VEVENT > USING_PROPERTIES ATTENDEE att > WHERE PARAM( att, 'PARTSTAT' ) = 'DECLINED' (I reordered the quoting for readability). I dont want to assume anything so Ill check w/the WG; Is using the last form of the ABNF: capselect = ( "SELECT" " " cap-cols " " "FROM" " " cap-tbl " " "WHERE" " " cap-cmps / "SELECT" " " cap-cols " " "FROM" " " cap-tbl / "SELECT " " cap-cols " " "FROM" " " cap-tbl " " "USING_PROPERTIES" " " cap-col cap-local "WHERE" " " cap-cmps ) required when using PARAM(..) in a query? Its not expressly stated so its very unclear of the linkage between the "USING_PROPERTIES" version and when I can or cannot use PARAM(..). If it is not required then is USING_PROPERTIES really necessary? Couldnt we just simplfy the last term of the ABNF to into the 1st? We could even further simplify the ABNF, using optional bracketing for capselect to something like: capselect = ( "SELECT" " " cap-cols " " "FROM" " " cap-tbl [ " " [ "USING_PROPERTIES" " " cap-col cap-local " " ] "WHERE" " " cap-cmps ] If it is required then some prose to that effect needs to be added (at least to the proposal as it was posted). However I dont see any need for mandating it. Its not clear why the given example could not be simplified down to: SELECT * FROM VEVENT WHERE PARAM( ATTENDEE , 'PARTSTAT' ) = 'DECLINED' Finally, is the prose for PARAM() left out because its part of the current drat but in a different section or was it accidentally left undescribed to generate traffic?? :^) Bruce PS: If we dont simplify the ABNF down, then you need to add a missing " " at the end of the current "USING_PROPERTIES" line!) =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005E120C85256B50_= Content-Type: text/html; charset="US-ASCII"
Patrice Lapierre thoughtfully replied on 01/28/2002 11:24:03 AM:
> > Just how are property parameters (ie: PART-STAT=Declined,
> > X-LDC-BLECH=ALWAYS or SENT-BY="mailto:Bruce@fizbin.com") to be organized /
> > treated?
>
> The proposition includes the PARAM() function for this purpose:
>
> e.g.,
>
>    SELECT * FROM VEVENT
>    USING_PROPERTIES ATTENDEE att
>    WHERE PARAM( att, 'PARTSTAT' ) = 'DECLINED'
(I reordered the quoting for readability).  I dont want to assume anything so Ill check w/the WG; Is using the last form of the ABNF:

    capselect  = ( "SELECT" " " cap-cols " "
                  "FROM"   " " cap-tbl " "
                        "WHERE"  " " cap-cmps

                / "SELECT" " " cap-cols " "
                  "FROM"   " " cap-tbl

                / "SELECT  " " cap-cols " "
                  "FROM"   " " cap-tbl  " "
                  "USING_PROPERTIES" " " cap-col cap-local
                  "WHERE"  " " cap-cmps )

required when using PARAM(..) in a query?  Its not expressly stated so its very unclear of the linkage between the "USING_PROPERTIES" version and when I can or cannot use PARAM(..).

If it is not required then is USING_PROPERTIES really necessary?  Couldnt we just simplfy the last term of the ABNF to into the 1st?  We could even further simplify the ABNF, using optional bracketing for capselect to something like:

    capselect  = ( "SELECT" " " cap-cols " "
                  "FROM"   " " cap-tbl [ " "
                  [ "USING_PROPERTIES" " " cap-col cap-local " " ]
                          "WHERE"  " " cap-cmps ]

If it is required then some prose to that effect needs to be added (at least to the proposal as it was posted).  However I dont see any need for mandating it.  Its not clear why the given example could not be simplified down to:

    SELECT * FROM VEVENT
   WHERE PARAM( ATTENDEE , 'PARTSTAT' ) = 'DECLINED'
Finally, is the prose for PARAM() left out because its part of the current drat but in a different section or was it accidentally left undescribed to generate traffic?? :^)

Bruce
PS: If we dont simplify the ABNF down, then you need to add a missing " " at the end of the current "USING_PROPERTIES" line!)
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005E120C85256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 12:29:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10437 for ; Tue, 29 Jan 2002 12:29:23 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TH7J624018 for ietf-calendar-bks; Tue, 29 Jan 2002 09:07: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 g0TH7H324014 for ; Tue, 29 Jan 2002 09:07: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 JAA09472 for ; Tue, 29 Jan 2002 09:07:18 -0800 (PST) Message-ID: <3C56D6C2.AA021310@Royer.com> Date: Tue, 29 Jan 2002 10:07:14 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: SELF or SELF() (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56B1A7.695267DF@steltor.com> Content-Type: multipart/mixed; boundary="------------CCBC884ECBF2787AF344201D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CCBC884ECBF2787AF344201D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > [ I've replied to your 3 points in separate messages. ] > > Doug Royer wrote: > > > > (1) I noticed Bernard called SELF a function 'SELF()' and not 'SELF'. > > Are you proposing a change, or is this a typo? > > > > I like the idea, but lets do it to all of the non-literal values > > if we do it for any: > > > > OWNER() > > NONOWNER() > > SELF() > > Anything else? > > > > OWNER and NONOWNER are not in the same name space as SELF > (or SELF()). OWNER and NONOWNER are valid values for the > GRANT and DENY properties, while SELF (or SELF()) will need > to be added to the CAP-QL ABNF. OWNER NONOWNER and SELF have been in defined and used in the past. So you have invented something new? Or is it a typo? --------------CCBC884ECBF2787AF344201D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 12:31:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0THDlf24155 for ietf-calendar-bks; Tue, 29 Jan 2002 09:13:47 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0THDk324151 for ; Tue, 29 Jan 2002 09:13:46 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA18737 for ; Tue, 29 Jan 2002 12:13:42 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0THDfQ17866 for ; Tue, 29 Jan 2002 12:13:41 -0500 (EST) Message-ID: <3C56D8AA.2C21631A@steltor.com> Date: Tue, 29 Jan 2002 12:15:22 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (RESTRICTION) VCARs - any other specific proposals? References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C558246.6A61F95B@Royer.com> <3C5589EC.BD82855@steltor.com> <3C55D1A2.695569A2@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: > > > > > Here, the SCOPE property specifies that you are allowed > > to modify the ATTENDEE property that matches SELF. While > > the RESTRICTION property simply ensure that you are not > > going to change the value of the ATTENDEE property to > > some other value than SELF, that is, you'll be allowed > > to change the value of the parameter of the property but > > not its value. > > So you are saying that RESTRICTION only applied to WRITE? RESTRICTION only applies to permissions WRITE and MODIFY. > > > If the CAP-QL change previously proposed by Alan, and > > mentionned by Patrice today, is adopted, we could also > > improve the definition of our SCOPE property as follows : > > Why is this improved? It looks the same to me except > it require more code. I see no advantage at all. > > > SCOPE:SELECT att FROM VEVENT > > USING_PROPERTIES ATTENDEE att > > WHERE att = SELF() > > Assuming PERMISSION:READ, SCOPE:SELECT ATTENDEE FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() would grant you the right to read ALL instances of the ATTENDEE property of a VEVENT for which one ATTENDEE is set to SELF, while SCOPE:SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() would only grant you the right to read the instances of the ATTENDEE property of a VEVENT that are set to SELF. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 12:42:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10826 for ; Tue, 29 Jan 2002 12:42:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0THEYg24185 for ietf-calendar-bks; Tue, 29 Jan 2002 09:14:34 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0THEX324180 for ; Tue, 29 Jan 2002 09:14:33 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA09490 for ; Tue, 29 Jan 2002 09:14:33 -0800 (PST) Message-ID: <3C56D875.603010E8@Royer.com> Date: Tue, 29 Jan 2002 10:14:29 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> Content-Type: multipart/mixed; boundary="------------C371D4EBCB05BA6D00FA64AB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C371D4EBCB05BA6D00FA64AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Couldn't we simply allow the '*' character before and > after the '@' character? > > GRANT:* Grant anybody (including anonymous) > GRANT:@ Grant anonymous only > GRANT:*@* Grant named from any realm only > GRANT:@example.com Grant anonymous from example.com only > GRANT:*@example.com Grant named from example.com > GRANT:doug@* Grant doug from any realm > GRANT:doug@example.com Grant doug@example.com No, not the same issue. "doug@example.com" is the UPN. It might be connecting from "foo.com". I want to restrict the UPN "doug@example.com" and only allow the VCAR to apply when connecting from "example.com", if they connect from any other domain, I do not want them to have access. Yes your examples grant or deny the UPN, but is what is missing is where they are connecting FROM. --------------C371D4EBCB05BA6D00FA64AB Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 12:43:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0THF0C24203 for ietf-calendar-bks; Tue, 29 Jan 2002 09:15:00 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0THEt324196 for ; Tue, 29 Jan 2002 09:14:56 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Jan 2002 12:21:44 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/29/2002 12:14:58 PM, Serialize complete at 01/29/2002 12:14:58 PM Content-Type: multipart/alternative; boundary="=_alternative 005E92F085256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E92F085256B50_= Content-Type: text/plain; charset="US-ASCII" One last ABNF comment for now. This ABNF: cap-cmp = ( cap-ucol cap-cmd-rhs / cap-ucol cap-oper cap-literal / "PARAM(" cap-col "," cap-param ")" cap-cmp-rhs / "CONTAINS(" cap-col "," col-literal ")" / cap-logical [Snip] cap-cmp-rhs = ( cap-oper col-literal / "IS NULL" ) / "IS NOT NULL" / "LIKE" " " col-literal ) # Where the SQL '%' and '_' # Wildcard characters may # be used in col-literal seems to be a bit redundant. In particular, the first 2 parts of cap-cmp resolve to a sub and superset so why have the subset at all? Expansion of the 1st 2 terms becomes: cap-cmp = ( cap-ucol ( cap-oper col-literal / "IS NULL" ) / "IS NOT NULL" / "LIKE" " " col-literal ) / cap-ucol cap-oper cap-literal which can simplified down to: cap-cmp = ( cap-ucol ( cap-oper col-literal / "IS NULL" ) / "IS NOT NULL" / "LIKE" " " col-literal ) or just: cap-cmp = ( cap-ucol cap-cmd-rhs basically (I left off the last 2 lines of the original ABNF for clarity). Am I missing something or can we simplify the ABNF down?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005E92F085256B50_= Content-Type: text/html; charset="US-ASCII"
One last ABNF comment for now.  This ABNF:

    cap-cmp     = ( cap-ucol cap-cmd-rhs
                 / cap-ucol cap-oper cap-literal
                 / "PARAM(" cap-col "," cap-param ")" cap-cmp-rhs
                                   / "CONTAINS(" cap-col "," col-literal ")"
                 / cap-logical
[Snip]
   cap-cmp-rhs = ( cap-oper col-literal
                 / "IS NULL" )
                 / "IS NOT NULL"
                 / "LIKE" " " col-literal ) # Where the SQL '%' and '_'
                                            # Wildcard characters may
                                            # be used in col-literal

seems to be a bit redundant.  In particular, the first 2 parts of cap-cmp resolve to a sub and superset so why have the subset at all?  Expansion of the 1st 2 terms becomes:

    cap-cmp     = ( cap-ucol ( cap-oper col-literal
                         / "IS NULL" )
                         / "IS NOT NULL"
                         / "LIKE" " " col-literal )
                 / cap-ucol cap-oper cap-literal

which can simplified down to:

    cap-cmp     = ( cap-ucol ( cap-oper col-literal
                         / "IS NULL" )
                         / "IS NOT NULL"
                         / "LIKE" " " col-literal )

or just:

    cap-cmp     = ( cap-ucol cap-cmd-rhs

basically (I left off the last 2 lines of the original ABNF for clarity).  Am I missing something or can we simplify the ABNF down??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005E92F085256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 12:50:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11133 for ; Tue, 29 Jan 2002 12:50:42 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0THRgk24467 for ietf-calendar-bks; Tue, 29 Jan 2002 09:27: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 g0THRe324463 for ; Tue, 29 Jan 2002 09:27: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 JAA09527 for ; Tue, 29 Jan 2002 09:27:41 -0800 (PST) Message-ID: <3C56DB89.3915FCA0@Royer.com> Date: Tue, 29 Jan 2002 10:27:37 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <3C55E8BA.623748AC@Royer.com> <1012322479.32660.5.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------67AFB8B16B294DEAB43A9A3C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------67AFB8B16B294DEAB43A9A3C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > On Mon, 2002-01-28 at 19:11, Doug Royer wrote: > ... > > > *** NOTE *** : Multiple QUERY properties in a VQUERY is a new addition. > > > > > > I'm not opposed, however I can see some potential side effects that > > > were not mentioned: > > > > It was discussed - just never made it into the ABNF before. > > > > > - Are the result of different QUERYs returned in the same VCALENDAR? > > > > As if two seperate VQUERYs had been submitted. > > > > > - What is the orderings of the returned components? > > > > Same as if two seperate VQUERYs had been submitted. > > OK great, this would work. A note should be added to the > search command to indicate that distinct "ANS" messages will > be received for each QUERY (not just for different targets). Or, they can be in the same RPY just like before BEEP: BEGIN:VCALEDNAR .... .... END:VCALENDAR BEGIN:VCALENDAR ... ... END:VCALENDAR iCalendar allows for N number of BEGIN/END segments per MIME body. That was outlined in 05 and was not a TRANSPORT issue. --------------67AFB8B16B294DEAB43A9A3C Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 12:52:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0THZef24729 for ietf-calendar-bks; Tue, 29 Jan 2002 09:35: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 g0THZd324724 for ; Tue, 29 Jan 2002 09:35: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 MAA19137 for ; Tue, 29 Jan 2002 12:35: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 g0THZZQ19515 for ; Tue, 29 Jan 2002 12:35:35 -0500 (EST) Message-ID: <3C56DDCB.27C1CE8C@steltor.com> Date: Tue, 29 Jan 2002 12:37:15 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: SELF or SELF() (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56B1A7.695267DF@steltor.com> <3C56D6C2.AA021310@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > OWNER and NONOWNER are not in the same name space as SELF > > (or SELF()). OWNER and NONOWNER are valid values for the > > GRANT and DENY properties, while SELF (or SELF()) will need > > to be added to the CAP-QL ABNF. > > OWNER NONOWNER and SELF have been in defined and used in the > past. So you have invented something new? Or is it a typo? In the previous proposal OWNER and NONOWNER were listed as valid values for the UPN rule part. In my proposal these values are listed as valid values for the properties GRANT and DENY. The GRANT and DENY properties are only used to specify what used to be in the UPN rule part of RIGHTS value type. That's new, but I wouldn't claimed I invented it! In the previous proposal SELF was listed as a valid value for propvalue and was meant to be used with VALUE (but the ABNF wasn't written properly to allow it). In my proposal I assumed that CAP-QL would also have a way to express SELF, and I used a function for that (i.e., SELF()). I've simply transposed this concept in my proposal. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 12:56:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11347 for ; Tue, 29 Jan 2002 12:56:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0THg5v24919 for ietf-calendar-bks; Tue, 29 Jan 2002 09:42: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 g0THg4324915 for ; Tue, 29 Jan 2002 09:42: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 MAA19325; Tue, 29 Jan 2002 12:42:00 -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 g0THfxQ20297; Tue, 29 Jan 2002 12:41:59 -0500 (EST) Message-Id: <5.1.0.14.0.20020129122107.03250c88@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jan 2002 12:45:35 -0500 To: Bruce_Kahn@notesdev.ibm.com, Patrice Lapierre From: Alan Davies Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism Cc: ietf-calendar@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:16 PM 29/01/2002 -0500, Bruce_Kahn@notesdev.ibm.com wrote: >required when using PARAM(..) in a query? Its not expressly stated so its >very unclear of the linkage between the "USING_PROPERTIES" version and >when I can or cannot use PARAM(..). USING_PROPERTIES is nothing to do with PARAM(). >If it is not required then is USING_PROPERTIES really necessary? Couldnt >we just simplfy the last term of the ABNF to into the 1st? We could even >further simplify the ABNF, using optional bracketing for capselect to >something like: > > capselect = ( "SELECT" " " cap-cols " " > "FROM" " " cap-tbl [ " " > [ "USING_PROPERTIES" " " cap-col cap-local " " ] > "WHERE" " " cap-cmps ] That's an alternative and perhaps clearer layout. >Finally, is the prose for PARAM() left out because its part of the current >drat but in a different section or was it accidentally left undescribed to >generate traffic?? :^) It's in Doug's most recent revision (#3). --Alan From owner-ietf-calendar@mail.imc.org Tue Jan 29 13:06:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11710 for ; Tue, 29 Jan 2002 13:06:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0THoIm25149 for ietf-calendar-bks; Tue, 29 Jan 2002 09:50: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 g0THoH325145 for ; Tue, 29 Jan 2002 09:50: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 JAA09549 for ; Tue, 29 Jan 2002 09:50:17 -0800 (PST) Message-ID: <3C56E0D5.ADA505F3@Royer.com> Date: Tue, 29 Jan 2002 10:50:13 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------BF5FBC31C740DEF69B72AEC3" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BF5FBC31C740DEF69B72AEC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > >Because if the 'att1' property was added to the component, > >you can no longer get '*' without re-compiling your > >CUA with a new VQUERY command. > > I still don't see why it won't work; if my CUA sends a "SELECT * FROM..." > query to a CS that supports the new "att1" property, is should recieve > the att1 property no matter when it was 'compiled'. The "*" is expanded > by the CS, and has nothing to do with the CUA. So if a 'att1' property exists, then this will get it? SELECT att1 FROM VEVENT USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 WHERE att1.att1 = 'foo' AND att2.att1 = 'fee' --------------BF5FBC31C740DEF69B72AEC3 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 13:25:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TIAFk25587 for ietf-calendar-bks; Tue, 29 Jan 2002 10:10: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 g0TIAD325583 for ; Tue, 29 Jan 2002 10:10: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 KAA09589 for ; Tue, 29 Jan 2002 10:10:14 -0800 (PST) Message-ID: <3C56E581.3F30ABD5@Royer.com> Date: Tue, 29 Jan 2002 11:10:09 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: (RESTRICTION) VCARs - any other specific proposals? References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C558246.6A61F95B@Royer.com> <3C5589EC.BD82855@steltor.com> <3C55D1A2.695569A2@Royer.com> <3C56D8AA.2C21631A@steltor.com> Content-Type: multipart/mixed; boundary="------------0809DA20B1F71B6D13E109E2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0809DA20B1F71B6D13E109E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > > > Here, the SCOPE property specifies that you are allowed > > > to modify the ATTENDEE property that matches SELF. While > > > the RESTRICTION property simply ensure that you are not > > > going to change the value of the ATTENDEE property to > > > some other value than SELF, that is, you'll be allowed > > > to change the value of the parameter of the property but > > > not its value. > > > > So you are saying that RESTRICTION only applied to WRITE? > > RESTRICTION only applies to permissions WRITE and MODIFY. So, RESTRICTION would NEVER be in a VCAR that was only READ? If so, I missed that or the ABNF or TEXT needs to be updated. > > > > > If the CAP-QL change previously proposed by Alan, and > > > mentionned by Patrice today, is adopted, we could also > > > improve the definition of our SCOPE property as follows : > > > > Why is this improved? It looks the same to me except > > it require more code. I see no advantage at all. > > > > > SCOPE:SELECT att FROM VEVENT > > > USING_PROPERTIES ATTENDEE att > > > WHERE att = SELF() > > > > Assuming PERMISSION:READ, > > SCOPE:SELECT ATTENDEE FROM VEVENT > USING_PROPERTIES ATTENDEE att > WHERE att = SELF() I read the text to mean that I would get ALL ATTENDEE properties where the ATTENDEE value = SELF. > would grant you the right to read ALL instances > of the ATTENDEE property of a VEVENT for which > one ATTENDEE is set to SELF, while > > SCOPE:SELECT att FROM VEVENT > USING_PROPERTIES ATTENDEE att > WHERE att = SELF() I read the text to mean that I would get ALL ATTENDEE properties where the ATTENDEE value = SELF. I an not figure out how anyone not on this list and reading this email would know the difference. Could you propose some text that could be included in CAP that could explain to someone that is reading CAP for the fist time? It would help me understand what you are trying to do that you can not already do. > would only grant you the right to read the instances > of the ATTENDEE property of a VEVENT that are set > to SELF. --------------0809DA20B1F71B6D13E109E2 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 13:33:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TIJmH26169 for ietf-calendar-bks; Tue, 29 Jan 2002 10:19:48 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TIJl326164 for ; Tue, 29 Jan 2002 10:19:47 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA20001 for ; Tue, 29 Jan 2002 13:19:44 -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 g0TIJhQ23424 for ; Tue, 29 Jan 2002 13:19:43 -0500 (EST) Message-Id: <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jan 2002 13:23:19 -0500 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism In-Reply-To: <3C56E0D5.ADA505F3@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:50 AM 29/01/2002 -0700, Doug Royer wrote: > > I still don't see why it won't work; if my CUA sends a "SELECT * FROM..." > > query to a CS that supports the new "att1" property, is should recieve > > the att1 property no matter when it was 'compiled'. The "*" is expanded > > by the CS, and has nothing to do with the CUA. > > >So if a 'att1' property exists, then this will get it? > > SELECT att1 FROM VEVENT > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > WHERE att1.att1 = 'foo' > AND att2.att1 = 'fee' I don't understand that example, and don't see how it relates to the answer that I gave about the expansion of "*". Are you treating ATTENDEE as if it's a subcomponent, not a property with the ATTENDEE.att1 type syntax? I still don't see why Patrice's quote on this issue from some way back up the thread doesn't solve the problem that I think you're trying to demonstrate: Patrice Lapierre wrote: > Local identifiers prefixed with "x-" won't ensure that there is no > conflict. The simplest way to resolve this issue is simply stating the > local identifiers introduced in the USING_PROPERTIES clause have > precedence over the other properties. --Alan From owner-ietf-calendar@mail.imc.org Tue Jan 29 13:41:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13231 for ; Tue, 29 Jan 2002 13:41:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TIW5F26576 for ietf-calendar-bks; Tue, 29 Jan 2002 10:32:05 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TIW4326572 for ; Tue, 29 Jan 2002 10:32:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA09627 for ; Tue, 29 Jan 2002 10:32:05 -0800 (PST) Message-ID: <3C56EAA0.94D1ACC4@Royer.com> Date: Tue, 29 Jan 2002 11:32:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: SELF or SELF() (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56B1A7.695267DF@steltor.com> <3C56D6C2.AA021310@Royer.com> <3C56DDCB.27C1CE8C@steltor.com> Content-Type: multipart/mixed; boundary="------------32368848F63934CF2307B93B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------32368848F63934CF2307B93B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > OWNER and NONOWNER are not in the same name space as SELF > > > (or SELF()). OWNER and NONOWNER are valid values for the > > > GRANT and DENY properties, while SELF (or SELF()) will need > > > to be added to the CAP-QL ABNF. > > > > OWNER NONOWNER and SELF have been in defined and used in the > > past. So you have invented something new? Or is it a typo? > > In the previous proposal OWNER and NONOWNER were listed as > valid values for the UPN rule part. > > In my proposal these values are listed as valid values for > the properties GRANT and DENY. The GRANT and DENY properties > are only used to specify what used to be in the UPN rule part > of RIGHTS value type. That's new, but I wouldn't claimed I > invented it! > > In the previous proposal SELF was listed as a valid value for > propvalue and was meant to be used with VALUE (but the ABNF > wasn't written properly to allow it). In previous proposals: SELF - was a tag that meant 'currently authenticated UPN' in VCAR and VQUERY OWNER - Was a tag that meant 'currently authenticated UPN - IF they are the owner'. In both VCAR and VQUERY. NONOWNER- Was a tag that meant 'currently authenticated UPN' - IF they are NOT the owner of the calendar. In both VCAR and VQUERY. * - stood for 'any currently authenticated UPN. In both VCAR and VQUERY. > In my proposal I assumed that CAP-QL would also have a way to > express SELF, and I used a function for that (i.e., SELF()). > I've simply transposed this concept in my proposal. So my question is, do we want to change OWNER -> OWNER(), and NONOWNER() to NONOWNER() and so on? If not, lets make them all the same format. (All as functions, or all not as functions). --------------32368848F63934CF2307B93B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 13:44:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TIPvP26338 for ietf-calendar-bks; Tue, 29 Jan 2002 10:25:57 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TIPt326334 for ; Tue, 29 Jan 2002 10:25:55 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA20174 for ; Tue, 29 Jan 2002 13:25:52 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TIPgQ23892 for ; Tue, 29 Jan 2002 13:25:42 -0500 (EST) Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C56DB89.3915FCA0@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <3C55E8BA.623748AC@Royer.com> <1012322479.32660.5.camel@c-1241.in.steltor.com> <3C56DB89.3915FCA0@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 29 Jan 2002 13:33:40 -0500 Message-Id: <1012329221.32660.29.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 2002-01-29 at 12:27, Doug Royer wrote: > Patrice Lapierre wrote: ... > > > > > > It was discussed - just never made it into the ABNF before. > > > > > > > - Are the result of different QUERYs returned in the same VCALENDAR? > > > > > > As if two seperate VQUERYs had been submitted. > > > > > > > - What is the orderings of the returned components? > > > > > > Same as if two seperate VQUERYs had been submitted. > > > > OK great, this would work. A note should be added to the > > search command to indicate that distinct "ANS" messages will > > be received for each QUERY (not just for different targets). > > Or, they can be in the same RPY just like before BEEP: > > BEGIN:VCALEDNAR > .... > .... > END:VCALENDAR > BEGIN:VCALENDAR > ... > ... > END:VCALENDAR > > iCalendar allows for N number of BEGIN/END segments per MIME > body. That was outlined in 05 and was not a TRANSPORT issue. Multiple VCALENDARs in the same BEEP message also works. But shouldn't we chose one alternative and document it in the draft. From owner-ietf-calendar@mail.imc.org Tue Jan 29 13:56:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15468 for ; Tue, 29 Jan 2002 13:56:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TIecv26824 for ietf-calendar-bks; Tue, 29 Jan 2002 10:40: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 g0TIeb326820 for ; Tue, 29 Jan 2002 10:40:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id KAA09637 for ; Tue, 29 Jan 2002 10:40:38 -0800 (PST) Message-ID: <3C56ECA1.5AB49A5D@Royer.com> Date: Tue, 29 Jan 2002 11:40:33 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP by Minneapolis References: Content-Type: multipart/mixed; boundary="------------10AE3DC899B57735E1FA7D4A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------10AE3DC899B57735E1FA7D4A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Got your VM message. Thanks to some bean counter @ IBM I have to get > a new phone # (but my FAX # stays the same, go figure!!). In any > case, its been correct in my sig since just before the change over. > If you dialed the # below then its a different probelm... I dialed your old number - and its 'dial by name' function is busted. some prompts then - please enter the last name of the person you are dialing - 'k' 'a' 'h' 'n' - I'm sorry that is an invalid destination - ZERO five times worked :-) > I havent see a #3 proposal yet so Ill have to see why. I havent seen > my responses back yet so I wonder we are having inbound problems > again... %^| Tell IBM/Lotus I'll be happy to sell them web and email hosting services that work :-) And BTW, I don't know if you have noticed, but Stelcor is proposing and wanting to keep in the BEEP layers: (1) The header to the BEEP commands exceed the size of may of the iCal objects. (except for sync) (2) They want ONLY ONE iCal reply per BEEP reply. So a VQUERY that replies with 100 answers will be in 100 BEEP-ANS messages, each one of which will have to be in a BEGIN/END VCALENDAR. Each one of which will have a BEEP+MIME + CID + ICAL+MIME multipart related object ! Which is unlike 05 where they are in one BEGIN/END wrapper, which contains 100 BEGIN/END answers. They are dramatically increasing the byte count and chattiness of the protocol. -Doug --------------10AE3DC899B57735E1FA7D4A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 14:09:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TIxGx27325 for ietf-calendar-bks; Tue, 29 Jan 2002 10:59:16 -0800 (PST) Received: from Arista.iris.com (arista.notesdev.ibm.com [198.112.211.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TIxE327321 for ; Tue, 29 Jan 2002 10:59:15 -0800 (PST) To: Alan Davies Cc: ietf-calendar@imc.org, Patrice Lapierre Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Jan 2002 14:04:06 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/29/2002 01:57:42 PM, Serialize complete at 01/29/2002 01:57:42 PM Content-Type: multipart/alternative; boundary="=_alternative 0067F20985256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067F20985256B50_= Content-Type: text/plain; charset="US-ASCII" Alan Davies wrote on 01/29/2002 12:45:35 PM: > USING_PROPERTIES is nothing to do with PARAM(). Thanks for clarifying that. It should be stated that there is NO text about USING_PROPERTIES in the #2 proposal that I can find. Only the ABNF has it but w/o any description or text. Perhaps it should be renamed so as to NOT imply property parameters (given the cited examples it can easily be mistakenly inferred like I did.). Hint, hint... > >Finally, is the prose for PARAM() left out because its part of the current > >drat but in a different section or was it accidentally left undescribed to > >generate traffic?? :^) > > It's in Doug's most recent revision (#3). I got a note from Doug saying that all my postings were out of date and that #3 had been posted on Sunday PM (and a #4 will result of the apparent traffic on #3). I havent seen 'em yet (nor have I gotten my own back yet) so Ill have to recheck w/Paul H. about it. He reported lots of problems last week due to the IBM changeover going on but I thought they were resolved by now. Ill try to do a web search of the IMC archives and catch up but given I saw no traffic on the ABNF in #2 I suspect many of my ABNF related postings are still relevant. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0067F20985256B50_= Content-Type: text/html; charset="US-ASCII"
Alan Davies <aland@steltor.com> wrote on 01/29/2002 12:45:35 PM:
> USING_PROPERTIES is nothing to do with PARAM().
Thanks for clarifying that.  

It should be stated that there is NO text about USING_PROPERTIES in the #2 proposal that I can find.  Only the ABNF has it but w/o any description or text.  Perhaps it should be renamed so as to NOT imply property parameters (given the cited examples it can easily be mistakenly inferred like I did.).  Hint, hint...

> >Finally, is the prose for PARAM() left out because its part of the current
> >drat but in a different section or was it accidentally left undescribed to
> >generate traffic?? :^)
>
> It's in Doug's most recent revision (#3).
I got a note from Doug saying that all my postings were out of date and that #3 had been posted on Sunday PM (and a #4 will result of the apparent traffic on #3).  I havent seen 'em yet (nor have I gotten my own back yet) so Ill have to recheck w/Paul H. about it.  He reported lots of problems last week due to the IBM changeover going on but I thought they were resolved by now.

Ill try to do a web search of the IMC archives and catch up but given I saw no traffic on the ABNF in #2 I suspect many of my ABNF related postings are still relevant.

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

--=_alternative 0067F20985256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 15:01:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19330 for ; Tue, 29 Jan 2002 15:01:49 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TJcgT28628 for ietf-calendar-bks; Tue, 29 Jan 2002 11:38:42 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TJce328622 for ; Tue, 29 Jan 2002 11:38: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 OAA21678 for ; Tue, 29 Jan 2002 14:38:37 -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 g0TJcaQ02047 for ; Tue, 29 Jan 2002 14:38:36 -0500 (EST) Message-ID: <3C56FAA0.A0C6C766@steltor.com> Date: Tue, 29 Jan 2002 14:40:16 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@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: > > > Couldn't we simply allow the '*' character before and > > after the '@' character? > > > > GRANT:* Grant anybody (including anonymous) > > GRANT:@ Grant anonymous only > > GRANT:*@* Grant named from any realm only > > GRANT:@example.com Grant anonymous from example.com only > > GRANT:*@example.com Grant named from example.com > > GRANT:doug@* Grant doug from any realm > > GRANT:doug@example.com Grant doug@example.com > > No, not the same issue. > > "doug@example.com" is the UPN. > It might be connecting from "foo.com". > > I want to restrict the UPN "doug@example.com" and only > allow the VCAR to apply when connecting from "example.com", if > they connect from any other domain, I do not want them to have access. > > Yes your examples grant or deny the UPN, but is what is missing > is where they are connecting FROM. It is not missing. It simply does not belong in the VCAR. VCARs are supposed to allow calendar users to grant and deny rights to other authenticated users, regardless of where they are connecting from, the authentication mechanism they've used, or whether they are using TLS or not. AFAIK, this was not identified as a requirement and is certainly outside the scope for CAP 1.0. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 15:19:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19688 for ; Tue, 29 Jan 2002 15:19:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TK3Jh29665 for ietf-calendar-bks; Tue, 29 Jan 2002 12:03: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 g0TK3I329661 for ; Tue, 29 Jan 2002 12:03:18 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA09739 for ; Tue, 29 Jan 2002 12:03:19 -0800 (PST) Message-ID: <3C570001.5A0DB113@Royer.com> Date: Tue, 29 Jan 2002 13:03:13 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------485C916BDA6A2C8F473B7CC0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------485C916BDA6A2C8F473B7CC0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > > At 10:50 AM 29/01/2002 -0700, Doug Royer wrote: > > > I still don't see why it won't work; if my CUA sends a "SELECT * FROM..." > > > query to a CS that supports the new "att1" property, is should recieve > > > the att1 property no matter when it was 'compiled'. The "*" is expanded > > > by the CS, and has nothing to do with the CUA. > > > > > >So if a 'att1' property exists, then this will get it? > > > > SELECT att1 FROM VEVENT > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > > WHERE att1.att1 = 'foo' > > AND att2.att1 = 'fee' > > I don't understand that example, and don't see how it relates > to the answer that I gave about the expansion of "*". My point is that for that property, it would be the same as that property as part of '*'? If not, then I don't understand the USING_PROPERTIES yet. > Are you treating ATTENDEE as if it's a subcomponent, not a > property with the ATTENDEE.att1 type syntax? I am lost - :-) Maybe that is my point. I need more text to understand it. I thought I understood it when it COULD NOT be part of the SELECT clause. > I still don't see why Patrice's quote on this issue from some way > back up the thread doesn't solve the problem that I think you're > trying to demonstrate: I was just trying different examples in order for me to understand the difference. I was not proposing any solution - yet - as I don't understand what the USING_PROPERTIES local-name does when it is in the SELECT clause. If you are saying that it is treated just like the property name (attendee in this example), then why not just enter attendee? If you are saying that it is NOT treated just like the property that it is an ~alias~ for, then how will it know how to treat it if it is part of the expanded '*', or named specificly in the future as an existing property in the component in the FROM clause? What am I missing? --------------485C916BDA6A2C8F473B7CC0 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 15:32:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TKHlB00275 for ietf-calendar-bks; Tue, 29 Jan 2002 12:17:47 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TKHk300271 for ; Tue, 29 Jan 2002 12:17:46 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA22583 for ; Tue, 29 Jan 2002 15:17:43 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TKHhQ06086 for ; Tue, 29 Jan 2002 15:17:43 -0500 (EST) Message-ID: <3C5703CB.7752106E@steltor.com> Date: Tue, 29 Jan 2002 15:19: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: (RESTRICTION) VCARs - any other specific proposals? References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C558246.6A61F95B@Royer.com> <3C5589EC.BD82855@steltor.com> <3C55D1A2.695569A2@Royer.com> <3C56D8AA.2C21631A@steltor.com> <3C56E581.3F30ABD5@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: > > > > > > > > > > > Here, the SCOPE property specifies that you are allowed > > > > to modify the ATTENDEE property that matches SELF. While > > > > the RESTRICTION property simply ensure that you are not > > > > going to change the value of the ATTENDEE property to > > > > some other value than SELF, that is, you'll be allowed > > > > to change the value of the parameter of the property but > > > > not its value. > > > > > > So you are saying that RESTRICTION only applied to WRITE? > > > > RESTRICTION only applies to permissions WRITE and MODIFY. > > So, RESTRICTION would NEVER be in a VCAR that was only READ? > > If so, I missed that or the ABNF or TEXT needs to be updated. This information was specified in the restriction table at the end of my proposal. . . . RESTRICTION 0 or 0+ Note, allowed only if PERMISSION:WRITE and/or PERMISSION:MODIFY are/is present. But it wouldn't hurt to add a comment in the text as well. > > Assuming PERMISSION:READ, > > > > SCOPE:SELECT ATTENDEE FROM VEVENT > > USING_PROPERTIES ATTENDEE att > > WHERE att = SELF() > > I read the text to mean that I would get ALL ATTENDEE properties > where the ATTENDEE value = SELF. This is incorrect. For instance, SCOPE:SELECT * FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() would get you all the properties of VEVENT components for which one of the ATTENDEE property is set to SELF. And, SCOPE:SELECT ORGANIZER FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() would get you the ORGANIZER property of VEVENT components for which one of the ATTENDEE property is set to SELF. > > > would grant you the right to read ALL instances > > of the ATTENDEE property of a VEVENT for which > > one ATTENDEE is set to SELF, while > > > > SCOPE:SELECT att FROM VEVENT > > USING_PROPERTIES ATTENDEE att > > WHERE att = SELF() > > I read the text to mean that I would get ALL ATTENDEE properties > where the ATTENDEE value = SELF. In this case the intent is to specify that we only want to get those ATTENDEE properties that matches the condition. > I an not figure out how anyone not on this list and reading this > email would know the difference. > > Could you propose some text that could be included in CAP > that could explain to someone that is reading CAP for the > fist time? It would help me understand what you are trying > to do that you can not already do. Sure. I'll come up with something. Just to make sure we are on the same page. This is a CAP-QL issue. Not a VCAR issue. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 15:33:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20129 for ; Tue, 29 Jan 2002 15:33:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TKGRi00227 for ietf-calendar-bks; Tue, 29 Jan 2002 12:16: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 g0TKGQ300223 for ; Tue, 29 Jan 2002 12:16: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 MAA09753 for ; Tue, 29 Jan 2002 12:16:27 -0800 (PST) Message-ID: <3C570316.CB317696@Royer.com> Date: Tue, 29 Jan 2002 13:16:22 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <3C55E8BA.623748AC@Royer.com> <1012322479.32660.5.camel@c-1241.in.steltor.com> <3C56DB89.3915FCA0@Royer.com> <1012329221.32660.29.camel@c-1241.in.steltor.com> Content-Type: multipart/mixed; boundary="------------E86CD74B3108F1649C1F5338" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E86CD74B3108F1649C1F5338 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: ND:VCALENDAR > > > > iCalendar allows for N number of BEGIN/END segments per MIME > > body. That was outlined in 05 and was not a TRANSPORT issue. > > Multiple VCALENDARs in the same BEEP message also works. > But shouldn't we chose one alternative and document it in the > draft. I have no problem saying that the CS MAY reply with multiple ANS messages. But for slow connections, I would prefer if the CS could reply with one RPY and avoid all of the chattiness of the protocol when needed. Without byte reduction in the BEEP layer, the BEEP transport overhead easily exceeds the iCalendar object size. At least doubling the bandwidth consumed. So when bandwidth is a more important issue - one RPY is best. Also, there are valid iCalendar objects that contain multiple objects, so a CS and CUA MUST support that. For a LARGE query on a SLOW CS - there is an advantages to multiple ANS messages if a person is watching the data transfers - the perceived performance goes up. As in 100 objects each arriving one second apart is perceived to be faster to a user than one big message coming after a 100 second delay. But if the CUA is not a person waiting for the data, why waste the bandwidth with the BEEP overhead, just send one RPY. Something the impmlementors will have to take into account depending on their application and the CS and CUA needs. I think a CUA MUST allow for both RPY and ANS. With no LESS than one iCalendar object per ANS or RPY. If the CUA gets a ANS, it keeps processing until the last message. If the CUA gets a RPY - done. --------------E86CD74B3108F1649C1F5338 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 15:35:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TKJq100349 for ietf-calendar-bks; Tue, 29 Jan 2002 12:19: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 g0TKJp300345 for ; Tue, 29 Jan 2002 12:19: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 MAA09757 for ; Tue, 29 Jan 2002 12:19:52 -0800 (PST) Message-ID: <3C5703E2.7CD69239@Royer.com> Date: Tue, 29 Jan 2002 13:19:46 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> Content-Type: multipart/mixed; boundary="------------D106482C27E37804409E635E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D106482C27E37804409E635E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Yes your examples grant or deny the UPN, but is what is missing > > is where they are connecting FROM. > > It is not missing. It simply does not belong in the VCAR. > > VCARs are supposed to allow calendar users to grant and deny > rights to other authenticated users, regardless of where they > are connecting from, Why then do we have anonymous@named-domain UPNs? > the authentication mechanism they've used, > or whether they are using TLS or not. I did not propose anything todo with TLS. > AFAIK, this was not identified as a requirement and is certainly > outside the scope for CAP 1.0. Again that's why we have anonymous@realm. What is to keep them from supplying anonymous@realm if they are not from realm? Nothing - that's what I noticed was missing. --------------D106482C27E37804409E635E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 15:46:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TKSc400694 for ietf-calendar-bks; Tue, 29 Jan 2002 12:28: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 g0TKSb300690 for ; Tue, 29 Jan 2002 12:28:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id MAA09784; Tue, 29 Jan 2002 12:28:28 -0800 (PST) Message-ID: <3C5705E6.958E531C@Royer.com> Date: Tue, 29 Jan 2002 13:28:22 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alan Davies , "ietf-calendar@imc.org" Subject: Re: CAP by Minneapolis References: <5.1.0.14.0.20020129141033.033f2e08@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------C663DDD623D69C3ECCE44996" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C663DDD623D69C3ECCE44996 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Davies wrote: > > Was this meant for the list? :) > > --Alan Yes - would you prefer if we talked in secret ? :-) When Microsoft was active, they screamed if Bruce and I had 'secret' email. Secret aliances make for distrusting IETF WG's. I know that Bruce had objections to splitting the RPY messages into multiple ANS's (pre BEEP) in the past. I wanted to make sure he did not miss that point. I used to work for Software.com selling email servers, in competition with Lotus (Bruce), and before that for Sun Microsystems - in competition with Lotus. We just poke at each other from time to time as friends. Thanks! -Doug --------------C663DDD623D69C3ECCE44996 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 15:49:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TKWU500822 for ietf-calendar-bks; Tue, 29 Jan 2002 12:32: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 g0TKWS300817 for ; Tue, 29 Jan 2002 12:32: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 PAA22867 for ; Tue, 29 Jan 2002 15:32:25 -0500 Received: from c1271 (c-1271.in.steltor.com [101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id g0TKWMQ07680 for ; Tue, 29 Jan 2002 15:32:22 -0500 (EST) Message-ID: <163201c1a904$2c7e69d0$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> <3C570001.5A0DB113@Royer.com> Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism Date: Tue, 29 Jan 2002 15:33:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > >So if a 'att1' property exists, then this will get it? > > > > > > SELECT att1 FROM VEVENT > > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > > > WHERE att1.att1 = 'foo' > > > AND att2.att1 = 'fee' No; because the USING_PROPERTIES redefines 'att1' (in the context of this CAP-QL text *ONLY*) to be a specific ATTENDEE property that matches the WHERE clause. If 'att1' becomes a property name at some later point, it doesn't matter, because the local definition in USING_PROPERTIES (or USING_COMPONENTS) will override it (although it still could/would be selected in a "SELECT *". > I was just trying different examples in order for me to understand > the difference. I was not proposing any solution - yet - as > I don't understand what the USING_PROPERTIES local-name does > when it is in the SELECT clause. Basically, rather than SELECTing all (to use an example) ATTENDEE properties in the components referred to in the FROM clause, *only* those ATTENDEE properties that match the definition of 'att1' (i.e., that fit the WHERE clause) will be SELECTed. > If you are saying that it is treated just like the property > name (attendee in this example), then why not just enter > attendee? If you are saying that it is NOT treated just > like the property that it is an ~alias~ for, then how will > it know how to treat it if it is part of the expanded '*', > or named specificly in the future as an existing property > in the component in the FROM clause? I don't know if it's possible to use the named property (or component) in the FROM clause? But assuming it was (for the sake of argument), then there are 2 cases : (a) You have an existing VQUERY using the new property name as a USING_* variable name that you don't want to change. Because of the local precedence rule, you're fine here; the semantics of the VQUERY won't change. (b) You want to modify a VQUERY to use the new property name (or component name) in the FROM clause, but you've already used the name as a USING_* variable. In that case, since you're already modifying the VQUERY, just change the variable name :) Graham From owner-ietf-calendar@mail.imc.org Tue Jan 29 16:08:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21013 for ; Tue, 29 Jan 2002 16:08:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TKk8A01328 for ietf-calendar-bks; Tue, 29 Jan 2002 12:46:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TKk7301323 for ; Tue, 29 Jan 2002 12:46:07 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA23046 for ; Tue, 29 Jan 2002 15:46:04 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TKk3Q09071 for ; Tue, 29 Jan 2002 15:46:03 -0500 (EST) Message-ID: <3C570A70.AA07C482@steltor.com> Date: Tue, 29 Jan 2002 15:47:44 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: SELF or SELF() (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56B1A7.695267DF@steltor.com> <3C56D6C2.AA021310@Royer.com> <3C56DDCB.27C1CE8C@steltor.com> <3C56EAA0.94D1ACC4@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > In previous proposals: > > SELF - was a tag that meant 'currently authenticated UPN' > in VCAR and VQUERY > > OWNER - Was a tag that meant 'currently authenticated UPN > - IF they are the owner'. > In both VCAR and VQUERY. > > NONOWNER- Was a tag that meant 'currently authenticated UPN' > - IF they are NOT the owner of the calendar. > In both VCAR and VQUERY. > > * - stood for 'any currently authenticated UPN. > In both VCAR and VQUERY. Which proposals are you referring to? I've looked in the archive and I could not find any proposal for VQUERY that made mention of these tags. > > In my proposal I assumed that CAP-QL would also have a way to > > express SELF, and I used a function for that (i.e., SELF()). > > I've simply transposed this concept in my proposal. > > So my question is, do we want to change OWNER -> OWNER(), > and NONOWNER() to NONOWNER() and so on? OWNER no. NONOWNER no. SELF okay since it is used in CAP-QL. > > If not, lets make them all the same format. (All as > functions, or all not as functions). Again, as I said, the only change I did, as part of my proposal, was to bring SELF in the CAP-QL vocabulary. Whether we make SELF a function or not in CAP-QL should not have any impact on the tags OWNER and NONOWNER for the GRANT and DENY properties. Don't mix apples with oranges as my old math teacher used to say! Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 16:09:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21066 for ; Tue, 29 Jan 2002 16:09:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0TKu8401597 for ietf-calendar-bks; Tue, 29 Jan 2002 12:56:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TKu7301593 for ; Tue, 29 Jan 2002 12:56:07 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA23239 for ; Tue, 29 Jan 2002 15:56:04 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TKu3Q10143 for ; Tue, 29 Jan 2002 15:56:04 -0500 (EST) Message-ID: <3C570CC8.6374428D@steltor.com> Date: Tue, 29 Jan 2002 15:57:44 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > Yes your examples grant or deny the UPN, but is what is missing > > > is where they are connecting FROM. > > > > It is not missing. It simply does not belong in the VCAR. > > > > VCARs are supposed to allow calendar users to grant and deny > > rights to other authenticated users, regardless of where they > > are connecting from, > > Why then do we have anonymous@named-domain UPNs? I don't know. You brought this up: http://www.imc.org/ietf-calendar/mail-archive/msg03333.html http://www.imc.org/ietf-calendar/mail-archive/msg03342.html > > AFAIK, this was not identified as a requirement and is certainly > > outside the scope for CAP 1.0. > > Again that's why we have anonymous@realm. What is to > keep them from supplying anonymous@realm if they are not from > realm? Nothing - that's what I noticed was missing. I propose NO anonymous@realm. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jan 29 16:59:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22132 for ; Tue, 29 Jan 2002 16:59:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TLksR03536 for ietf-calendar-bks; Tue, 29 Jan 2002 13:46: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 g0TLkr303530 for ; Tue, 29 Jan 2002 13:46:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA09887; Tue, 29 Jan 2002 13:46:54 -0800 (PST) Message-ID: <3C571847.5579F703@Royer.com> Date: Tue, 29 Jan 2002 14:46:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> <3C570001.5A0DB113@Royer.com> <163201c1a904$2c7e69d0$092e0165@in.steltor.com> Content-Type: multipart/mixed; boundary="------------D47D7E71018A674B2FFAA49B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------D47D7E71018A674B2FFAA49B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Graham Gilmore wrote: > > > > >So if a 'att1' property exists, then this will get it? > > > > > > > > SELECT att1 FROM VEVENT > > > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > > > > WHERE att1.att1 = 'foo' > > > > AND att2.att1 = 'fee' > > No; because the USING_PROPERTIES redefines 'att1' (in the context of > this CAP-QL text *ONLY*) to be a specific ATTENDEE property that matches the > WHERE clause. > If 'att1' becomes a property name at some later point, it doesn't > matter, because the local definition in USING_PROPERTIES (or > USING_COMPONENTS) will override it (although it still could/would be > selected in a "SELECT *". So in other words - if that happens - your toast and your CUA can never again get out what it put it. Using the same original VQUERY over time. What about the ROM CUA - hand held devices and phones? Today - you want to get out the UID and ATTENDEE entries, but only for ATTENDEE is 'foo' or 'fee'. If I understand the proposal, this is the QUERY: SELECT UID,att1 from VEVENT USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 WHERE att1 = 'foo' OR att2 = 'fee' A year from today the 'att1' property is added as a valid property that has NOTHING to do with ATTENDEE and without your CUA knowing that it was added in the component stored in the CS. Now the same VQUERY will not return the same results? The same VQUERY will now return the UID and the value of the att1 property? If not how can I then get the UID and value of the att1 property when the ATTENDEE is 'foo' or 'fee'. I think your past reply stated that the CUA must determine the QUERY line dynamically? That won't work ether as any CUA at any point in time will not know if the 'att1' property really exists in the component or not. You also stated that the USING_() value overrides the SELECT clause. How will the CS know not to when the property names in the components are NOT known until after the CS does the VQUERY? How would it know that 'this' time I want the value of the property name that I don't know exists, until after I do the VQUERY? How could the CUA make a smart VQUERY using only unknown property names - before it knows the property names in the components that will be in the result set? That is why I am proposing we define reserved name schema that will never be a property name. > > If you are saying that it is treated just like the property > > name (attendee in this example), then why not just enter > > attendee? If you are saying that it is NOT treated just > > like the property that it is an ~alias~ for, then how will > > it know how to treat it if it is part of the expanded '*', > > or named specificly in the future as an existing property > > in the component in the FROM clause? > > I don't know if it's possible to use the named property (or component) > in the FROM clause? But assuming it was (for the sake of argument), then > there are 2 cases : (a) You have an existing VQUERY using the new property > name as a USING_* variable name that you don't want to change. Because of > the local precedence rule, you're fine here; the semantics of the VQUERY > won't change. (b) You want to modify a VQUERY to use the new property name > (or component name) in the FROM clause, but you've already used the name as > a USING_* variable. In that case, since you're already modifying the > VQUERY, just change the variable name :) To what? The CUA will NOT know what non-existant property names exist until after the VQUERY. --------------D47D7E71018A674B2FFAA49B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 17:01:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TLds503130 for ietf-calendar-bks; Tue, 29 Jan 2002 13:39:54 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TLdq303126 for ; Tue, 29 Jan 2002 13:39:52 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA24555 for ; Tue, 29 Jan 2002 16:39:49 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TLdlQ15956 for ; Tue, 29 Jan 2002 16:39:49 -0500 (EST) Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C570001.5A0DB113@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> <3C570001.5A0DB113@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 29 Jan 2002 16:47:45 -0500 Message-Id: <1012340867.6287.14.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit An example may help clarifying the proposition. Assuming that the target of a VQUERY only contains the following component: BEGIN:VEVENT UID:abc12234 ... ATTENDEE:recalid1@example.com ATTENDEE:recalid2@example.com ATTENDEE:recalid3@example.com ATTENDEE:recalid4@example.com ATTENDEE:recalid5@example.com att1:imaginary property to demonstrate scoping. END:VEVENT (1) The following VQUERY: BEGIN:VQUERY QUERY:SELECT UID,ATTENDEE FROM VEVENT USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 WHERE att1 = 'recalid1@example.com' AND att2 = 'recalid2@example.com' END:VQUERY would return the following component (omitting the surrounding VCALENDAR,...) BEGIN:VEVENT UID:abc12234 ATTENDEE:recalid1@example.com ATTENDEE:recalid2@example.com ATTENDEE:recalid3@example.com ATTENDEE:recalid4@example.com ATTENDEE:recalid5@example.com END:VEVENT (2) The following VQUERY: BEGIN:VEVENT QUERY:SELECT UID,att1 FROM VEVENT USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 WHERE att1 = 'recalid1@example.com' AND att2 = 'recalid2@example.com' END:VEVENT would return the component: BEGIN:VEVENT UID:abc12234 ATTENDEE:recalid1@example.com END:VEVENT NOTE: only the ATTENDEE properties matching the att1 in the query are returned. (3) The following VQUERY: BEGIN:VEVENT QUERY:SELECT * FROM VEVENT USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 WHERE att1 = 'recalid1@example.com' AND att2 = 'recalid2@example.com' END:VEVENT would return the component: BEGIN:VEVENT UID:abc12234 ... ATTENDEE:recalid1@example.com ATTENDEE:recalid2@example.com ATTENDEE:recalid3@example.com ATTENDEE:recalid4@example.com ATTENDEE:recalid5@example.com att1:imaginary property to demonstrate scoping. END:VEVENT Now of course if your query explicitly refers to the "att1" property, then you'll need to use another name for local variable in your query. e.g, BEGIN:VEVENT QUERY:SELECT att1,UID,att3 FROM VEVENT USING_PROPERTIES ATTENDEE att3, ATTENDEE att2 WHERE att3 = 'recalid1@example.com' AND att2 = 'recalid2@example.com' END:VEVENT Would return: BEGIN:VEVENT UID:abc12234 ATTENDEE:recalid1@example.com att1:imaginary property to demonstrate scoping. END:VEVENT The same pattern would apply for components used in conjunction with the USING_COMPONENTS proposition. On Tue, 2002-01-29 at 15:03, Doug Royer wrote: > Alan Davies wrote: > > > > At 10:50 AM 29/01/2002 -0700, Doug Royer wrote: > > > > I still don't see why it won't work; if my CUA sends a "SELECT * FROM..." > > > > query to a CS that supports the new "att1" property, is should recieve > > > > the att1 property no matter when it was 'compiled'. The "*" is expanded > > > > by the CS, and has nothing to do with the CUA. > > > > > > > > >So if a 'att1' property exists, then this will get it? > > > > > > SELECT att1 FROM VEVENT > > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > > > WHERE att1.att1 = 'foo' > > > AND att2.att1 = 'fee' > > > > I don't understand that example, and don't see how it relates > > to the answer that I gave about the expansion of "*". > > My point is that for that property, it would be the > same as that property as part of '*'? If not, then I don't > understand the USING_PROPERTIES yet. > > > Are you treating ATTENDEE as if it's a subcomponent, not a > > property with the ATTENDEE.att1 type syntax? > > I am lost - :-) > > Maybe that is my point. I need more text to understand it. > I thought I understood it when it COULD NOT be part of > the SELECT clause. > > > I still don't see why Patrice's quote on this issue from some way > > back up the thread doesn't solve the problem that I think you're > > trying to demonstrate: > > I was just trying different examples in order for me to understand > the difference. I was not proposing any solution - yet - as > I don't understand what the USING_PROPERTIES local-name does > when it is in the SELECT clause. > > If you are saying that it is treated just like the property > name (attendee in this example), then why not just enter > attendee? If you are saying that it is NOT treated just > like the property that it is an ~alias~ for, then how will > it know how to treat it if it is part of the expanded '*', > or named specificly in the future as an existing property > in the component in the FROM clause? > > What am I missing? From owner-ietf-calendar@mail.imc.org Tue Jan 29 17:09:14 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22469 for ; Tue, 29 Jan 2002 17:09:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TLwGa03738 for ietf-calendar-bks; Tue, 29 Jan 2002 13:58: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 g0TLwF303732 for ; Tue, 29 Jan 2002 13:58: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 QAA24987 for ; Tue, 29 Jan 2002 16:58:12 -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 g0TLwCQ17858 for ; Tue, 29 Jan 2002 16:58:12 -0500 (EST) Message-Id: <5.1.0.14.0.20020129165413.01b64c40@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Jan 2002 17:01:47 -0500 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism In-Reply-To: <3C571847.5579F703@Royer.com> References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> <3C570001.5A0DB113@Royer.com> <163201c1a904$2c7e69d0$092e0165@in.steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:46 PM 29/01/2002 -0700, you wrote: >Graham Gilmore wrote: > > > > > > >So if a 'att1' property exists, then this will get it? > > > > > > > > > > SELECT att1 FROM VEVENT > > > > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > > > > > WHERE att1.att1 = 'foo' > > > > > AND att2.att1 = 'fee' > > > > No; because the USING_PROPERTIES redefines 'att1' (in the context of > > this CAP-QL text *ONLY*) to be a specific ATTENDEE property that > matches the > > WHERE clause. > > If 'att1' becomes a property name at some later point, it doesn't > > matter, because the local definition in USING_PROPERTIES (or > > USING_COMPONENTS) will override it (although it still could/would be > > selected in a "SELECT *". > >So in other words - if that happens - your toast and your >CUA can never again get out what it put it. Using the same >original VQUERY over time. What about the ROM CUA - hand held >devices and phones? No, your query will return the same results. A query like "SELECT * from VEVENT" would return the new property, but a query that names the attributes, or provides aliases for them with "USING_PROPERTIES", would always return the same result. >Today - you want to get out the UID and ATTENDEE entries, but >only for ATTENDEE is 'foo' or 'fee'. If I understand the >proposal, this is the QUERY: > > SELECT UID,att1 from VEVENT > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > WHERE att1 = 'foo' > OR att2 = 'fee' This query should be written: SELECT UID, att1 from VEVENT USING_PROPERTIES ATTENDEE att1 WHERE att1 = 'foo' OR att1 = 'fee' or SELECT UID, ATTENDEE from VEVENT WHERE ATTENDEE = 'foo' OR ATTENDEE = 'fee' >A year from today the 'att1' property is added as a valid property >that has NOTHING to do with ATTENDEE and without your CUA knowing >that it was added in the component stored in the CS. Now the same >VQUERY will not return the same results? The same VQUERY will now >return the UID and the value of the att1 property? If not how can >I then get the UID and value of the att1 property when the ATTENDEE >is 'foo' or 'fee'. As stated by Patrice and repeated by me, the local alias used for the property would override any future property names in that query and that query only. >I think your past reply stated that the CUA must determine >the QUERY line dynamically? That won't work ether as any CUA >at any point in time will not know if the 'att1' property >really exists in the component or not. I don't understand what you mean; at the time of evaluation the whole query should be present, and the "USING_PROPERTIES" clause can be parsed. >You also stated that the USING_() value overrides the SELECT >clause. How will the CS know not to when the property names in >the components are NOT known until after the CS does the VQUERY? >How would it know that 'this' time I want the value of the >property name that I don't know exists, until after I do >the VQUERY? How could the CUA make a smart VQUERY using >only unknown property names - before it knows the property names >in the components that will be in the result set? I really don't understand this, the CUA doesn't have to know about unknown property names. >That is why I am proposing we define reserved name schema >that will never be a property name. I don't think that's necessary when a 1-line statement about the scope that the names are valid in is enough. > I don't know if it's possible to use the named property (or component) > > in the FROM clause? But assuming it was (for the sake of argument), then > > there are 2 cases : (a) You have an existing VQUERY using the new property > > name as a USING_* variable name that you don't want to change. Because of > > the local precedence rule, you're fine here; the semantics of the VQUERY > > won't change. (b) You want to modify a VQUERY to use the new property name > > (or component name) in the FROM clause, but you've already used the name as > > a USING_* variable. In that case, since you're already modifying the > > VQUERY, just change the variable name :) > >To what? The CUA will NOT know what non-existant property names >exist until after the VQUERY. Of course it doesn't, and it doesn't need to. --Alan From owner-ietf-calendar@mail.imc.org Tue Jan 29 17:09:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22486 for ; Tue, 29 Jan 2002 17:09:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TLwV103747 for ietf-calendar-bks; Tue, 29 Jan 2002 13:58:31 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TLwU303743 for ; Tue, 29 Jan 2002 13:58:30 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA09911 for ; Tue, 29 Jan 2002 13:58:31 -0800 (PST) Message-ID: <3C571B01.9C9653DF@Royer.com> Date: Tue, 29 Jan 2002 14:58:25 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> Content-Type: multipart/mixed; boundary="------------575114888E8519FBDEBBADCB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------575114888E8519FBDEBBADCB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > Yes your examples grant or deny the UPN, but is what is missing > > > > is where they are connecting FROM. > > > > > > It is not missing. It simply does not belong in the VCAR. > > > > > > VCARs are supposed to allow calendar users to grant and deny > > > rights to other authenticated users, regardless of where they > > > are connecting from, > > > > Why then do we have anonymous@named-domain UPNs? > > I don't know. You brought this up: > > http://www.imc.org/ietf-calendar/mail-archive/msg03333.html > http://www.imc.org/ietf-calendar/mail-archive/msg03342.html Yes I did bring it up. The reason was so that we could authenticate BY CONNECTED from DOMAIN, yet we failed to complete the proposal in access rights. Which is my point and why I sent the above email and email on this topic. > > > AFAIK, this was not identified as a requirement and is certainly > > > outside the scope for CAP 1.0. > > > > Again that's why we have anonymous@realm. What is to > > keep them from supplying anonymous@realm if they are not from > > realm? Nothing - that's what I noticed was missing. > > I propose NO anonymous@realm. Too late. Already in CAP and not realistic. Publicly available calendars exist and are going to exist. We can't mandate that you can only look at a public schedule if you already have an account. And the reason that anonymous@realm existed was so that calendar administrators could select the realm of the anonymous connections. Which only seems to be related to the UPN they authenticated with. But it does not solve the problem that was only half proposed by creating anonymous@realm. --------------575114888E8519FBDEBBADCB Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 17:16:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TM5eI03893 for ietf-calendar-bks; Tue, 29 Jan 2002 14:05: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 g0TM5d303888 for ; Tue, 29 Jan 2002 14:05: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 OAA09930 for ; Tue, 29 Jan 2002 14:05:41 -0800 (PST) Message-ID: <3C571CAE.70FF2037@Royer.com> Date: Tue, 29 Jan 2002 15:05:34 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Returned mail: Host unknown (Name server: imc.or: host not found)] Content-Type: multipart/mixed; boundary="------------CBAC259C9C94544CC699742E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CBAC259C9C94544CC699742E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > In previous proposals: > > > > SELF - was a tag that meant 'currently authenticated UPN' > > in VCAR and VQUERY > > > > OWNER - Was a tag that meant 'currently authenticated UPN > > - IF they are the owner'. > > In both VCAR and VQUERY. > > > > NONOWNER- Was a tag that meant 'currently authenticated UPN' > > - IF they are NOT the owner of the calendar. > > In both VCAR and VQUERY. > > > > * - stood for 'any currently authenticated UPN. > > In both VCAR and VQUERY. > > Which proposals are you referring to? I've looked in the > archive and I could not find any proposal for VQUERY that > made mention of these tags. They were in CAP, you added it to VQUERY. We don't need two ways to do the same thing. If we add one, lets add them all. If we rename one to a function, lets rename them all to functions. > > > In my proposal I assumed that CAP-QL would also have a way to > > > express SELF, and I used a function for that (i.e., SELF()). > > > I've simply transposed this concept in my proposal. > > > > So my question is, do we want to change OWNER -> OWNER(), > > and NONOWNER() to NONOWNER() and so on? > > OWNER no. > > NONOWNER no. > > SELF okay since it is used in CAP-QL. I'll add them to CAP-QL - as functions - any objections?. They all need to be the same, function or non-function. Which? > > > > If not, lets make them all the same format. (All as > > functions, or all not as functions). > > Again, as I said, the only change I did, as part of my > proposal, was to bring SELF in the CAP-QL vocabulary. > Whether we make SELF a function or not in CAP-QL should > not have any impact on the tags OWNER and NONOWNER for > the GRANT and DENY properties. Don't mix apples with > oranges as my old math teacher used to say! They are NOT apples and oranges. SELF means the currently authenticed user in both VQUERY and VCAR? What is the other meaning? --------------CBAC259C9C94544CC699742E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 17:31:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TMK3o04841 for ietf-calendar-bks; Tue, 29 Jan 2002 14:20:03 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TMK1304837 for ; Tue, 29 Jan 2002 14:20:02 -0800 (PST) To: ietf-calendar@imc.org Subject: Re-work on RFC2739 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 29 Jan 2002 17:19:58 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/29/2002 05:20:05 PM, Serialize complete at 01/29/2002 05:20:05 PM Content-Type: multipart/alternative; boundary="=_alternative 007AADCC85256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007AADCC85256B50_= Content-Type: text/plain; charset="us-ascii" We have a couple of options on this change. First off, we need to agree that there is a problem with the draft and we need to make the change. Since no one responded to Bruce's original note about the problems in RFC2739, I am assuming that everyone agrees???? Speak up or forever hold your piece. If I don't hear any comments back on this statement, then here's what I recommend we do. We have lots of options that we can use to make an RFC change. 1- Send in a notice which is published under "known bugs in RFC's" which no one ever reads (so I've heard) 2- Write a new RFC which update the old one, and "just" fix this error 3- Write a new RFC which obsoletes the old one I and one of our area directors suggest number 2. Comments/thoughts/disagreements/totally dont' cares --=_alternative 007AADCC85256B50_= Content-Type: text/html; charset="us-ascii"
We have a couple of options on this change.  

First off, we need to agree that there is a problem with the draft and we need to make the change.  Since no one responded to Bruce's original note about the problems in RFC2739, I am assuming that everyone agrees???? Speak up or forever hold your piece.

If I don't hear any comments back on this statement, then here's what I recommend we do. We have lots of options that we can use to make an RFC change.

 1- Send in a notice which is published under "known bugs in RFC's"
  which no one ever reads (so I've heard)

2- Write a new RFC which update the old one, and "just" fix this
  error

3- Write a new RFC which obsoletes the old one

I and one of our area directors suggest number 2.

Comments/thoughts/disagreements/totally dont' cares --=_alternative 007AADCC85256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 17:36:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23294 for ; Tue, 29 Jan 2002 17:36:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TMOd704980 for ietf-calendar-bks; Tue, 29 Jan 2002 14:24:39 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TMOb304971 for ; Tue, 29 Jan 2002 14:24:37 -0800 (PST) To: "ietf-calendar@imc.org" Cc: Alan Davies , "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: CAP by Minneapolis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 29 Jan 2002 17:24:35 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/29/2002 05:24:40 PM, Serialize complete at 01/29/2002 05:24:40 PM Content-Type: multipart/alternative; boundary="=_alternative 007B19AC85256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B19AC85256B50_= Content-Type: text/plain; charset="us-ascii" Hi Alan. Doug is right. We need to keep all notes on the list. I don't think Doug was saying anything bad about Steltor - he was making sure Bruce knew who was making a case for the topic. Bruce's email has been sort of "mucked up" and he may not have seen all the threads. I believe Doug wanted to make sure Bruce knew the context. And yes, we did get our hands slapped for notes off the list. But, we're better now. So, all of the rest of you who are annoyed at the traffic - well, this is a discussion on calendar standards efforts. This is how we try to figure out what to do. Keep those cards and letters coming. And play nice! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 007B19AC85256B50_= Content-Type: text/html; charset="us-ascii"
Hi Alan.  Doug is right.  We need to keep all notes on the list.  I don't think Doug was saying anything bad about Steltor - he was making sure Bruce knew who was making a case for the topic.  Bruce's email has been sort of "mucked up" and he may not have seen all the threads.  I believe Doug wanted to make sure Bruce knew the context.

And yes, we did get our hands slapped for notes off the list.  But, we're better now.  So, all of the rest of you who are annoyed at the traffic - well, this is a discussion on calendar standards efforts. This is how we try to figure out what to do.  Keep those cards and letters coming.

And play nice!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 007B19AC85256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 18:39:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24577 for ; Tue, 29 Jan 2002 18:39:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TNRpI06216 for ietf-calendar-bks; Tue, 29 Jan 2002 15:27:51 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TNRo306212 for ; Tue, 29 Jan 2002 15:27:50 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA26436 for ; Tue, 29 Jan 2002 18:27:48 -0500 Received: from c1271 (c-1271.in.steltor.com [101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id g0TNRlQ26879 for ; Tue, 29 Jan 2002 18:27:47 -0500 (EST) Message-ID: <167e01c1a91c$adf75310$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> <3C570001.5A0DB113@Royer.com> <163201c1a904$2c7e69d0$092e0165@in.steltor.com> <3C571847.5579F703@Royer.com> Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism Date: Tue, 29 Jan 2002 18:28:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > No; because the USING_PROPERTIES redefines 'att1' (in the context of > > this CAP-QL text *ONLY*) to be a specific ATTENDEE property that matches the > > WHERE clause. > > If 'att1' becomes a property name at some later point, it doesn't > > matter, because the local definition in USING_PROPERTIES (or > > USING_COMPONENTS) will override it (although it still could/would be > > selected in a "SELECT *". > > So in other words - if that happens - your toast and your > CUA can never again get out what it put it. Using the same > original VQUERY over time. What about the ROM CUA - hand held > devices and phones? > > Today - you want to get out the UID and ATTENDEE entries, but > only for ATTENDEE is 'foo' or 'fee'. If I understand the > proposal, this is the QUERY: > > SELECT UID,att1 from VEVENT > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > WHERE att1 = 'foo' > OR att2 = 'fee' I get the feeling you don't quite understand the proposal (or, more specifically, Patrice's scoping addition); the VQUERY to "get out the UID and ATTENDEE entries, but only for ATTENDEE is 'foo' or 'fee'" would be: SELECT UID,att1 from VEVENT USING_PROPERTIES ATTENDEE att1 WHERE att1 = 'foo' OR att1 = 'fee' The incidence of the token 'att1' in the USING_PROPERTIES clause reserves the name 'att1' to mean the ATTENDEE property (from the USING_PROPERTIES clause) that fits whatever description is forthcoming in the WHERE clause. Think of it as a pointer variable definition in C. When 'att1' is used in the WHERE clause, it is stating exactly which ATTENDEE property is referenced by the 'att1' name, by giving value constraints. Thus, in the example above, 'att1' becomes any ATTENDEE property whose value is 'foo' or 'fee'. Think of it as assigning a value to your pointer variable. Finally, in the SELECT clause, the 'att1' name is used as a placeholder for the full definition which has been set up by the USING_PROPERTIES and WHERE clauses. Think of it as dereferencing your pointer variable. Maybe it would be more clear if the USING_PROPERTIES line came before the SELECT, like this? : USING_PROPERTIES ATTENDEE att1 SELECT UID,att1 from VEVENT WHERE att1 = 'foo' OR att1 = 'fee' > A year from today the 'att1' property is added as a valid property > that has NOTHING to do with ATTENDEE and without your CUA knowing > that it was added in the component stored in the CS. Now the same > VQUERY will not return the same results? The same VQUERY will now > return the UID and the value of the att1 property? If not how can > I then get the UID and value of the att1 property when the ATTENDEE > is 'foo' or 'fee'. I'm afraid you've misunderstood my post; my apologies if it wasn't clear enough. If, a year from today the 'att1' property is added as a valid property (that has NOTHING to do with ATTENDEE and without my CUA knowing that it was added in the component stored in the CS), THEN my VQUERY will return the SAME results as it does today; because now, one year from now, and until the end of time (or at least until a newer version of CAP changes the scoping rules ;), 'att1' will mean "the ATTENDEE whose value is 'foo' or 'fee'" inside my VQUERY, and it will NEVER mean any new component or property or parameter or command or what have you. Yes, this means that if I continue to use the name 'att1' then in that same VQUERY I will not be able to *specifically* select a property named 'att1', because I will only get the local VQUERY definition rather than the global definition (but remember that a wildcard SELECT will still retrieve the property.) > I think your past reply stated that the CUA must determine > the QUERY line dynamically? That won't work ether as any CUA > at any point in time will not know if the 'att1' property > really exists in the component or not. > > You also stated that the USING_() value overrides the SELECT > clause. How will the CS know not to when the property names in > the components are NOT known until after the CS does the VQUERY? > How would it know that 'this' time I want the value of the > property name that I don't know exists, until after I do > the VQUERY? How could the CUA make a smart VQUERY using > only unknown property names - before it knows the property names > in the components that will be in the result set? I think this point is moot if you consider my (hopefully sufficiently clear this time) explanation above. The CS can figure out that 'att1' means some user-defined substitution described in the VQUERY itself based solely on the USING_PROPERTIES, regardless of the existence or non-existence of a property named 'att1'. Graham From owner-ietf-calendar@mail.imc.org Tue Jan 29 18:54:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24834 for ; Tue, 29 Jan 2002 18:54:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TNZBT06332 for ietf-calendar-bks; Tue, 29 Jan 2002 15:35:11 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TNZ9306328 for ; Tue, 29 Jan 2002 15:35:10 -0800 (PST) To: Cc: ietf-calendar@imc.org Subject: RE: Re-work on RFC2739 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 29 Jan 2002 18:35:07 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/29/2002 06:35:13 PM, Serialize complete at 01/29/2002 06:35:13 PM Content-Type: multipart/alternative; boundary="=_alternative 00818F1F85256B50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00818F1F85256B50_= Content-Type: text/plain; charset="us-ascii" My understanding is it's just the piece that's wrong. Here's verbiage from a note from an AD - "I.e. write a new I-D which only talk about the part of the old RFC which is wrong, and do the normal sing-and-dance thing with it." How do you interpret that statement. I think it means just talk about the part. There is a precedent for this - i just don't have time to look up an example RFC to show everyone. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 01/29/02 18:27 To: cc: Subject: RE: Re-work on RFC2739 Assume that #2 means to publish a complete text for revised RFC and not just an errata sheet in the form of a RFC? If I don't hear any comments back on this statement, then here's what I recommend we do. We have lots of options that we can use to make an RFC change. 1- Send in a notice which is published under "known bugs in RFC's" which no one ever reads (so I've heard) 2- Write a new RFC which update the old one, and "just" fix this error 3- Write a new RFC which obsoletes the old one I and one of our area directors suggest number 2. Comments/thoughts/disagreements/totally dont' cares --=_alternative 00818F1F85256B50_= Content-Type: text/html; charset="us-ascii"
My understanding is it's just the piece that's wrong. Here's verbiage from a note from an AD -

"I.e. write a new I-D which only talk about the part of the old RFC which is
wrong, and do the normal sing-and-dance thing with it."

How do you interpret that statement.  I think it means just talk about the part.  There is a precedent for this - i just don't have time to look up an example RFC to show everyone.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


<Frank.Dawson@nokia.com>

01/29/02 18:27

       
        To:        <pregen@egenconsulting.com>
        cc:        
        Subject:        RE: Re-work on RFC2739



Assume that #2 means to publish a complete text for revised RFC and not just an errata sheet in the form of a RFC?
If I don't hear any comments back on this statement, then here's what I recommend we do. We have lots of options that we can use to make an RFC change.

1- Send in a notice which is published under "known bugs in RFC's"
 which no one ever reads (so I've heard)

2- Write a new RFC which update the old one, and "just" fix this
 error

3- Write a new RFC which obsoletes the old one

I and one of our area directors suggest number 2.

Comments/thoughts/disagreements/totally dont' cares

--=_alternative 00818F1F85256B50_=-- From owner-ietf-calendar@mail.imc.org Tue Jan 29 19:12:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25164 for ; Tue, 29 Jan 2002 19:12:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0U01Ta06756 for ietf-calendar-bks; Tue, 29 Jan 2002 16:01: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 g0U01S306752 for ; Tue, 29 Jan 2002 16:01:28 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA10069; Tue, 29 Jan 2002 16:01:28 -0800 (PST) Message-ID: <3C5737D1.1D4BA1D0@Royer.com> Date: Tue, 29 Jan 2002 17:01:21 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: Graham Gilmore CC: ietf-calendar@imc.org Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> <3C570001.5A0DB113@Royer.com> <163201c1a904$2c7e69d0$092e0165@in.steltor.com> <3C571847.5579F703@Royer.com> <167e01c1a91c$adf75310$092e0165@in.steltor.com> Content-Type: multipart/mixed; boundary="------------DFA5BC89F3325BDB4A1A9AAF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DFA5BC89F3325BDB4A1A9AAF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Graham Gilmore wrote: > > Today - you want to get out the UID and ATTENDEE entries, but > > only for ATTENDEE is 'foo' or 'fee'. If I understand the > > proposal, this is the QUERY: > > > > SELECT UID,att1 from VEVENT > > USING_PROPERTIES ATTENDEE att1, ATTENDEE att2 > > WHERE att1 = 'foo' > > OR att2 = 'fee' > > I get the feeling you don't quite understand the proposal (or, more > specifically, Patrice's scoping addition); the VQUERY to "get out the UID > and ATTENDEE entries, but only for ATTENDEE is 'foo' or 'fee'" would be: Your right! But I don't know how else to figure it out without going over this. Someone (Patrice?) send a nice summary. I'll digest that in the AM when my brain is still feeding on food and not sugar and Caffeine. Assuming that the proposal goes "as is", I do think that we need more text to explain the proposal. Bruce (when he catches up), seem so far to have similar questions to me. So I am guessing other readers will have the same questions. --------------DFA5BC89F3325BDB4A1A9AAF Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 20:55:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0U1dkE08852 for ietf-calendar-bks; Tue, 29 Jan 2002 17:39:46 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0U1di308848 for ; Tue, 29 Jan 2002 17:39: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 RAA10235 for ; Tue, 29 Jan 2002 17:39:47 -0800 (PST) Message-ID: <3C574EDB.D7429D48@Royer.com> Date: Tue, 29 Jan 2002 18:39:39 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: TODO items Content-Type: multipart/mixed; boundary="------------7DB05F903C0B1713B8E18798" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7DB05F903C0B1713B8E18798 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The CAP TODO items, http://calsch.org/ietf/cap-ToDo.html I had sent out sever proposals for resolutions for many of the items. Without much feedback. I am going to assume that the ones that were not debated - were accepted? And I'll propose that they be added/modified in CAP on THURSDAY of THIS week. If no objections. I think that they all had 'TODO' in the subject line. --------------7DB05F903C0B1713B8E18798 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Tue, 29 Jan 2002 21:05:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0U1sbG09138 for ietf-calendar-bks; Tue, 29 Jan 2002 17:54: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 g0U1sa309134 for ; Tue, 29 Jan 2002 17:54: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 RAA10257 for ; Tue, 29 Jan 2002 17:54:38 -0800 (PST) Message-ID: <3C575255.7C326385@Royer.com> Date: Tue, 29 Jan 2002 18:54:29 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Editors notes in CAP Content-Type: multipart/mixed; boundary="------------8F63C5DA7BD30FC701B15DD7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8F63C5DA7BD30FC701B15DD7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We need to clean up the editors notes in CAP -COMMENTS? I have included my comments. > [Editors Note: TODO - get the lower port number ] WHY? Lets get this out of the CAP text and into the TODO list. > [EDITORS NOTE: Issues: > > - Can one use DELETE to remove all VALARMs and VTIMEZONEs that > match a certain search criteria and that belong to all > components, event though VALARMs and VTIMEZONEs never exist as > independent components? Yes - with the old DELETE command - checking to see if it still can be done. > Or should one use MODIFY? If they can > be deleted, do we return the REQUEST-STATUS of their deletion > in a VEVENT or separately? ??? > [EDITORS NOTE: Issue: does write access to a VAGENDA give you the > right to move a calendar into it? No - about MOVE permission. > [EDITORS NOTE: need to make a pass through the iTIP restriction > tables to make sure that there are no problems with using them as > they exist] TODO. > [EDITORS NOTE: Do we want to use the same set of codes?] Error codes - YES when they are the same error. And we need to make sure that we do NOT use the same error codes for already defined iTIP errors if they have different meanings. > 6.XXX [EDITORS NOTE: More are in this memo - add here TODO] Yes - we need to do this. I have volunteered as soon as we get the next version of the draft ready to ship, I'll update this section will all of the error codes that are in the doc, and compare / sync them with iCal, iTIP and iMIP where they overlap. > [EDITORS NOTE: These extensions/changes to iCalendar need to be > reformatted to conform to the IANA registration process defined in > section 7 of [iCAL].] Anyone volunteer? > [Editor's Note: see if the above still make sense after > reviewing the VCARs in ICAL-updates.html doc] (default VCARS) still needed - delete the note. > [EDITORS NOTE: hopefully, calid is defined somewhere...] I am confused, this comment is in the definition for CALID? Remove it? > [EDITORS NOTE: John Stracke to review any updates] I talked to him about this. He has not done this. Lets make it usable. The problem (as I recall) was that there was no appeal process once the method reviewer accepted a proposal. I think we want to be able to appeal all method reviewer decisions. --------------8F63C5DA7BD30FC701B15DD7 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 06:40:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UBQjR16171 for ietf-calendar-bks; Wed, 30 Jan 2002 03:26:45 -0800 (PST) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UBQh316167 for ; Wed, 30 Jan 2002 03:26:44 -0800 (PST) Received: from jsoft.com (IDENT:qyAUbUgqLVhEJvUsfCcltnUApnti3sl3@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g0UBJga09565 for ; Wed, 30 Jan 2002 05:19:42 -0600 Message-ID: <3C57D6CE.20608@jsoft.com> Date: Wed, 30 Jan 2002 05:19:42 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar Subject: Re: CAP by Minneapolis References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Patricia Egen mentioned: >Keep those cards and letters > coming. I have been wondering if anything is going on with the XML version of iCalendar. I was waiting for CAP conversation to slow down... ... Is anything going on with the XML version of iCalendar? Gary pregen@egenconsulting.com wrote: > > Hi Alan. Doug is right. We need to keep all notes on the list. I > don't think Doug was saying anything bad about Steltor - he was making > sure Bruce knew who was making a case for the topic. Bruce's email has > been sort of "mucked up" and he may not have seen all the threads. I > believe Doug wanted to make sure Bruce knew the context. > > And yes, we did get our hands slapped for notes off the list. But, > we're better now. So, all of the rest of you who are annoyed at the > traffic - well, this is a discussion on calendar standards efforts. This > is how we try to figure out what to do. Keep those cards and letters > coming. > > And play nice! > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 From owner-ietf-calendar@mail.imc.org Wed Jan 30 08:30:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17715 for ; Wed, 30 Jan 2002 08:30:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UDKCu24024 for ietf-calendar-bks; Wed, 30 Jan 2002 05:20:12 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UDKB324015 for ; Wed, 30 Jan 2002 05:20: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 IAA31710; Wed, 30 Jan 2002 08:20:07 -0500 Received: from c2767 ([101.1.46.19]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UDK6Q03850; Wed, 30 Jan 2002 08:20:06 -0500 (EST) From: "ericp" To: "'Gary Frederick'" , "'ietf-calendar'" Subject: RE: CAP by Minneapolis Date: Wed, 30 Jan 2002 08:19:04 -0500 Message-ID: <004201c1a990$b0964f30$132e0165@in.steltor.com> 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, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C57D6CE.20608@jsoft.com> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Good Morning Gary, The XML iCalendar has been pretty quite, due to the CAP work and the focus on completing the draft. I will be sending out a updated issues list soon. The XML draft will expire on Feb 16 2002, so I hope to have an update of the draft. There may not be too many significant changes to it, with another update to follow in the spring. Eric ------------------------------- Eric R. Plamondon Steltor - Chief Web Architect 2000 Peel Street, 4th Floor Montreal, Quebec mailto:ericp@steltor.com http://www.steltor.com > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of Gary Frederick > Sent: Wednesday, January 30, 2002 6:20 AM > To: ietf-calendar > Subject: Re: CAP by Minneapolis > > > > Patricia Egen mentioned: > >Keep those cards and letters > > coming. > > I have been wondering if anything is going on with the XML version of > iCalendar. I was waiting for CAP conversation to slow down... > > ... > > Is anything going on with the XML version of iCalendar? > > Gary > > pregen@egenconsulting.com wrote: > > > > > Hi Alan. Doug is right. We need to keep all notes on the list. I > > don't think Doug was saying anything bad about Steltor - he > was making > > sure Bruce knew who was making a case for the topic. > Bruce's email has > > been sort of "mucked up" and he may not have seen all the > threads. I > > believe Doug wanted to make sure Bruce knew the context. > > > > And yes, we did get our hands slapped for notes off the list. But, > > we're better now. So, all of the rest of you who are > annoyed at the > > traffic - well, this is a discussion on calendar standards > efforts. This > > is how we try to figure out what to do. Keep those cards > and letters > > coming. > > > > And play nice! > > ___________________ > > Patricia Egen Consulting > > www.egenconsulting.com > > 423-875-2652 > > > > > From owner-ietf-calendar@mail.imc.org Wed Jan 30 10:00:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21238 for ; Wed, 30 Jan 2002 10:00:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UEeqc29115 for ietf-calendar-bks; Wed, 30 Jan 2002 06:40:52 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UEeo329111 for ; Wed, 30 Jan 2002 06:40:51 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA00807 for ; Wed, 30 Jan 2002 09:40:46 -0500 Received: from steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UEekQ12498 for ; Wed, 30 Jan 2002 09:40:46 -0500 (EST) Message-ID: <3C5807CA.1801939@steltor.com> Date: Wed, 30 Jan 2002 09:48:42 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: (#3) 4.1.1 Grammar for Search Mechanism References: <3C546DE4.94064E6B@Royer.com> <1012234815.2000.41.camel@c-1241.in.steltor.com> <5.1.0.14.0.20020128194522.035480d8@imap1.in.steltor.com> <5.1.0.14.0.20020129094841.01aa2c68@imap1.in.steltor.com> <5.1.0.14.0.20020129125939.0355ac70@imap1.in.steltor.com> <3C570001.5A0DB113@Royer.com> <163201c1a904$2c7e69d0$092e0165@in.steltor.com> <3C571847.5579F703@Royer.com> <167e01c1a91c$adf75310$092e0165@in.steltor.com> <3C5737D1.1D4BA1D0@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: ... > > But I don't know how else to figure it out without going over > this. Someone (Patrice?) send a nice summary. ... Here's an informal summary of my understanding of the USING_PROPERTIES clause. 1. Overview of USING_PROPERTIES (without new suggestions). The USING_PROPERTIES clause was introduced to manipulate properties that may occur more than one in a component (e.g., ATTENDEE). Informally, a clause of the form: USING_PROPERTIES PROPERTYNAME varname has the following semantic: There exist at least one property PROPERTYNAME (referred to as varname) that satisfies the query. Here's an example of its usage: SELECT * FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = 'relcalid@example.com' This means select all VEVENTs having at least one property ATTENDEE with the value 'relcalid@example.com' Alan also proposed that when referring directly to a multi-value property in the WHERE clause, the semantic would be "for all". e.g., SELECT * FROM VEVENT WHERE PARAM( ATTENDEE, PARTSTAT ) = 'ACCEPTED' Means select all VEVENT where ALL attendees have their participation status set to ACCEPTED. 2. The problem of potential name conflict. The USING_PROPERTIES does introduce new identifiers that may conflict with existing or future properties (or components). As a solution, Doug suggested the use or a prefix (i.e, "x-" or "l-"). The other alternative, debated yesterday, is to give precedence to the local identifiers (e.g., problem similar the scope of variables in programming languages such as C). 3. Proposition to allow the USING_PROPERTIES identifiers in the SELECT clause. As mentioned in (1), the USING_PROPERTIES construct allows the manipulate individual instances of multi-value properties. It appears that the same concept could also apply to the SELECT clause. i.e., - SELECT MULTIPROPERTYNAME FROM COMPONENT... means return ALL the instances of MULTIPROPERTYNAME. - SELECT ident FROM COMPONENT USING_PROPERTIES ident ... means return only the instances of MULTIPROPERTYNAME where the expression in the WHERE clause can be satisfied if the ident is bounded to the property. e.g., SELECT ATTENDEE FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = 'relcalid@example.com' would mean: Return ALL the attendee properties of the VEVENT containing 'relcalid@example.com' as an attendee. And SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = 'relcalid@example.com' Would mean: Return only the attendee(s) with value = 'relcalid@example.com' for all VEVENTs having 'relcalid@example.com' as an attendee. Examples of (2) and (3) can be found here: http://www.imc.org/ietf-calendar/mail-archive/msg03622.html 4. USING_COMPONENTS. Alan mentioned that the multi-value problem is similar to the multiple occurrences of sub-components. e.g. VEVENTs in VAGENDA, VALARMs in VEVENT It seems that the introduction of a USING_COMPONENTS clause, could address the issues of multi sub-components in a similar manner. -- Patrice From owner-ietf-calendar@mail.imc.org Wed Jan 30 12:10:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25511 for ; Wed, 30 Jan 2002 12:10:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UGlql04286 for ietf-calendar-bks; Wed, 30 Jan 2002 08:47:52 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UGlo304282 for ; Wed, 30 Jan 2002 08:47:51 -0800 (PST) To: ietf-calendar@imc.org Subject: CALSCH meeting time in Minn MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 30 Jan 2002 11:47:50 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 01/30/2002 11:47:53 AM, Serialize complete at 01/30/2002 11:47:53 AM Content-Type: multipart/alternative; boundary="=_alternative 005C452C85256B51_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C452C85256B51_= Content-Type: text/plain; charset="us-ascii" We've been assigned the Thursday, 3:30 timeslot for Minneapolis. I'm providing this info so those of you coming to Minneapolis can plan your trip accordingly. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 005C452C85256B51_= Content-Type: text/html; charset="us-ascii"
We've been assigned the Thursday, 3:30 timeslot for Minneapolis.    I'm providing this info so those of you coming to Minneapolis can plan your trip accordingly.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 005C452C85256B51_=-- From owner-ietf-calendar@mail.imc.org Wed Jan 30 12:15:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25773 for ; Wed, 30 Jan 2002 12:15:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UGt9N04458 for ietf-calendar-bks; Wed, 30 Jan 2002 08:55:09 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UGt8304451 for ; Wed, 30 Jan 2002 08:55:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA11136 for ; Wed, 30 Jan 2002 08:55:08 -0800 (PST) Message-ID: <3C582569.466CA267@Royer.com> Date: Wed, 30 Jan 2002 09:55:05 -0700 From: Doug Royer Reply-To: ietf-calendar@royer.com Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP by Minneapolis References: <3C57D6CE.20608@jsoft.com> Content-Type: multipart/mixed; boundary="------------8A3C0AB8A957C30FE21B7CDD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8A3C0AB8A957C30FE21B7CDD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > > Patricia Egen mentioned: > >Keep those cards and letters > > coming. > > I have been wondering if anything is going on with the XML version of > iCalendar. I was waiting for CAP conversation to slow down... > > ... > > Is anything going on with the XML version of iCalendar? As soon as CAP is out, I hope we go full steam ahead with XML. --------------8A3C0AB8A957C30FE21B7CDD Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 13:33:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UIM7a06762 for ietf-calendar-bks; Wed, 30 Jan 2002 10:22:07 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UIM6306758 for ; Wed, 30 Jan 2002 10:22:06 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA06149 for ; Wed, 30 Jan 2002 13:22:03 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UIM2Q06867 for ; Wed, 30 Jan 2002 13:22:03 -0500 (EST) Message-ID: <3C583A30.55D9A890@steltor.com> Date: Wed, 30 Jan 2002 13:23:44 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > I propose NO anonymous@realm. > > Too late. Already in CAP and not realistic. Publicly > available calendars exist and are going to exist. We can't > mandate that you can only look at a public schedule if > you already have an account. > > And the reason that anonymous@realm existed was so that > calendar administrators could select the realm of the > anonymous connections. Which only seems to be related > to the UPN they authenticated with. But it does not solve > the problem that was only half proposed by creating > anonymous@realm. The UPN "bernard@steltor.com" doesn't mean that "bernard" is connecting from the domain "steltor.com". It simply means that someone had the proper credentials to authenticate himself as "bernard@steltor.com". Now, whether the user "bernard@steltor.com" is required to connect from a specific domain or not is the matter of the authentication mechanism, not of VCAR. Same applies to anonymous users. A calendar administrator could configure, in a proprietary way, the authentication mechanisms supported by his CS to enforce that anonymous authentication for the REALM "toto.com" (i.e., UPN=@toto.com) is only possible for connections being made from the domain "toto.com". I don't think any changes are required in CAP. We simply need to agree on the syntax of UPN. 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 Jan 30 13:55:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29056 for ; Wed, 30 Jan 2002 13:55:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UIdes07212 for ietf-calendar-bks; Wed, 30 Jan 2002 10:39: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 g0UIdd307208 for ; Wed, 30 Jan 2002 10:39: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 NAA06578; Wed, 30 Jan 2002 13:39:34 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UIdYQ08976; Wed, 30 Jan 2002 13:39:34 -0500 (EST) Message-ID: <3C583DE5.B5ACE56A@steltor.com> Date: Wed, 30 Jan 2002 13:39:33 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Editors notes in CAP References: <3C575255.7C326385@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: [snip] > > [EDITORS NOTE: These extensions/changes to iCalendar need to be > > reformatted to conform to the IANA registration process defined in > > section 7 of [iCAL].] > > Anyone volunteer? I can take of of this. If anyone sees an extension to iCalendar that is not defined in section 11 "Properties" and is not already in the To Do list please let us know. Section 4 defines the syntax for queries. Should these definitions go into section 11? Do we really need section 4? Or should we rename it to "Searching" since all it deals with is searching? Once we have a consensus on VCARs, the definition of the components, parameters, and properties used in VCARs can also go into section 11. George From owner-ietf-calendar@mail.imc.org Wed Jan 30 13:57:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29117 for ; Wed, 30 Jan 2002 13:57:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UIV6H07022 for ietf-calendar-bks; Wed, 30 Jan 2002 10:31:06 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UIV5307018 for ; Wed, 30 Jan 2002 10:31:05 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA06372; Wed, 30 Jan 2002 13:31:01 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UIV0Q07945; Wed, 30 Jan 2002 13:31:00 -0500 (EST) Message-ID: <3C583BE4.714B2419@steltor.com> Date: Wed, 30 Jan 2002 13:31:00 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Issues And To-Do List References: <3C41CA00.6EE40932@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: > > - have decreed VCARS? If yes, need to make some changes to VCARS > in order to allow Decreed VCARS to be identifiable. > > I don't know why? > We have CARID's and if you have access to the VCARs, then > you can VQUERY for them. Do you mean you want to mandate > that all decreed VCARS have CARID's and that if you have > sufficient permission, you can view them? > > If that is what you mean, then I propose that all decreed VCARS > be stored under one VCAR in the implementation with a > CARID of 'decreed'. Comments? The issue with decreed VCARs is that there is no way of telling them apart from non-decreed VCARs. > > - DENY/GRANT does have an ordering > see post "CAP: no ordering on GRANT/DENY?" > > True. You can GRANT then later DENY, and you can DENY then > later GRANT. They are bits, not a chain of events to process. > > - CALMASTER: why does it have to be a mailto: URI? Why not im: > (when IMPP is standardized), or http: (to get a page to read > before sending a message)? ... > > The idea was that you could send email to a responsible entity. > Like hostmaster, postmaster, and so on. It is a contact entity. > > ....If it does have to be email, why > not a bare email address rather than a URI? > > So that we could later specify that it was something other > than a mailto URI. :-) Does anyone see a reason why we should remove the restriction that is must be a "mailto" URI. If not think we can close this issue. An alternative is to reuse the iCalendar "CONTACT" property. It is already defined, thus we do not have to define CALAMASTER. It can also contain a phone number, name, and so forth. > > - CURRENT_DATETIME: > * What is this for? So the CUA can synchronize its clock > with the CS? If so, then doing it over TCP is probably > a bad idea. NTP already provides this functionality; > CAP shouldn't attempt to duplicate it. > > I think we discussed this recently. It is my impression that the > WG list decided it would stay. > > * It says it's a DATE-TIME value, but it's returned as a > local time and TZID. How? The DATE-TIME syntax doesn't > have room for a TZID. This is OK by me. > > There is a TIMEZONE property also, that plus CURRENT_DATETIME > gives you everything. > > - Transparency for scheduled components? What should be the default? > Maybe specify it as a VCAR per VAGENDA: For calendar X people can > or can not set the transparency. > (December 2001) > > So if I send you a bunch of junk, then your CS is going to > block your schedule? No. They are transparent until processed > by some CUA. This is OK by me. > > - What should the format be for relcalid? Should it be utf8? > (December 2001) > > Any valid URI. Lets not define what that means. Note to > impmlementors that URI's may be 8-bit in future. > > To Register: > ============ > > - Register Olson timezone's with IANA. > (Does CAP really depend on this?) > > No. Yes it does not belong in to the do list. > > - Register "cap" service name for SASL with IANA > (No longer need to do this due to BEEP?) Yes, it is handled by BEEP. > > I think we do need to MANDATE a minimum authentication > level in CAP. As I recall from my discussions with the > area directors, it is a requirement. Ideas anyone? > > ToDos: > ====== > > - Add restriction tables to the server replies to the "schedule" > command? > > Drop redundant schedule command. > > - Review CAP Requirements doc to make sure that we have met > all requirements. > > - Make sure that CAP supports synch. > > Synch? Synchronization. > > - Section 8.0 > Response codes. Need to make sure response codes in all drafts - > iCal, iMip and iTip and examples. Error numbers need to be the same. > Put > text about error codes in comments below the examples (so that > people don't look at them as being required in their text). Pat > will look at the codes. (Doug's list). > > Same for related errors. Make sure that when CAP lists error > message, that it is what iTIP specifies for iTIP methods. > > - Section 15.1.4 (now section ?) > Submit entity for approval - John submitted to list. Need to find. > Get John's text and add back into CAP draft. John submitted as a > separate draft document. Use the MIME appeal verbiage with John's > additional text. Point WG at John's draft and say it should be > included in the draft. We need to also submit to April Marine as > well. > See thread: "[EDITORS NOTE: John Stracke to review..." > > JOHN - IT HAS BEEN OVER A YEAR - ARE YOU DONE? :-) > > - If iTIP specifies that the commands must be processed in order, > then see do not need to specify it in CAP, since CAP must conform > to iTIP. > see thread: "CAP: order of processing iTIP messages" > > I agree. I think that there may have been one comment that > is unique to CAP and iTIP. > > - How do you identify specific counters? Can you use the ATTENDEE > property, but is it unique. This issue seems to have come up on > the list before with iTIP. In CAP we'll be able to retrieve specific > components. Make sure all itip components have unique keys. > (December 2001) > > I proposed we add SENT-BY the the METHOD in CAP. Comments? > > - Add a UID to VALARMs. (December 2001.) > > Add ALARMID or SEQUENCE to VALARMS. The idea is to uniquely > identify a VALARM within a component. There is no need for > it to be globally unique. If we make it globally unique, it will easily allow for global VALARMs in some future version of CAP, if they are needed. > > - Add the ability to use a wildcard in queries, > if there are no objections. > See thread: "Wildcard for component name." > (November-December 2001) > > With recent posts and the concern for understandable SQL (for > some reason :-), I think we need to remove wildcards for everything > except the SELECT clause. From owner-ietf-calendar@mail.imc.org Wed Jan 30 14:01:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29244 for ; Wed, 30 Jan 2002 14:01:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UIhfL07328 for ietf-calendar-bks; Wed, 30 Jan 2002 10:43:41 -0800 (PST) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UIhe307324 for ; Wed, 30 Jan 2002 10:43:40 -0800 (PST) Received: from jsoft.com (IDENT:RgicnHTosTSnEBuf3f/ySDBmdCptqBc1@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g0UIaca14043 for ; Wed, 30 Jan 2002 12:36:38 -0600 Message-ID: <3C583D36.7040304@jsoft.com> Date: Wed, 30 Jan 2002 12:36:38 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 CC: ietf-calendar Subject: Re: CAP by Minneapolis References: <3C57D6CE.20608@jsoft.com> <3C582569.466CA267@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would guess that when CAP is out, there will be a 'bit' of follow up as people digest. I would like to see a reference CS so people could test. There is interest (OpenOffice, PHPGroupware, Mozilla, ...) (or is a server different from a Calendar Store? :-) ) My needs are pretty simple. For example, I will probably get calendar info into XML and do my queries using XMLish queries, rather than the SQLesque language in CAP. That lets me get up and searching right away. Now back to my 9-5 as you all get ready for Minneapolis :-) Gary Doug Royer wrote: > Gary Frederick wrote: > >>Patricia Egen mentioned: >> >Keep those cards and letters >> > coming. >> >>I have been wondering if anything is going on with the XML version of >>iCalendar. I was waiting for CAP conversation to slow down... >> >>... >> >>Is anything going on with the XML version of iCalendar? >> > > As soon as CAP is out, I hope we go full steam ahead with XML. > > From owner-ietf-calendar@mail.imc.org Wed Jan 30 14:07:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29400 for ; Wed, 30 Jan 2002 14:07:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UIoaN07545 for ietf-calendar-bks; Wed, 30 Jan 2002 10:50:36 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UIoZ307541 for ; Wed, 30 Jan 2002 10:50: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 KAA11382 for ; Wed, 30 Jan 2002 10:50:36 -0800 (PST) Message-ID: <3C584078.D6A71CEA@Royer.com> Date: Wed, 30 Jan 2002 11:50:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> <3C583A30.55D9A890@steltor.com> Content-Type: multipart/mixed; boundary="------------674F4224E41646EFA7547F0C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------674F4224E41646EFA7547F0C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > I propose NO anonymous@realm. > > > > Too late. Already in CAP and not realistic. Publicly > > available calendars exist and are going to exist. We can't > > mandate that you can only look at a public schedule if > > you already have an account. > > > > And the reason that anonymous@realm existed was so that > > calendar administrators could select the realm of the > > anonymous connections. Which only seems to be related > > to the UPN they authenticated with. But it does not solve > > the problem that was only half proposed by creating > > anonymous@realm. > > The UPN "bernard@steltor.com" doesn't mean that "bernard" is > connecting from the domain "steltor.com". It simply means > that someone had the proper credentials to authenticate > himself as "bernard@steltor.com". YES - THAT IS EXACTLY MY POINT. How do I say that 'bernard@steltor.com' only has access if he is connecting from 'steltor.com' ? Otherwise he has NO access. That is why anonymous@place was proposed. So we could limit access based on not only the UPN (anonymous), but the limit it to where they are connecting from. --------------674F4224E41646EFA7547F0C Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 14:53:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UJiqn08866 for ietf-calendar-bks; Wed, 30 Jan 2002 11:44:52 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UJip308862 for ; Wed, 30 Jan 2002 11:44:51 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA08103; Wed, 30 Jan 2002 14:44:47 -0500 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UJilQ16059; Wed, 30 Jan 2002 14:44:47 -0500 (EST) Message-ID: <3C584D2E.1A2DE196@steltor.com> Date: Wed, 30 Jan 2002 14:44:46 -0500 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Updated CAP To Do and Issues List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've update the CAP To Do and issues list. You can go get it at: http://www.calsch.org/ietf/drafts.html There you will also find a link to the previous version of the To Do list. Summary of changes: - Removed items not directly related to CAP, such as needing to register timezones with IANA. - Put in some of the editors comments that are in the CAP document - Added some clarifications - Updated some items such as the query and VCAR issues Please have a look at it. If I've missed something, let me know. George From owner-ietf-calendar@mail.imc.org Wed Jan 30 14:55:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00855 for ; Wed, 30 Jan 2002 14:55:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UJfk108791 for ietf-calendar-bks; Wed, 30 Jan 2002 11:41: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 g0UJfj308787 for ; Wed, 30 Jan 2002 11:41:45 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA08011 for ; Wed, 30 Jan 2002 14:41:42 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UJfgQ15503 for ; Wed, 30 Jan 2002 14:41:42 -0500 (EST) Message-ID: <3C584CDB.CD4886A3@steltor.com> Date: Wed, 30 Jan 2002 14:43:23 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> <3C583A30.55D9A890@steltor.com> <3C584078.D6A71CEA@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Bernard Desruisseaux wrote: > > > > The UPN "bernard@steltor.com" doesn't mean that "bernard" is > > connecting from the domain "steltor.com". It simply means > > that someone had the proper credentials to authenticate > > himself as "bernard@steltor.com". > > YES - THAT IS EXACTLY MY POINT. > > How do I say that 'bernard@steltor.com' only has > access if he is connecting from 'steltor.com' ? > Otherwise he has NO access. My point is that it could be left to the implementor. I see this as an administrative task that is outside the scope of the CAP protocol. 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 Jan 30 15:00:34 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00951 for ; Wed, 30 Jan 2002 15:00:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UJm8t08955 for ietf-calendar-bks; Wed, 30 Jan 2002 11:48:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UJm7308951 for ; Wed, 30 Jan 2002 11:48:07 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA08187 for ; Wed, 30 Jan 2002 14:48:04 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UJm3Q16211 for ; Wed, 30 Jan 2002 14:48:03 -0500 (EST) Message-ID: <3C584E59.3188B72C@steltor.com> Date: Wed, 30 Jan 2002 14:49:45 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Returned mail: Host unknown (Name server: imc.or: host not found)] References: <3C571CAE.70FF2037@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: > > > > > > In previous proposals: > > > > > > SELF - was a tag that meant 'currently authenticated UPN' > > > in VCAR and VQUERY > > > > > > OWNER - Was a tag that meant 'currently authenticated UPN > > > - IF they are the owner'. > > > In both VCAR and VQUERY. > > > > > > NONOWNER- Was a tag that meant 'currently authenticated UPN' > > > - IF they are NOT the owner of the calendar. > > > In both VCAR and VQUERY. > > > > > > * - stood for 'any currently authenticated UPN. > > > In both VCAR and VQUERY. > > > > Which proposals are you referring to? I've looked in the > > archive and I could not find any proposal for VQUERY that > > made mention of these tags. > > They were in CAP, you added it to VQUERY. Not true. Again, I only added SELF() to CAP-QL. OWNER and NONOWNER have never been part of the query language, and I most certainly did not add them to VQUERY myself. > We don't need > two ways to do the same thing. If we add one, lets add them all. > If we rename one to a function, lets rename them all to functions. They are not the same thing. Beside, show me how you would use OWNER and NONOWNER in CAP-QL. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Jan 30 15:09:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01164 for ; Wed, 30 Jan 2002 15:09:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UK0ct09277 for ietf-calendar-bks; Wed, 30 Jan 2002 12:00:38 -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 g0UK0b309273 for ; Wed, 30 Jan 2002 12:00:37 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA08468 for ; Wed, 30 Jan 2002 15:00:34 -0500 Received: from c1271 (c-1271.in.steltor.com [101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id g0UK0YQ17682 for ; Wed, 30 Jan 2002 15:00:34 -0500 (EST) Message-ID: <16f501c1a9c8$e5f50d00$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> <3C583A30.55D9A890@steltor.com> <3C584078.D6A71CEA@Royer.com> Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) Date: Wed, 30 Jan 2002 15:01:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > The UPN "bernard@steltor.com" doesn't mean that "bernard" is > > connecting from the domain "steltor.com". It simply means > > that someone had the proper credentials to authenticate > > himself as "bernard@steltor.com". > > YES - THAT IS EXACTLY MY POINT. > > How do I say that 'bernard@steltor.com' only has > access if he is connecting from 'steltor.com' ? > Otherwise he has NO access. Why would we want to define this area of CS administration in CAP? I thought it was for calendaring, period. A reasonable CS authentication mechanism should be able to forbid anyone to log in as bernard@steltor.com, unless they are connecting from steltor.com. In fact, mandating that 'anonymous@host.com' MUST mean that the user has connected from 'host.com' will severely LIMIT the flexibility of CS administrators to choose realm names, or set up things like separate calendaring realms for different org units in a company without completely changing their internal network architecture. With a reasonable CS implementation, it shouldn't be hard to do things like: (a) deny authentication as the UPN 'bernard@steltor.com' if the user is not connecting from the domain steltor.com (b) If the user is wants to authenticate anonymously, give them the UPN anonymous@internal.royer.com if they're connecting from inside royer.com, otherwise give them the UPN anonymous@external.royer.com (and set up VCARs to give appropriate rights to anonymous in those CAP realms). (c) Have users logging in assigned a UPN in a CAP realm corresponding to their machine's NT workgroup. I'm sure CS administrators can think of other possibilities. What would we gain by tying CAP realms to network domains inside CAP? Graham From owner-ietf-calendar@mail.imc.org Wed Jan 30 16:26:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02516 for ; Wed, 30 Jan 2002 16:26:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0ULHaI10856 for ietf-calendar-bks; Wed, 30 Jan 2002 13:17:36 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ULHZ310852 for ; Wed, 30 Jan 2002 13:17: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 NAA11629 for ; Wed, 30 Jan 2002 13:17:36 -0800 (PST) Message-ID: <3C5862EB.20661BB8@Royer.com> Date: Wed, 30 Jan 2002 14:17:31 -0700 From: Doug Royer Reply-To: ietf-calendar Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP by Minneapolis References: <3C57D6CE.20608@jsoft.com> <3C582569.466CA267@Royer.com> <3C583D36.7040304@jsoft.com> Content-Type: multipart/mixed; boundary="------------EEDE9D20B2CE94B09939C20A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EEDE9D20B2CE94B09939C20A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > > My needs are pretty simple. For example, I will probably get calendar > info into XML and do my queries using XMLish queries, rather than the > SQLesque language in CAP. That lets me get up and searching right away. It's not going to be that simple. First you have to get the data from a CS - and that is CAP. When XML is out, then CAP can serve up XML objects, but it's still CAP. Plus if you think about synchronization issues with resources you are just going to be wasting bandwidth. If you get everything, query the local XML data then attempt to book a resource, discover it is taken, ask again for everyone, XML search everything, discover .... That is why this WG invented iTIP, and why you need a real-time (whatever that really means) connection protocol to reserve resources where the CS determines who gets what booked items. I don't see any need to invent another get stuff from a CS language. We will have to add a capability to CAP that says that the CS can dish out XML objects, and a way for the CUA to ask for them. But you will still need CAP. Think of CAP as IMAP or POP. You can have any kind of MIME objects that you fetch with IMAP and POP, but you still have to get he MIME object using IMAP or POP (or CAP). --------------EEDE9D20B2CE94B09939C20A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 16:31:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ULMgl10995 for ietf-calendar-bks; Wed, 30 Jan 2002 13:22: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 g0ULMe310991 for ; Wed, 30 Jan 2002 13:22: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 NAA11633 for ; Wed, 30 Jan 2002 13:22:42 -0800 (PST) Message-ID: <3C58641C.51F83FDD@Royer.com> Date: Wed, 30 Jan 2002 14:22:36 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Issues And To-Do List References: <3C41CA00.6EE40932@Royer.com> <3C583BE4.714B2419@steltor.com> Content-Type: multipart/mixed; boundary="------------6FE17D468EAD316A981C1DAE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6FE17D468EAD316A981C1DAE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > Doug Royer wrote: > > > > - have decreed VCARS? If yes, need to make some changes to VCARS > > in order to allow Decreed VCARS to be identifiable. > > > > I don't know why? > > We have CARID's and if you have access to the VCARs, then > > you can VQUERY for them. Do you mean you want to mandate > > that all decreed VCARS have CARID's and that if you have > > sufficient permission, you can view them? > > > > If that is what you mean, then I propose that all decreed VCARS > > be stored under one VCAR in the implementation with a > > CARID of 'decreed'. Comments? > > The issue with decreed VCARs is that there is no way of telling > them apart from non-decreed VCARs. If you don't have the VCAR to change them - what's the differance? In effect they are decreed to you. I assume with the new proposal you can still DENY/GRANT access to VCARs by ID? If we want the ones "compiled in" to be tagged, then lets add a paramater? CARID;decreed=true:NAME --------------6FE17D468EAD316A981C1DAE Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 16:36:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0ULPRs11040 for ietf-calendar-bks; Wed, 30 Jan 2002 13:25: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 g0ULPQ311036 for ; Wed, 30 Jan 2002 13:25: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 NAA11641 for ; Wed, 30 Jan 2002 13:25:27 -0800 (PST) Message-ID: <3C5864C2.B0E745A0@Royer.com> Date: Wed, 30 Jan 2002 14:25:22 -0700 From: Doug Royer Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: "ietf-calendar@imc.org" Subject: Re: CAP Issues And To-Do List References: <3C41CA00.6EE40932@Royer.com> <3C583BE4.714B2419@steltor.com> Content-Type: multipart/mixed; boundary="------------C814BC9C7E8F927CC32210D1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C814BC9C7E8F927CC32210D1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > > - DENY/GRANT does have an ordering > > see post "CAP: no ordering on GRANT/DENY?" > > > > True. You can GRANT then later DENY, and you can DENY then > > later GRANT. They are bits, not a chain of events to process. > > > > - CALMASTER: why does it have to be a mailto: URI? Why not im: > > (when IMPP is standardized), or http: (to get a page to read > > before sending a message)? ... > > > > The idea was that you could send email to a responsible entity. > > Like hostmaster, postmaster, and so on. It is a contact entity. > > > > ....If it does have to be email, why > > not a bare email address rather than a URI? > > > > So that we could later specify that it was something other > > than a mailto URI. :-) > > Does anyone see a reason why we should remove the restriction > that is must be a "mailto" URI. If not think we can close this > issue. I think it should stay a MAILTO URI. > An alternative is to reuse the iCalendar "CONTACT" property. > It is already defined, thus we do not have to define CALAMASTER. > It can also contain a phone number, name, and so forth. I could see adding CONTACT, but if we remove CALMASTER then we loose a way to always find an email address. As the CONTACT property value has no pre-defined format. --------------C814BC9C7E8F927CC32210D1 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 16:40:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0ULTRk11105 for ietf-calendar-bks; Wed, 30 Jan 2002 13:29: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 g0ULTQ311101 for ; Wed, 30 Jan 2002 13:29: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 NAA11650 for ; Wed, 30 Jan 2002 13:29:28 -0800 (PST) Message-ID: <3C5865B2.49D198E5@Royer.com> Date: Wed, 30 Jan 2002 14:29:22 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP Issues And To-Do List References: <3C41CA00.6EE40932@Royer.com> <3C583BE4.714B2419@steltor.com> Content-Type: multipart/mixed; boundary="------------DCFF838A60C3AEE65C4451C9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------DCFF838A60C3AEE65C4451C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > > > - Add the ability to use a wildcard in queries, > > if there are no objections. > > See thread: "Wildcard for component name." > > (November-December 2001) > > > > With recent posts and the concern for understandable SQL (for > > some reason :-), I think we need to remove wildcards for everything > > except the SELECT clause. I agree, this item should be deleted - use the new query syntax. --------------DCFF838A60C3AEE65C4451C9 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 16:49:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ULdd011332 for ietf-calendar-bks; Wed, 30 Jan 2002 13:39:39 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ULdc311327 for ; Wed, 30 Jan 2002 13:39:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11658 for ; Wed, 30 Jan 2002 13:39:39 -0800 (PST) Message-ID: <3C586815.78DF924C@Royer.com> Date: Wed, 30 Jan 2002 14:39:33 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Returned mail: Host unknown (Name server: imc.or: host not found)] References: <3C571CAE.70FF2037@Royer.com> <3C584E59.3188B72C@steltor.com> Content-Type: multipart/mixed; boundary="------------AEF7735E94B4E97ECB6FA55E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------AEF7735E94B4E97ECB6FA55E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > They were in CAP, you added it to VQUERY. > > Not true. Again, I only added SELF() to CAP-QL. SELF was in CAP, it was in the SQL-MIN, you renamed it. self = "SELF" ; Only valid for ATTENDEE value. ; When OBJECT=ATTENDEE;VALUE=SELF. > Beside, show me how you would use OWNER and NONOWNER > in CAP-QL. VCARs? Get all VCARs where UPN is {calendar OWNER, non calendar NONOWNER} by UPN value and not by 'tag' name. GRANT:UPN=OWNER GRANT:UPN=doug Now if 'doug' is the calendar owner, Get where UPN is calendar owner/non-owner. ...WHERE UPN = OWNER() will return both, and ... WHERE UPN = 'OWNER' will only get the first. --------------AEF7735E94B4E97ECB6FA55E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 16:54:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ULi0S11432 for ietf-calendar-bks; Wed, 30 Jan 2002 13:44:00 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ULhx311427 for ; Wed, 30 Jan 2002 13:43:59 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11700; Wed, 30 Jan 2002 13:44:01 -0800 (PST) Message-ID: <3C58691B.173B7995@Royer.com> Date: Wed, 30 Jan 2002 14:43:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> <3C583A30.55D9A890@steltor.com> <3C584078.D6A71CEA@Royer.com> <16f501c1a9c8$e5f50d00$092e0165@in.steltor.com> Content-Type: multipart/mixed; boundary="------------801A1FE4A6553F71046140C5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------801A1FE4A6553F71046140C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Graham Gilmore wrote: > > > > The UPN "bernard@steltor.com" doesn't mean that "bernard" is > > > connecting from the domain "steltor.com". It simply means > > > that someone had the proper credentials to authenticate > > > himself as "bernard@steltor.com". > > > > YES - THAT IS EXACTLY MY POINT. > > > > How do I say that 'bernard@steltor.com' only has > > access if he is connecting from 'steltor.com' ? > > Otherwise he has NO access. > > Why would we want to define this area of CS administration in CAP? Old point, that is why we added anonymous@domain. We just never finished the work. Cap requirements: 4.6 Security CAP MUST specify: - How the CUA authenticates itself to the CS (not the calendar). Authentication to the CS is required for all access to the CS. The CS MUST be able to uniquely identify each user for the purposes of authentication and authorization. - How anonymous access to calendars is specified (if allowed). - How the CUA authenticates to CS using SASL. - How the CUA and the CS negotiate encryption mechanism for a secure connection. - How calendars can be made secure from unwanted access and false entries. --> - How the CUA and CS can specify denial of service to another calendar user. --------------801A1FE4A6553F71046140C5 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 17:01:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0ULmCM11540 for ietf-calendar-bks; Wed, 30 Jan 2002 13:48:12 -0800 (PST) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ULmB311536 for ; Wed, 30 Jan 2002 13:48:11 -0800 (PST) Received: from jsoft.com (IDENT:8xElpG1scxHqd1XCUkSvAbQ1lQFWUvJs@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g0ULfA002619 for ; Wed, 30 Jan 2002 15:41:10 -0600 Message-ID: <3C586876.4090105@jsoft.com> Date: Wed, 30 Jan 2002 15:41:10 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar Subject: Re: CAP by Minneapolis References: <3C57D6CE.20608@jsoft.com> <3C582569.466CA267@Royer.com> <3C583D36.7040304@jsoft.com> <3C5862EB.20661BB8@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yep. My needs (currently) are simple. When CAP is out, I'll get the objects in iCal or xcs, doesn't matter to me, and then work with the XML version. I'm not doing any scheduling, synchronization whatever..., just displaying events. simple... (currently) > I don't see any need to invent another get stuff from a CS > language. We will have to add a capability to CAP that > says that the CS can dish out XML objects, and a way for > the CUA to ask for them. But you will still need CAP. No argument there. I was trying to say that I was waiting for after CAP to see if someone comes up with a simple server to test against. Gary Doug Royer wrote: > Gary Frederick wrote: > >>My needs are pretty simple. For example, I will probably get calendar >>info into XML and do my queries using XMLish queries, rather than the >>SQLesque language in CAP. That lets me get up and searching right away. >> > > It's not going to be that simple. First you have to get > the data from a CS - and that is CAP. When XML is out, then > CAP can serve up XML objects, but it's still CAP. > > Plus if you think about synchronization issues with resources > you are just going to be wasting bandwidth. If you get everything, > query the local XML data then attempt to book a resource, discover > it is taken, ask again for everyone, XML search everything, discover > .... > > That is why this WG invented iTIP, and why you need a real-time > (whatever that really means) connection protocol to reserve > resources where the CS determines who gets what booked items. > > I don't see any need to invent another get stuff from a CS > language. We will have to add a capability to CAP that > says that the CS can dish out XML objects, and a way for > the CUA to ask for them. But you will still need CAP. > > Think of CAP as IMAP or POP. You can have any kind > of MIME objects that you fetch with IMAP and POP, but you still > have to get he MIME object using IMAP or POP (or CAP). > > From owner-ietf-calendar@mail.imc.org Wed Jan 30 17:01:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03274 for ; Wed, 30 Jan 2002 17:01:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0ULqnN11637 for ietf-calendar-bks; Wed, 30 Jan 2002 13:52:49 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ULqm311633 for ; Wed, 30 Jan 2002 13:52:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11723 for ; Wed, 30 Jan 2002 13:52:49 -0800 (PST) Message-ID: <3C586B2B.FF944117@Royer.com> Date: Wed, 30 Jan 2002 14:52:43 -0700 From: Doug Royer Reply-To: ietf-calendar Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP by Minneapolis References: <3C57D6CE.20608@jsoft.com> <3C582569.466CA267@Royer.com> <3C583D36.7040304@jsoft.com> Content-Type: multipart/mixed; boundary="------------E7B567CD8A1ABBBFF903EC93" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E7B567CD8A1ABBBFF903EC93 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > My needs are pretty simple. For example, I will probably get calendar > info into XML and do my queries using XMLish queries, rather than the > SQLesque language in CAP. That lets me get up and searching right away. Plus - I have been saving my calendar data for over 10 years. Using the Unix 'calendar' versions of 'cm' and 'dtcm'. Each time I upgrade, I convert the data to the new format. I have over 17 MB of 10 years of calendar data. So do you really want to download 17 MB of data to see if I am available at 2pm tomorrow? I think you want CAP-QL. Currently there is NO tool that I have to find the data. I have to remember where it was and start searching. --------------E7B567CD8A1ABBBFF903EC93 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 17:21:58 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UMDOX12142 for ietf-calendar-bks; Wed, 30 Jan 2002 14:13:24 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UMDM312138 for ; Wed, 30 Jan 2002 14:13:23 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA14809 for ; Wed, 30 Jan 2002 17:13:20 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UMDJQ03700 for ; Wed, 30 Jan 2002 17:13:19 -0500 (EST) Message-ID: <3C587065.E8DE9984@steltor.com> Date: Wed, 30 Jan 2002 17:15:01 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: Returned mail: Host unknown (Name server: imc.or: host not found)] References: <3C571CAE.70FF2037@Royer.com> <3C584E59.3188B72C@steltor.com> <3C586815.78DF924C@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: > > > > They were in CAP, you added it to VQUERY. > > > > Not true. Again, I only added SELF() to CAP-QL. > > SELF was in CAP, it was in the SQL-MIN, you renamed it. > > self = "SELF" ; Only valid for ATTENDEE value. > ; When OBJECT=ATTENDEE;VALUE=SELF. This is not true. Indeed, SELF was in CAP but only in the ABFN of RIGHTS value type. NOT in the ABNF of SQL-MIN. What you are quoting is from the ABNF of RIGHTS value type. > > > Beside, show me how you would use OWNER and NONOWNER > > in CAP-QL. > > VCARs? In a VCAR or a VQUERY. CAP-QL is used by the SCOPE property of VCAR and by the QUERY property of VQUERY. > Get all VCARs where UPN is {calendar OWNER, non calendar NONOWNER} > by UPN value and not by 'tag' name. > > GRANT:UPN=OWNER > GRANT:UPN=doug Actually, that would we : GRANT:OWNER GRANT:doug > > Now if 'doug' is the calendar owner, > > Get where UPN is calendar owner/non-owner. > > ...WHERE UPN = OWNER() > > will return both, and > > ... WHERE UPN = 'OWNER' > > will only get the first. There is no such thing as a UPN property. Your example is not valid. Plus, how the CS is supposed to guess that "'doug' is the calendar owner". What is the context? 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 Jan 30 17:31:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02762 for ; Wed, 30 Jan 2002 16:40:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0ULUcO11156 for ietf-calendar-bks; Wed, 30 Jan 2002 13:30: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 g0ULUb311152 for ; Wed, 30 Jan 2002 13:30:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id NAA11654 for ; Wed, 30 Jan 2002 13:30:38 -0800 (PST) Message-ID: <3C5865F8.5386CADA@Royer.com> Date: Wed, 30 Jan 2002 14:30:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> <3C583A30.55D9A890@steltor.com> <3C584078.D6A71CEA@Royer.com> <3C584CDB.CD4886A3@steltor.com> Content-Type: multipart/mixed; boundary="------------A0A073689E702B341F24072A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A0A073689E702B341F24072A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > The UPN "bernard@steltor.com" doesn't mean that "bernard" is > > > connecting from the domain "steltor.com". It simply means > > > that someone had the proper credentials to authenticate > > > himself as "bernard@steltor.com". > > > > YES - THAT IS EXACTLY MY POINT. > > > > How do I say that 'bernard@steltor.com' only has > > access if he is connecting from 'steltor.com' ? > > Otherwise he has NO access. > > My point is that it could be left to the implementor. > I see this as an administrative task that is outside > the scope of the CAP protocol. We it's not, that's why we have anonymous@domain. So how do we deal with it? --------------A0A073689E702B341F24072A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 17:39:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UMPqt12444 for ietf-calendar-bks; Wed, 30 Jan 2002 14:25:52 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UMPp312440 for ; Wed, 30 Jan 2002 14:25:51 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA15129 for ; Wed, 30 Jan 2002 17:25:48 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UMPjQ05341 for ; Wed, 30 Jan 2002 17:25:45 -0500 (EST) Message-ID: <3C58734E.B6B19941@steltor.com> Date: Wed, 30 Jan 2002 17:27:26 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> <3C583A30.55D9A890@steltor.com> <3C584078.D6A71CEA@Royer.com> <16f501c1a9c8$e5f50d00$092e0165@in.steltor.com> <3C58691B.173B7995@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: > > Graham Gilmore wrote: > > > > Why would we want to define this area of CS administration in CAP? > > Old point, that is why we added anonymous@domain. You may have added anonymous@domain for this reason. But "why would we want to define this area of CS administration in CAP?" in the first place? > We just never finished the work. > > Cap requirements: > > 4.6 Security > > CAP MUST specify: > > - How the CUA authenticates itself to the CS (not the calendar). > > Authentication to the CS is required for all access to the CS. > The CS MUST be able to uniquely identify each user for the > purposes of authentication and authorization. > > - How anonymous access to calendars is specified (if allowed). > > - How the CUA authenticates to CS using SASL. > > - How the CUA and the CS negotiate encryption mechanism for a > secure connection. > > - How calendars can be made secure from unwanted access and false > entries. > > --> - How the CUA and CS can specify denial of service to another > calendar user. Calendar users being represented by UPN, you simply have to say: DENY:user@realm I'm sorry but the text you quoted doesn't specify that the CU (or CUA) must have a way to segregate another calendar user based on where it is connecting from. 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 Jan 30 18:07:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04457 for ; Wed, 30 Jan 2002 18:07:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UMrHS13018 for ietf-calendar-bks; Wed, 30 Jan 2002 14:53:17 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UMrF313011 for ; Wed, 30 Jan 2002 14:53: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 RAA15807 for ; Wed, 30 Jan 2002 17:53:13 -0500 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0UMrCQ08176 for ; Wed, 30 Jan 2002 17:53:13 -0500 (EST) Message-ID: <3C5879BE.CEDB172@steltor.com> Date: Wed, 30 Jan 2002 17:54:54 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Editors notes in CAP References: <3C575255.7C326385@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: > > > [EDITORS NOTE: Issues: > > > > - Can one use DELETE to remove all VALARMs and VTIMEZONEs that > > match a certain search criteria and that belong to all > > components, event though VALARMs and VTIMEZONEs never exist as > > independent components? > > Yes - with the old DELETE command > - checking to see if it still can be done. How would you write the VQUERY even with the old METHOD:DELETE? > > Or should one use MODIFY? If they can > > be deleted, do we return the REQUEST-STATUS of their deletion > > in a VEVENT or separately? Deleting VALARMs could easily be done by remplacing them with nothing. > > [EDITORS NOTE: Issue: does write access to a VAGENDA give you the > > right to move a calendar into it? > > No - about MOVE permission. I disagree. Again, see my post on why we can't have a MOVE PERMISSION: http://www.imc.org/ietf-calendar/mail-archive/msg03230.html You have not replied to this post. 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 Jan 30 18:08:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04475 for ; Wed, 30 Jan 2002 18:08:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UMxRw13134 for ietf-calendar-bks; Wed, 30 Jan 2002 14:59: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 g0UMxP313130 for ; Wed, 30 Jan 2002 14:59: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 OAA12049 for ; Wed, 30 Jan 2002 14:59:27 -0800 (PST) Message-ID: <3C587AC9.7DCB037A@Royer.com> Date: Wed, 30 Jan 2002 15:59:21 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> <3C583A30.55D9A890@steltor.com> <3C584078.D6A71CEA@Royer.com> <16f501c1a9c8$e5f50d00$092e0165@in.steltor.com> <3C58691B.173B7995@Royer.com> <3C58734E.B6B19941@steltor.com> Content-Type: multipart/mixed; boundary="------------44C7CD6864D7EBA60CE1B225" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------44C7CD6864D7EBA60CE1B225 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Graham Gilmore wrote: > > > > > > Why would we want to define this area of CS administration in CAP? > > > > Old point, that is why we added anonymous@domain. > > You may have added anonymous@domain for this reason. > But "why would we want to define this area of CS > administration in CAP?" in the first place? Lets drop VCARs then - that is also CS administration. --------------44C7CD6864D7EBA60CE1B225 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 18:09:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UMwcv13107 for ietf-calendar-bks; Wed, 30 Jan 2002 14:58: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 g0UMwb313103 for ; Wed, 30 Jan 2002 14:58:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA12045 for ; Wed, 30 Jan 2002 14:58:39 -0800 (PST) Message-ID: <3C587A98.D513F867@Royer.com> Date: Wed, 30 Jan 2002 15:58:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Returned mail: Host unknown (Name server: imc.or: host not found)] References: <3C571CAE.70FF2037@Royer.com> <3C584E59.3188B72C@steltor.com> <3C586815.78DF924C@Royer.com> <3C587065.E8DE9984@steltor.com> Content-Type: multipart/mixed; boundary="------------813595D19916FD31627EB994" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------813595D19916FD31627EB994 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Bernard Desruisseaux wrote: > > > > > > They were in CAP, you added it to VQUERY. > > > > > > Not true. Again, I only added SELF() to CAP-QL. > > > > SELF was in CAP, it was in the SQL-MIN, you renamed it. > > > > self = "SELF" ; Only valid for ATTENDEE value. > > ; When OBJECT=ATTENDEE;VALUE=SELF. > > This is not true. Indeed, SELF was in CAP but only > in the ABFN of RIGHTS value type. NOT in the ABNF > of SQL-MIN. What you are quoting is from the ABNF > of RIGHTS value type. What? It was in CAP. What's the differance? There are now two ways to say 'SELF' - UN-ACCEPTABLE. --------------813595D19916FD31627EB994 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 18:42:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UNXKM13869 for ietf-calendar-bks; Wed, 30 Jan 2002 15:33:20 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UNXJ313864 for ; Wed, 30 Jan 2002 15:33: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 PAA12095 for ; Wed, 30 Jan 2002 15:33:20 -0800 (PST) Message-ID: <3C5882BA.1E69072A@Royer.com> Date: Wed, 30 Jan 2002 16:33:14 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Editors notes in CAP References: <3C575255.7C326385@Royer.com> <3C5879BE.CEDB172@steltor.com> Content-Type: multipart/mixed; boundary="------------7CEF037DA759C54D04CD8971" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7CEF037DA759C54D04CD8971 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > > [EDITORS NOTE: Issues: > > > > > > - Can one use DELETE to remove all VALARMs and VTIMEZONEs that > > > match a certain search criteria and that belong to all > > > components, event though VALARMs and VTIMEZONEs never exist as > > > independent components? > > > > Yes - with the old DELETE command > > - checking to see if it still can be done. > > How would you write the VQUERY even with the old METHOD:DELETE? The DATA for a delete command could be a VQUERY BEGIN/END block. That would delete everything that the QUERY:SELECT ... selected. > > > Or should one use MODIFY? If they can > > > be deleted, do we return the REQUEST-STATUS of their deletion > > > in a VEVENT or separately? > > Deleting VALARMs could easily be done by remplacing them with nothing. > > > [EDITORS NOTE: Issue: does write access to a VAGENDA give you the > > > right to move a calendar into it? > > > > No - about MOVE permission. > > I disagree. Again, see my post on why we can't have a MOVE PERMISSION: No , that explains that you don't want a MOVE permission. Proposed text for MOVE permission: The MOVE permission means you have WRITE permission on the TARGET calendar and DELETE permission on the OLD-TARGET calendar. And the permissions do not need to be reciprocal. --------------7CEF037DA759C54D04CD8971 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Wed, 30 Jan 2002 19:14:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0V02ko14449 for ietf-calendar-bks; Wed, 30 Jan 2002 16:02:46 -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 g0V02i314445 for ; Wed, 30 Jan 2002 16:02:44 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA01942 for ; Wed, 30 Jan 2002 18:02:08 -0600 From: "Shannon J. Clark" To: Subject: RE: Editors notes in CAP Date: Wed, 30 Jan 2002 18:03:00 -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: <3C5882BA.1E69072A@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, So would a MOVE permission have to EXPLICITLY state the OLD_TARGET and TARGET as part of the permission??? i.e. if a store had 10 calendars and I wanted to give MOVE permission from all 10 to all 10 - I have to specify 81 separate MOVE permissions? (i.e. from each calendar to each of the other 9 calendars ) This seems rather cumbersome and ugly. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Wednesday, January 30, 2002 5:33 PM To: ietf-calendar@imc.org Subject: Re: Editors notes in CAP Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > > [EDITORS NOTE: Issues: > > > > > > - Can one use DELETE to remove all VALARMs and VTIMEZONEs that > > > match a certain search criteria and that belong to all > > > components, event though VALARMs and VTIMEZONEs never exist as > > > independent components? > > > > Yes - with the old DELETE command > > - checking to see if it still can be done. > > How would you write the VQUERY even with the old METHOD:DELETE? The DATA for a delete command could be a VQUERY BEGIN/END block. That would delete everything that the QUERY:SELECT ... selected. > > > Or should one use MODIFY? If they can > > > be deleted, do we return the REQUEST-STATUS of their deletion > > > in a VEVENT or separately? > > Deleting VALARMs could easily be done by remplacing them with nothing. > > > [EDITORS NOTE: Issue: does write access to a VAGENDA give you the > > > right to move a calendar into it? > > > > No - about MOVE permission. > > I disagree. Again, see my post on why we can't have a MOVE PERMISSION: No , that explains that you don't want a MOVE permission. Proposed text for MOVE permission: The MOVE permission means you have WRITE permission on the TARGET calendar and DELETE permission on the OLD-TARGET calendar. And the permissions do not need to be reciprocal. From owner-ietf-calendar@mail.imc.org Wed Jan 30 19:22:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05243 for ; Wed, 30 Jan 2002 19:22:58 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0V08kR14561 for ietf-calendar-bks; Wed, 30 Jan 2002 16:08: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 g0V08j314556 for ; Wed, 30 Jan 2002 16:08:45 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id TAA16770 for ; Wed, 30 Jan 2002 19:08:43 -0500 Received: from steltor.com ([101.0.0.4]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0V08dQ15075 for ; Wed, 30 Jan 2002 19:08:39 -0500 (EST) Message-ID: <3C588B74.EF8F9DA1@steltor.com> Date: Wed, 30 Jan 2002 19:10:28 -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: Editors notes in CAP References: <3C575255.7C326385@Royer.com> <3C5879BE.CEDB172@steltor.com> <3C5882BA.1E69072A@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: > > > > > > > [EDITORS NOTE: Issues: > > > > > > > > - Can one use DELETE to remove all VALARMs and VTIMEZONEs that > > > > match a certain search criteria and that belong to all > > > > components, event though VALARMs and VTIMEZONEs never exist as > > > > independent components? > > > > > > Yes - with the old DELETE command > > > - checking to see if it still can be done. > > > > How would you write the VQUERY even with the old METHOD:DELETE? > > The DATA for a delete command could be a VQUERY BEGIN/END block. > That would delete everything that the QUERY:SELECT ... selected. So could I use the following VQUERY with the "delete" command to specify that I want to delete all the ATTENDEEs from a VEVENT? BEGIN:VQUERY QUERY:SELECT ATTENDEE FROM VEVENT WHERE UID = '123' END:VQUERY I'd prefer if we would use the "modify" command for that. > > > > > Or should one use MODIFY? If they can > > > > be deleted, do we return the REQUEST-STATUS of their deletion > > > > in a VEVENT or separately? > > > > Deleting VALARMs could easily be done by remplacing them with nothing. > > > > > [EDITORS NOTE: Issue: does write access to a VAGENDA give you the > > > > right to move a calendar into it? > > > > > > No - about MOVE permission. > > > > I disagree. Again, see my post on why we can't have a MOVE PERMISSION: > > No , that explains that you don't want a MOVE permission. > > Proposed text for MOVE permission: > > The MOVE permission means you have WRITE permission > on the TARGET calendar and DELETE permission > on the OLD-TARGET calendar. And the permissions do > not need to be reciprocal. 1- Would you need the MOVE permission granted in both the TARGET and OLD-TARGET? If so, see my post to find why this is bad. If not, how can this work? 2- Since MOVE is defined in terms of other PERMISSSIONS we clearly don't need it. 3- Wouldn't you need the right to READ in the OLD-TARGET 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 Jan 30 19:28:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05315 for ; Wed, 30 Jan 2002 19:28:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0V0GAq14882 for ietf-calendar-bks; Wed, 30 Jan 2002 16:16:10 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0V0G9314878 for ; Wed, 30 Jan 2002 16:16:09 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id TAA16817 for ; Wed, 30 Jan 2002 19:16:07 -0500 Received: from steltor.com ([101.0.0.4]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0V0G5Q15687 for ; Wed, 30 Jan 2002 19:16:06 -0500 (EST) Message-ID: <3C588D32.7F0FD9D3@steltor.com> Date: Wed, 30 Jan 2002 19:17:54 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: UPN wild-carding (Was: Re: incomplete UPN restrictions in VCARs) References: <3C4E06EF.6E4EBBAB@Royer.com> <3C4ED02C.948B2E61@steltor.com> <3C556EAA.F182BB60@steltor.com> <3C5592BC.6DEA8E2A@Royer.com> <3C56BF65.930583E3@steltor.com> <3C56D875.603010E8@Royer.com> <3C56FAA0.A0C6C766@steltor.com> <3C5703E2.7CD69239@Royer.com> <3C570CC8.6374428D@steltor.com> <3C571B01.9C9653DF@Royer.com> <3C583A30.55D9A890@steltor.com> <3C584078.D6A71CEA@Royer.com> <16f501c1a9c8$e5f50d00$092e0165@in.steltor.com> <3C58691B.173B7995@Royer.com> <3C58734E.B6B19941@steltor.com> <3C587AC9.7DCB037A@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: > > > > > > Graham Gilmore wrote: > > > > > > > > Why would we want to define this area of CS administration in CAP? > > > > > > Old point, that is why we added anonymous@domain. > > > > You may have added anonymous@domain for this reason. > > But "why would we want to define this area of CS > > administration in CAP?" in the first place? > > Lets drop VCARs then - that is also CS administration. No. It is the responsability of a CU to grant or deny rights to other authenticated calendar users (UPN) (by using VCAR). It is the responsability of the calendar administrator to setup his authentication policy as he pleased, and how exactly he is supposed to do that does not need to be specified in CAP. 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 Jan 30 19:33:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05403 for ; Wed, 30 Jan 2002 19:33:21 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0V0LX014975 for ietf-calendar-bks; Wed, 30 Jan 2002 16:21: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 g0V0LW314971 for ; Wed, 30 Jan 2002 16:21:32 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id TAA16859 for ; Wed, 30 Jan 2002 19:21:30 -0500 Received: from steltor.com ([101.0.0.4]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0V0LSQ16109 for ; Wed, 30 Jan 2002 19:21:28 -0500 (EST) Message-ID: <3C588E76.427B275@steltor.com> Date: Wed, 30 Jan 2002 19:23:18 -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: [Fwd: Returned mail: Host unknown (Name server: imc.or: host not found)] References: <3C571CAE.70FF2037@Royer.com> <3C584E59.3188B72C@steltor.com> <3C586815.78DF924C@Royer.com> <3C587065.E8DE9984@steltor.com> <3C587A98.D513F867@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: > > There are now two ways to say 'SELF' - UN-ACCEPTABLE. This is not true. With my proposals SELF is only defined in CAP-QL as 'SELF()' and nowhere else. The property SCOPE of VCAR makes use of CAP-QL. The property QUERY of VQUERY makes use of CAP-QL. There is only one way to say 'SELF' and it is defined as 'SELF()' in CAP-QL. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Jan 30 20:05:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05653 for ; Wed, 30 Jan 2002 20:05:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0V0qlp15625 for ietf-calendar-bks; Wed, 30 Jan 2002 16:52: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 g0V0qk315621 for ; Wed, 30 Jan 2002 16:52:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id QAA12251 for ; Wed, 30 Jan 2002 16:52:48 -0800 (PST) Message-ID: <3C589558.7D2F64C9@Royer.com> Date: Wed, 30 Jan 2002 17:52:40 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: RE: Editors notes in CAP Content-Type: multipart/mixed; boundary="------------6131BD168C53A50C2D2259E2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6131BD168C53A50C2D2259E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Doug, By TARGET I meant what we used to call parent, but as we did away with hiericaial calendars - 'parent' has no valid meaning any more. > i.e. if a store had 10 calendars and I wanted to give MOVE permission from > all 10 to all 10 - I have to specify 81 separate MOVE permissions? (i.e. > from each calendar to each of the other 9 calendars ) This seems rather > cumbersome and ugly. No - It means that if you don't have DELETE on the old location, and WRITE on the new location PLUS the MOVE permission (that I was defining) - you can't move. --------------6131BD168C53A50C2D2259E2 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 08:38:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VDNkp09999 for ietf-calendar-bks; Thu, 31 Jan 2002 05:23: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 g0VDNi309991 for ; Thu, 31 Jan 2002 05:23: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 IAA22125 for ; Thu, 31 Jan 2002 08:23:40 -0500 Received: from steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VDNdQ17300 for ; Thu, 31 Jan 2002 08:23:40 -0500 (EST) Message-ID: <3C594736.BB52C8CA@steltor.com> Date: Thu, 31 Jan 2002 08:31:34 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Doug Royer wrote: ... > > (And I thought that XML (or XSL, XSLT...) reserved the 'id' tag) It's not reserved in XML (and other BEEP profiles use it), but I have no objection to naming it cmdid, even if it takes 3 more bytes :-). > ... > Put the METHOD, TARGET, and optional CMDID back into > the data. (Assume they are in these brief examples). > CMDID is also used by the , and messages, that don't use iCalendar objects. Therefore the id seems to belong in the command section (the link between the request and the associated reply is now handled by beep). -- Patrice. From owner-ietf-calendar@mail.imc.org Thu Jan 31 08:48:51 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26326 for ; Thu, 31 Jan 2002 08:48:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VDRZQ10104 for ietf-calendar-bks; Thu, 31 Jan 2002 05:27:35 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VDRX310100 for ; Thu, 31 Jan 2002 05:27: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 IAA22165 for ; Thu, 31 Jan 2002 08:27:29 -0500 Received: from steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VDRSQ17613 for ; Thu, 31 Jan 2002 08:27:28 -0500 (EST) Message-ID: <3C59481B.E9B84FB3@steltor.com> Date: Thu, 31 Jan 2002 08:35:23 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Doug Royer wrote: ... > > I also propose changing the REPLY from the CS to be an EMPTY > BEEP reply for success. Eliminating the the not needed 2.0 > success code. If the BEEP reply contains any data, then > parse that iCalendar data. > That would be awkward. I would tend to keep something in the payload (even if it's just ). Draft-06 uses a distinct ANS for each target in the command. And part of the payload was to indicate to which target the reply correspond. If there is a need to minimize the byte count, then it may make sense to allow a single ANS (or RPY) to refer to many targets with identical replies (e.g. success). But I would not remove the target(s) from the reply. > ... > 6.2.4.2 "delete" Command > > C: > > S: ...empty BEEP RPY is success... This is slightly off topic, but for the delete, move and modify commands it would probably be useful to always return the number of selected components. -- Patrice. From owner-ietf-calendar@mail.imc.org Thu Jan 31 08:50:50 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26358 for ; Thu, 31 Jan 2002 08:50:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VDbAN10300 for ietf-calendar-bks; Thu, 31 Jan 2002 05:37:10 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VDb9310296 for ; Thu, 31 Jan 2002 05:37:09 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id IAA22353 for ; Thu, 31 Jan 2002 08:37:04 -0500 Received: from steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VDb4Q18664 for ; Thu, 31 Jan 2002 08:37:04 -0500 (EST) Message-ID: <3C594A5A.65588C9D@steltor.com> Date: Thu, 31 Jan 2002 08:44:58 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@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: ... > Change the command in the existing example: > ... > > > TO: > > C:Content-Type: application/...beep... > C: > C: > C: C: BEGIN:VCALENDAR > C: CMDID:unique-id > C: TARGET:opaqueid101 > C: BEGIN:VQUERY > C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT > C: WHERE DTEND >= '19990714T080000' AND > C: DTSTART <= '19990715T080000' > C: END:VQUERY > C: END:VCALENDAR > C: ]]> XML document MUST have a single root. And placing the iCalendar object directly in the search, would limit future extension to the addition of attributes in the search element. I think that an additional element is needed to allow extension (e.g. element in draft-06) C: C: S: 20011121T120000Z-12343@cal.example.com S: S: -- Patrice. From owner-ietf-calendar@mail.imc.org Thu Jan 31 08:51:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26401 for ; Thu, 31 Jan 2002 08:51:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VDdB410350 for ietf-calendar-bks; Thu, 31 Jan 2002 05:39:11 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VDdA310346 for ; Thu, 31 Jan 2002 05:39:10 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id IAA22403 for ; Thu, 31 Jan 2002 08:39:05 -0500 Received: from steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VDd5Q19087 for ; Thu, 31 Jan 2002 08:39:05 -0500 (EST) Message-ID: <3C594AD3.7171568C@steltor.com> Date: Thu, 31 Jan 2002 08:46:59 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Doug Royer wrote: ... > And I changed the names to MATCH (case) the iCalendar objects. > As iCalendar objects are upper case, the same named objects > should be here. And I upper cased the new ones in CAP to > be consistent with iCalendar. And I changed the names > of the CAPABILITY replies to be the same as the PROPERTY > names they map to (same case). > > There is a typo in 06 on the name of date max and date min. > > 6.1.2 "get-capability" Command > > C: > > S:1.0 > S:bla bla bla > S:... > S:CAR-FULL-1 > S:00000101T000000Z > S:99991231T235959Z > S:0 > S:1.0 It's a matter of taste. But we loose grouping of related elements and the cases are inconsistent with other XML construct in the same DTD. -- Patrice. From owner-ietf-calendar@mail.imc.org Thu Jan 31 09:35:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27806 for ; Thu, 31 Jan 2002 09:35:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VENeE13629 for ietf-calendar-bks; Thu, 31 Jan 2002 06:23:40 -0800 (PST) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VENd313623 for ; Thu, 31 Jan 2002 06:23:39 -0800 (PST) Received: from jsoft.com (IDENT:kk7fOTCcMPDX2clbJq5QwE2ORy9uE+Em@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g0VEGX008713 for ; Thu, 31 Jan 2002 08:16:33 -0600 Message-ID: <3C5951C1.1060801@jsoft.com> Date: Thu, 31 Jan 2002 08:16:33 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C594AD3.7171568C@steltor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. There was conversation a while ago about the XML version of iCalendar (xcs) and the consensus was that the tags be lowercase (mostly - with an exception). I like the idea that the various related standards have the same XML tag names. Gary Patrice Lapierre wrote: >>Doug Royer wrote: >> > ... > >>And I changed the names to MATCH (case) the iCalendar objects. >>As iCalendar objects are upper case, the same named objects >>should be here. And I upper cased the new ones in CAP to >>be consistent with iCalendar. And I changed the names >>of the CAPABILITY replies to be the same as the PROPERTY >>names they map to (same case). >> >>There is a typo in 06 on the name of date max and date min. >> >>6.1.2 "get-capability" Command >> >>C: >> >>S:1.0 >>S:bla bla bla >>S:... >>S:CAR-FULL-1 >>S:00000101T000000Z >>S:99991231T235959Z >>S:0 >>S:1.0 >> > > It's a matter of taste. But we loose grouping of related elements > and the cases are inconsistent with other XML construct in the same > DTD. > > > -- > Patrice. > From owner-ietf-calendar@mail.imc.org Thu Jan 31 09:46:29 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28086 for ; Thu, 31 Jan 2002 09:46:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VETin14309 for ietf-calendar-bks; Thu, 31 Jan 2002 06:29:44 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VETh314305 for ; Thu, 31 Jan 2002 06:29:43 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA24180 for ; Thu, 31 Jan 2002 09:29:39 -0500 Received: from steltor.com ([101.0.0.6]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VETcQ25201 for ; Thu, 31 Jan 2002 09:29:39 -0500 (EST) Message-ID: <3C595540.DCF0CFDA@steltor.com> Date: Thu, 31 Jan 2002 09:31:28 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: CARID:UPDATEPARTSTATUS (Was: Re: VCAR: RIGHTS Value Type Ambiguous) References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <3C4D8FCA.CF98FE20@steltor.com> <3C4DF26F.3A1394A9@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: > > Changing some one elses ATTENDEE value (for non-owner) is not a > reasonable need and I can think of no reason to allow it. If it does > not already exist in 2445-2447, then lets just state that in CAP: > > You can't change components for iTIP generated > objects unless you are the ORGANIZER or OWNER. > And the OWNER is limited to local changes only > when the OWNER is not the ORGANIZER. The only time > any OWNER can modify the objects in an iTIP generated > object is when it comes from the ORGANIZER. This applies > even if there is no specific VCAR. If you do, iTIP breaks. > > Any UPN that is granted access to modify any iTIP originated > object is in effect given proxy OWNERship access as > far as the VCAR specifies. And that UPN is limited > to the same restrictions as the OWNER even if there > is not a specific VCAR. If you do, iTIP breaks. To avoid breaking iTIP, I think we should drop the predefined CARID:UPDATEPARTSTATUS or at least replace it by a predefined CARID (e.g., CARID:DEFAULTORGANIZER) that would be more in line with what you said. Shall we drop it or replace it? Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jan 31 10:28:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29577 for ; Thu, 31 Jan 2002 10:28:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VFDDJ15650 for ietf-calendar-bks; Thu, 31 Jan 2002 07:13: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 g0VFDC315646 for ; Thu, 31 Jan 2002 07:13: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 KAA25707 for ; Thu, 31 Jan 2002 10:13:08 -0500 Received: from steltor.com ([101.0.0.6]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VFD8Q00569 for ; Thu, 31 Jan 2002 10:13:08 -0500 (EST) Message-ID: <3C595F71.C711E1E5@steltor.com> Date: Thu, 31 Jan 2002 10:14: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: CAP: COALESCE property in VQUERY 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 http://www.imc.org/ietf-calendar/mail-archive/msg03240.html (VCAR: CARID Property) we agreed to have a COALESCE property in VQUERY components to specify whether returned VCARs should be coalesced or not (default is FALSE). By default (COALESCE:FALSE), VCAR components will be returned as is (raw) to the owner of the VCAR components, and MAY be returned coalesced to the non-owners for security reasons. If COALESCE:TRUE, then VCAR components MUST be returned coalesced. How should we define COALESCE in the draft? 1- When COALESCE is TRUE, only VCARs that pertain to the authenticated user MUST be returned, and the GRANT and DENY properties of the returned VCARs MUST only specify the UPN of the authenticated users. 2- When COALESCE is TRUE, multiple VCARs with the same CARID (is that allowed?) MUST be returned as a single VCAR. [ As I mentioned in the introduction of my proposal we would need to add a grouping component (e.g., VRIGHTS) for that purpose. ]. 3- When COALESCE is TRUE and the user is searching for CARID = 'REQUESTONLY' OR CARID = 'DEFAULTOWNER' what should we returned? A single coalesced VCAR with no CARID, or two coalesced VCARs with each a CARID? (1) makes plenty of sense and has been agreed more than once by this WG. (2) and (3) aren't clear to me yet. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jan 31 10:40:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29915 for ; Thu, 31 Jan 2002 10:40:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VFQvh16011 for ietf-calendar-bks; Thu, 31 Jan 2002 07:26:57 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VFQu316006 for ; Thu, 31 Jan 2002 07:26:56 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: Proposal for non-SQL query language MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 31 Jan 2002 10:34:04 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 01/31/2002 10:34:12 AM, Serialize complete at 01/31/2002 10:34:12 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug Royer wrote: >John Stracke wrote: >> >> This is my counterproposal to get us free of the SQL swamp. (Sorry to take so long to reply, BTW; I've been on paternity leave.) >Great idea starter for the xml-ical proposal. But it does not conform >to the CAP-requiements that it be a iCalendar data object. (a) Neither is a SQL statement, but you can embed SQL in a VQUERY. (b) The XML was just an easy way to write it out. >And I think the latest proposal will work from Patrice, Alan, >you, and others without throwing the entire CAP >query issue open for a LONG debate. This one has produced I'm still unconvinced (though I've got two weeks of progress to read up on, so maybe); but, since nobody's expressed real interest in my proposal, I'll drop it. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |================================================================| |How many roads must a man walk down before he admits he is LOST?| \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 31 10:40:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29914 for ; Thu, 31 Jan 2002 10:40:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VFIl415804 for ietf-calendar-bks; Thu, 31 Jan 2002 07:18:47 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VFIk315800 for ; Thu, 31 Jan 2002 07:18:46 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA25875 for ; Thu, 31 Jan 2002 10:18:42 -0500 Received: from c-1401.steltor.com ([101.1.76.28]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VFIfQ01289 for ; Thu, 31 Jan 2002 10:18:41 -0500 (EST) Message-Id: <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> X-Sender: markp@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 Jan 2002 10:15:23 -0500 To: "ietf-calendar@imc.org" From: Mark Paterson Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: Last Call ByMarchIETF: Need Volunteers!] In-Reply-To: <3C489A57.B836C9AD@Royer.com> References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe:
At 02:57 PM 1/18/2002 -0700, Doug Royer wrote:

...
Use SEQUENCE. Only the ORGANIZER can update the SEQUENCE number.
....

Sorry for taking so long to get back on this thread. My day job got in the way :-)

I didn't quite get what you meant about older data appearing newer then newer data at first but I suppose some CS implementations where all messages ever sent are kept I suppose this is possible but all this means is that when we do a query for changes a sync CUA needs to be careful to filter out those objects whose SEQUENCE appears older then the SEQUENCE which the sync CUA last remembers. It doesn't resolve my questions. A sync CUA is still not going to fetch each and every object it knows about to check the latest SEQUENCE to determine changes. This would be way too heavy on the CS.

Let's try pulling back on reigns and refocus on my original questions. My claim was that in order for CAP to live up to the Sync requirements listed in the CAP Requirements a Sync CUA must be able to get the answers to the following 3 questions:

1) Within the given date range what entries are new?
2) Within the given date range what entries have changed?
3) Within the given date range what entries have been deleted?

Having followed the CAP-QL thread its perhaps time I took a crack at building my own queries. I've made a few simplifying assumptions. I've just worried about events, I've used DTSTART to determine if something is in range and rather then figuring out what attributes to retrieve I've just put "*". So here we go:

BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT WHERE
DTSTART < upper_range
AND DTSTART > lower range
AND DTSTAMP > last_time_asked
END:VQUERY

If the Sync CUA then filters out any objects whose SEQUENCE seems to indicate that it is actually older then what the Sync CUA last knew about (as per Doug's suggestion) then the results that remain should be all the changes within the range. By enumerating through the results a Sync CUA can determine everything that is new by the objects whose UID it doesn't recognize, everything that has changed by the objects whose UID it does recognize, and finally everything that has been deleted from the objects within the changed list who now are marked with METHOD:DELETE (as long as CUAs are forced to use this method to delete objects).

What about instances of a recurring object?

The EXPAND:TRUE line in the query should ensure that all new and changed instances get returned. Correct?

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

Instead another query such as this is needed I think:

BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT WHERE
EXDATE < upper_range
AND EXDATE > lower range
AND DTSTAMP > last_time_asked
END:VQUERY

This would give a Sync CUA any newly changed recurring objects with exceptions within the range, I think? It will only work however if CUAs always add an EXDATE when an instance from a pre-existing recurrence set is deleted. If they just redo the recurrence set completely then it becomes impossible.
 
If my logic holds true (and that remains to be seen. I need the expertise of the CAP-QL contributors) then text for the following should be added:

1. CUAs must use METHOD:DELETE to mark something as deleted.
2. CUAs must use EXDATE to mark an instance within an existing Recurrence set as deleted rather than redefining the recurrence set.

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

So does my logic make sense?

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



 From owner-ietf-calendar@mail.imc.org Thu Jan 31 11:17:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01601 for ; Thu, 31 Jan 2002 11:17:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VG0Ia16824 for ietf-calendar-bks; Thu, 31 Jan 2002 08:00: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 g0VG0H316819 for ; Thu, 31 Jan 2002 08:00:17 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA27138 for ; Thu, 31 Jan 2002 11:00:13 -0500 Received: from steltor.com ([101.0.0.6]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VG0CQ06465 for ; Thu, 31 Jan 2002 11:00:12 -0500 (EST) Message-ID: <3C596A79.F4D3FAF8@steltor.com> Date: Thu, 31 Jan 2002 11:02:01 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: UPN (User Principal Name) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would like to propose the following syntax and semantic for UPN values that can be specified in the GRANT and DENY properties in VCAR components for the purpose of authorization. OWNER The owner of the VAGENDA in which the encapsulating VCAR is stored NONOWNER All users except the owner of the VAGENDA in which the encapsulating VCAR is stored * All users (including anonymous) @ All anonymous users from unnamed realms @* All anonymous users from all named realms @realm All anonymous users from specified realm *@* All named users from all named realms *@realm All named users from specified realm user@realm Specified user from specified realm user@* Specified user from all named realms Examples, GRANT:bernard@steltor.com # Grant user identified as # "bernard@steltor.com" DENY:NOWOWNER # Deny non owner of the VAGENDA GRANT:*@steltor.com # Grant all named users from realm # "steltor.com" GRANT:@steltor.com # Grant anonymous users from the # realm "steltor.com" 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 Jan 31 11:41:23 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02691 for ; Thu, 31 Jan 2002 11:41:22 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VGOsu17761 for ietf-calendar-bks; Thu, 31 Jan 2002 08:24:54 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VGOr317756 for ; Thu, 31 Jan 2002 08:24:53 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA27832 for ; Thu, 31 Jan 2002 11:24:49 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VGOmQ09375 for ; Thu, 31 Jan 2002 11:24:48 -0500 (EST) Message-ID: <3C59703D.3EBBB6F3@steltor.com> Date: Thu, 31 Jan 2002 11:26:37 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: CAR-MIN vs CAR-FULL-1 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 latest interim version of the draft still does not provide sufficient information about the level of CAR support CAR-MIN and CAR-FULL-1. I would like to propose some text that could be included in the draft, but I'm missing some key information. 1- What is the purpose of CAR-MIN? a) Make CS vendors' life easier (i.e., not forced to provide full CAR support)? It seems that to implement CAR-MIN a vendor will have to implement CAR-FULL-1 and then add a restriction on the value of CARID. Why would a vendor restrict his implementation to CAR-MIN? Unless I'm missing something it's not easier to support CAR-MIN than CAR-FULL-1. b) Make CUA vendors' life easier (i.e., can query specific predefined VCARs by CARID to figure out easily if they are granted the right to perform a command or not)? Wouldn't this ability be lost when the CS supports CAR-FULL-1? 2- What are the limitations implied by CAR-MIN? a) VAGENDA can only contains VCARs with predefined CARIDs (e.g., CARID:REQUESTONLY)? b) VAGENDA can only contains VCAR with a CARID value listed in the property DEFAULT_VCARS of the CALSTORE. 3- With CAR-MIN, could a user have multiple VCARs with the same predefined CARID (e.g., 2 VCARs with CARID:DEFAULTOWNER)? 4- When a CU is searching for a predefined CARID (e.g., CARID:REQUESTONLY) is the CS supposed: a) to look at all the VCARs (including the decreed VCARs) regardless of their CARID and returned a coalesced VCARs that contains information pertinent to the definition of that CARID only? Does anybody looked at how this could be implemented? b) to look at all the VCARs with the specified CARID and return a coalesced VCAR? 5- Are there any restrictions on the rights that can be granted or denied in VCARs with predefined CARIDs? For instance, could I grant all users the right to read all my VEVENTs in the VCAR with CARID:REQUESTONLY? 6- Does CAR-MIN impose restrictions on decreed VCARs? Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jan 31 12:06:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03637 for ; Thu, 31 Jan 2002 12:06:26 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VGnNi18514 for ietf-calendar-bks; Thu, 31 Jan 2002 08:49:23 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VGnL318510 for ; Thu, 31 Jan 2002 08:49:21 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id IAA13236 for ; Thu, 31 Jan 2002 08:49:22 -0800 (PST) Message-ID: <3C59758E.6144BC0A@Royer.com> Date: Thu, 31 Jan 2002 09:49:18 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C59481B.E9B84FB3@steltor.com> Content-Type: multipart/mixed; boundary="------------4119390DC7F6A393EADA55CF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4119390DC7F6A393EADA55CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > > Doug Royer wrote: > ... > > > > I also propose changing the REPLY from the CS to be an EMPTY > > BEEP reply for success. Eliminating the the not needed 2.0 > > success code. If the BEEP reply contains any data, then > > parse that iCalendar data. > > > > That would be awkward. I would tend to keep something in the > payload (even if it's just ). > > Draft-06 uses a distinct ANS for each target in the command. > And part of the payload was to indicate to which target the > reply correspond. If there is a need to minimize the byte count, > then it may make sense to allow a single ANS (or RPY) to refer to > many targets with identical replies (e.g. success). But I would > not remove the target(s) from the reply. CMDID used to be optional and only needed when you did pipelineing. I don't see any need for CMDID when there is only one command issued at a time. When the CUA issues more than one command without waiting for all of replies to outstanding commands, then CMDID is needed. Do you agree? --------------4119390DC7F6A393EADA55CF Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 12:08:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VGnr518549 for ietf-calendar-bks; Thu, 31 Jan 2002 08:49:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VGnq318544 for ; Thu, 31 Jan 2002 08:49: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 IAA13240 for ; Thu, 31 Jan 2002 08:49:52 -0800 (PST) Message-ID: <3C5975AC.F90F6506@Royer.com> Date: Thu, 31 Jan 2002 09:49:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C59481B.E9B84FB3@steltor.com> Content-Type: multipart/mixed; boundary="------------9847DBB270A7549178723EAC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9847DBB270A7549178723EAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > ... > > 6.2.4.2 "delete" Command > > > > C: > > > > S: ...empty BEEP RPY is success... > > This is slightly off topic, but for the delete, move and modify > commands it would probably be useful to always return the number of > selected components. Why? What are you going to do with '23'? --------------9847DBB270A7549178723EAC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 12:14:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VH2QO18933 for ietf-calendar-bks; Thu, 31 Jan 2002 09:02: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 g0VH2P318928 for ; Thu, 31 Jan 2002 09:02: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 JAA13273 for ; Thu, 31 Jan 2002 09:02:25 -0800 (PST) Message-ID: <3C59789D.B85A3185@Royer.com> Date: Thu, 31 Jan 2002 10:02:21 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C594A5A.65588C9D@steltor.com> Content-Type: multipart/mixed; boundary="------------A9E17C223C4244B513ED8970" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A9E17C223C4244B513ED8970 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > C: > > > > S: 20011121T120000Z-12342@cal.example.com > > S: 20011121T120000Z-12343@cal.example.com > > S: 20011121T120000Z-12344@cal.example.com > > Again XML document must have a single root. Don't confuse an XML document with XML data. XML data most definatly can just be tags. > And it's a good practice to group list elements in a > container (e.g. in HTML

  • are inside
      or
        ). That is a matter for debate. > Furthermore it may be relevent to add some information > that relates to the entire list. But until then - I really don't care. We can add stuff later - and it is XML - so it will be easy to add it WHEN there is a proposal. Just adding it because "it's nice", is not a valid argument. > e.g., > > C: > > S: > S: 20011121T120000Z-12343@cal.example.com > S: > S: > > -- > Patrice. --------------A9E17C223C4244B513ED8970 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 12:16:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VH45I18992 for ietf-calendar-bks; Thu, 31 Jan 2002 09:04:05 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VH44318988 for ; Thu, 31 Jan 2002 09:04:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA13277 for ; Thu, 31 Jan 2002 09:04:04 -0800 (PST) Message-ID: <3C597900.898AA7C1@Royer.com> Date: Thu, 31 Jan 2002 10:04:00 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C594AD3.7171568C@steltor.com> Content-Type: multipart/mixed; boundary="------------6B5BA1EC6A24D7E61872D2CC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6B5BA1EC6A24D7E61872D2CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > > Doug Royer wrote: > ... > > And I changed the names to MATCH (case) the iCalendar objects. > > As iCalendar objects are upper case, the same named objects > > should be here. And I upper cased the new ones in CAP to > > be consistent with iCalendar. And I changed the names > > of the CAPABILITY replies to be the same as the PROPERTY > > names they map to (same case). > > > > There is a typo in 06 on the name of date max and date min. > > > > 6.1.2 "get-capability" Command > > > > C: > > > > S:1.0 > > S:bla bla bla > > S:... > > S:CAR-FULL-1 > > S:00000101T000000Z > > S:99991231T235959Z > > S:0 > > S:1.0 > > It's a matter of taste. But we loose grouping of related elements > and the cases are inconsistent with other XML construct in the same > DTD. We DID NOT HAVE THAT IN 05, that was added without debate or discussion. Back to what was agreed to in 05. And XML is secondary. The DATA is important. Reducing the byte count is important. --------------6B5BA1EC6A24D7E61872D2CC Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 12:17:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VH4gj19012 for ietf-calendar-bks; Thu, 31 Jan 2002 09:04:42 -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 g0VH4f319008 for ; Thu, 31 Jan 2002 09:04:41 -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 g0VH4b716489 for ; Thu, 31 Jan 2002 09:04:38 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GQTBFP00.5TI; Thu, 31 Jan 2002 09:04:37 -0800 Message-ID: <3C59792F.26B2EF4E@netscape.com> Date: Thu, 31 Jan 2002 09:04: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: Bernard Desruisseaux CC: ietf-calendar@imc.org Subject: Re: CAP: UPN (User Principal Name) References: <3C596A79.F4D3FAF8@steltor.com> Content-Type: multipart/mixed; boundary="------------A37304DB2E8087F76A6F82D9" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A37304DB2E8087F76A6F82D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > I would like to propose the following syntax and semantic > for UPN values that can be specified in the GRANT and DENY > properties in VCAR components for the purpose of authorization. > > OWNER The owner of the VAGENDA in which the > encapsulating VCAR is stored > > NONOWNER All users except the owner of the VAGENDA > in which the encapsulating VCAR is stored > > * All users (including anonymous) > > @ All anonymous users from unnamed realms could you explain the difference between * and @ ?? Examples? -Steve --------------A37304DB2E8087F76A6F82D9 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650.937.3351 x-mozilla-html:FALSE org:Netscape adr:;;;;;; version:2.1 title:Director of Engineering fn:Steve Mansour end:vcard --------------A37304DB2E8087F76A6F82D9-- From owner-ietf-calendar@mail.imc.org Thu Jan 31 12:25:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04445 for ; Thu, 31 Jan 2002 12:24:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VGqpI18631 for ietf-calendar-bks; Thu, 31 Jan 2002 08:52:51 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VGqo318627 for ; Thu, 31 Jan 2002 08:52:50 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA28544 for ; Thu, 31 Jan 2002 11:52:46 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VGqjQ12320 for ; Thu, 31 Jan 2002 11:52:45 -0500 (EST) Message-ID: <3C5976CA.45A088DC@steltor.com> Date: Thu, 31 Jan 2002 11:54:34 -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> 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: > > 11.2 Calendar Properties / DEFAULT_VCAR > > I agree, 11.2 DEFAULT_VCARS is not needed. I agree. We need to remove DEFAULT_VCARS in VAGENDA. 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 Jan 31 12:25:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04463 for ; Thu, 31 Jan 2002 12:25:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VH6Rt19055 for ietf-calendar-bks; Thu, 31 Jan 2002 09:06: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 g0VH6Q319051 for ; Thu, 31 Jan 2002 09:06: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 JAA13281 for ; Thu, 31 Jan 2002 09:06:27 -0800 (PST) Message-ID: <3C59798E.3B14B5EB@Royer.com> Date: Thu, 31 Jan 2002 10:06:22 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: CARID:UPDATEPARTSTATUS (Was: Re: VCAR: RIGHTS Value Type Ambiguous) References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <3C4D8FCA.CF98FE20@steltor.com> <3C4DF26F.3A1394A9@Royer.com> <3C595540.DCF0CFDA@steltor.com> Content-Type: multipart/mixed; boundary="------------CC00CFBFF0863AD0D9124549" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CC00CFBFF0863AD0D9124549 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > Changing some one elses ATTENDEE value (for non-owner) is not a > > reasonable need and I can think of no reason to allow it. If it does > > not already exist in 2445-2447, then lets just state that in CAP: > > > > You can't change components for iTIP generated > > objects unless you are the ORGANIZER or OWNER. > > And the OWNER is limited to local changes only > > when the OWNER is not the ORGANIZER. The only time > > any OWNER can modify the objects in an iTIP generated > > object is when it comes from the ORGANIZER. This applies > > even if there is no specific VCAR. If you do, iTIP breaks. > > > > Any UPN that is granted access to modify any iTIP originated > > object is in effect given proxy OWNERship access as > > far as the VCAR specifies. And that UPN is limited > > to the same restrictions as the OWNER even if there > > is not a specific VCAR. If you do, iTIP breaks. > > To avoid breaking iTIP, I think we should drop the predefined > CARID:UPDATEPARTSTATUS or at least replace it by a predefined > CARID (e.g., CARID:DEFAULTORGANIZER) that would be more in line > with what you said. > > Shall we drop it or replace it? Nether. Not the same topic. UPDATEPARTSTATUS allows for the changing of the PARTSTAT, not the ATTTENDEE value. --------------CC00CFBFF0863AD0D9124549 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 12:41:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VHJwZ19446 for ietf-calendar-bks; Thu, 31 Jan 2002 09:19:58 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VHJv319442 for ; Thu, 31 Jan 2002 09:19: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 MAA29255 for ; Thu, 31 Jan 2002 12:19:54 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VHJrQ15675 for ; Thu, 31 Jan 2002 12:19:53 -0500 (EST) Message-ID: <3C597D26.6F902C3B@steltor.com> Date: Thu, 31 Jan 2002 12:21:42 -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: UPN (User Principal Name) References: <3C596A79.F4D3FAF8@steltor.com> <3C59792F.26B2EF4E@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: > > Bernard Desruisseaux wrote: > > > * All users (including anonymous) > > > > @ All anonymous users from unnamed realms > > could you explain the difference between * and @ ?? Examples? > > -Steve "GRANT:*" will grant all users, that is, anonymous and non-anonymous (e.g, "@", "@toto.com", "sman@netscape.com", and "sman@"). "GRANT:@" will only grant anonymous from unnamed realms, that is, "@" will be granted, but NOT "@toto.com", "sman@netscape.com" and "sman@". 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 Jan 31 12:42:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05015 for ; Thu, 31 Jan 2002 12:42:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VHNA319536 for ietf-calendar-bks; Thu, 31 Jan 2002 09:23:10 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VHN9319532 for ; Thu, 31 Jan 2002 09:23:09 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA29303 for ; Thu, 31 Jan 2002 12:23:06 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VHN5Q15771 for ; Thu, 31 Jan 2002 12:23:05 -0500 (EST) Message-ID: <3C597DE6.9C6F6E79@steltor.com> Date: Thu, 31 Jan 2002 12:24:54 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP: CARID:UPDATEPARTSTATUS (Was: Re: VCAR: RIGHTS Value Type Ambiguous) References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <3C4D8FCA.CF98FE20@steltor.com> <3C4DF26F.3A1394A9@Royer.com> <3C595540.DCF0CFDA@steltor.com> <3C59798E.3B14B5EB@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: > > UPDATEPARTSTATUS allows for the changing of the PARTSTAT, > not the ATTTENDEE value. Shouldn't that been done through iTIP? A invites B and C. C shouldn't be allowed to change his PARTSTATS in B's VAGENDA. Otherwise, "iTIP is busted". No? 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 Jan 31 13:02:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05982 for ; Thu, 31 Jan 2002 13:02:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VHpkn20562 for ietf-calendar-bks; Thu, 31 Jan 2002 09:51:46 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VHpj320557 for ; Thu, 31 Jan 2002 09:51:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id JAA13363 for ; Thu, 31 Jan 2002 09:51:45 -0800 (PST) Message-ID: <3C59842C.10943E84@Royer.com> Date: Thu, 31 Jan 2002 10:51:40 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: Last CallByMarchIETF: Need Volunteers!] References: <5.1.0.14.0.20020118090626.00ad2888@imap1.in.steltor.com> <5.1.0.14.0.20020118142900.00ad0a48@imap1.in.steltor.com> <5.1.0.14.0.20020130152918.00af58a8@imap1.in.steltor.com> Content-Type: multipart/mixed; boundary="------------8AD577E7FDCF7E368AB0CC7A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8AD577E7FDCF7E368AB0CC7A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Paterson wrote: > > At 02:57 PM 1/18/2002 -0700, Doug Royer wrote: > > ... > > > Use SEQUENCE. Only the ORGANIZER can update the SEQUENCE number. > > .... > > Sorry for taking so long to get back on this thread. My day job got in > the way :-) > > I didn't quite get what you meant about older data appearing newer > then newer data at first but I suppose some CS implementations where > all messages ever sent are kept I suppose this is possible but all > this means is that when we do a query for changes a sync CUA needs to > be careful to filter out those objects whose SEQUENCE appears older > then the SEQUENCE which the sync CUA last remembers. It doesn't > resolve my questions. A sync CUA is still not going to fetch each and > every object it knows about to check the latest SEQUENCE to determine > changes. This would be way too heavy on the CS. I did not mean to imply that. I meant that LAST-MODIFIED only tells you that it has been modified. It does not mean that it is more-valid data simply because it has a newer time stamp. > Let's try pulling back on reigns and refocus on my original questions. > My claim was that in order for CAP to live up to the Sync requirements > listed in the CAP Requirements a Sync CUA must be able to get the > answers to the following 3 questions: > > 1) Within the given date range what entries are new? > 2) Within the given date range what entries have changed? > 3) Within the given date range what entries have been deleted? > > Having followed the CAP-QL thread its perhaps time I took a crack at > building my own queries. I've made a few simplifying assumptions. I've > just worried about events, I've used DTSTART to determine if something > is in range and rather then figuring out what attributes to retrieve > I've just put "*". So here we go: > > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT * FROM VEVENT WHERE > DTSTART < upper_range > AND DTSTART > lower range > AND DTSTAMP > last_time_asked > END:VQUERY (replace DTSTAMP with LAST-MODIFIED and I think it is right, I incorrectly used DTSTAMP when I should have said LAST-MODIFIED. DTSTAMP is the time the iCalendar object was created for transport and is ALWAYS updated [per iTIP?] just before transporting the object.) > If the Sync CUA then filters out any objects whose SEQUENCE seems to > indicate that it is actually older then what the Sync CUA last knew > about (as per Doug's suggestion) then the results that remain should > be all the changes within the range. Yes, and by also filtering out from the returned set any with the same UID and older SEQUENCE numbers in the return set. As in if there were 5 updates between your sync times, you may get: UID:1, and 5 objects, with SEQUENCE numbers 1 2 3 4 5 Where only '5' would be the newest and 1, 2, 3, 4 are discarded using iTIP rules. > By enumerating through the > results a Sync CUA can determine everything that is new by the objects > whose UID it doesn't recognize, ... Yes. > ... everything that has changed by the > objects whose UID it does recognize, .. No - changes would have the same UID for the same objects and has a newer SEQUENCE number. > .. and finally everything that has > been deleted from the objects within the changed list who now are > marked with METHOD:DELETE (as long as CUAs are forced to use this > method to delete objects). iCalendar objects are marked for delete with METHOD:MODIFY. They are deleted from the CS by . > > What about instances of a recurring object? > > The EXPAND:TRUE line in the query should ensure that all new and > changed instances get returned. Correct? Yes and all existing and unchanged instances. > The problem is still deleted instances. I don't think EXPAND:TRUE will > make sure that the Sync CUA gets returned instances marked with METHOD > DELETE within the range. If it does then we're covered but I somehow > don't think that's the way it is (comments from the CAP-QL gang?). The instances of objects with a RECURRENCE-ID do not exists anyway. They are an expansion of an existing object that is expanded and for booked objects only. The ORGANIZER never sends a METHOD:REQUEST object that contains a RECURRENCE-ID. And don't forget about METHOD:CANCEL sent by the ORGANIZER, which can cancel entire objects or specific instances. So, if the EXPAND:FALSE object is marked METHOD:DELETE, then ALL of the instances are deleted and that object will NEVER have a RECURRENCE-ID property (because EXPAND is FALSE). iTIP allows for updates to instances of objects. When that happens there can be multiple objects created: 'One' new object with an updated SEQUENCE 'More than one' object each with the SAME UID and SEQUENCE. And each object specifying one or more instances. (see ADD in iTIP) - and all booked. And if an object is METHOD:CANCEL, then its containing DTSTART, DTEND/DURATION, RRULE, EXRULE, RDATE, and EXDATE properties specific instances that have been canceled, for the same SEQUENCE number and UID objects. (see iTIP). > Instead another query such as this is needed I think: > > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT * FROM VEVENT WHERE > EXDATE < upper_range > AND EXDATE > lower range > AND DTSTAMP > last_time_asked > END:VQUERY > > This would give a Sync CUA any newly changed recurring objects with > exceptions within the range, I think? No, an object can be modified and instances can be removed by changing the RRULE and never adding a EXDATE. Or by adding a RDATE, or by adding or altering a EXRULE, or by DTSTART, or RECURRANCE-ID, ... > It will only work however if > CUAs always add an EXDATE when an instance from a pre-existing > recurrence set is deleted. If they just redo the recurrence set > completely then it becomes impossible. Not impossible. Your first query (with LAST-MODIFIED) will get all of the objects in that time range. Then the CUA must compare using SEQUENCE and merging any multiple objects with the same UID (originally created with ADD), then it knows the state of the 'UID' object. > If my logic holds true (and that remains to be seen. I need the > expertise of the CAP-QL contributors) then text for the following > should be added: > > 1. CUAs must use METHOD:DELETE to mark something as deleted. Entire objects are marked for delete by using METHOD:MODIFY and changing the object in the store to METHOD:DELETE. It is NOT used when CANCELing instances of an object. > 2. CUAs must use EXDATE to mark an instance within an existing > Recurrence set as deleted rather than redefining the recurrence set. No. That is not practical. > If we can do this and people agree that my logic makes sense then I > think we can mark off the synchronization requirements for CAP as > covered. Not yet :-) > So does my logic make sense? As noted above. --------------8AD577E7FDCF7E368AB0CC7A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 13:12:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VI2Uw24099 for ietf-calendar-bks; Thu, 31 Jan 2002 10:02:30 -0800 (PST) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VI2T324095 for ; Thu, 31 Jan 2002 10:02:29 -0800 (PST) Received: from jsoft.com (IDENT:7Mw33rmRwJy6T5PRL7NL0Tu0HDENv1mI@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g0VHtJ011561 for ; Thu, 31 Jan 2002 11:55:19 -0600 Message-ID: <3C598507.9020604@jsoft.com> Date: Thu, 31 Jan 2002 11:55:19 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C594A5A.65588C9D@steltor.com> <3C59789D.B85A3185@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Don't confuse XML data with data that looks like XML because it uses tags. XML data can only have a single root. regarding the debate about grouping elements in a container, 6.1.1 states it returns a list and the example shows the list is inside a tag. That looks like what Patrice suggested. Is that to be changed? Gary http://calsch.org/ietf/draft-ietf-calsch-cap-06.html#generate-uid 6.1.1 "generate-uid" Command Attributes: num: Number of UIDs to generate (1 if omitted). Response: "uid-list" The "generate-uid" command returns one or more unique identifiers which MUST be unique on the server's calendar store. It is recommended that the return values be globally unique ids. Example: C: MSG 1 5 . 2837 60 C: Content-Type: application/beep+xml C: C: C: END S: RPY 1 5 . 2897 328 S: Content-Type: application/beep+xml S: S: S: 20011121T120000Z-12340@cal.example.com S: 20011121T120000Z-12341@cal.example.com S: 20011121T120000Z-12342@cal.example.com S: 20011121T120000Z-12343@cal.example.com S: 20011121T120000Z-12344@cal.example.com S: S: END Doug Royer wrote: > Patrice Lapierre wrote: > > >>>C: >>> >>>S: 20011121T120000Z-12342@cal.example.com >>>S: 20011121T120000Z-12343@cal.example.com >>>S: 20011121T120000Z-12344@cal.example.com >>> >> Again XML document must have a single root. >> > > Don't confuse an XML document with XML data. > > XML data most definatly can just be tags. > > >> And it's a good practice to group list elements in a >>container (e.g. in HTML
      • are inside
          or
            ). >> > > That is a matter for debate. > > >> Furthermore it may be relevent to add some information >>that relates to the entire list. >> > > But until then - I really don't care. We can add stuff > later - and it is XML - so it will be easy to add it > WHEN there is a proposal. Just adding it because "it's nice", > is not a valid argument. > > >>e.g., >> >> C: >> >> S: >> S: 20011121T120000Z-12343@cal.example.com >> S: >> S: >> >>-- >>Patrice. >> >> From owner-ietf-calendar@mail.imc.org Thu Jan 31 13:25:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06958 for ; Thu, 31 Jan 2002 13:25:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VI3h624166 for ietf-calendar-bks; Thu, 31 Jan 2002 10:03:43 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VI3f324162 for ; Thu, 31 Jan 2002 10:03:41 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA30090 for ; Thu, 31 Jan 2002 13:03:38 -0500 Received: from steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VI3bQ19827 for ; Thu, 31 Jan 2002 13:03:37 -0500 (EST) Message-ID: <3C5988D3.33E70CED@steltor.com> Date: Thu, 31 Jan 2002 13:11:31 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C59481B.E9B84FB3@steltor.com> <3C59758E.6144BC0A@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: > ... > > CMDID used to be optional and only needed when you did > pipelineing. I don't see any need for CMDID when there is > only one command issued at a time. When the CUA issues > more than one command without waiting for all of replies > to outstanding commands, then CMDID is needed. > > Do you agree? Yes I agree that it should be optional. And it is optional in the DTD of draft-06. Furthermore since pipelining is handled by BEEP, the CMDID is not necessarily needed for matching replies even if there is more than one outstanding commands. From owner-ietf-calendar@mail.imc.org Thu Jan 31 13:34:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07221 for ; Thu, 31 Jan 2002 13:34:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VIJa027987 for ietf-calendar-bks; Thu, 31 Jan 2002 10:19:36 -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 g0VIJX327983 for ; Thu, 31 Jan 2002 10:19:34 -0800 (PST) To: Bernard Desruisseaux Cc: ietf-calendar@imc.org Subject: Re: VCARs - any other specific proposals? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 31 Jan 2002 13:07:48 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/31/2002 01:26:31 PM, Serialize complete at 01/31/2002 01:26:31 PM Content-Type: multipart/alternative; boundary="=_alternative 0062BF4E85256B52_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062BF4E85256B52_= Content-Type: text/plain; charset="US-ASCII" While I wade thru the immense flood of recent postings and try to stay abreast of the discussions I have one simple sugestion. WRT: The "CARID" property specifies the local identifier for the "VCAR" calendar component. The "NAME" property specifies a localizable display name. Given the ABNF and the prose it appears as if I can have a NAME but no CARID. Since the CARID is what is used to find the definition of the rights, but NAME is not, why not follow the same approach we took for ATTENDEE and CN. Make NAME a property parameter of CARID. Better still, you can reuse the CN property parameter name since its essentially the same thing, just in another property now. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0062BF4E85256B52_= Content-Type: text/html; charset="US-ASCII"
            While I wade thru the immense flood of recent postings and try to stay abreast of the discussions I have one simple sugestion.  WRT:

               The "CARID" property specifies the local identifier for the "VCAR"
              calendar component.  The "NAME" property specifies a localizable
              display name.

            Given the ABNF and the prose it appears as if I can have a NAME but no CARID.  Since the CARID is what is used to find the definition of the rights, but NAME is not, why not follow the same approach we took for ATTENDEE and CN.  Make NAME a property parameter of CARID.  Better still, you can reuse the CN property parameter name since its essentially the same thing, just in another property now.

            Bruce
            ===========================================================================
            Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
            Messaging & Collaboration                 Phone: 978.399.6496
            IBM Software Group                         FAX: and nothing but the FAX...
            Standard disclaimers apply, even where prohibited by law...             --=_alternative 0062BF4E85256B52_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 31 13:58:12 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07958 for ; Thu, 31 Jan 2002 13:58:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VIh1P28547 for ietf-calendar-bks; Thu, 31 Jan 2002 10:43:01 -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 g0VIgx328543 for ; Thu, 31 Jan 2002 10:42:59 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA02916 for ; Thu, 31 Jan 2002 12:42:01 -0600 From: "Shannon J. Clark" To: "Ietf-Calendar@Imc. Org" Subject: Initial connection to CAP server? Date: Thu, 31 Jan 2002 12:43:15 -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 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 A question occurred to me about initial connections to a Calendar Server: How does a user learn what their Calendar is? i.e. the first time a user connects to a given CS and validates identity in some manner - how do they learn what their Calendar Address is? Shannon Shannon J. Clark President - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Thu Jan 31 14:00:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08072 for ; Thu, 31 Jan 2002 14:00:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VIgfh28539 for ietf-calendar-bks; Thu, 31 Jan 2002 10:42: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 g0VIge328535 for ; Thu, 31 Jan 2002 10:42: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 NAA30949 for ; Thu, 31 Jan 2002 13:42:37 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VIgaQ24011 for ; Thu, 31 Jan 2002 13:42:36 -0500 (EST) Message-ID: <3C599088.5E2CB18D@steltor.com> Date: Thu, 31 Jan 2002 13:44:24 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP: LANGUAGE parameter 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 As a French speaker I'm concerned by the fact that we don't allow properties that make use of the LANGUAGE parameter to occur more than once in our components. For instance, how am I supposed to specify my home town in both French and English as the location of a VEVENT, given that LOCATION is only allowed to occur once in a VEVENT? That is, the following is not legal: LOCATION;LANGUAGE=en:Montreal LOCATION;LANGUAGE=fr-CA:Montréal <-- Montréal in UTF-8 Can we change our restriction tables to allow LOCATION, SUMMARY, CATEGORIES, NAME, etc. to occur more than once in our components? 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 Jan 31 14:03:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08168 for ; Thu, 31 Jan 2002 14:03:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VIqOP28870 for ietf-calendar-bks; Thu, 31 Jan 2002 10:52:24 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VIqM328864 for ; Thu, 31 Jan 2002 10:52:22 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA31191 for ; Thu, 31 Jan 2002 13:52:19 -0500 Received: from steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VIqJQ25142 for ; Thu, 31 Jan 2002 13:52:19 -0500 (EST) Message-ID: <3C59943C.20297C16@steltor.com> Date: Thu, 31 Jan 2002 14:00:12 -0500 From: Patrice Lapierre X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C59481B.E9B84FB3@steltor.com> <3C5975AC.F90F6506@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Patrice Lapierre wrote: > > > > ... > > > 6.2.4.2 "delete" Command > > > > > > C: > > > > > > S: ...empty BEEP RPY is success... > > > > This is slightly off topic, but for the delete, move and modify > > commands it would probably be useful to always return the number of > > selected components. > If the VQUERY inside these command doesn't match any > Why? What are you going to do with '23'? It's up the to the CUA, it could for example update a counter displayed next to name of the VAGENDA in a tree view. If a the VQUERY inside one of these commands doesn't match any components, it's not considered an error. Therefore if CUA performs "move" of a single VEVENT (query on the UID). If the count is not returned, the CUA doesn't know that the component was indeed moved (a command from another session could have deleted the VEVENT just before the execution of the "move"). From owner-ietf-calendar@mail.imc.org Thu Jan 31 14:11:36 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08514 for ; Thu, 31 Jan 2002 14:11:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VJ16o29151 for ietf-calendar-bks; Thu, 31 Jan 2002 11:01:06 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VJ15329145 for ; Thu, 31 Jan 2002 11:01:05 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA31433 for ; Thu, 31 Jan 2002 14:01:02 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VJ11Q26286 for ; Thu, 31 Jan 2002 14:01:01 -0500 (EST) Message-ID: <3C5994DA.F7F78E74@steltor.com> Date: Thu, 31 Jan 2002 14:02:50 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: VCARs - any other specific proposals? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > While I wade thru the immense flood of recent postings and try to stay > abreast of the discussions I have one simple sugestion. WRT: > > The "CARID" property specifies the local identifier for the "VCAR" > calendar component. The "NAME" property specifies a localizable > display name. > > Given the ABNF and the prose it appears as if I can have a NAME but no > CARID. Since the CARID is what is used to find the definition of the > rights, but NAME is not, why not follow the same approach we took for > ATTENDEE and CN. Make NAME a property parameter of CARID. Better > still, you can reuse the CN property parameter name since its > essentially the same thing, just in another property now. What about localization? :-( In my last post (CAP: LANGUAGE parameter), I requested that we allow NAME to occur more than once to be able to specify this property in different languages in the same VCAR. I for one would not have any objection to make CARID mandatory. I did propose to use UID instead of CARID, but this proposition was not well received. Apparently, using UID in VCAR would cause us problems. That is, problems that we already have to deal with in VEVENT. UID is ok for VEVENT but not for VCAR, or so it seems. 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 Jan 31 14:18:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08661 for ; Thu, 31 Jan 2002 14:18:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VJ7DR29325 for ietf-calendar-bks; Thu, 31 Jan 2002 11:07:13 -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 g0VJ7C329321 for ; Thu, 31 Jan 2002 11:07:12 -0800 (PST) To: ietf-calendar@imc.org Subject: Consistant naming of tags MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 31 Jan 2002 14:09:27 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/31/2002 02:14:07 PM, Serialize complete at 01/31/2002 02:14:07 PM Content-Type: multipart/alternative; boundary="=_alternative 0068641D85256B52_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068641D85256B52_= Content-Type: text/plain; charset="US-ASCII" In looking at the versions of CAP Ive noticed that we are somewhat arbitrary in how we name multiword properties and parameters. For example we have properties like: DEFAULT_VCARS CURRENT_DATETIME RECUR_ACCEPTED RECUR_EXPAND as well as some like: ALLOW-CONFLICT LAST-MODIFIED etc. For those less observant the difference is a '_' vs a '-'. We should be consistanly using one or the other. Since iCalendar opt'd for '-' I propose that all '_' in properties be changed to '-' in the draft for consistancy reasons. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0068641D85256B52_= Content-Type: text/html; charset="US-ASCII"
            In looking at the versions of CAP Ive noticed that we are somewhat arbitrary in how we name multiword properties and parameters.  For example we have properties like:

            DEFAULT_VCARS  CURRENT_DATETIME  RECUR_ACCEPTED  RECUR_EXPAND  

            as well as some like:

            ALLOW-CONFLICT  LAST-MODIFIED  

            etc.

            For those less observant the difference is a '_' vs a '-'.  We should be consistanly using one or the other.  Since iCalendar opt'd for '-' I propose that all '_' in properties be changed to '-' in the draft for consistancy reasons.

            Bruce
            ===========================================================================
            Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
            Messaging & Collaboration                 Phone: 978.399.6496
            IBM Software Group                         FAX: and nothing but the FAX...
            Standard disclaimers apply, even where prohibited by law...             --=_alternative 0068641D85256B52_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 31 14:22:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08831 for ; Thu, 31 Jan 2002 14:22:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VJDIX29507 for ietf-calendar-bks; Thu, 31 Jan 2002 11:13: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 g0VJDH329503 for ; Thu, 31 Jan 2002 11:13:17 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA31752 for ; Thu, 31 Jan 2002 14:13:14 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VJDDQ27586 for ; Thu, 31 Jan 2002 14:13:13 -0500 (EST) Message-ID: <3C5997B5.DD6B7C48@steltor.com> Date: Thu, 31 Jan 2002 14:15:01 -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: Consistant naming of tags References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > I propose that all '_' in properties be changed to '-' in the draft > for consistancy reasons. I agree. Regards, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jan 31 14:28:10 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09079 for ; Thu, 31 Jan 2002 14:28:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VJHII29614 for ietf-calendar-bks; Thu, 31 Jan 2002 11:17:18 -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 g0VJHH329610 for ; Thu, 31 Jan 2002 11:17:18 -0800 (PST) To: ietf-calendar@imc.org Subject: RFC 2446: Delegation text needs some changes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_01232002 January 23, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 31 Jan 2002 14:23:54 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 01/31/2002 02:24:13 PM, Serialize complete at 01/31/2002 02:24:13 PM Content-Type: multipart/alternative; boundary="=_alternative 0069B6B885256B52_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069B6B885256B52_= Content-Type: text/plain; charset="US-ASCII" In RFC 2446 we wrote: . Send a "REPLY" to the "Organizer" with the following updates: . The "Delegator's" "ATTENDEE" property "partstat" parameter set to "delegated" and the "delegated-to" parameter is set to the address of the "Delegate" . Add an additional "ATTENDEE" property for the "Delegate" with the "delegated-from" property parameter set to the "Delegator" . Indicate whether they want to continue to receive updates when the "Organizer" sends out updated versions of the event. Setting the "rsvp" property parameter to "TRUE" will cause the updates to be sent, setting it to "FALSE" causes no further updates to be sent. Note that in either case, if the "Delegate" declines the invitation the "Delegator" will be notified. . The "Delegator" MUST also send a copy of the original "REQUEST" method to the "Delegate". however there is a small problem w/the last line. If the Delegator actually does this then they CANNOT add a new ATTENDEE line with the Delegatees info NOR can they update their own ATTENDEE line to reflect the delegation. In addition it is NOT legal for the Delegator to include a COMMENT to tell the Delgatee something like "Im in FL that week. I need you to go for me!" or "I dont like meetings w/Joe so Im sending you insetad!". It should be allowable that a Delegator can send non-process info like a COMMENT (or other IANA properties/parameters) in the Delegation notice. The phrase "send a copy of the original" implys that these changes/additions cannot be done. Without the changes, the Delegatee has no way to know why they got a REQUEST from the Delegator and not from the Organizer. We intended to make sure that the Delegator sent an accurate representation of the Organizers REQUEST but we did this (accdientally) at the expense of some feature sets or functionality. I will try to work up some change text for this (that preserves the base intent but allows for needed or future changes) and present it to the WG for discussion unless there is strong dissent about the need for it. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0069B6B885256B52_= Content-Type: text/html; charset="US-ASCII"
            In RFC 2446 we wrote:

                 .  Send a "REPLY" to the "Organizer" with the following updates:
                .  The "Delegator's" "ATTENDEE" property "partstat" parameter set
                   to "delegated" and the "delegated-to" parameter is set to the
                   address of the "Delegate"
                .  Add an additional "ATTENDEE" property for the "Delegate" with
                   the "delegated-from" property parameter set to the "Delegator"
                .  Indicate whether they want to continue to receive updates when
                   the "Organizer" sends out updated versions of the event.
                   Setting the "rsvp" property parameter to "TRUE" will cause the
                   updates to be sent, setting it to "FALSE" causes no further
                   updates to be sent. Note that in either case, if the "Delegate"
                   declines the invitation the "Delegator" will be notified.
                .  The "Delegator" MUST also send a copy of the original "REQUEST"
                   method to the "Delegate".

            however there is a small problem w/the last line.  If the Delegator actually does this then they CANNOT add a new ATTENDEE line with the Delegatees info NOR can they update their own ATTENDEE line to reflect the delegation.    In addition it is NOT legal for the Delegator to include a COMMENT to tell the Delgatee something like "Im in FL that week.  I need you to go for me!" or "I dont like meetings w/Joe so Im sending you insetad!".  

            It should be allowable that a Delegator can send non-process info like a COMMENT (or other IANA properties/parameters) in the Delegation notice.

            The phrase "send a copy of the original" implys that these changes/additions cannot be done.  Without the changes, the Delegatee has no way to know why they got a REQUEST from the Delegator and not from the Organizer.  

            We intended to make sure that the Delegator sent an accurate representation of the Organizers REQUEST but we did this (accdientally) at the expense of some feature sets or functionality.  I will try to work up some change text for this (that preserves the base intent but allows for needed or future changes) and present it to the WG for discussion unless there is strong dissent about the need for it.

            Bruce
            ===========================================================================
            Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
            Messaging & Collaboration                 Phone: 978.399.6496
            IBM Software Group                         FAX: and nothing but the FAX...
            Standard disclaimers apply, even where prohibited by law...             --=_alternative 0069B6B885256B52_=-- From owner-ietf-calendar@mail.imc.org Thu Jan 31 14:47:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09767 for ; Thu, 31 Jan 2002 14:47:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VJZB700271 for ietf-calendar-bks; Thu, 31 Jan 2002 11:35:11 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VJZA300262 for ; Thu, 31 Jan 2002 11:35:10 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA13524 for ; Thu, 31 Jan 2002 11:35:11 -0800 (PST) Message-ID: <3C599C69.67357158@Royer.com> Date: Thu, 31 Jan 2002 12:35:05 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: CAR-MIN vs CAR-FULL-1 References: <3C59703D.3EBBB6F3@steltor.com> Content-Type: multipart/mixed; boundary="------------440EBFC62AA46EA40570967B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------440EBFC62AA46EA40570967B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > The latest interim version of the draft still does > not provide sufficient information about the level > of CAR support CAR-MIN and CAR-FULL-1. > > I would like to propose some text that could be > included in the draft, but I'm missing some key > information. > > 1- What is the purpose of CAR-MIN? > > a) Make CS vendors' life easier (i.e., not forced > to provide full CAR support)? > > It seems that to implement CAR-MIN a vendor will > have to implement CAR-FULL-1 and then add a > restriction on the value of CARID. Why would a > vendor restrict his implementation to CAR-MIN? > Unless I'm missing something it's not easier to > support CAR-MIN than CAR-FULL-1. No. If a CS does not understand 'VCAR' but does hard code the predefined CARID's then it is CAR-MIN. The example used was a palm pilot. It in effect is a mini-CS, and may never implement CAR-FULL-1. Same with an IP cell phone. > b) Make CUA vendors' life easier (i.e., can query > specific predefined VCARs by CARID to figure out > easily if they are granted the right to perform a > command or not)? Wouldn't this ability be lost > when the CS supports CAR-FULL-1? Lost - no. A CUA can just ask 'can I post a METHOD:REQUEST' to this CS. And NEVER implement CARs in the CUA. No it is not lost because the other end of the connection may be CAR-MIN only so a CS MUST always understand and compute them. A CUA that supports CAR-FUL-1 can ask for REQUESTONLY and still support CAR-FUL-1. > 2- What are the limitations implied by CAR-MIN? > > a) VAGENDA can only contains VCARs with predefined > CARIDs (e.g., CARID:REQUESTONLY)? In a CS - yes - if a CS only supports CAR-MIN, then that is all it has and it will not process any VCARs sent it. They could conceivably be decreed and not changeable in the CS. (it SHOULD still store them) If in a CUA - that is all they will ever ask for and will ignore any sent to it (it SHOULD still store them). For a CS that supports CAR-FUL-1, when asked for any of the CAR-MIN CARID's, it MUST compute the answer and provide the results to the CUA. > b) VAGENDA can only contains VCAR with a CARID > value listed in the property DEFAULT_VCARS > of the CALSTORE. No - CAR-MIN (and its text needs to be added back into CAP), means the pre-defined CAR-MIN VCARs as defined in CAP and that *at least* those are in DEFAULT_VCARS. CAR-MIN in a CS is a MUST. It MAY support CAR-FULL-1 and those extra VCARs MAY be in DEFAULT_VCARS. > 3- With CAR-MIN, could a user have multiple VCARs > with the same predefined CARID (e.g., 2 VCARs > with CARID:DEFAULTOWNER)? Not in the same scope (calendar). > 4- When a CU is searching for a predefined CARID > (e.g., CARID:REQUESTONLY) is the CS supposed: > > a) to look at all the VCARs (including the decreed > VCARs) regardless of their CARID and returned a > coalesced VCARs that contains information pertinent > to the definition of that CARID only? Yes - that is one of the primary reasons they were invented. > Does anybody > looked at how this could be implemented? The same as COLESED=TRUE and a QUERY were done with those restrictions on the query. > b) to look at all the VCARs with the specified CARID > and return a coalesced VCAR? No, when asking for a CAR-MIN VCAR, it means look at everything and return the COLESED result that applies as specified in CAP (again text needs to be re-added). > 5- Are there any restrictions on the rights that can > be granted or denied in VCARs with predefined CARIDs? > For instance, could I grant all users the right to > read all my VEVENTs in the VCAR with CARID:REQUESTONLY? When the text goes (back) into CAP, it will be clear that REQUESTONLY only applies to the desire to know if you can deposit a METHOD:REQUEST into the TARGET calendar. > 6- Does CAR-MIN impose restrictions on decreed VCARs? No - they can be decreed, they might not be decreed. --------------440EBFC62AA46EA40570967B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 14:52:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VJgwX00396 for ietf-calendar-bks; Thu, 31 Jan 2002 11:42:58 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VJgv300392 for ; Thu, 31 Jan 2002 11:42:57 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA13551 for ; Thu, 31 Jan 2002 11:42:58 -0800 (PST) Message-ID: <3C599E3D.BA20A53C@Royer.com> Date: Thu, 31 Jan 2002 12:42:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: CARID:UPDATEPARTSTATUS (Was: Re: VCAR: RIGHTS Value Type Ambiguous) References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <3C4D8FCA.CF98FE20@steltor.com> <3C4DF26F.3A1394A9@Royer.com> <3C595540.DCF0CFDA@steltor.com> <3C59798E.3B14B5EB@Royer.com> <3C597DE6.9C6F6E79@steltor.com> Content-Type: multipart/mixed; boundary="------------C0ED804DBC3ED9DDD56D9319" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C0ED804DBC3ED9DDD56D9319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Doug Royer wrote: > > > > UPDATEPARTSTATUS allows for the changing of the PARTSTAT, > > not the ATTTENDEE value. > > Shouldn't that been done through iTIP? It can be, however the CU may wish to do that to their own copy of the ORGANIZER object in the CU's calendar :-) There are three issues. (1) How do I store un-processed iTIP requests in my calendar. (2) How do I store the results of MY procesing iTIP requests in MY calendar? (3) How do I directly update MY PARTSTAT in the ORGANIZERs (or some other) calendar? (not my calendar). UPDATEPARTSTATUS applies to (3). If I connect to the ORGANIZERs calendar. Authenticate. Ask if I can update my PARTSTAT - yes. I update it. > A invites B and C. C shouldn't be allowed to > change his PARTSTATS in B's VAGENDA. Otherwise, > "iTIP is busted". No? Correct. But UPDATEPARTSTATUS is for B and C to be able to update A directly. Don't forget about METHOD:PUBLISH objects, that do not follow the same rules as METHOD:REQUEST objects. --------------C0ED804DBC3ED9DDD56D9319 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 14:59:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VJkPl00481 for ietf-calendar-bks; Thu, 31 Jan 2002 11:46:25 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VJkO300476 for ; Thu, 31 Jan 2002 11:46:24 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id LAA13566 for ; Thu, 31 Jan 2002 11:46:25 -0800 (PST) Message-ID: <3C599F0C.52D461A7@Royer.com> Date: Thu, 31 Jan 2002 12:46:20 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCARs - any other specific proposals? References: Content-Type: multipart/mixed; boundary="------------846BAFBFDE1E9A1BBD0DDA8A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------846BAFBFDE1E9A1BBD0DDA8A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > While I wade thru the immense flood of recent postings and try to stay > abreast of the discussions I have one simple sugestion. WRT: > > The "CARID" property specifies the local identifier for the "VCAR" > calendar component. The "NAME" property specifies a localizable > display name. > > Given the ABNF and the prose it appears as if I can have a NAME but no > CARID. bug! > Since the CARID is what is used to find the definition of the > rights, but NAME is not, why not follow the same approach we took for > ATTENDEE and CN. Make NAME a property parameter of CARID. Better > still, you can reuse the CN property parameter name since its > essentially the same thing, just in another property now. I thought of the same thing, however a CN (2445) is: 4.2.2 Common Name Parameter Name: CN Purpose: To specify the common name to be associated with the calendar user specified by the property. It's not a calendar user. BUT - It could be a paramater to CARID - yes. --------------846BAFBFDE1E9A1BBD0DDA8A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 15:34:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VKOxe01873 for ietf-calendar-bks; Thu, 31 Jan 2002 12:24: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 g0VKOw301869 for ; Thu, 31 Jan 2002 12:24:58 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA01405 for ; Thu, 31 Jan 2002 15:24:51 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VKOoQ06863 for ; Thu, 31 Jan 2002 15:24:50 -0500 (EST) Message-ID: <3C59A87F.D0724CA@steltor.com> Date: Thu, 31 Jan 2002 15:26: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: VCARs - any other specific proposals? References: <3C599F0C.52D461A7@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: > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > While I wade thru the immense flood of recent postings and try to stay > > abreast of the discussions I have one simple sugestion. WRT: > > > > The "CARID" property specifies the local identifier for the "VCAR" > > calendar component. The "NAME" property specifies a localizable > > display name. > > > > Given the ABNF and the prose it appears as if I can have a NAME but no > > CARID. > > bug! As I said to Bruce let's make CARID mandatory (i.e., MUST occur once). > BUT - It could be a paramater to CARID - yes. Can't be done because of localization. See my reply to Bruce. 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 Jan 31 15:43:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11782 for ; Thu, 31 Jan 2002 15:43:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VKXGk02154 for ietf-calendar-bks; Thu, 31 Jan 2002 12:33:16 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VKXF302150 for ; Thu, 31 Jan 2002 12:33:15 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: Consistant naming of tags MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 31 Jan 2002 15:40:17 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 01/31/2002 03:40:33 PM, Serialize complete at 01/31/2002 03:40:33 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >For those less observant the difference is a '_' vs a '-'. We should be consistanly using one or the other. Good point--those are easy characters to misread/misremember. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===============================================================| |"If it failed then, there's no reason to think we can't make it| |fail now." -- Colin Benson | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 31 15:53:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12138 for ; Thu, 31 Jan 2002 15:53:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VKg9o02391 for ietf-calendar-bks; Thu, 31 Jan 2002 12:42:09 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VKg8302385 for ; Thu, 31 Jan 2002 12:42:08 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA01902 for ; Thu, 31 Jan 2002 15:42:05 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VKg4Q08628 for ; Thu, 31 Jan 2002 15:42:04 -0500 (EST) Message-ID: <3C59AC88.EFFC0071@steltor.com> Date: Thu, 31 Jan 2002 15:43: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: CAP: CARID:UPDATEPARTSTATUS (Was: Re: VCAR: RIGHTS Value Type Ambiguous) References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <3C4D8FCA.CF98FE20@steltor.com> <3C4DF26F.3A1394A9@Royer.com> <3C595540.DCF0CFDA@steltor.com> <3C59798E.3B14B5EB@Royer.com> <3C597DE6.9C6F6E79@steltor.com> <3C599E3D.BA20A53C@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: > > It can be, however the CU may wish to do that to their own > copy of the ORGANIZER object in the CU's calendar :-) CARID:DEFAULTOWNER will most probably allow them to. > > There are three issues. > > (1) How do I store un-processed iTIP requests in my calendar. > > (2) How do I store the results of MY procesing iTIP requests > in MY calendar? > > (3) How do I directly update MY PARTSTAT in the ORGANIZERs > (or some other) calendar? (not my calendar). > > UPDATEPARTSTATUS applies to (3). > > If I connect to the ORGANIZERs calendar. > Authenticate. > Ask if I can update my PARTSTAT - yes. > I update it. > > > A invites B and C. C shouldn't be allowed to > > change his PARTSTATS in B's VAGENDA. Otherwise, > > "iTIP is busted". No? > > Correct. But UPDATEPARTSTATUS is for B and C to be able > to update A directly. Then, I have never seen a definition of CARID:UPDATEPARTSTATUS that made sure that B and C could not bust iTIP. Basically, CARID:UPDATEPARTSTATUS would need to select only the VEVENTs that have the ORGANIZER property set to the address of the calendar in which they are stored. Have I finally helped you finding a valid reason to add OWNER() to CAP-QL? :-) How about the following definition? BEGIN:VCAR CARID:UPDATEPARTSTATUS GRANT:* PERMISSION:MODIFY SCOPE:SELECT att FROM VEVENT USING_PROPERTIES ATTENDEE att WHERE att = SELF() AND ORGANIZER = OWNER() RESTRICTION:ATTENDEE = SELF() END:VCAR GRANT all users (*) the right to MODIFY the instances of the ATTENDEE property set to one of their calendar adresses (att = SELF()) in the VEVENT components for which the ORGANIZER property is set to the address of the VAGENDA in which the VEVENT is stored (OWNER()), given that the submitted value of the ATTENDEE property is a calendar address of the current user (ATTENDEE = SELF()). 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 Jan 31 16:30:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13132 for ; Thu, 31 Jan 2002 16:30:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VLKI703668 for ietf-calendar-bks; Thu, 31 Jan 2002 13:20:18 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VLKF303659 for ; Thu, 31 Jan 2002 13:20:16 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP: LANGUAGE parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 31 Jan 2002 16:27:24 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 01/31/2002 04:27:34 PM, Serialize complete at 01/31/2002 04:27:34 PM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0VLKI303663 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit >Can we change our restriction tables to allow LOCATION, >SUMMARY, CATEGORIES, NAME, etc. to occur more than once >in our components? Not without breaking compatibility with 2445. In any event, simply adding multiple properties isn't clear enough--do two LOCATION properties mean two alternate names for the same location, or two separate locations (for example, a party that starts at a restaurant and goes on to a theatre)? We'd have to come up with a structured model, with analogues of MIME's multipart/mixed and multipart/alternative. As a workaround, you could use ALTREP and a data: URI (RFC-2397): LOCATION;ALTREP=;LANGUAGE=en:Montreal (all the stuff within <> has to be escaped, of course, since it uses ; and :). Pretty messy, I admit--and the data: doesn't support a Content-Language: header, so you can't tag the "Montréal" as being fr-CA. /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |===========================================================| |"I only wish I had time to get married myself, as I've told| |m'wife many's the time." | \===========================================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 31 17:02:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13954 for ; Thu, 31 Jan 2002 17:02:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VLmBm04429 for ietf-calendar-bks; Thu, 31 Jan 2002 13:48:11 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VLm8304424 for ; Thu, 31 Jan 2002 13:48:08 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: Byte reduction in BEEP commands. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 31 Jan 2002 16:55:15 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 01/31/2002 04:55:27 PM, Serialize complete at 01/31/2002 04:55:27 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Doug Royer wrote: >... >> And I changed the names to MATCH (case) the iCalendar objects. >> As iCalendar objects are upper case, No, they aren't; they're case-insensitive. RFC-2445, section 4.1 (last paragraph on page 15). The specs habitually write them as uppercase; but that's not normative. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |============================================================| |Just because we are out to get you does not mean you are not| |paranoid. | \============================================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 31 17:19:45 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14224 for ; Thu, 31 Jan 2002 17:19:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VMASo05004 for ietf-calendar-bks; Thu, 31 Jan 2002 14:10:28 -0800 (PST) Received: from postman.incentivesystems.com ([207.190.196.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VMAO304997 for ; Thu, 31 Jan 2002 14:10:24 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: Editors notes in CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 31 Jan 2002 17:17:32 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.6a |January 17, 2001) at 01/31/2002 05:17:43 PM, Serialize complete at 01/31/2002 05:17:43 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I think we want to >be able to appeal all method reviewer decisions. Actually, I would prefer to strike the MR process from CAP and iCalendar altogether. As I wrote back in August (), it simply does not make sense. To quote: >CAP seems to have picked up the "item registration" meme from iCalendar, >which got it from MIME. In MIME, it makes sense (all Content-types, for >example, are independent); in iCalendar, it's risky (different >properties can interact); in CAP, it's an out-and-out mistake. CAP is a >protocol, not a data format; it cannot be defined piecemeal. For that >reason, protocols need to be updated by the normal RFC process. If >someone wants to define, say, a new method for CAP, they need to write >an I-D and get it approved as a standards-track RFC, updating the CAP >RFC. (This does not mean that they have to reissue an updated CAP RFC; >they can have a smaller RFC that just defines the new method.) > >This is the normal mechanism for extending protocols. We should not be >coming up with our own mechanism just for CAP. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com|My opinions are my own. | |=============================================================| |Rope is rope, and string is string, and never the twine shall| |meet. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Thu Jan 31 17:42:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14697 for ; Thu, 31 Jan 2002 17:42:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VMXg005564 for ietf-calendar-bks; Thu, 31 Jan 2002 14:33: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 g0VMXf305559 for ; Thu, 31 Jan 2002 14:33: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 OAA13772 for ; Thu, 31 Jan 2002 14:33:42 -0800 (PST) Message-ID: <3C59C63F.4A26435B@Royer.com> Date: Thu, 31 Jan 2002 15:33:35 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: LANGUAGE parameter References: <3C599088.5E2CB18D@steltor.com> Content-Type: multipart/mixed; boundary="------------FF1EBA27FF9A012379439347" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------FF1EBA27FF9A012379439347 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Bernard Desruisseaux wrote: > = > As a French speaker I'm concerned by the fact that we > don't allow properties that make use of the LANGUAGE > parameter to occur more than once in our components. > = > For instance, how am I supposed to specify my home town > in both French and English as the location of a VEVENT, > given that LOCATION is only allowed to occur once in a > VEVENT? That is, the following is not legal: > = > LOCATION;LANGUAGE=3Den:Montreal > LOCATION;LANGUAGE=3Dfr-CA:Montr=C3=A9al <-- Montr=E9al in UTF-8 > = > Can we change our restriction tables to allow LOCATION, > SUMMARY, CATEGORIES, NAME, etc. to occur more than once > in our components? The SkiCal people pointed that out a couple of years ago. They also had an issue with what the language spoken at the event would be: LOCATION;LANGUAGE=3Den:Montreal LOCATION;LANGUAGE=3Dfr-CA:Montr=C3=A9al = = But that did not say if English or French would be the language spoken at the event. Have you looked at the SkiCaL proposals to see how they solved this? And would you agree this is a separate issue from CAP? I don't think that CAP cares, so this would be a separate draft on making 2445 more L18N'able. --------------FF1EBA27FF9A012379439347 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 17:45:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VMTR605441 for ietf-calendar-bks; Thu, 31 Jan 2002 14:29: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 g0VMTP305436 for ; Thu, 31 Jan 2002 14:29: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 OAA13768 for ; Thu, 31 Jan 2002 14:29:27 -0800 (PST) Message-ID: <3C59C540.5508600D@Royer.com> Date: Thu, 31 Jan 2002 15:29:20 -0700 From: Doug Royer Reply-To: Ietf-Calendar@Imc, Org@royer.com Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Initial connection to CAP server? References: Content-Type: multipart/mixed; boundary="------------6BD6183305F6CC8B94128AEB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6BD6183305F6CC8B94128AEB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > > A question occurred to me about initial connections to a Calendar Server: > > How does a user learn what their Calendar is? i.e. the first time a user > connects to a given CS and validates identity in some manner - how do they > learn what their Calendar Address is? As in IMAP has an INBOX, do we need a DEFAULT_CAL for each UPN? Could the default cal be their UPN? --------------6BD6183305F6CC8B94128AEB Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 17:45:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VMadj05629 for ietf-calendar-bks; Thu, 31 Jan 2002 14:36:39 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VMac305625 for ; Thu, 31 Jan 2002 14:36:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13778 for ; Thu, 31 Jan 2002 14:36:39 -0800 (PST) Message-ID: <3C59C6F0.121D9891@Royer.com> Date: Thu, 31 Jan 2002 15:36:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C59481B.E9B84FB3@steltor.com> <3C5975AC.F90F6506@Royer.com> <3C59943C.20297C16@steltor.com> Content-Type: multipart/mixed; boundary="------------3D7B8DA62D634C2068618002" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3D7B8DA62D634C2068618002 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > Doug Royer wrote: > > > > Patrice Lapierre wrote: > > > > > > ... > > > > 6.2.4.2 "delete" Command > > > > > > > > C: > > > > > > > > S: ...empty BEEP RPY is success... > > > > > > This is slightly off topic, but for the delete, move and modify > > > commands it would probably be useful to always return the number of > > > selected components. > > If the VQUERY inside these command doesn't match any > > Why? What are you going to do with '23'? > > It's up the to the CUA, it could for example update a counter > displayed next to name of the VAGENDA in a tree view. > If a the VQUERY inside one of these commands doesn't match > any components, it's not considered an error. Therefore if CUA performs > "move" of a single VEVENT (query on the UID). If the count is not > returned, the CUA doesn't know that the component was indeed moved Sure it does, if there is an error your get an error. If there is no error and it is not done, your implementation is busted. > (a command from another session could have deleted the VEVENT > just before the execution of the "move"). In which case you would get a 'no such event' error. And not a success code (Or empty as I proposed). And adding a RETURN COUNTER is a new thing - and we all need to keep each other from inventing new things at this point in time. --------------3D7B8DA62D634C2068618002 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 17:47:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VMcwC05680 for ietf-calendar-bks; Thu, 31 Jan 2002 14:38:58 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VMcv305676 for ; Thu, 31 Jan 2002 14:38:57 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13783 for ; Thu, 31 Jan 2002 14:38:58 -0800 (PST) Message-ID: <3C59C77B.9E9476E6@Royer.com> Date: Thu, 31 Jan 2002 15:38:51 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: VCARs - any other specific proposals? References: <3C5994DA.F7F78E74@steltor.com> Content-Type: multipart/mixed; boundary="------------F411D3E1FBAB2914F5AD4C56" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F411D3E1FBAB2914F5AD4C56 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > Bruce_Kahn@notesdev.ibm.com wrote: > > > > While I wade thru the immense flood of recent postings and try to stay > > abreast of the discussions I have one simple sugestion. WRT: > > > > The "CARID" property specifies the local identifier for the "VCAR" > > calendar component. The "NAME" property specifies a localizable > > display name. > > > > Given the ABNF and the prose it appears as if I can have a NAME but no > > CARID. Since the CARID is what is used to find the definition of the > > rights, but NAME is not, why not follow the same approach we took for > > ATTENDEE and CN. Make NAME a property parameter of CARID. Better > > still, you can reuse the CN property parameter name since its > > essentially the same thing, just in another property now. > > What about localization? :-( Your right. > In my last post (CAP: LANGUAGE parameter), I requested > that we allow NAME to occur more than once to be able > to specify this property in different languages in the > same VCAR. As we are inventing VCARs and VQUERYs (2445 did not), it is not too late to do that. I am okay with multiple NAME's per VCAR, but only if they have unique LANGUAGE parameters. --------------F411D3E1FBAB2914F5AD4C56 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 17:49:26 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VMeqO05744 for ietf-calendar-bks; Thu, 31 Jan 2002 14:40: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 g0VMep305738 for ; Thu, 31 Jan 2002 14:40: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 OAA13795 for ; Thu, 31 Jan 2002 14:40:53 -0800 (PST) Message-ID: <3C59C7EE.633A7AF8@Royer.com> Date: Thu, 31 Jan 2002 15:40:46 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Consistant naming of tags References: Content-Type: multipart/mixed; boundary="------------2D42B75706A7C13DF4F38DC6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2D42B75706A7C13DF4F38DC6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In looking at the versions of CAP Ive noticed that we are somewhat > arbitrary in how we name multiword properties and parameters. For > example we have properties like: > > DEFAULT_VCARS CURRENT_DATETIME RECUR_ACCEPTED RECUR_EXPAND > > as well as some like: > > ALLOW-CONFLICT LAST-MODIFIED > > etc. > > For those less observant the difference is a '_' vs a '-'. We should > be consistanly using one or the other. Since iCalendar opt'd for '-' > I propose that all '_' in properties be changed to '-' in the draft > for consistancy reasons. I agree, I think they sneaked in when I had a buggy version of my text processor, it printed '_' instead of '-', then when I fixed the text, I missed many of them. --------------2D42B75706A7C13DF4F38DC6 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 17:56:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VMlci05959 for ietf-calendar-bks; Thu, 31 Jan 2002 14:47:38 -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 g0VMlb305955 for ; Thu, 31 Jan 2002 14:47:37 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA05023 for ; Thu, 31 Jan 2002 17:47:34 -0500 Received: from steltor.com ([101.0.0.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VMlXQ23228 for ; Thu, 31 Jan 2002 17:47:33 -0500 (EST) Message-ID: <3C59C9F1.8E533A42@steltor.com> Date: Thu, 31 Jan 2002 17:49:21 -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: LANGUAGE parameter 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: > > >Can we change our restriction tables to allow LOCATION, > >SUMMARY, CATEGORIES, NAME, etc. to occur more than once > >in our components? > > Not without breaking compatibility with 2445. You're right. It is clear in 2445 that LOCATION and SUMMARY MUST NOT occur more than once. On the other hand, CATEGORIES and COMMENT MAY occur more than once in 2445 but not in CAP. We need to fix the restriction tables in CAP. > In any event, simply adding multiple properties isn't clear enough--do two > LOCATION properties mean two alternate names for the same location, or two > separate locations (for example, a party that starts at a restaurant and > goes on to a theatre)? We'd have to come up with a structured model, with > analogues of MIME's multipart/mixed and multipart/alternative. I agree that multiple instances may not be appropriate for some properties but it is a pity that 2445 doesn't provide us with a "proper" way of doing that. The same way 2445 allows TZNAME to occur more than once, I propose that CAP allows the property NAME to occur more than once in the components VAGENDA and 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 Thu Jan 31 17:59:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15019 for ; Thu, 31 Jan 2002 17:59:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VMooE06063 for ietf-calendar-bks; Thu, 31 Jan 2002 14:50:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VMon306059 for ; Thu, 31 Jan 2002 14:50:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id OAA13812 for ; Thu, 31 Jan 2002 14:50:51 -0800 (PST) Message-ID: <3C59CA43.EAC69A5F@Royer.com> Date: Thu, 31 Jan 2002 15:50:43 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC 2446: Delegation text needs some changes References: Content-Type: multipart/mixed; boundary="------------5696C0B6FB80DE632BDD0729" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5696C0B6FB80DE632BDD0729 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In RFC 2446 we wrote: > > . Send a "REPLY" to the "Organizer" with the following updates: > . The "Delegator's" "ATTENDEE" property "partstat" parameter set > to "delegated" and the "delegated-to" parameter is set to the > address of the "Delegate" > . Add an additional "ATTENDEE" property for the "Delegate" with > the "delegated-from" property parameter set to the "Delegator" > . Indicate whether they want to continue to receive updates when > the "Organizer" sends out updated versions of the event. > Setting the "rsvp" property parameter to "TRUE" will cause the > updates to be sent, setting it to "FALSE" causes no further > updates to be sent. Note that in either case, if the "Delegate" > declines the invitation the "Delegator" will be notified. > . The "Delegator" MUST also send a copy of the original "REQUEST" > method to the "Delegate". > > however there is a small problem w/the last line. If the Delegator > actually does this then they CANNOT add a new ATTENDEE line with the > Delegatees info NOR can they update their own ATTENDEE line to reflect > the delegation. In addition it is NOT legal for the Delegator to > include a COMMENT to tell the Delgatee something like "Im in FL that > week. I need you to go for me!" or "I dont like meetings w/Joe so Im > sending you insetad!". > > It should be allowable that a Delegator can send non-process info like > a COMMENT (or other IANA properties/parameters) in the Delegation > notice. As COMMENT is already defined, the delegatee would have no way of knowing if the COMMENT was from the ORGANIZER or the Delegate. I think we would need a new property. Instead; How about we modify the last sentence of the above 2445 text to say: The "ORGANIZER" MUST send out a new REQUEST with an updated SEQUENCE number. That I think solves the problem. And then everyone, delegatee included is notified. The delegatee's CUA can see that they are tagged as DELEGATED-TO and know what it means. If they decline they can send an update as described above. > The phrase "send a copy of the original" implys that these > changes/additions cannot be done. Without the changes, the Delegatee > has no way to know why they got a REQUEST from the Delegator and not > from the Organizer. Yea, that is busted. > We intended to make sure that the Delegator sent an accurate > representation of the Organizers REQUEST but we did this > (accdientally) at the expense of some feature sets or functionality. > I will try to work up some change text for this (that preserves the > base intent but allows for needed or future changes) and present it to > the WG for discussion unless there is strong dissent about the need > for it. --------------5696C0B6FB80DE632BDD0729 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 18:03:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VMrtK06121 for ietf-calendar-bks; Thu, 31 Jan 2002 14:53: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 g0VMrr306117 for ; Thu, 31 Jan 2002 14:53: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 OAA13830 for ; Thu, 31 Jan 2002 14:53:55 -0800 (PST) Message-ID: <3C59CAFC.BC1E10C8@Royer.com> Date: Thu, 31 Jan 2002 15:53:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP & BEEP: Initial connection References: Content-Type: multipart/mixed; boundary="------------624FF467F64540D43AEBB285" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------624FF467F64540D43AEBB285 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Did you guys mean to say that: > > 3. Protocol Framework > CAP uses the BEEP application protocol kernel mapped onto TCP (refer > to [BEEP] and [BEEPTCP] for more information). The default port that > the Calendar Service listens for connections on is port 5229. > > from the latest draft covers "How does a CUA connect up to the CS and > authenticate with it?" If you did, its needs to be MUCH clearer. At > least you MUST put some text like "Authentication and session creation > management are covered in sections XXX and YYY of [RFC...]". > > Its just not clear (or even vaguely clear) how a CUA gets the session > to the CS going... [I MOVED THIS TO THE WG LIST] If you read BEEP you will know :-) Yes I too think it needs to explicitly say how. I do agree that we MUST mandate at least ONE minimum authentication level that CS/BEEP MUST support. This was dictated to us by the area directors years ago. --------------624FF467F64540D43AEBB285 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 18:18:30 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VN8xI06640 for ietf-calendar-bks; Thu, 31 Jan 2002 15:08:59 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VN8v306636 for ; Thu, 31 Jan 2002 15:08:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA13857 for ; Thu, 31 Jan 2002 15:08:59 -0800 (PST) Message-ID: <3C59CE84.65AAE8D1@Royer.com> Date: Thu, 31 Jan 2002 16:08:52 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: CARID:UPDATEPARTSTATUS (Was: Re: VCAR: RIGHTS Value Type Ambiguous) References: <3C4C4308.4B0C2881@steltor.com> <3C4C51B2.BC17E727@Royer.com> <3C4C7728.424E2E13@steltor.com> <3C4C8D85.7EC613C8@Royer.com> <3C4D8FCA.CF98FE20@steltor.com> <3C4DF26F.3A1394A9@Royer.com> <3C595540.DCF0CFDA@steltor.com> <3C59798E.3B14B5EB@Royer.com> <3C597DE6.9C6F6E79@steltor.com> <3C599E3D.BA20A53C@Royer.com> <3C59AC88.EFFC0071@steltor.com> Content-Type: multipart/mixed; boundary="------------16BC50071CC7980800B91C28" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------16BC50071CC7980800B91C28 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > > > (3) How do I directly update MY PARTSTAT in the ORGANIZERs > > (or some other) calendar? (not my calendar). > > > > UPDATEPARTSTATUS applies to (3). > > > > If I connect to the ORGANIZERs calendar. > > Authenticate. > > Ask if I can update my PARTSTAT - yes. > > I update it. > > > > > A invites B and C. C shouldn't be allowed to > > > change his PARTSTATS in B's VAGENDA. Otherwise, > > > "iTIP is busted". No? > > > > Correct. But UPDATEPARTSTATUS is for B and C to be able > > to update A directly. > > Then, I have never seen a definition of CARID:UPDATEPARTSTATUS > that made sure that B and C could not bust iTIP. If you mean the text in CAP is busted - yep it could be :-) > Basically, CARID:UPDATEPARTSTATUS would need to select only the > VEVENTs that have the ORGANIZER property set to the address of > the calendar in which they are stored. Yes. > Have I finally helped you finding a valid reason to add OWNER() > to CAP-QL? :-) > > How about the following definition? > > BEGIN:VCAR > CARID:UPDATEPARTSTATUS > GRANT:* > PERMISSION:MODIFY > SCOPE:SELECT att FROM VEVENT > USING_PROPERTIES ATTENDEE att > WHERE att = SELF() AND ORGANIZER = OWNER() > RESTRICTION:ATTENDEE = SELF() > END:VCAR Yes. > GRANT all users (*) the right to MODIFY the instances > of the ATTENDEE property set to one of their calendar > adresses (att = SELF()) in the VEVENT components for > which the ORGANIZER property is set to the address of > the VAGENDA in which the VEVENT is stored (OWNER()), > given that the submitted value of the ATTENDEE property is > a calendar address of the current user (ATTENDEE = SELF()). Yes. --------------16BC50071CC7980800B91C28 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 18:23:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VNETX06825 for ietf-calendar-bks; Thu, 31 Jan 2002 15: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 g0VNES306820 for ; Thu, 31 Jan 2002 15:14: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 PAA13871 for ; Thu, 31 Jan 2002 15:14:30 -0800 (PST) Message-ID: <3C59CFCF.86A9BCD7@Royer.com> Date: Thu, 31 Jan 2002 16:14:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: LANGUAGE parameter References: Content-Type: multipart/mixed; boundary="------------C2F361E50B6144E0FC282B09" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C2F361E50B6144E0FC282B09 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >Can we change our restriction tables to allow LOCATION, > >SUMMARY, CATEGORIES, NAME, etc. to occur more than once > >in our components? > > Not without breaking compatibility with 2445. It would break iTIP, but I don' think that there are restriction tables in 2445. Also, as LANGUAGE is a valid paramater to the ATTENDEE property (it applies to the CN paramater), then there could only be one ATTENDEE per UPN, and only one LANGUAGE per UPN. Multiple LANGUAGEs would have to be restricted to specific sets. --------------C2F361E50B6144E0FC282B09 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 18:26:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VNHOq06911 for ietf-calendar-bks; Thu, 31 Jan 2002 15:17: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 g0VNHN306906 for ; Thu, 31 Jan 2002 15:17: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 PAA13876 for ; Thu, 31 Jan 2002 15:17:24 -0800 (PST) Message-ID: <3C59D07D.3D5A55D5@Royer.com> Date: Thu, 31 Jan 2002 16:17:17 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: UPN (User Principal Name) References: <3C596A79.F4D3FAF8@steltor.com> Content-Type: multipart/mixed; boundary="------------363322E790B685D20B0C1AAF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------363322E790B685D20B0C1AAF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > I would like to propose the following syntax and semantic > for UPN values that can be specified in the GRANT and DENY > properties in VCAR components for the purpose of authorization. You have confused the REALM part of the UPN and called it 'from' realm below. They are not the same. If I authenticate as 'doug@royer.com' by connecting to 'calendar.steltor.com' it says NOTHING about where I connected FROM. It just says that my UPN is 'doug@royer.com' I may have connected from 'i-hacked-you.com'. > OWNER The owner of the VAGENDA in which the > encapsulating VCAR is stored It means you name is in the OWNER property of the VAGENDA - correct? > NONOWNER All users except the owner of the VAGENDA > in which the encapsulating VCAR is stored It means your name is NOT in the OWNER property of the VAGANDA - correct? > * All users (including anonymous) Okay. > @ All anonymous users from unnamed realms Okay. > @* All anonymous users from all named realms What would and un-named realm be? > @realm All anonymous users from specified realm Are you saying that the CS MUST do a reverse lookup and determine that they are in fact connecting 'from' realm? OR are you saying that they supplied anonymous@realm as their UPN during authentication? > *@* All named users from all named realms How is that different than '*' ? > *@realm All named users from specified realm All named users that have a UPN with @realm at the end? Or all valid UPNs that connect and the reverse lookup says they are in fact connecting from the 'from' realm? > user@realm Specified user from specified realm OR specifies that 'user@realm' was entered for the authentication? and they can in fact connect from any realm? > user@* Specified user from all named realms Connecting from any realm, or supplying any realm? > Examples, > > GRANT:bernard@steltor.com # Grant user identified as > # "bernard@steltor.com" > > DENY:NOWOWNER # Deny non owner of the VAGENDA > > GRANT:*@steltor.com # Grant all named users from realm > # "steltor.com" So, can I connect from royer.com but supply a UPN of 'bernard@steltor.com' ? Or are you saying that 'bernard' is only valid when connecting from realm 'steltor.com' ? > GRANT:@steltor.com # Grant anonymous users from the > # realm "steltor.com" But only connecting from steltor.com , or connecting from any? --------------363322E790B685D20B0C1AAF Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 18:27:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0VNIc606939 for ietf-calendar-bks; Thu, 31 Jan 2002 15:18:38 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VNIb306935 for ; Thu, 31 Jan 2002 15:18:38 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA13884 for ; Thu, 31 Jan 2002 15:18:39 -0800 (PST) Message-ID: <3C59D0C8.5F6DA92D@Royer.com> Date: Thu, 31 Jan 2002 16:18:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP: LANGUAGE parameter References: <3C59C9F1.8E533A42@steltor.com> Content-Type: multipart/mixed; boundary="------------56BA1C8BC14423E7B356891F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------56BA1C8BC14423E7B356891F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Bernard Desruisseaux wrote: > = > I agree that multiple instances may not be appropriate for some > properties but it is a pity that 2445 doesn't provide us with a > "proper" way of doing that. We could invent something like ALT_LOCATION, ALT_SUMMARY, ... to mean alternate: LOCATION;LANGUAGE=3Dfr_ca:Montr=C3=A9al ALT_LOCATION;LANGUAGE=3Den:Montreal It would not break iTIP. --------------56BA1C8BC14423E7B356891F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC ; Thu, 31 Jan 2002 18:28:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VNJo106983 for ietf-calendar-bks; Thu, 31 Jan 2002 15:19:50 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VNJn306978 for ; Thu, 31 Jan 2002 15:19:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.9.1/8.9.1) with ESMTP id PAA13888 for ; Thu, 31 Jan 2002 15:19:32 -0800 (PST) Message-ID: <3C59D0FC.9521453B@Royer.com> Date: Thu, 31 Jan 2002 16:19:24 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-21 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Byte reduction in BEEP commands. References: <3C55E3F8.D7BB794D@Royer.com> <3C594A5A.65588C9D@steltor.com> Content-Type: multipart/mixed; boundary="------------EE7B787AC69D60450FC86866" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EE7B787AC69D60450FC86866 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrice Lapierre wrote: > > > Doug Royer wrote: > ... > > Change the command in the existing example: > > > ... > > > > > > TO: > > > > C:Content-Type: application/...beep... > > C: > > C: > > C: > C: BEGIN:VCALENDAR > > C: CMDID:unique-id > > C: TARGET:opaqueid101 > > C: BEGIN:VQUERY > > C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT > > C: WHERE DTEND >= '19990714T080000' AND > > C: DTSTART <= '19990715T080000' > > C: END:VQUERY > > C: END:VCALENDAR > > C: ]]> > > And placing the iCalendar object directly in the search, > would limit future extension to the addition of attributes > in the search element. NO - its XML, we just add - IF we ever choose to add. > I think that an additional element is needed to allow extension > (e.g. element in draft-06) > > C: > C: