From owner-ietf-calendar@mail.imc.org Thu Mar 7 21:00: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 VAA07295 for ; Thu, 7 Mar 2002 21:00:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g281k2l25195 for ietf-calendar-bks; Thu, 7 Mar 2002 17:46:02 -0800 (PST) Received: from localhost.localdomain ([24.157.64.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g281k0825189 for ; Thu, 7 Mar 2002 17:46:00 -0800 (PST) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g281jLu20629; Thu, 7 Mar 2002 20:45:21 -0500 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: UID & RECURRENCE-ID From: JP Rosevear To: ietf-calendar@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 07 Mar 2002 20:45:18 -0500 Message-Id: <1015551919.17530.90.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit According to the spec regarding UID: This property defines the persistent, globally unique identifier for the calendar component. Now, with itip, RECURRENCE-ID can specify how to modify a single instance of a recurring event and it specifies which event(s) based on RECURRENCE-ID and UID. Now, if you such a change is made, how should the changes be stored? If you create a new component, a new UID will be created, removing any possibility of the organizer sending future changes. If a separate component is created with the same UID and containing the given RECURRENCE-ID, it would seem to violate the the UID spec (as quoted above). Thoughts? -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Thu Mar 7 22:42: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 WAA12155 for ; Thu, 7 Mar 2002 22:42:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g283Wgf27089 for ietf-calendar-bks; Thu, 7 Mar 2002 19:32: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 g283Wf827084 for ; Thu, 7 Mar 2002 19:32:41 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g283WdXi019012 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 7 Mar 2002 19:32:43 -0800 (PST) Message-ID: <3C8830CE.9030800@Royer.com> Date: Thu, 07 Mar 2002 20:32:30 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: UID & RECURRENCE-ID References: <1015551919.17530.90.camel@endspiel.ximian.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 JP Rosevear wrote: > According to the spec regarding UID: > > This property defines the persistent, globally unique > identifier for the calendar component. Its wrong (and good catch!), it should say something like: Purpose: This property defines the persistent, globally unique identifier for the calendar object. Where object is one or more components that make up one VEVENT, VTODO, VJOURNAL, or any other iCalendar object. > Now, with itip, RECURRENCE-ID can specify how to modify a single > instance of a recurring event and it specifies which event(s) based on > RECURRENCE-ID and UID. Now, if you such a change is made, how should > the changes be stored? Storage is not specified in iCal, iTIP, iMIP or CAP. > ... If a separate component is created with the same UID and > containing the given RECURRENCE-ID, it would seem to violate the the UID > spec (as quoted above). > > Thoughts? We need to fix 2445 so it does not say that it is unique per component. The ADD method has the same problem. From owner-ietf-calendar@mail.imc.org Fri Mar 8 07:07: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 HAA00982 for ; Fri, 8 Mar 2002 07:07:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g28BuHW11221 for ietf-calendar-bks; Fri, 8 Mar 2002 03:56:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28BuG811216 for ; Fri, 8 Mar 2002 03:56:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29249; Fri, 8 Mar 2002 06:56:15 -0500 (EST) Message-Id: <200203081156.GAA29249@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cap-07.txt Date: Fri, 08 Mar 2002 06:56:14 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendar Access Protocol (CAP) Author(s) : S. Mansour, D. Royer, G. Babics, P. Hill Filename : draft-ietf-calsch-cap-07.txt Pages : 115 Date : 07-Mar-02 The Calendar Access Protocol (CAP) is an Internet protocol that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). This memo defines the CAP specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-cap-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cap-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020307115816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307115816.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Fri Mar 8 11:11: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 LAA12544 for ; Fri, 8 Mar 2002 11:11:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g28G11B25308 for ietf-calendar-bks; Fri, 8 Mar 2002 08:01:01 -0800 (PST) Received: from localhost.localdomain ([24.157.64.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28G0w825293 for ; Fri, 8 Mar 2002 08:00:58 -0800 (PST) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g28G0IU28169; Fri, 8 Mar 2002 11:00:18 -0500 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: UID & RECURRENCE-ID From: JP Rosevear To: ietf-calendar@imc.org Cc: Doug Royer In-Reply-To: <3C8830CE.9030800@Royer.com> References: <1015551919.17530.90.camel@endspiel.ximian.com> <3C8830CE.9030800@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 08 Mar 2002 11:00:17 -0500 Message-Id: <1015603217.20155.20.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thu, 2002-03-07 at 22:32, Doug Royer wrote: > > > > JP Rosevear wrote: > > > According to the spec regarding UID: > > > > This property defines the persistent, globally unique > > identifier for the calendar component. > > > Its wrong (and good catch!), it should say something like: > > Purpose: This property defines the persistent, globally unique > identifier for the calendar object. Where object is one or > more components that make up one VEVENT, VTODO, VJOURNAL, > or any other iCalendar object. > > > > Now, with itip, RECURRENCE-ID can specify how to modify a single > > instance of a recurring event and it specifies which event(s) based on > > RECURRENCE-ID and UID. Now, if you such a change is made, how should > > the changes be stored? > > > Storage is not specified in iCal, iTIP, iMIP or CAP. Fair enough, but there is a practical implementation side to things here. Essentially what I meant by storage was an iCalendar object. > > ... If a separate component is created with the same UID and > > containing the given RECURRENCE-ID, it would seem to violate the the UID > > spec (as quoted above). > > > > Thoughts? > > > We need to fix 2445 so it does not say that it is unique per component. > The ADD method has the same problem. If this is so, it would seem to mean that any icalendar objects that allow recurrences cannot be considered individually by a CUA in many cases (like recurrence instance generation) because there might exist a modifying object with the same UID and a RECURRENCE-ID. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Mar 8 11:34: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 LAA13983 for ; Fri, 8 Mar 2002 11:34:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g28GOg726943 for ietf-calendar-bks; Fri, 8 Mar 2002 08:24:42 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28GOe826935 for ; Fri, 8 Mar 2002 08:24:40 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: UID & RECURRENCE-ID MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 8 Mar 2002 11:33:53 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/08/2002 11:34:04 AM, Serialize complete at 03/08/2002 11:34:04 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >If this is so, it would seem to mean that any icalendar objects that >allow recurrences cannot be considered individually by a CUA in many >cases (like recurrence instance generation) because there might exist a >modifying object with the same UID and a RECURRENCE-ID. That is more or less correct. In your internal storage, of course, you'd want to simplify it by, say, storing objects with the same UID together; but, however you manage it, any time you're expanding a recurrence rule, you do have to be aware that there can be exceptions. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |This space intentionally not left blank. | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 8 12:10: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 MAA17607 for ; Fri, 8 Mar 2002 12:10:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g28GxnS29722 for ietf-calendar-bks; Fri, 8 Mar 2002 08:59:49 -0800 (PST) Received: from localhost.localdomain ([24.157.64.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28Gxl829717 for ; Fri, 8 Mar 2002 08:59:47 -0800 (PST) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g28GwLf07870; Fri, 8 Mar 2002 11:58:21 -0500 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: UID & RECURRENCE-ID From: JP Rosevear To: John Stracke Cc: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 08 Mar 2002 11:58:19 -0500 Message-Id: <1015606699.9993.5.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-03-08 at 11:33, John Stracke wrote: > > >If this is so, it would seem to mean that any icalendar objects that > >allow recurrences cannot be considered individually by a CUA in many > >cases (like recurrence instance generation) because there might exist a > >modifying object with the same UID and a RECURRENCE-ID. > > That is more or less correct. In your internal storage, of course, you'd > want to simplify it by, say, storing objects with the same UID together; > but, however you manage it, any time you're expanding a recurrence rule, > you do have to be aware that there can be exceptions. You also need to be extremely careful when sending out itip requests to new attendees or canceling existing events. In my mind it somewhat defeats the purpose of a unique identifier. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Mar 8 12:15: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 MAA17891 for ; Fri, 8 Mar 2002 12:15:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28H76Y29931 for ietf-calendar-bks; Fri, 8 Mar 2002 09:07:06 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28H75829926 for ; Fri, 8 Mar 2002 09:07:05 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: UID & RECURRENCE-ID MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 8 Mar 2002 12:16:17 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/08/2002 12:16:29 PM, Serialize complete at 03/08/2002 12:16:29 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >You also need to be extremely careful when sending out itip requests to >new attendees or canceling existing events. Er? Can't you send out the REQUEST with the extra recurrence included? /=========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=========================================================| |I am Homer of Borg. Prepare to be assi... Mmm, doughnuts!| \=========================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 8 12:43:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19773 for ; Fri, 8 Mar 2002 12:43:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28HY8d01191 for ietf-calendar-bks; Fri, 8 Mar 2002 09:34:08 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28HY6801187 for ; Fri, 8 Mar 2002 09:34:06 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g28HY3Xi020803 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Mar 2002 09:34:07 -0800 (PST) Message-ID: <3C88F608.2080203@Royer.com> Date: Fri, 08 Mar 2002 10:34:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: "ietf-calendar@imc.org" Subject: Re: UID & RECURRENCE-ID References: <1015606699.9993.5.camel@endspiel.ximian.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 >>That is more or less correct. In your internal storage, of course, you'd >>want to simplify it by, say, storing objects with the same UID together; >>but, however you manage it, any time you're expanding a recurrence rule, >>you do have to be aware that there can be exceptions. >> > > You also need to be extremely careful when sending out itip requests to > new attendees or canceling existing events. In my mind it somewhat > defeats the purpose of a unique identifier. The UID is unique per event (as you have pointed out), not unique per packet (component). So you can ADD and CANCEL instances of the same UID. It is also possible to not be able to represent a single event in one single component. Only the ORGANIZER and the ORGANIZER-CUA(s) know what the entire state of any UID as not all ATTENDEEs have data for the other ATTENDEEs. iCalendar and iTIP are not meant to represent the exact state of any event. They are an interoperability protocol for exchanging the information between users so that the ORGANIZER has control of an event. From owner-ietf-calendar@mail.imc.org Fri Mar 8 13:01: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 NAA20876 for ; Fri, 8 Mar 2002 13:01:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28HrAG01821 for ietf-calendar-bks; Fri, 8 Mar 2002 09:53:10 -0800 (PST) Received: from localhost.localdomain ([24.157.64.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28Hr8801817 for ; Fri, 8 Mar 2002 09:53:08 -0800 (PST) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g28HpmC25622; Fri, 8 Mar 2002 12:51:48 -0500 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: UID & RECURRENCE-ID From: JP Rosevear To: John Stracke Cc: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 08 Mar 2002 12:51:47 -0500 Message-Id: <1015609907.26946.8.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-03-08 at 12:16, John Stracke wrote: > > >You also need to be extremely careful when sending out itip requests to > >new attendees or canceling existing events. > > Er? Can't you send out the REQUEST with the extra recurrence included? Yes, but you need to recognize that. Similarly for updating any common properties, like summary. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Mar 8 13:22: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 NAA22145 for ; Fri, 8 Mar 2002 13:22:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g28IDx903453 for ietf-calendar-bks; Fri, 8 Mar 2002 10:13:59 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28IDw803446 for ; Fri, 8 Mar 2002 10:13:58 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: UID & RECURRENCE-ID MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 8 Mar 2002 13:23:10 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/08/2002 01:23:22 PM, Serialize complete at 03/08/2002 01:23:22 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Er? Can't you send out the REQUEST with the extra recurrence included? > >Yes, but you need to recognize that. Uh-huh. And in what way could a representation format for events (a) support repeating events with exceptions and (b) not require implementations to recognize repeating events with exceptions? /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===========================================================| |Stupid, adj.: Losing $25 on the game and $50 on the instant| |replay. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 8 13:28: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 NAA22508 for ; Fri, 8 Mar 2002 13:28:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g28IKMt03919 for ietf-calendar-bks; Fri, 8 Mar 2002 10:20: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 g28IKL803914 for ; Fri, 8 Mar 2002 10:20:21 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g28IKAXi020893 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Mar 2002 10:20:19 -0800 (PST) Message-ID: <3C8900D6.5010207@Royer.com> Date: Fri, 08 Mar 2002 11:20:06 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: UID & RECURRENCE-ID References: <1015609907.26946.8.camel@endspiel.ximian.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 JP Rosevear wrote: > On Fri, 2002-03-08 at 12:16, John Stracke wrote: > >>>You also need to be extremely careful when sending out itip requests to >>>new attendees or canceling existing events. >>> >>Er? Can't you send out the REQUEST with the extra recurrence included? >> > > Yes, but you need to recognize that. Similarly for updating any common > properties, like summary. Summary can be unique per instance: BEGIN:VCALENDAR METHOD:REQUEST UID:1 ... BEGIN:VEVENT SUMMARY:summary 1 DTSTART:....... ... RRULE:...every Friday... END:VEVENT END:VCALENDAR Then later you add to UID:1 an instance for Tuesday: BEGIN:VEVENT METHOD:ADD UID:1 ... BEGIN:VEVENT SUMMARY:summary 2 unique to this instance DTSTART:...next-tue... END:VEVENT END:VCALEDAR From owner-ietf-calendar@mail.imc.org Fri Mar 8 15:21: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 PAA01485 for ; Fri, 8 Mar 2002 15:21:27 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g28KAvV07241 for ietf-calendar-bks; Fri, 8 Mar 2002 12:10:57 -0800 (PST) Received: from localhost.localdomain ([24.157.64.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28KAn807228 for ; Fri, 8 Mar 2002 12:10:49 -0800 (PST) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g28K9NR06343; Fri, 8 Mar 2002 15:09:23 -0500 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: UID & RECURRENCE-ID From: JP Rosevear To: John Stracke Cc: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 08 Mar 2002 15:09:23 -0500 Message-Id: <1015618163.9992.26.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-03-08 at 13:23, John Stracke wrote: > > >> Er? Can't you send out the REQUEST with the extra recurrence included? > > > >Yes, but you need to recognize that. > > Uh-huh. And in what way could a representation format for events (a) > support repeating events with exceptions and (b) not require > implementations to recognize repeating events with exceptions? The issue is not with recognizing that fact but with recognizing that external calendar components can affect when and how another component repeats. If I have the orignal VEVENT component, simply expanding its recurrence rules may yield a faulty expansion if another component contains the same UID, a RECURRENCE-ID and a different DTSTART/DTEND pair. At any rate, the statement was made as a final clarifying statement. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Mar 8 15:41: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 PAA02543 for ; Fri, 8 Mar 2002 15:41:31 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g28KWq608177 for ietf-calendar-bks; Fri, 8 Mar 2002 12:32: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 g28KWp808173 for ; Fri, 8 Mar 2002 12:32: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 PAA06453 for ; Fri, 8 Mar 2002 15:32:38 -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 g28KWbQ11997 for ; Fri, 8 Mar 2002 15:32:37 -0500 (EST) Message-ID: <09fe01c1c6e0$932983f0$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <1015618163.9992.26.camel@endspiel.ximian.com> Subject: Re: UID & RECURRENCE-ID Date: Fri, 8 Mar 2002 15:33:58 -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: "JP Rosevear" To: "John Stracke" Cc: Sent: Friday, March 08, 2002 3:09 PM Subject: Re: UID & RECURRENCE-ID > > On Fri, 2002-03-08 at 13:23, John Stracke wrote: > > > > >> Er? Can't you send out the REQUEST with the extra recurrence included? > > > > > >Yes, but you need to recognize that. > > > > Uh-huh. And in what way could a representation format for events (a) > > support repeating events with exceptions and (b) not require > > implementations to recognize repeating events with exceptions? > > The issue is not with recognizing that fact but with recognizing that > external calendar components can affect when and how another component > repeats. If I have the orignal VEVENT component, simply expanding its > recurrence rules may yield a faulty expansion if another component > contains the same UID, a RECURRENCE-ID and a different DTSTART/DTEND > pair. A calendar component cannot unilaterally lay claim to an existing UID using a RECURRENCE-ID. Components that use the RECURRENCE-ID property must be referenced by the original, either by being part of an RRULE or explicitly with an RDATE. The reason for having the extra component is not to add more dates; it is to describe in detail the other properties that are different from the original component (for example, SUMMARY, DESCRIPTION, ATTENDEEs, etc.). The only time a "subsidiary" calendar component has a DTSTART that is not referenced by the original component is when you're sending an iTIP message that says "I'm moving this component, originally scheduled at [RECURRENCE-ID], to be at [DTSTART]". The original and subsidiary calendar components must then be "updated" (I'll leave the semantics of that in terms of object storage aside) with the new date of the subsidiary. Graham From owner-ietf-calendar@mail.imc.org Fri Mar 8 16:13: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 QAA04345 for ; Fri, 8 Mar 2002 16:13:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28L4dE08747 for ietf-calendar-bks; Fri, 8 Mar 2002 13:04:39 -0800 (PST) Received: from localhost.localdomain ([24.157.64.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28L4b808743 for ; Fri, 8 Mar 2002 13:04:37 -0800 (PST) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g28L3Gk06687; Fri, 8 Mar 2002 16:03:16 -0500 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: UID & RECURRENCE-ID From: JP Rosevear To: Graham Gilmore Cc: ietf-calendar@imc.org In-Reply-To: <09fe01c1c6e0$932983f0$092e0165@in.steltor.com> References: <1015618163.9992.26.camel@endspiel.ximian.com> <09fe01c1c6e0$932983f0$092e0165@in.steltor.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 08 Mar 2002 16:03:16 -0500 Message-Id: <1015621396.6371.48.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-03-08 at 15:33, Graham Gilmore wrote: > > > ----- Original Message ----- > From: "JP Rosevear" > To: "John Stracke" > Cc: > Sent: Friday, March 08, 2002 3:09 PM > Subject: Re: UID & RECURRENCE-ID > > > > > > On Fri, 2002-03-08 at 13:23, John Stracke wrote: > > > > > > >> Er? Can't you send out the REQUEST with the extra recurrence > included? > > > > > > > >Yes, but you need to recognize that. > > > > > > Uh-huh. And in what way could a representation format for events (a) > > > support repeating events with exceptions and (b) not require > > > implementations to recognize repeating events with exceptions? > > > > The issue is not with recognizing that fact but with recognizing that > > external calendar components can affect when and how another component > > repeats. If I have the orignal VEVENT component, simply expanding its > > recurrence rules may yield a faulty expansion if another component > > contains the same UID, a RECURRENCE-ID and a different DTSTART/DTEND > > pair. > > A calendar component cannot unilaterally lay claim to an existing UID > using a RECURRENCE-ID. Components that use the RECURRENCE-ID property must > be referenced by the original, either by being part of an RRULE or > explicitly with an RDATE. The reason for having the extra component is not > to add more dates; it is to describe in detail the other properties that are > different from the original component (for example, SUMMARY, DESCRIPTION, > ATTENDEEs, etc.). I know it is not to have more dates. But it can have different dates, as you clearly state below, in some cases. Also, I haven't seen anything which states that only the differing properties should be listed in the component with the RECURRENCE-ID. > The only time a "subsidiary" calendar component has a DTSTART that is > not referenced by the original component is when you're sending an iTIP > message that says "I'm moving this component, originally scheduled at > [RECURRENCE-ID], to be at [DTSTART]". The original and subsidiary calendar > components must then be "updated" (I'll leave the semantics of that in terms > of object storage aside) with the new date of the subsidiary. Why does the original need to be updated in this particular case? -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Mar 8 17:22: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 RAA07673 for ; Fri, 8 Mar 2002 17:22:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28MA2709990 for ietf-calendar-bks; Fri, 8 Mar 2002 14:10:02 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28MA0809978 for ; Fri, 8 Mar 2002 14:10:00 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g28M9uXi021609 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Mar 2002 14:10:01 -0800 (PST) Message-ID: <3C8936AF.9030008@Royer.com> Date: Fri, 08 Mar 2002 15:09:51 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: UID & RECURRENCE-ID References: <1015618163.9992.26.camel@endspiel.ximian.com> <09fe01c1c6e0$932983f0$092e0165@in.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 Graham Glimmer wrote: > The only time a "subsidiary" calendar component has a DTSTART that is > not referenced by the original component is when you're sending an iTIP > message that says "I'm moving this component, originally scheduled at > [RECURRENCE-ID], to be at [DTSTART]". I am not sure of what you are saying. And I don't think that is correct. By "subsidiary" - you mean one that has the same UID but is not in the same component - correct? If so: A "subsidiary" calendar component can be 100% different (except UID) from the original component. It is the only way to add a new DTSTART value to an existing component and when the ADDed component has one or more other properties not in common (Such as SUMMARY). > The original and subsidiary calendar > components must then be "updated" (I'll leave the semantics of that in terms > of object storage aside) with the new date of the subsidiary. 'date' did you mean 'data'? If not: New 'date'? I don't follow your point. You can do a REQUEST with DTSTART and later ADD a new instance with a DTSTART where DTSTART != DTSTART. And you are NOT updating or moving any existing instance. The values in the original REQUEST can be completely unrelated to the contents in the ADD object - other than they are the same sequence of events with the same UID. From owner-ietf-calendar@mail.imc.org Fri Mar 8 17:29:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08011 for ; Fri, 8 Mar 2002 17:29:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28LkY909446 for ietf-calendar-bks; Fri, 8 Mar 2002 13:46: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 g28LkW809441 for ; Fri, 8 Mar 2002 13: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 QAA07999 for ; Fri, 8 Mar 2002 16:46:30 -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 g28LkTQ19772 for ; Fri, 8 Mar 2002 16:46:29 -0500 (EST) Message-ID: <0a2201c1c6ea$e4bccd30$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <1015618163.9992.26.camel@endspiel.ximian.com> <09fe01c1c6e0$932983f0$092e0165@in.steltor.com> <1015621396.6371.48.camel@endspiel.ximian.com> Subject: Re: UID & RECURRENCE-ID Date: Fri, 8 Mar 2002 16:47:50 -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 > On Fri, 2002-03-08 at 15:33, Graham Gilmore wrote: > > > > > > ----- Original Message ----- > > From: "JP Rosevear" > > To: "John Stracke" > > Cc: > > Sent: Friday, March 08, 2002 3:09 PM > > Subject: Re: UID & RECURRENCE-ID > > > > > > > > > > On Fri, 2002-03-08 at 13:23, John Stracke wrote: > > > > > > > > >> Er? Can't you send out the REQUEST with the extra recurrence > > included? > > > > > > > > > >Yes, but you need to recognize that. > > > > > > > > Uh-huh. And in what way could a representation format for events (a) > > > > support repeating events with exceptions and (b) not require > > > > implementations to recognize repeating events with exceptions? > > > > > > The issue is not with recognizing that fact but with recognizing that > > > external calendar components can affect when and how another component > > > repeats. If I have the orignal VEVENT component, simply expanding its > > > recurrence rules may yield a faulty expansion if another component > > > contains the same UID, a RECURRENCE-ID and a different DTSTART/DTEND > > > pair. > > > > A calendar component cannot unilaterally lay claim to an existing UID > > using a RECURRENCE-ID. Components that use the RECURRENCE-ID property must > > be referenced by the original, either by being part of an RRULE or > > explicitly with an RDATE. The reason for having the extra component is not > > to add more dates; it is to describe in detail the other properties that are > > different from the original component (for example, SUMMARY, DESCRIPTION, > > ATTENDEEs, etc.). > > I know it is not to have more dates. But it can have different dates, > as you clearly state below, in some cases. Also, I haven't seen > anything which states that only the differing properties should be > listed in the component with the RECURRENCE-ID. > > > The only time a "subsidiary" calendar component has a DTSTART that is > > not referenced by the original component is when you're sending an iTIP > > message that says "I'm moving this component, originally scheduled at > > [RECURRENCE-ID], to be at [DTSTART]". The original and subsidiary calendar > > components must then be "updated" (I'll leave the semantics of that in terms > > of object storage aside) with the new date of the subsidiary. > > Why does the original need to be updated in this particular case? > So that its list of dates (RRULE, EXRULE, etc.) remains in sync with the other components sharing the same UID. If you move an instance of a RRULE (as described), for example, from then on your component with the RRULE must reflect the changed date; one way that this can be done by using the EXDATE and RDATE properties to remove the old date and add the new one to the recurrence set. In this way, the "original" component (by which I don't mean the original state; but rather the "master" component) always keeps track of the dates of all of its subsidiary components. Otherwise, as you surmised, you could never *know* what all the dates would be without finding all the components that might have the same UID (leaving aside, of course, the possibility of outstanding unprocessed iTIP messages). Graham From owner-ietf-calendar@mail.imc.org Fri Mar 8 18:18: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 SAA10623 for ; Fri, 8 Mar 2002 18:18:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28N99G11587 for ietf-calendar-bks; Fri, 8 Mar 2002 15:09: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 g28N97811583 for ; Fri, 8 Mar 2002 15:09: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 SAA09285 for ; Fri, 8 Mar 2002 18:09:05 -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 g28N95Q28127 for ; Fri, 8 Mar 2002 18:09:05 -0500 (EST) Message-ID: <0a8601c1c6f6$6e8ea0a0$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <1015618163.9992.26.camel@endspiel.ximian.com> <09fe01c1c6e0$932983f0$092e0165@in.steltor.com> <3C8936AF.9030008@Royer.com> Subject: Re: UID & RECURRENCE-ID Date: Fri, 8 Mar 2002 18:10:26 -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: Friday, March 08, 2002 5:09 PM Subject: Re: UID & RECURRENCE-ID > > > > Graham [Gilmore] wrote: [Doug - your address book keeps putting 'Graham Glimmer'] > > The only time a "subsidiary" calendar component has a DTSTART that is > > not referenced by the original component is when you're sending an iTIP > > message that says "I'm moving this component, originally scheduled at > > [RECURRENCE-ID], to be at [DTSTART]". > > > I am not sure of what you are saying. And I don't think that is correct. > By "subsidiary" - you mean one that has the same UID but is not > in the same component - correct? If so: > > A "subsidiary" calendar component can be 100% different (except UID) from > the original component. It is the only way to add a new DTSTART value > to an existing component and when the ADDed component has one or more other > properties not in common (Such as SUMMARY). I'll try to explain what I'm saying before you correct something entirely different :) Yes, the subsidiary component can have completely different data. I'm simply saying RECURRENCE-ID must match a date in the "original" component's (this is a bad term; it implies that we're comparing a "before" and "after" view of the component, which is not the intention. I'll call it the "master" component) recurrence set (EXCEPT when the iCalendar is part of an iTIP message whose purpose is modifying those dates, like moving an instance of a recurring event, or as you suggest, doing an ADD. I tried to say/imply that I was considering only the calendaring data ("booked" data, in CAP terms, that is, a snapshot of the calendar), and not "in-flight" iTIP scheduling data, but I guess I failed). > > The [master] and subsidiary calendar > > components must then be "updated" (I'll leave the semantics of that in terms > > of object storage aside) with the new date of the subsidiary. > > 'date' did you mean 'data'? If not: > > New 'date'? I don't follow your point. You can do a REQUEST with DTSTART > and later ADD a new instance with a DTSTART where DTSTART != DTSTART. > And you are NOT updating or moving any existing instance. The values > in the original REQUEST can be completely unrelated to the contents in the > ADD object - other than they are the same sequence of events with the same UID. 'Date'. But the data store that is keeping track of the calendar data should update the calendar object that you're ADDing to, to reflect the ADD, after it is performed. Whether your data store interprets "update the component" as meaning "change the contents of the blob stored at address X to be Y" or "the most up-to-date version of this component is now at address Z instead of address W" is truly irrelevant. Conceptually, the CU's view of the data has been "updated", and when they export their "updated" data in iCalendar form, the "original" component's iCalendar representation should reference the newly added instance in its recurrence set. Graham From owner-ietf-calendar@mail.imc.org Fri Mar 8 20:37: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 UAA15067 for ; Fri, 8 Mar 2002 20:37:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g291Pk014072 for ietf-calendar-bks; Fri, 8 Mar 2002 17:25: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 g291Pi814067 for ; Fri, 8 Mar 2002 17:25:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g291PhXi022074 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 8 Mar 2002 17:25:47 -0800 (PST) Message-ID: <3C89648F.1060008@Royer.com> Date: Fri, 08 Mar 2002 18:25:35 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: UID & RECURRENCE-ID References: <1015618163.9992.26.camel@endspiel.ximian.com> <09fe01c1c6e0$932983f0$092e0165@in.steltor.com> <3C8936AF.9030008@Royer.com> <0a8601c1c6f6$6e8ea0a0$092e0165@in.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 Graham Gilmore wrote: > > > [Doug - your address book keeps putting 'Graham Glimmer'] Sorry! It must be the spell checker/fixer. I just added your last name to the dictionary - it is correct in my address book. Let me know if it does it again - I am using Netscape 6.2, we'll get Steve to fix it :-) > Yes, ... :-) Yes now I understand your point. Thanks. From owner-ietf-calendar@mail.imc.org Mon Mar 11 14: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 OAA19387 for ; Mon, 11 Mar 2002 14:02:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2BIkID21402 for ietf-calendar-bks; Mon, 11 Mar 2002 10:46:18 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BIkG821398 for ; Mon, 11 Mar 2002 10:46:17 -0800 (PST) To: JP Rosevear Cc: ietf-calendar@imc.org Subject: Re: UID & RECURRENCE-ID MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03032002 March 03, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 11 Mar 2002 13:46:13 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_03042002|March 04, 2002) at 03/11/2002 01:41:08 PM, Serialize complete at 03/11/2002 01:41:08 PM Content-Type: multipart/alternative; boundary="=_alternative 0067082085256B79_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067082085256B79_= Content-Type: text/plain; charset="US-ASCII" JP wrote: > If you create a new component, a new UID will be >created, removing any possibility of the organizer sending future >changes. Playing catchup on the thread here... By "create a new component" it sounds like "create a new VEVENT". If thats true then clearly a new UID is called for. However, I suspect you meant you "add a new instance to a repeat set" (ie: the METHOD:ADD of iTIP) or even make it a repeating instance from a singleton . This is not a problem since the UID for this scenario belongs to the 'set' rather than to 1 single instance of the set. This is fully described in the 2nd full paragraph on p112. In reading Dougs suggested text I could mistakenly think that each instance of a repeating entity (ie: a repeating VEVENT) has a separate UID and I know he was not proposing that. Otherwise changes to repeating entries is doomed to a chaotic death. Besides we already specificly address the components in the Conformance section of Section 4.8.4.7 Unique Identifier. > If a separate component is created with the same UID and >containing the given RECURRENCE-ID, it would seem to violate the the UID >spec If you were talking about adding, say, a new VTODO with the same UID as an existing VEVENT then thats bad! We never intended to have separate UID spaces for each component type! This is more error prone than having a 'unified UID space' (or some such phrase Frank used to have). It may be possible for 2 CUAs to accidentally generate the same UID for different components but if the recommendations in Section 4.8.4.7 Unique Identifier are followed (see the Description in Section 4.8.4.7 Unique Identifier). I dont know of any text we created to deal with the "What if there is a mismatch between component types w/the same UID?" or "Can a component be changed and reuse the UID?" cases (ie: You turn a VTODO into a VEVENT and reuse the UID). Were you looking for something along those lines?? 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 0067082085256B79_= Content-Type: text/html; charset="US-ASCII"
JP wrote:
>                  If you create a new component, a new UID will be
>created, removing any possibility of the organizer sending future
>changes.

Playing catchup on the thread here...

By "create a new component" it sounds like "create a new VEVENT".  If thats true then clearly a new UID is called for.  However, I suspect you meant you "add a new instance to a repeat set"  (ie: the METHOD:ADD of iTIP) or even make it a repeating instance from a singleton .  This is not a problem since the UID for this scenario belongs to the 'set' rather than to 1 single instance of the set.  This is fully described in the 2nd full paragraph on p112.

In reading Dougs suggested text I could mistakenly think that each instance of a repeating entity (ie: a repeating VEVENT) has a separate UID and I know he was not proposing that.  Otherwise changes to repeating entries is doomed to a chaotic death.   Besides we already specificly address the components in the Conformance section of Section 4.8.4.7 Unique Identifier.

>                If a separate component is created with the same UID and
>containing the given RECURRENCE-ID, it would seem to violate the the UID
>spec

If you were talking about adding, say, a new VTODO with the same UID as an existing VEVENT then thats bad!  We never intended to have separate UID spaces for each component type!  This is more error prone than having a 'unified UID space' (or some such phrase Frank used to have).  It may be possible for 2 CUAs to accidentally generate the same UID for different components but if the recommendations in Section 4.8.4.7 Unique Identifier are followed (see the Description in Section 4.8.4.7 Unique Identifier).

I dont know of any text we created to deal with the "What if there is a mismatch between component types w/the same UID?" or "Can a component be changed and reuse the UID?" cases (ie: You turn a VTODO into a VEVENT and reuse the UID).  Were you looking for something along those lines??

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 0067082085256B79_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 12 08:50: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 IAA21632 for ; Tue, 12 Mar 2002 08:50:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CDSRh28737 for ietf-calendar-bks; Tue, 12 Mar 2002 05:28: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 g2CDSP428732 for ; Tue, 12 Mar 2002 05:28: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 IAA08596 for ; Tue, 12 Mar 2002 08:28:20 -0500 Received: from c2767 ([101.1.46.19]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CDSKQ04592 for ; Tue, 12 Mar 2002 08:28:20 -0500 (EST) From: "ericp" To: Subject: vQuery LIKE question Date: Tue, 12 Mar 2002 08:26:48 -0500 Message-ID: <001e01c1c9c9$90087f50$132e0165@in.steltor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2CDSQ428733 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Good Morning, I've been going over Draft 7 of the CAP specification, specifically the new LIKE clause. Where performing comparisons on a text property (for example DESCRIPTION or LOCATION), the draft indicates the LIKE comparisons are to be case insensitive. SELECT * FROM VEVENT WHERE LOCATION LIKE 'a%' Would or should the comparison return a match if there is an accented version of the character (i.e. à á â ã ä å)? Or would the vQuery have to specify all cases with an OR SELECT * FROM VEVENT WHERE LOCATION LIKE 'a%' OR LOCATION LIKE 'à%' OR LOCATION LIKE 'á%' ...etc... Thanks, Eric ------------------------------- Eric R. Plamondon Steltor - Chief Web Architect 2000 Peel Street, 4th Floor Montreal, Quebec mailto:ericp@steltor.com http://www.steltor.com From owner-ietf-calendar@mail.imc.org Tue Mar 12 13:29:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00189 for ; Tue, 12 Mar 2002 13:29:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2CI4eZ17299 for ietf-calendar-bks; Tue, 12 Mar 2002 10:04: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 g2CI4d417295 for ; Tue, 12 Mar 2002 10:04:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2CI4ZnB009638 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Mar 2002 10:04:40 -0800 (PST) Message-ID: <3C8E432F.3010009@Royer.com> Date: Tue, 12 Mar 2002 11:04:31 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: ietf-calendar@imc.org Subject: Re: vQuery LIKE question References: <001e01c1c9c9$90087f50$132e0165@in.steltor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2CI4d417296 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > Would or should the comparison return a match > if there is an accented version of the character > (i.e. à á â ã ä å)? > > Or would the vQuery have to specify all cases > with an OR > > SELECT * FROM VEVENT > WHERE LOCATION LIKE 'a%' > OR LOCATION LIKE 'à%' > OR LOCATION LIKE 'á%' > ...etc... I would think that 'a' would not match any of à á â ã ä or å. As we modeled it after the SQL LIKE. It should do the same. I am also not sure that those can be assumed to mean that they are simply accented versions of the character in all languages. But I am not an expert on languages. From owner-ietf-calendar@mail.imc.org Tue Mar 12 13: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 NAA00547 for ; Tue, 12 Mar 2002 13:36:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CILFH18160 for ietf-calendar-bks; Tue, 12 Mar 2002 10:21:15 -0800 (PST) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CILD418156 for ; Tue, 12 Mar 2002 10:21:13 -0800 (PST) To: ietf-calendar@imc.org Subject: Interop - not scheduled MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 12 Mar 2002 13:21:13 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 03/12/2002 01:21:16 PM, Serialize complete at 03/12/2002 01:21:16 PM Content-Type: multipart/alternative; boundary="=_alternative 0064D23485256B7A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064D23485256B7A_= Content-Type: text/plain; charset="us-ascii" Because of travel restrictions and software schedules, we will not hold the March 28-29 interop testing. We will reschedule it for later in the year (working on when at the moment). Novell has stated they would still like to host the event, so we will plan for it to be in Provo, Utah when we settle on the date. In the mean time, so we don't delay this process, I am putting together a "virtual interop" session and more news will be available after the Minneapolis meeting. Stay tuned for information. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0064D23485256B7A_= Content-Type: text/html; charset="us-ascii"
Because of travel restrictions and software schedules, we will not hold the March 28-29 interop testing.  We will reschedule it for later in the year (working on when at the moment).  Novell has stated they would still like to host the event, so we will plan for it to be in Provo, Utah when we settle on the date.

In the mean time, so we don't delay this process, I am putting together a "virtual interop" session and more news will be available after the Minneapolis meeting.  Stay tuned for information.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0064D23485256B7A_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 12 13:40: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 NAA00791 for ; Tue, 12 Mar 2002 13:40:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CIJdE18086 for ietf-calendar-bks; Tue, 12 Mar 2002 10:19: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 g2CIJb418080 for ; Tue, 12 Mar 2002 10:19:37 -0800 (PST) To: ietf-calendar@imc.org Subject: Minneapolis Dinner MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 12 Mar 2002 13:19:28 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 03/12/2002 01:19:40 PM, Serialize complete at 03/12/2002 01:19:40 PM Content-Type: multipart/alternative; boundary="=_alternative 0064A8F085256B7A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064A8F085256B7A_= Content-Type: text/plain; charset="us-ascii" We are changing from the norm of dinner on Monday night to meeting for dinner on Tuesday. We will meet at 7:00 in the lobby of the Hilton. There will be several of us onsite in Minneapolis, so if you are there on Monday, look for one of the members. I believe there will be takers for dinner. See you in Minneapolis --=_alternative 0064A8F085256B7A_= Content-Type: text/html; charset="us-ascii"
We are changing from the norm of dinner on Monday night to meeting for dinner on Tuesday.  We will meet at 7:00 in the lobby of the Hilton.

There will be several of us onsite in Minneapolis, so if you are there on Monday, look for one of the members.  I believe there will be takers for dinner.  

See you in Minneapolis
 --=_alternative 0064A8F085256B7A_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 12 13:53: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 NAA01393 for ; Tue, 12 Mar 2002 13:53:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CIYIn18690 for ietf-calendar-bks; Tue, 12 Mar 2002 10:34:18 -0800 (PST) Received: from office2.jigzaw.com ([216.248.40.78]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CIYH418683 for ; Tue, 12 Mar 2002 10:34:17 -0800 (PST) Received: from colatz ([10.0.0.10]) by office2.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA10150 for ; Tue, 12 Mar 2002 12:32:12 -0600 From: "Shannon J. Clark" To: Subject: RE: vQuery LIKE question Date: Tue, 12 Mar 2002 12:34:43 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3C8E432F.3010009@Royer.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think that this is something to look at in terms of internationalization wit two parts of the SQL stuff that comes to mind. one - the issue of LIKE that has been raised (are accented characters "like" their non-accented versions?) and two - any instance where we might use a SORT - ideally the sort should then be doable in the locale in question Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Tuesday, March 12, 2002 12:05 PM Cc: ietf-calendar@imc.org Subject: Re: vQuery LIKE question > > Would or should the comparison return a match > if there is an accented version of the character > (i.e. à á â ã ä å)? > > Or would the vQuery have to specify all cases > with an OR > > SELECT * FROM VEVENT > WHERE LOCATION LIKE 'a%' > OR LOCATION LIKE 'à%' > OR LOCATION LIKE 'á%' > ...etc... I would think that 'a' would not match any of à á â ã ä or å. As we modeled it after the SQL LIKE. It should do the same. I am also not sure that those can be assumed to mean that they are simply accented versions of the character in all languages. But I am not an expert on languages. From owner-ietf-calendar@mail.imc.org Tue Mar 12 14:15: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 OAA02170 for ; Tue, 12 Mar 2002 14:14:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CIrb219726 for ietf-calendar-bks; Tue, 12 Mar 2002 10:53:37 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CIra419719 for ; Tue, 12 Mar 2002 10:53:36 -0800 (PST) To: "ietf-calendar@imc.org" Subject: Re: vQuery LIKE question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 12 Mar 2002 14:03:04 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/12/2002 02:03:15 PM, Serialize complete at 03/12/2002 02:03:15 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 g2CIra419721 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit >I would think that 'a' would not match any of à á â ã ä or å. >As we modeled it after the SQL LIKE. It should do the same. I don't know that that follows. SQL doesn't really handle Unicode, for example; but CAP needs to. >I am also not sure that those can be assumed to mean that they >are simply accented versions of the character in all languages. It might be that whether it matches should depend on the locale. On the other hand, it might be that we should match strictly, on the theory that then a CUA has a more precise building block to work with. If I'm using a language that has, say, "foo" and "föö", and they're completely different words, then maybe I want to be able to search for "LIKE 'foo%'" and not get strings starting with "föö". If I want both, I can always OR them. That puts the locale awareness in the CUA, where it belongs. So...yeah, I think we should specify an exact character match for now; if we need something more powerful later, we can add an extension. (It might not need locale-aware matches, either; it might be that full regexp support would be enough.) /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Unless. -- The Lorax | \========================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 12 16:27: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 QAA08416 for ; Tue, 12 Mar 2002 16:27:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2CLBsC26544 for ietf-calendar-bks; Tue, 12 Mar 2002 13:11: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 g2CLBr426531 for ; Tue, 12 Mar 2002 13:11:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2CLBgnB012540 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Mar 2002 13:11:54 -0800 (PST) Message-ID: <3C8E6EDB.6090100@Royer.com> Date: Tue, 12 Mar 2002 14:10:51 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: vQuery LIKE question References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2CLBs426536 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit John Stracke wrote: >>I would think that 'a' would not match any of à á â ã ä or å. >>As we modeled it after the SQL LIKE. It should do the same. >> > > I don't know that that follows. SQL doesn't really handle Unicode, for > example; but CAP needs to. SQL-92 can handle 8-bit charsets and various locales. In fact it has a very extensive description of charset issues. Newer versions have more support. SQL-92: CHARACTER_SETS, CHARACTER_SETS_CHECK_REFERANCE_COLLATIONS, CHARACTER_SETS_DEFAULT_COLATE, CHARACTER_SETS_DEFAULT_COLLATENAME_NOT_NULL, CHARACTER_SETS_DEFAULT_COLLATE_SCHEMA_NOT_NULL, CHARACTER_SETS_FORGEIGN_KEY_SCHEMA, CHARACTER_SET_CATALOG,CHARACTER_SET_NAME, CHARACTER_SET_SCHEMA, DEFAULT_COLLATE_CATALOG, DEFAULT ..... Some implementations do not support locals - get a new SQL supplier. > >>I am also not sure that those can be assumed to mean that they >>are simply accented versions of the character in all languages. >> > > It might be that whether it matches should depend on the locale. > > On the other hand, it might be that we should match strictly, on the > theory that then a CUA has a more precise building block to work with. We should always match on the LOCALE settings. If the LC_COLLATE setting in the locale definition match, then we match. It's really out of scope for CAP to specify the details. We just need to say that the results depend on the LOCALE (not charset). I had posted a proposal for a CS to advertise its locals as a MUST. Where BEEP says that it is a MAY. I think that that simply means that we MAY say it is a MUST :-) Then if we were to add (later) the 2nd part of my proposal which allows a CUA to specify the locale for the query, restricted to the set supplied by the CS at greeting time; then the CU will get the set they would expect to get. From owner-ietf-calendar@mail.imc.org Wed Mar 13 13:01: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 NAA13235 for ; Wed, 13 Mar 2002 13:01:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2DHjA012387 for ietf-calendar-bks; Wed, 13 Mar 2002 09:45: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 g2DHj9412381 for ; Wed, 13 Mar 2002 09:45:09 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2DHj5nB000046 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Mar 2002 09:45:10 -0800 (PST) Message-ID: <3C8F901E.5050905@Royer.com> Date: Wed, 13 Mar 2002 10:45:02 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: BEEP and CAP - one-to-many 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 As CAP can not mandate the BEEP payload boundaries, this needs to be deleted from CAP-07: > 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 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. From owner-ietf-calendar@mail.imc.org Wed Mar 13 14: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 OAA16167 for ; Wed, 13 Mar 2002 14:32:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2DJCui17405 for ietf-calendar-bks; Wed, 13 Mar 2002 11:12: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 g2DJCs417401 for ; Wed, 13 Mar 2002 11:12:55 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2DJCpnB001303 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Mar 2002 11:12:55 -0800 (PST) Message-ID: <3C8FA4AF.9030303@Royer.com> Date: Wed, 13 Mar 2002 12:12:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: New 'CALENDAR' properties 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 updated the calendar section of CAP to reflect the WG discussions. This will be in the 08 verion of CAP (I also added the Occurs) collumn: Name Read Occurs Value Description Only Type ------------------------------------------------------------------- ALLOW-CONFLICT N 0 or 1 BOOLEAN This boolean value indicates Whether or not the calendar supports event conflicts. That is, whether or not any of the events in the calendar can overlap. If not supplied the default value is TRUE meaning that conflicts are allowed. CALSCALE N 0 or 1 TEXT The CALSCALE for this calendar. If not supplied the default is GREGORIAN. CHARSET N 0 or 1 TEXT The default charset for Localized strings in this calendar. If not supplied, the default is UTF-8. CREATED Y 1 DATE-TIME The timestamp of the calendar's create date. LANGUAGE N 1 TEXT The default language for localizable strings in this calendar. The possible values of this property are those specified in RFC-3066. ("en_US" for example). LAST-MODIFIED Y 1 DATE-TIME The timestamp when the Properties of the calendar were last updated. METHOD N 1 TEXT MUST BE "CREATE" or "DELETE". NAME N 0+ TEXT Optional display name for this calendar. It is a localizable string. May be multiple instance and no two instances may have the same LANG paramater. OWNER N 1+ URI A multi-instanced property indicating the calendar owner. Each entry returned will be a UPN. There must be at least one owner. RELATED-TO N 0+ TEXT An optional multi-instance property indicating any relationship to other CALIDs. RELCALID N 1 URI A unique identifier within this cal-store for the calendar. TZID N 0 or 1 TEXT The id of the timezone Associated with this calendar. See TZID in [RFC2445]. The default value is UTC. From owner-ietf-calendar@mail.imc.org Wed Mar 13 15:29: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 PAA18254 for ; Wed, 13 Mar 2002 15:29:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2DKB9818836 for ietf-calendar-bks; Wed, 13 Mar 2002 12:11: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 g2DKB7418832 for ; Wed, 13 Mar 2002 12:11: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 PAA07107 for ; Wed, 13 Mar 2002 15:11:04 -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 g2DKB3Q19311 for ; Wed, 13 Mar 2002 15:11:03 -0500 (EST) Subject: Re: BEEP and CAP - one-to-many From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C8F901E.5050905@Royer.com> References: <3C8F901E.5050905@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Mar 2002 15:17:42 -0500 Message-Id: <1016050662.1325.11.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-03-13 at 12:45, Doug Royer wrote: > > > As CAP can not mandate the BEEP payload boundaries, this needs to > be deleted from CAP-07: I don't understand, the section does not specify how messages may be partitioned into multiple frames (this is clearly handled internally and is dependent on the transport service). The section simply states when one-to-many exchanges are to be used (e.g., in our case when a command refers to more than one target). ASAIK a profile must indicate what exchange style is to be used. Section 5.1 of RFC3080 (Profile Registration Template) does have distinct sections for one-to-one exchanges and one-to-many exchanges. > > > 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 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. > > > From owner-ietf-calendar@mail.imc.org Wed Mar 13 16:55: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 QAA21120 for ; Wed, 13 Mar 2002 16:55:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2DLhD021032 for ietf-calendar-bks; Wed, 13 Mar 2002 13:43: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 g2DLhC421028 for ; Wed, 13 Mar 2002 13:43:12 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2DLh7nB003750 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Mar 2002 13:43:13 -0800 (PST) Message-ID: <3C8FC7E5.6090200@Royer.com> Date: Wed, 13 Mar 2002 14:43:01 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: BEEP and CAP - one-to-many References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.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 Patrice Lapierre wrote: > On Wed, 2002-03-13 at 12:45, Doug Royer wrote: > >> >>As CAP can not mandate the BEEP payload boundaries, this needs to >>be deleted from CAP-07: >> > The section simply states when one-to-many exchanges are to be > used (e.g., in our case when a command refers to more than one > target). I can't speak to the BEEP profile. But according to RFC3081, BEEP on a TCP connection selects the window sizes, and thus the MSG or ANS/NUL replies when a MSG does not fit in a TCP window. It makes no difference to the CUA or CS. They just process iCalendar objects - however it might get them from BEEP, iMIP, or any iTIP object. If I give BEEP a 10M iCalendar object, that is all I can do. BEEP decides if it is going to use MSG or ANS/NUL - not CAP Plus, it is not a true statement. Some of the commands return multiple targets with one iCalendar object result. We say you can do that, but only when all of the METHODs are the same. The only time there has to be multiple iCalendar objects is when the METHOD changes. iTIP allows that, so CAP MUST allow that. From owner-ietf-calendar@mail.imc.org Wed Mar 13 17:31: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 RAA22359 for ; Wed, 13 Mar 2002 17:31:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2DML2t22048 for ietf-calendar-bks; Wed, 13 Mar 2002 14:21: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 g2DML0422041 for ; Wed, 13 Mar 2002 14:21: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 RAA10537 for ; Wed, 13 Mar 2002 17:20:57 -0500 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DMKvQ04759 for ; Wed, 13 Mar 2002 17:20:57 -0500 (EST) Subject: Re: BEEP and CAP - one-to-many From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C8FC7E5.6090200@Royer.com> References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com> <3C8FC7E5.6090200@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 13 Mar 2002 17:27:35 -0500 Message-Id: <1016058455.1323.24.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-03-13 at 16:43, Doug Royer wrote: > > > I can't speak to the BEEP profile. But according to RFC3081, BEEP > on a TCP connection selects the window sizes, and thus the > MSG or ANS/NUL replies when a MSG does not fit in a TCP window. > I think that you are confusing the concept of frames and with different ANS. Suppose the server wants to return a 10M iCalendar object, the message may indeed be divided as follows: RPY 1 23 * seq1 size1 Part 1 of the 10M object END RPY 1 23 * seq2 size2 Part 2 of the 10M object END ... RPY 1 23 . seqn sizen Last part of the 10M object END All message types can be divided, that is the purpose of the '.' or '*' in the header. The use of ANS/NUL vs RPY has nothing to do with the window size. From owner-ietf-calendar@mail.imc.org Wed Mar 13 17:47:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22957 for ; Wed, 13 Mar 2002 17:47:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2DMZKL22320 for ietf-calendar-bks; Wed, 13 Mar 2002 14:35:20 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2DMZJ422315 for ; Wed, 13 Mar 2002 14:35:19 -0800 (PST) Received: from kalia (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g2DMLY512009; Wed, 13 Mar 2002 14:21:34 -0800 (PST) Date: Wed, 13 Mar 2002 14:34:43 -0800 From: Marshall Rose To: "ietf-calendar@imc.org" Cc: Doug@royer.com Subject: Re: BEEP and CAP - one-to-many Message-Id: <20020313143443.20e9c6dd.mrose@dbc.mtview.ca.us> In-Reply-To: <3C8FC7E5.6090200@Royer.com> References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com> <3C8FC7E5.6090200@Royer.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I can't speak to the BEEP profile. But according to RFC3081, BEEP > on a TCP connection selects the window sizes, and thus the > MSG or ANS/NUL replies when a MSG does not fit in a TCP window. > > It makes no difference to the CUA or CS. They just process > iCalendar objects - however it might get them from BEEP, iMIP, > or any iTIP object. If I give BEEP a 10M iCalendar object, that > is all I can do. BEEP decides if it is going to use MSG or > ANS/NUL - not CAP you are confusing "one-to-one" and "one-to-many" which are exchange styles with segmentation that deals with whether a message (MSG, RPY, ERR, ANS, NUL) is sent as one frame or many frames. MSG, RPY, ERR, ANS and NUL may be segmented into multiple frames. depending on the API you use, this may be done transparently or explicitly. however, segmentation has nothing to do with one-to-one or one-to-many exchanges. absolutely nothing. the choice of whether an exchange is one-to-one or one-to-many is up to the profile specification. BEEP doesn't care about how large the MSG, RPY,ERR, or ANS is. it will segment as needed. /mtr From owner-ietf-calendar@mail.imc.org Wed Mar 13 18:02: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 SAA23688 for ; Wed, 13 Mar 2002 18:02:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2DMqj722700 for ietf-calendar-bks; Wed, 13 Mar 2002 14:52:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2DMqi422696 for ; Wed, 13 Mar 2002 14:52:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2DMqfnB004826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Mar 2002 14:52:46 -0800 (PST) Message-ID: <3C8FD833.1030201@Royer.com> Date: Wed, 13 Mar 2002 15:52:35 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: "ietf-calendar@imc.org" Subject: Re: BEEP and CAP - one-to-many References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com> <3C8FC7E5.6090200@Royer.com> <20020313143443.20e9c6dd.mrose@dbc.mtview.ca.us> 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 Marshall Rose wrote: >>I can't speak to the BEEP profile. But according to RFC3081, BEEP >>on a TCP connection selects the window sizes, and thus the >>MSG or ANS/NUL replies when a MSG does not fit in a TCP window. >> >>It makes no difference to the CUA or CS. They just process >>iCalendar objects - however it might get them from BEEP, iMIP, >>or any iTIP object. If I give BEEP a 10M iCalendar object, that >>is all I can do. BEEP decides if it is going to use MSG or >>ANS/NUL - not CAP >> > > you are confusing "one-to-one" and "one-to-many" which are exchange > styles with segmentation that deals with whether a message > (MSG, RPY, ERR, ANS, NUL) is sent as one frame or many frames. So are you saying that if I send a HUGE attachment, that CAP can mandate that it only send a single MSG that exceed the window size? That is what CAP says, as I quoted in my original message that started this thread. > MSG, RPY, ERR, ANS and NUL may be segmented into multiple frames. > depending on the API you use, this may be done transparently or explicitly. > however, segmentation has nothing to do with one-to-one or one-to-many > exchanges. absolutely nothing. The text in CAP says that CAP decides if it is going to be MSG or ANS/NUL. Are you saying that CAP can say that no matter what the payload size, that you MUST send the data in on MSG? You sent email on this before and only said "it is obvious", perhaps you can be explicit this time - thanks. From owner-ietf-calendar@mail.imc.org Wed Mar 13 18:05: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 SAA23798 for ; Wed, 13 Mar 2002 18:05:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2DMuOl22782 for ietf-calendar-bks; Wed, 13 Mar 2002 14:56: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 g2DMuN422778 for ; Wed, 13 Mar 2002 14:56:23 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2DMuLnB004877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Mar 2002 14:56:25 -0800 (PST) Message-ID: <3C8FD90E.8020807@Royer.com> Date: Wed, 13 Mar 2002 15:56:14 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: "ietf-calendar@imc.org i" Subject: Re: BEEP and CAP - one-to-many References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com> <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.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 Patrice Lapierre wrote: > ... > > All message types can be divided, that is the purpose of > the '.' or '*' in the header. The use of ANS/NUL vs RPY > has nothing to do with the window size. Yes, perhaps I am confused with RPY. However we still can't limit iCalendar objects as separate just because of BEEP when iTIP allows them, so the section needs to be deleted and each section can specify any limit it needs. The only iTIP limit is when the METHOD changes. From owner-ietf-calendar@mail.imc.org Wed Mar 13 19:23: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 TAA25602 for ; Wed, 13 Mar 2002 19:23:58 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2E0Cnj24956 for ietf-calendar-bks; Wed, 13 Mar 2002 16:12:49 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2E0Cl424948 for ; Wed, 13 Mar 2002 16:12:47 -0800 (PST) Received: from kalia (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g2DNx2512281; Wed, 13 Mar 2002 15:59:02 -0800 (PST) Date: Wed, 13 Mar 2002 16:11:38 -0800 From: Marshall Rose To: "ietf-calendar@imc.org" Cc: Doug@royer.com Subject: Re: BEEP and CAP - one-to-many Message-Id: <20020313161138.4dfe2c79.mrose@dbc.mtview.ca.us> In-Reply-To: <3C8FD833.1030201@Royer.com> References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com> <3C8FC7E5.6090200@Royer.com> <20020313143443.20e9c6dd.mrose@dbc.mtview.ca.us> <3C8FD833.1030201@Royer.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > So are you saying that if I send a HUGE attachment, that > CAP can mandate that it only send a single MSG that exceed the > window size? That is what CAP says, as I quoted in my original > message that started this thread. yes. it doesn't matter how large it is. it will get segmented as needed. > The text in CAP says that CAP decides if it is going to be MSG or ANS/NUL. > Are you saying that CAP can say that no matter what the payload size, > that you MUST send the data in on MSG? > > You sent email on this before and only said "it is obvious", perhaps > you can be explicit this time - thanks. first, what you say "MSG or ANS/NUL" makes no sense. presumably, you meant to say "RPY or ANS/NUL". second, CAP can send a reply as either a RPY or (zero or more ANSs followed by NUL). the RPY and the ANS can be any size. the choice between RPY and ANS is about partial results, not payload size. /mtr From owner-ietf-calendar@mail.imc.org Thu Mar 14 09:32: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 JAA17732 for ; Thu, 14 Mar 2002 09:32:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2EELTG04525 for ietf-calendar-bks; Thu, 14 Mar 2002 06:21:29 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2EELR404517 for ; Thu, 14 Mar 2002 06:21: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 JAA18102 for ; Thu, 14 Mar 2002 09:21:23 -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 g2EELNQ26210 for ; Thu, 14 Mar 2002 09:21:23 -0500 (EST) Subject: Re: BEEP and CAP - one-to-many From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C8FD90E.8020807@Royer.com> References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.steltor.com> <3C8FD90E.8020807@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Mar 2002 09:27:59 -0500 Message-Id: <1016116079.1325.88.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-03-13 at 17:56, Doug Royer wrote: > > Yes, perhaps I am confused with RPY. > > However we still can't limit iCalendar objects as separate > just because of BEEP when iTIP allows them, so the section > needs to be deleted and each section can specify any limit > it needs. The only iTIP limit is when the METHOD changes. > Sorry, I don't understand your point. What do you mean by limit iCalendar objects as separate? Can you provide a concrete example that demonstrates how CAP breaks iTIP? From owner-ietf-calendar@mail.imc.org Thu Mar 14 12:54:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23947 for ; Thu, 14 Mar 2002 12:54:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2EHgls16473 for ietf-calendar-bks; Thu, 14 Mar 2002 09:42: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 g2EHgk416466 for ; Thu, 14 Mar 2002 09:42:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2EHggnB020783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Mar 2002 09:42:46 -0800 (PST) Message-ID: <3C90E10F.2040208@Royer.com> Date: Thu, 14 Mar 2002 10:42:39 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: BEEP and CAP - one-to-many References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.steltor.com> <3C8FD90E.8020807@Royer.com> <1016116079.1325.88.camel@c-1241.in.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 Patrice Lapierre wrote: > On Wed, 2002-03-13 at 17:56, Doug Royer wrote: > >>Yes, perhaps I am confused with RPY. >> >>However we still can't limit iCalendar objects as separate >>just because of BEEP when iTIP allows them, so the section >>needs to be deleted and each section can specify any limit >>it needs. The only iTIP limit is when the METHOD changes. >> >> > > Sorry, I don't understand your point. What do you mean by > limit iCalendar objects as separate? Can you provide a > concrete example that demonstrates how CAP breaks iTIP? What is the technical reason for adding this restriction to iCalendar objects? If I can iMIP an object with multipart/related, why can't I use CAP to transport it? From owner-ietf-calendar@mail.imc.org Thu Mar 14 13:45: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 NAA25443 for ; Thu, 14 Mar 2002 13:45:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2EIWeh18247 for ietf-calendar-bks; Thu, 14 Mar 2002 10:32: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 g2EIWc418243 for ; Thu, 14 Mar 2002 10:32: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 NAA25189 for ; Thu, 14 Mar 2002 13:32:35 -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 g2EIWPQ26152 for ; Thu, 14 Mar 2002 13:32:25 -0500 (EST) Subject: Re: BEEP and CAP - one-to-many From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C90E10F.2040208@Royer.com> References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.steltor.co m> <3C8FD90E.8020807@Royer.com> <1016116079.1325.88.camel@c-1241.in.steltor.com> <3C90E10F.2040208@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Mar 2002 13:31:27 -0500 Message-Id: <1016130687.1282.43.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thu, 2002-03-14 at 12:42, Doug Royer wrote: > > Sorry, I don't understand your point. What do you mean by > > limit iCalendar objects as separate? Can you provide a > > concrete example that demonstrates how CAP breaks iTIP? > > > What is the technical reason for adding this restriction to iCalendar > objects? A difference between a single RPY and ANS,ANS,...ANS/NUL is that partial results (several ANS) can be send "simultaneously". An implementation could take advantage of this as follows: when performing a search command on n TARGETs, several searches could be started parallel and the results of each individual target can be returned as they become available (i.e., no need to queue all of them). > If I can iMIP an object with multipart/related, why can't > I use CAP to transport it? You CAN! There is nothing in section 3.1 that prevents you from transporting a multipart/related object with CAP. From owner-ietf-calendar@mail.imc.org Thu Mar 14 14:18:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26722 for ; Thu, 14 Mar 2002 14:18:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2EJ3qo19741 for ietf-calendar-bks; Thu, 14 Mar 2002 11:03:52 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2EJ3p419734 for ; Thu, 14 Mar 2002 11:03:51 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: BEEP and CAP - one-to-many MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 14 Mar 2002 14:12:59 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/14/2002 02:13:37 PM, Serialize complete at 03/14/2002 02:13:37 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > An implementation could take advantage of this as follows: >when performing a search command on n TARGETs, several searches >could be started parallel and the results of each individual >target can be returned as they become available (i.e., no need >to queue all of them). That does sound useful. Does it add extra complexity on the CUA? If so, there could be a problem: a CUA that was developed only against a CS that doesn't send ANS might not bother to cope with ANS; it would then choke when run against a CS that did send ANS. If the first generation of CSes only send RPY, then it could be a problem waiting. But, if it doesn't add too much complexity on the CUA, then it'd be worth calling out in the spec that CUA implementors need to cope with it. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |Using strong crypto on the Internet is like using an armored car| |to transport money from someone living in a tent to someone | |living in a cardboard box. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 14 15:04: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 PAA28723 for ; Thu, 14 Mar 2002 15:04:23 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2EJsxW22547 for ietf-calendar-bks; Thu, 14 Mar 2002 11:54: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 g2EJsv422543 for ; Thu, 14 Mar 2002 11:54: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 OAA27712 for ; Thu, 14 Mar 2002 14:54:54 -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 g2EJsrQ06793 for ; Thu, 14 Mar 2002 14:54:53 -0500 (EST) Subject: Re: BEEP and CAP - one-to-many From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Mar 2002 14:53:55 -0500 Message-Id: <1016135635.1282.153.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thu, 2002-03-14 at 14:12, John Stracke wrote: ... > > That does sound useful. Does it add extra complexity on the CUA? On the CUA side, it's very straight forward to implement. All the required information is included in the BEEP header. When a CUA receives the frames from a response to a one-to-many exchange (i.e., a set of ANS with distinct ansnos, terminated by a NUL). For each frame: 1. If the type is NUL, then were are done. 2. If the type is ANS, then: - the ansno indicates to which partial (TARGET specific) result the payload should be added. - the '.' or '*' indicates if more frames are to be expected for this partial result. From owner-ietf-calendar@mail.imc.org Thu Mar 14 15:57: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 PAA00592 for ; Thu, 14 Mar 2002 15:57:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2EKlGV23691 for ietf-calendar-bks; Thu, 14 Mar 2002 12:47:16 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2EKlE423687 for ; Thu, 14 Mar 2002 12:47:14 -0800 (PST) To: ietf-calendar@imc.org Subject: Dinner in Minneapolis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 14 Mar 2002 15:46:56 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 03/14/2002 03:47:17 PM, Serialize complete at 03/14/2002 03:47:17 PM Content-Type: multipart/alternative; boundary="=_alternative 0072296E85256B7C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072296E85256B7C_= Content-Type: text/plain; charset="us-ascii" I had posted a note regarding meeting in the lobby on Tuesday evening in Minneapolis. My mistake. This is the night of the social. We need to reschedule the dinner to Thursday evening - early around 6:00 - so we can get to the Plenary. There will be, of course, a group looking for dinner on Monday evening in the lobby of the Hilton at 7:00 as well. See you there. --=_alternative 0072296E85256B7C_= Content-Type: text/html; charset="us-ascii"
I had posted a note regarding meeting in the lobby on Tuesday evening in Minneapolis.  My mistake.  This is the night of the social.  We need to reschedule the dinner to Thursday evening - early around 6:00 - so we can get to the Plenary.  There will be, of course, a group looking for dinner on Monday evening in the lobby of the Hilton at 7:00 as well.  See you there. --=_alternative 0072296E85256B7C_=-- From owner-ietf-calendar@mail.imc.org Thu Mar 14 16:35: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 QAA01790 for ; Thu, 14 Mar 2002 16:35:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2ELRrF24684 for ietf-calendar-bks; Thu, 14 Mar 2002 13:27: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 g2ELRq424680 for ; Thu, 14 Mar 2002 13:27:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2ELRknB024069 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Mar 2002 13:27:50 -0800 (PST) Message-ID: <3C9115CC.8060501@Royer.com> Date: Thu, 14 Mar 2002 14:27:40 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: "ietf-calendar@imc.org" Subject: Re: BEEP and CAP - one-to-many References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.steltor.co m> <3C8FD90E.8020807@Royer.com> <1016116079.1325.88.camel@c-1241.in.steltor.com> <3C90E10F.2040208@Royer.com> <1016130687.1282.43.camel@c-1241.in.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 Patrice Lapierre wrote: > On Thu, 2002-03-14 at 12:42, Doug Royer wrote: > >>>Sorry, I don't understand your point. What do you mean by >>>limit iCalendar objects as separate? Can you provide a >>>concrete example that demonstrates how CAP breaks iTIP? >>> >> >>What is the technical reason for adding this restriction to iCalendar >>objects? >> > > A difference between a single RPY and ANS,ANS,...ANS/NUL is > that partial results (several ANS) can be send "simultaneously". No, not simultaneously, they MUST still be sent in the same order as the TARGETs were supplied. If we remove that restriction on ordering then each reply would have to be on a separate channel in order for it to be realy simultaneous, they would just be in random order. I Thought that we had agreed that you MAY get them in separate replies, but you can also get them all together. 3.1 seems to contradict that agreement. > An implementation could take advantage of this as follows: > when performing a search command on n TARGETs, several searches > could be started parallel and the results of each individual > target can be returned as they become available (i.e., no need > to queue all of them). Currently the objects in the reply must be in the TARGET order of the original request. This restriction was placed in CAP as a result of a debate in the past where some vendors did not want to be forced to re-assemble or wait for all of the objects. They wanted to get everything all at once. So we agreed that the responses must be in the same order as the request. This I think was related to the creation of the max-component-size capability (then property) that would limit the object size in that reply. Its not going to do any good to send a 1MB object in 10K chunks, if it can only support 500K of data. These thin clients wanted "all or nothing" in the replies. Which reminds me - do we want the CUA to send the CS the CUAs limits? >>If I can iMIP an object with multipart/related, why can't >>I use CAP to transport it? >> > > You CAN! There is nothing in section 3.1 that prevents > you from transporting a multipart/related object with > CAP. What if it contains the entire QUERY reply in ONE mime object for multiple TARGETs? It sounds to me as if 3.1 is saying that I can never create such an multipart/related object. If that is not the intent, then how about we add something like: Unless the reply is a multipart/{related, alternate, ... MIME object when the CS MAY return multiple iCalendar objects in one RPY that might or might not contain the results from a multiple TARGET query. From owner-ietf-calendar@mail.imc.org Thu Mar 14 18:34:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04495 for ; Thu, 14 Mar 2002 18:34:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2ENNUv27167 for ietf-calendar-bks; Thu, 14 Mar 2002 15:23: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 g2ENNS427159 for ; Thu, 14 Mar 2002 15:23: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 SAA00168 for ; Thu, 14 Mar 2002 18:23:26 -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 g2ENNPQ01148 for ; Thu, 14 Mar 2002 18:23:25 -0500 (EST) Subject: Re: BEEP and CAP - one-to-many From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C9115CC.8060501@Royer.com> References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.stelto r.co m> <3C8FD90E.8020807@Royer.com> <1016116079.1325.88.camel@c-1241.in.steltor.co m> <3C90E10F.2040208@Royer.com> <1016130687.1282.43.camel@c-1241.in.steltor.com> <3C9115CC.8060501@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Mar 2002 18:22:27 -0500 Message-Id: <1016148147.1284.233.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thu, 2002-03-14 at 16:27, Doug Royer wrote: ... > > A difference between a single RPY and ANS,ANS,...ANS/NUL is > > that partial results (several ANS) can be send "simultaneously". > > > No, not simultaneously, they MUST still be sent in the same order > as the TARGETs were supplied. If we remove that restriction > on ordering then each reply would have to be on a separate channel > in order for it to be realy simultaneous, they would just be > in random order. See RFC3080 Section 2.6.1 [Asynchrony] Within a Single Channel, frames from different ANS may be interleaved. You may argue that this is "not really simultaneous", but then neither is communication on different channels if they share the same socket. > I Thought that we had agreed that you MAY get them in separate > replies, but you can also get them all together. 3.1 seems > to contradict that agreement. The only related discussion, that I can remember, was about multiple QUERY properties within a VQUERY, that is different. It now seems that the only point we disagree in section 3.1 is the MUST in the sentence: A CAP request, targeted at more than one containers, MUST use a one-to-many exchange, with a distinct answer associated with each target. Would you be OK with keeping the section, and simply transforming it into a MAY A CAP request, targeted at more than one containers, MAY use a one-to-many exchange, with a distinct answer associated with each target. >... > Which reminds me - do we want the CUA to send the CS the CUAs limits? I would definitely think so, it was present in the previous drafts. Draft-06 had the "max-results" and "max-size" elements (MAXSIZE and MAXRESULT properties in draft-05). From owner-ietf-calendar@mail.imc.org Thu Mar 14 19:08:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05379 for ; Thu, 14 Mar 2002 19:08:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2ENwUw27840 for ietf-calendar-bks; Thu, 14 Mar 2002 15:58: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 g2ENwT427836 for ; Thu, 14 Mar 2002 15:58:29 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2ENwRnB026192 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Mar 2002 15:58:31 -0800 (PST) Message-ID: <3C91391C.9090208@Royer.com> Date: Thu, 14 Mar 2002 16:58:20 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: "ietf-calendar@imc.org" Subject: Re: BEEP and CAP - one-to-many References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.stelto r.co m> <3C8FD90E.8020807@Royer.com> <1016116079.1325.88.camel@c-1241.in.steltor.co m> <3C90E10F.2040208@Royer.com> <1016130687.1282.43.camel@c-1241.in.steltor.com> <3C9115CC.8060501@Royer.com> <1016148147.1284.233.camel@c-1241.in.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 > It now seems that the only point we disagree in section 3.1 is > the MUST in the sentence: > > A CAP request, targeted at more than one containers, MUST use a > one-to-many exchange, with a distinct answer associated with > each target. > > Would you be OK with keeping the section, and simply transforming > it into a MAY > > A CAP request, targeted at more than one containers, MAY use a > one-to-many exchange, with a distinct answer associated with > each target. Yes! From owner-ietf-calendar@mail.imc.org Thu Mar 14 19:13: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 TAA05520 for ; Thu, 14 Mar 2002 19:13:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2F03vl27959 for ietf-calendar-bks; Thu, 14 Mar 2002 16:03: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 g2F03u427955 for ; Thu, 14 Mar 2002 16:03:56 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2F03snB026304 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 14 Mar 2002 16:03:58 -0800 (PST) Message-ID: <3C913A63.6020305@Royer.com> Date: Thu, 14 Mar 2002 17:03:47 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: "ietf-calendar@imc.org" Subject: Re: CUA sending capability References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.stelto r.co m> <3C8FD90E.8020807@Royer.com> <1016116079.1325.88.camel@c-1241.in.steltor.co m> <3C90E10F.2040208@Royer.com> <1016130687.1282.43.camel@c-1241.in.steltor.com> <3C9115CC.8060501@Royer.com> <1016148147.1284.233.camel@c-1241.in.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 >>Which reminds me - do we want the CUA to send the CS the CUAs limits? >> > > I would definitely think so, it was present in the previous drafts. > > Draft-06 had the "max-results" and "max-size" elements (MAXSIZE and > MAXRESULT properties in draft-05). No, that was the for the CS sending to the CUA. I mean, I think we want the CUA to send its capabilities to the CS? Perhaps in the "get-capabilities" request: ... In exactly the same format as the CS sends to the CUA. ... From owner-ietf-calendar@mail.imc.org Fri Mar 15 08:50: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 IAA28689 for ; Fri, 15 Mar 2002 08:50:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FDVqe21888 for ietf-calendar-bks; Fri, 15 Mar 2002 05:31: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 g2FDVo421884 for ; Fri, 15 Mar 2002 05:31: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 IAA05735 for ; Fri, 15 Mar 2002 08:31:46 -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 g2FDVkQ13222 for ; Fri, 15 Mar 2002 08:31:46 -0500 (EST) Subject: Re: CUA sending capability From: Patrice Lapierre To: "ietf-calendar@imc.org" In-Reply-To: <3C913A63.6020305@Royer.com> References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.stelt o r.co m> <3C8FD90E.8020807@Royer.com> <1016116079.1325.88.camel@c-1241.in. steltor.co m> <3C90E10F.2040208@Royer.com> <1016130687.1282.43.camel@c-1241.in.steltor.co m> <3C9115CC.8060501@Royer.com> <1016148147.1284.233.camel@c-1241.in.steltor.com> <3C913A63.6020305@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Mar 2002 08:30:46 -0500 Message-Id: <1016199046.8156.8.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thu, 2002-03-14 at 19:03, Doug Royer wrote: > > Draft-06 had the "max-results" and "max-size" elements (MAXSIZE and > > MAXRESULT properties in draft-05). > > No, that was the for the CS sending to the CUA. > I was not referring to the capabilities. MAXSIZE and MAXRESULT where properties of the VQUERY in draft-05. and elements of the select element in draft-06, they were forgotten in draft-07. These should remains settable at the command level. For example the MAXRESULT may vary for different queries in the same session (as for MAXSIZE, I don't know). > I mean, I think we want the CUA to send its capabilities > to the CS? It seem like a good idea, some CUA side capabilities could be useful. > Perhaps in the "get-capabilities" request: > > > > ... > In exactly the same format as the CS sends to the CUA. > ... > BEEP is peer-to-peer, let's use it. If the server sends a MSG, then the CUA will reply with a RPY. From owner-ietf-calendar@mail.imc.org Fri Mar 15 10:08: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 KAA00993 for ; Fri, 15 Mar 2002 10:08:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2FEu2728666 for ietf-calendar-bks; Fri, 15 Mar 2002 06:56:02 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FEu0428662 for ; Fri, 15 Mar 2002 06:56:00 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: BEEP and CAP - one-to-many MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 15 Mar 2002 10:04:50 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/15/2002 10:05:48 AM, Serialize complete at 03/15/2002 10:05:48 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Would you be OK with keeping the section, and simply transforming >> it into a MAY >> >> A CAP request, targeted at more than one containers, MAY use a >> one-to-many exchange, with a distinct answer associated with >> each target. > >Yes! But, Doug, that doesn't solve the thin-client problem you were talking about, because the MAY leaves it entirely up to the CS. A thin client that can't handle a monolithic reply can't tell whether the CS will send one or not. Right? /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |Reality is what refuses to go away when I stop believing in it.| \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 15 10:54:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02264 for ; Fri, 15 Mar 2002 10:54:33 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2FFgQp29538 for ietf-calendar-bks; Fri, 15 Mar 2002 07:42: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 g2FFgO429534 for ; Fri, 15 Mar 2002 07:42: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 KAA08789 for ; Fri, 15 Mar 2002 10:42:20 -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 g2FFgKQ27821 for ; Fri, 15 Mar 2002 10:42:20 -0500 (EST) Subject: Re: BEEP and CAP - one-to-many From: Patrice Lapierre To: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Mar 2002 10:41:19 -0500 Message-Id: <1016206879.8258.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 On Fri, 2002-03-15 at 10:04, John Stracke wrote: ... > A thin client that can't handle a monolithic reply can't tell > whether the CS will send one or not. Right? > What do you mean by a thin client can't handle a monolithic reply? If you mean to inverse (thin client that can only handle a monolithic reply), then these small clients could always limit themselves to a single TARGET per command. Another alternative would be to add a CUA side capability, to indicate if the CUA supports one-to-many exchanges, but that might be an overkill. From owner-ietf-calendar@mail.imc.org Fri Mar 15 11:19: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 LAA03059 for ; Fri, 15 Mar 2002 11:19:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2FG7hD01535 for ietf-calendar-bks; Fri, 15 Mar 2002 08:07:43 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FG7e401531 for ; Fri, 15 Mar 2002 08:07:40 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: BEEP and CAP - one-to-many MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 15 Mar 2002 11:16:31 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/15/2002 11:17:29 AM, Serialize complete at 03/15/2002 11:17:29 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >What do you mean by a thin client can't handle a monolithic >reply? Have you read Doug's earlier message? He wrote: >>Currently the objects in the reply must be in the TARGET order of the >>original request. This restriction was placed in CAP as a result >>of a debate in the past where some vendors did not want >>to be forced to re-assemble or wait for all of the objects. >>They wanted to get everything all at once. So we agreed that >>the responses must be in the same order as the request. >> >>This I think was related to the creation of the max-component-size >>capability (then property) that would limit the object size >>in that reply. Its not going to do any good to send a 1MB object >>in 10K chunks, if it can only support 500K of data. These thin >>clients wanted "all or nothing" in the replies. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |E pui muove! -- Galileo | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 15 11:25: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 LAA03172 for ; Fri, 15 Mar 2002 11:25:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2FGCtP01829 for ietf-calendar-bks; Fri, 15 Mar 2002 08:12: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 g2FGCs401825 for ; Fri, 15 Mar 2002 08:12:54 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2FGCpnB009962 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Mar 2002 08:12:55 -0800 (PST) Message-ID: <3C921D7F.9090801@Royer.com> Date: Fri, 15 Mar 2002 09:12:47 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org i" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: BEEP and CAP - one-to-many References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>>Would you be OK with keeping the section, and simply transforming >>>it into a MAY >>> >>> A CAP request, targeted at more than one containers, MAY use a >>> one-to-many exchange, with a distinct answer associated with >>> each target. >>> >>Yes! >> > > But, Doug, that doesn't solve the thin-client problem you were talking > about, because the MAY leaves it entirely up to the CS. A thin client > that can't handle a monolithic reply can't tell whether the CS will send > one or not. Right? Thin clients pick their provider. I don't think it will be an issue. From owner-ietf-calendar@mail.imc.org Fri Mar 15 11:54:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04250 for ; Fri, 15 Mar 2002 11:54:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FGhsJ03394 for ietf-calendar-bks; Fri, 15 Mar 2002 08:43:54 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FGhr403390 for ; Fri, 15 Mar 2002 08:43:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2FGhnnB010413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Mar 2002 08:43:53 -0800 (PST) Message-ID: <3C9224C2.7050406@Royer.com> Date: Fri, 15 Mar 2002 09:43:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CUA sending capability References: <3C8F901E.5050905@Royer.com> <1016050662.1325.11.camel@c-1241.in.steltor.com > <3C8FC7E5.6090200@Royer.com> <1016058455.1323.24.camel@c-1241.in.stelt o r.co m> <3C8FD90E.8020807@Royer.com> <1016116079.1325.88.camel@c-1241.in. steltor.co m> <3C90E10F.2040208@Royer.com> <1016130687.1282.43.camel@c-1241.in.steltor.co m> <3C9115CC.8060501@Royer.com> <1016148147.1284.233.camel@c-1241.in.steltor.com> <3C913A63.6020305@Royer.com> <1016199046.8156.8.camel@c-1241.in.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 >>Perhaps in the "get-capabilities" request: >> >> >> >> ... >> In exactly the same format as the CS sends to the CUA. >> ... >> >> > > BEEP is peer-to-peer, let's use it. If the server sends a > MSG, then the CUA will reply with a > RPY. Sounds just like what I was thinking. If there are no objections, I'll add text to the capability section that specifies that the CUA MAY send its capabilities to the CS. I'll also (if needed) list the ones that don't apply. From owner-ietf-calendar@mail.imc.org Fri Mar 15 12:34: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 MAA05439 for ; Fri, 15 Mar 2002 12:34:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2FHIwe06244 for ietf-calendar-bks; Fri, 15 Mar 2002 09:18:58 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2FHIv406237 for ; Fri, 15 Mar 2002 09:18:57 -0800 (PST) To: "ietf-calendar@imc.org i" Subject: Re: BEEP and CAP - one-to-many MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 15 Mar 2002 12:27:47 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/15/2002 12:28:46 PM, Serialize complete at 03/15/2002 12:28:46 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> But, Doug, that doesn't solve the thin-client problem you were talking >> about, because the MAY leaves it entirely up to the CS. A thin client >> that can't handle a monolithic reply can't tell whether the CS will send >> one or not. Right? > >Thin clients pick their provider. Calendaring thin clients do today, because they have no choice. In the email world, this is not the case; there are PDA and Web-based MUAs that can work with any IMAP server. The same should be true for CAP. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Linux: the Unix defragmentation tool. | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 15 13:36: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 NAA06871 for ; Fri, 15 Mar 2002 13:36:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2FIIPW08716 for ietf-calendar-bks; Fri, 15 Mar 2002 10:18: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 g2FIIO408712 for ; Fri, 15 Mar 2002 10:18:25 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2FIIKnB011767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 15 Mar 2002 10:18:26 -0800 (PST) Message-ID: <3C923AE7.4030400@Royer.com> Date: Fri, 15 Mar 2002 11:18:15 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org i" Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: BEEP and CAP - one-to-many 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 >>Thin clients pick their provider. >> > > Calendaring thin clients do today, because they have no choice. In the > email world, this is not the case; there are PDA and Web-based MUAs that > can work with any IMAP server. The same should be true for CAP. How about we add a capability 'can-multipart' ? For both the CS and the CUA. This would also solve the large vendor problem where they seem to refuse to do multipart. If one end of the connection does not advertise it, then the other end MUST "do one to many"? From owner-ietf-calendar@mail.imc.org Mon Mar 18 15:57: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 PAA19825 for ; Mon, 18 Mar 2002 15:57:40 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2IKfoc10268 for ietf-calendar-bks; Mon, 18 Mar 2002 12:41:50 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IKfi410261 for ; Mon, 18 Mar 2002 12:41:49 -0800 (PST) To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: Re: Dinner in Minneapolis MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03032002 March 03, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Mar 2002 15:41:43 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_03042002|March 04, 2002) at 03/18/2002 03:36:48 PM, Serialize complete at 03/18/2002 03:36:48 PM Content-Type: multipart/alternative; boundary="=_alternative 0071798E85256B80_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071798E85256B80_= Content-Type: text/plain; charset="US-ASCII" Pat wrote on 03/14/2002 03:46:56 PM: > We need to reschedule the dinner to Thursday evening - > early around 6:00 - so we can get to the Plenary. There will be, of > course, a group looking for dinner on Monday evening in the lobby of > the Hilton at 7:00 as well. See you there. How about picking the only other night we havent tried yet: Wednesday night? That would allow any non-Monday folks to be there too and we would not have to race thru dinner... 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 0071798E85256B80_= Content-Type: text/html; charset="US-ASCII"
Pat wrote on 03/14/2002 03:46:56 PM:
>           We need to reschedule the dinner to Thursday evening -
> early around 6:00 - so we can get to the Plenary.  There will be, of
> course, a group looking for dinner on Monday evening in the lobby of
> the Hilton at 7:00 as well.  See you there.

How about picking the only other night we havent tried yet: Wednesday night?  That would allow any non-Monday folks to be there too and we would not have to race thru dinner...

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 0071798E85256B80_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 18 16:45:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21504 for ; Mon, 18 Mar 2002 16:45:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2ILWNE11413 for ietf-calendar-bks; Mon, 18 Mar 2002 13:32:23 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2ILWL411409 for ; Mon, 18 Mar 2002 13:32:21 -0800 (PST) X-Notes-Item: 1; name=$PublicAccess X-Notes-Item: CN=Bruce Kahn/OU=Westford/O=IBM; name=$AltPrincipal X-Notes-Item: ; name=$LangPrincipal X-Notes-Item: 1; name=$SMTPKeepNotesItems X-Notes-Item: 1; name=WebDateTimeInit X-Notes-Item: ; name=OriginalNoticeType X-Notes-Item: 0; name=$EncryptionStatus X-Notes-Item: 0; name=$SignatureStatus X-Notes-Item: B; name=DeliveryReport X-Priority: 3 (Normal) X-Notes-Item: Thu, 21 Mar 2002 17:30:00 -0600; type=400; name=$NoPurge X-Notes-Item: Send Request by Notes Client on Bruce Kahn/Westford/IBM(Build V60_03032002|March 03 =?US-ASCII?Q?=2C_2002=29_at_03=2F18=2F2002_04=3A30=3A03_PM?=, Prepare Request by Notes Client on Bruce Kahn/Westford/IBM(Build V60_03032002|March 03 =?US-ASCII?Q?=2C_2002=29_at_03=2F18=2F2002_04=3A30=3A03_PM?=, CS Notice converted to iCalendar format by Notes Client on Bruce Kahn/Westford/IBM(Build V60_03032002|March 03 =?US-ASCII?Q?=2C_2002=29_at_03=2F18=2F2002_04=3A30=3A04_PM?=; type=501; name=$CSTrack X-Notes-Item: ietf-calendar@imc.org; flags=44; name=RequiredAttendees X-Notes-Item: ietf-calendar@imc.org; flags=44; name=AltRequiredNames X-Notes-Item: .; flags=44; name=INetRequiredNames X-Notes-Item: 2; flags=44; name=StorageRequiredNames To: ietf-calendar@imc.org X-Notes-Item: ; flags=45; name=INetCopyTo X-Notes-Item: ; flags=44; name=INetBlindCopyTo X-Notes-Item: 2; name=$StorageTo X-Notes-Item: 1; name=$HFFlags X-Notes-Item: 1; name=tmpRW X-Notes-Item: 0; name=tmpOwnerHW X-Notes-Item: 1; name=tmpParticipantHW X-Notes-Item: 1; name=tmpNoActionBar X-Notes-Item: 3; name=$ExpandGroups X-Notes-Item: StdNotesLtr15; name=Logo X-Notes-Item: ; name=MailOptions X-Notes-Item: ; name=Sign X-Notes-Item: ; name=tmpOEMClient X-Notes-Item: ; name=tmpDuration X-Notes-Item: Z=5$DO=1$DL=4 1 1 10 -1 1$ZX=25$ZN=Eastern; name=LocalTimeZone X-Notes-Item: en-US; name=$FromPreferredLanguage X-Notes-Item: ; name=ConferenceDatabase X-Notes-Item: ; name=SametimeServer X-Notes-Item: ; name=SametimeServerNetAddress X-Notes-Item: ; name=ApptUNIDURL X-Notes-Item: ; flags=44; name=RestrictToInviteList X-Notes-Item: ; flags=44; name=OnlinePlace X-Notes-Item: ; name=AudioVideoSelectionList X-Notes-Item: ; name=$LangChair X-Notes-Item: CN=Bruce Kahn/OU=Westford/O=IBM; flags=44; name=AltChair X-Notes-Item: D8E1E1; name=$BorderColor X-Notes-Item: ; name=tmpScheduleSwitch X-Notes-Item: 1; name=Alarms Subject: Broadcast: IETF 53 CalSch WG Meeting (Mar 21 03:30 PM CST in Rochester Room) X-Notes-Item: 2 Hrs. ; name=dispDuration X-Notes-Item: Rochester Room; name=Location X-Notes-Item: ; name=OnlineMeeting X-Notes-Item: 1; name=MeetingType X-Notes-Item: ; flags=44; name=Presenters X-Notes-Item: ; flags=44; name=OnlinePlaceToReserve X-Notes-Item: ; name=AudioVideoFlags X-Notes-Item: ; name=SendAttachments X-Notes-Item: ; name=RestrictAttendence X-Notes-Item: 2; name=SchedulerSwitcher X-Notes-Item: ; flags=44; name=tmpOrganizer X-Notes-Item: ; name=OrganizerInclude X-Notes-Item: iCalendar; name=Categories MIME-Version: 1.0 X-Notes-Item: Memo; name=Form X-Notes-Item: 1; name=$NoteContainsIcal X-Mailer: Lotus Notes Build V60_03032002 March 03, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 18 Mar 2002 16:32:21 -0500 X-Notes-Item: ; name=Encrypt X-Notes-Item: CN=Bruce Kahn/OU=Westford/O=IBM, CN=Clapton/O=Iris, CN=Mountain/O=Iris; type=501; flags=44; name=$UpdatedBy X-Notes-Item: CN=Clapton/O=Iris, CN=Mountain/O=Iris; type=501; flags=0; name=RouteServers X-Notes-Item: 18-Mar-2002 16:32:21 EST/18-Mar-2002 16:32:21 EST =?US-ASCII?Q?=2C_18-Mar-2002_16=3A30=3A07_EST=2F18-Mar-2002_16=3A30=3A08?= EST; type=401; flags=0; name=RouteTimes X-Notes-Item: AEF40C10:0FD6FDCF-85256B80:007651A5; type=4; name=$Orig X-Notes-Item: 2; name=$MsgTrackFlags X-Notes-Item: IRIS@iris.com; name=FromDomain X-Notes-Item: 23; type=300; name=$Hops X-Notes-Item: 1; name=$NoteHasNativeMIME X-Notes-Item: CN=Bruce Kahn/OU=Westford/O=IBM; name=OriginalFrom X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_03042002|March 04, 2002) at 03/18/2002 04:27:21 PM, Serialize complete at 03/18/2002 04:27:21 PM Content-Type: multipart/mixed; boundary="=_mixed 00761BF385256B80_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_mixed 00761BF385256B80_= Content-Type: multipart/alternative; boundary="=_alternative 00761BF385256B80_=" --=_alternative 00761BF385256B80_= Content-Type: text/plain; charset="US-ASCII" The CalSch WG meeting is scheduled from 15:30 - 17:30 on Thursday 21-Mar-2002 in Rochester. No agenda has been formally set yet but it will be part of any minutes we send out. If you grok iCal in your client, you should be able to put this on your calendar directly... --=_alternative 00761BF385256B80_= Content-Type: text/html; charset="US-ASCII"
The CalSch WG meeting is scheduled from 15:30 - 17:30 on Thursday 21-Mar-2002 in Rochester.  No agenda has been formally set yet but it will be part of any minutes we send out.

If you grok iCal in your client, you should be able to put this on your calendar directly... --=_alternative 00761BF385256B80_= Content-Type: text/calendar; method="REQUEST"; charset="utf-8" BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Lotus Development Corporation//NONSGML Notes 6.0//EN METHOD:REQUEST BEGIN:VTIMEZONE TZID:Central BEGIN:STANDARD DTSTART:20011028T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0600 RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10 X-LOTUS-TZINDEX:18 END:STANDARD BEGIN:DAYLIGHT DTSTART:20020407T020000 TZOFFSETFROM:-0600 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4 X-LOTUS-TZINDEX:18 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID="Central":20020321T153000 DTEND;TZID="Central":20020321T173000 TRANSP:OPAQUE DTSTAMP:20020318T213003Z SEQUENCE:0 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=Bruce Kahn;RSVP=FALSE :mailto:Bruce_Kahn@notesdev.ibm.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE :mailto:ietf-calendar@imc.org CLASS:PUBLIC DESCRIPTION:The CalSch WG meeting is scheduled from 15:30 - 17 :30 on Thursday \n21-Mar-2002 in Rochester. No agenda has been formal ly set yet but it will \nbe part of any minutes we send out.\n\nIf you grok iCal in your client\, you should be able to put this on your \nc alendar directly...\n SUMMARY:IETF 53 CalSch WG Meeting LOCATION:Rochester Room ORGANIZER;CN=Bruce Kahn:mailto:Bruce_Kahn@notesdev.ibm.com UID:BD63472205C8173185256B800074AADC-Lotus_Notes_Generated X-LOTUS-PREVENTCOUNTER:TRUE X-LOTUS-BROADCAST:TRUE END:VEVENT END:VCALENDAR --=_alternative 00761BF385256B80_=-- --=_mixed 00761BF385256B80_= Content-Type: text/calendar; method="REQUEST"; charset="utf-8"; name="c163004.ics" Content-Disposition: attachment; filename="c163004.ics" BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Lotus Development Corporation//NONSGML Notes 6.0//EN METHOD:REQUEST BEGIN:VTIMEZONE TZID:Central BEGIN:STANDARD DTSTART:20011028T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0600 RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10 X-LOTUS-TZINDEX:18 END:STANDARD BEGIN:DAYLIGHT DTSTART:20020407T020000 TZOFFSETFROM:-0600 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4 X-LOTUS-TZINDEX:18 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID="Central":20020321T153000 DTEND;TZID="Central":20020321T173000 TRANSP:OPAQUE DTSTAMP:20020318T213003Z SEQUENCE:0 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=Bruce Kahn;RSVP=FALSE :mailto:Bruce_Kahn@notesdev.ibm.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE :mailto:ietf-calendar@imc.org CLASS:PUBLIC DESCRIPTION:The CalSch WG meeting is scheduled from 15:30 - 17 :30 on Thursday \n21-Mar-2002 in Rochester. No agenda has been formal ly set yet but it will \nbe part of any minutes we send out.\n\nIf you grok iCal in your client\, you should be able to put this on your \nc alendar directly...\n SUMMARY:IETF 53 CalSch WG Meeting LOCATION:Rochester Room ORGANIZER;CN=Bruce Kahn:mailto:Bruce_Kahn@notesdev.ibm.com UID:BD63472205C8173185256B800074AADC-Lotus_Notes_Generated X-LOTUS-PREVENTCOUNTER:TRUE X-LOTUS-BROADCAST:TRUE END:VEVENT END:VCALENDAR --=_mixed 00761BF385256B80_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 18 16:46: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 QAA21516 for ; Mon, 18 Mar 2002 16:46:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2ILXer11446 for ietf-calendar-bks; Mon, 18 Mar 2002 13:33:40 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2ILXc411442 for ; Mon, 18 Mar 2002 13:33:38 -0800 (PST) To: ietf-calendar@imc.org Subject: Dinners in Minn MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: pregen@egenconsulting.com Message-ID: Date: Mon, 18 Mar 2002 16:33:35 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 03/18/2002 04:33:41 PM, Serialize complete at 03/18/2002 04:33:41 PM Content-Type: multipart/alternative; boundary="=_alternative 007663A285256B80_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007663A285256B80_= Content-Type: text/plain; charset="us-ascii" For those who are interested, the CalSch group will meet in the lobby of the Hilton for dinner at 6:00 on Wednesday night. This allows us time for people to get back for the Plenary if they so desire. --=_alternative 007663A285256B80_= Content-Type: text/html; charset="us-ascii"
For those who are interested, the CalSch group will meet in the lobby of the Hilton for dinner at 6:00 on Wednesday night.  This allows us time for people to get back for the Plenary if they so desire.
 --=_alternative 007663A285256B80_=-- From owner-ietf-calendar@mail.imc.org Thu Mar 21 22:22: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 WAA05708 for ; Thu, 21 Mar 2002 22:22:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2M39lU13437 for ietf-calendar-bks; Thu, 21 Mar 2002 19:09:47 -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 g2M39j413433 for ; Thu, 21 Mar 2002 19:09:45 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g2M39gO28881 for ; Thu, 21 Mar 2002 19:09:42 -0800 (PST) Received: from netscape.com ([205.217.229.157]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTCU4700.RO1 for ; Thu, 21 Mar 2002 19:09:43 -0800 Message-ID: <3C9A9FE3.6831B377@netscape.com> Date: Thu, 21 Mar 2002 19:07:15 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Review of CAP Draft 07 Content-Type: multipart/mixed; boundary="------------80FB10B5A502FEBA1B1C678D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------80FB10B5A502FEBA1B1C678D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All, Nothin' like a plane ride to use as uninterrupted time to read the CAP draft cover to cover and mark it up with issues :-) Bruce Kahn, who was also at the meeting, had also thoroughly read through the draft and marked up his copy with issues. We've spent the last two days working through them in the hallways along with many people from the calsched group. I'm going to post a bunch of issues to the list over the next few days. Most will be accompanied by recommendations. As always, we want to try to push through the issues and get to closure quickly so we can bring CAP to a last call. At the meeting today, we discussed a little different approach for dealing issues. We'd like to focus on one issue at a time, work through it, close it, then move to the next. Some of the issues we've seen on the list lately are complex. A number of people (myself included) have stayed away from issues that require keeping up with a lot of email messages. So, the intent of this change is to stay focused on a single issue, which will make it easier for all of us to stay caught up. Pat is going to look into some tools for logging and tracking issues. She will post more on this soon. -Steve --------------80FB10B5A502FEBA1B1C678D 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 --------------80FB10B5A502FEBA1B1C678D-- From owner-ietf-calendar@mail.imc.org Thu Mar 21 22: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 WAA07318 for ; Thu, 21 Mar 2002 22:56:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2M3h9r14088 for ietf-calendar-bks; Thu, 21 Mar 2002 19:43:09 -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 g2M3h8414084 for ; Thu, 21 Mar 2002 19:43:08 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g2M3h4O16503 for ; Thu, 21 Mar 2002 19:43:04 -0800 (PST) Received: from netscape.com ([205.217.229.157]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTCVNU00.ULT for ; Thu, 21 Mar 2002 19:43:06 -0800 Message-ID: <3C9AA7B6.2D4459DF@netscape.com> Date: Thu, 21 Mar 2002 19:40:38 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP / BEEP / XML / iCalendar Content-Type: multipart/mixed; boundary="------------95584758B8151832CCED623F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------95584758B8151832CCED623F Content-Type: multipart/alternative; boundary="------------D287C3363A9BBB014FB54F96" --------------D287C3363A9BBB014FB54F96 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All, While here in Minneapolis, several people brought up that there was concern over the use of XML with BEEP. I did a quick search through the messages since Jan 12. I can't really tell if there is a problem or not. I'd like to resolve this asap because there are other issues surrounding the transport / application layer separation that we need to work through. If anyone has an issue with the following, please bring it up on the list so we can work through it. Otherwise, we can press on with the other issues for draft 07. CAP defines a Transport protocol layer and an Application protocol layer. The data content type used in the Application protocol is text/iCalendar. The data format for the Transport protocol is application/beep+xml. Is everyone OK with this? If you're not OK with this, can you please describe the problem? (our chairs do not view silence as consensus) -Steve --------------D287C3363A9BBB014FB54F96 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All,

While here in Minneapolis, several people brought up that there was concern over the use of  XML with BEEP. I did a quick search through the messages since Jan 12. I can't really tell if there is a problem or not. I'd like to resolve this asap because there are other issues surrounding the transport / application layer separation that we need to work through. If anyone has an issue with the following, please bring it up on the list so we can work through it. Otherwise, we can press on with the other issues for draft 07.

CAP defines a Transport  protocol layer and an Application protocol layer.  The data content type used in the Application protocol is text/iCalendar.  The data format for the Transport protocol is application/beep+xml.
Is everyone OK with this?  If you're not OK with this, can you please describe the problem?

(our chairs do not view silence as consensus)

-Steve --------------D287C3363A9BBB014FB54F96-- --------------95584758B8151832CCED623F Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650.937.3351 x-mozilla-html:FALSE org:Netscape adr:;;;;;; version:2.1 title:Director of Engineering fn:Steve Mansour end:vcard --------------95584758B8151832CCED623F-- From owner-ietf-calendar@mail.imc.org Thu Mar 21 23:15: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 XAA07699 for ; Thu, 21 Mar 2002 23:15:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2M43oo14499 for ietf-calendar-bks; Thu, 21 Mar 2002 20:03:50 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2M43n414492 for ; Thu, 21 Mar 2002 20:03:49 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA28615; Thu, 21 Mar 2002 23:03:51 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA22377; Thu, 21 Mar 2002 23:03:51 -0500 (EST) Received: from monalisa ([166.63.186.160]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id XAA24719; Thu, 21 Mar 2002 23:00:29 -0500 (EST) From: "Paul B. Hill" To: "Steve Mansour" , "CalSched IETF" Subject: RE: CAP / BEEP / XML / iCalendar Date: Thu, 21 Mar 2002 23:00:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C9AA7B6.2D4459DF@netscape.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >...CAP defines a Transport protocol layer and an Application protocol layer. The data content type used in the Application protocol is text/iCalendar. The data format for the Transport protocol is application/beep+xml. >Is everyone OK with this? If you're not OK with this, can you please describe the problem? I'm OK with the use of beep and the use of XML in the transport protocol. The limited use of XML that has been introduced will not require a full parser to be used by an implementation. I see no prior work by the group that will be invalidated by this use. Paul From owner-ietf-calendar@mail.imc.org Thu Mar 21 23:37: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 XAA08748 for ; Thu, 21 Mar 2002 23:37:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2M4Sse15019 for ietf-calendar-bks; Thu, 21 Mar 2002 20:28:54 -0800 (PST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2M4Sq415015 for ; Thu, 21 Mar 2002 20:28:53 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3.Beta0/8.12.2.Beta3) with ESMTP id g2M4Sn4F031914; Thu, 21 Mar 2002 23:28:49 -0500 Date: Thu, 21 Mar 2002 23:28:49 -0500 Message-Id: <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: CalSched IETF , Steve Mansour In-reply-to: <3C9AA7B6.2D4459DF@netscape.com> Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Steve, I'm one of those people who gets easily confused. Looking at the OSI model, the "transport layer" is layer 4, and is occupied by TCP. If anything, BEEP occupies the "presentation" layer. My general confusion is why certain things were chosen to be put into the XML _application_ layer (such as "") and what was put into the payload (the iCAP CDATA blobs). here's one example from draft 07: 1 C: MSG 1 4 . 2043 680 2 C: Content-Type: application/cap+xml 3 C: 4 C: 5 C: = '19990714T080000Z' AND 15 C: DTSTART <= '19990715T080000Z' 16 C: END:VQUERY 17 C: END:VCALENDAR 18 C: ]]> 19 C: 20 C: END Of this, lines 1,2, and 20 are specified by BEEP and are part of the presentation layer. Lines 4-19 are specified by CAP and are in the application layer. These lines consist of a single command, "search". The search command appears to have three parameters: two of them are attributes ("latency" and "ask") and one of them is in the body (the CDATA iCAP object). The iCAP object, lines 6-18, appears to be some sort of data payload. It's not clear to me why there isn't just a LATENCY:3 ACTION:ask inside the VQUERY. It's also unclear to me if line 9 could be anything but METHOD:SEARCH; it appears to contain duplicate information from line 3, but I guess I'd have to reread the draft to state with any definitiveness. At this point, there appears to be much more investment into making more iCal objects; in fact, the examples in 6.2.2.5 don't even show the XML! Is there any reason for any of the XML fragments besides that BEEP uses XML messages for some of it's presentation? Larry From owner-ietf-calendar@mail.imc.org Thu Mar 21 23:50: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 XAA09005 for ; Thu, 21 Mar 2002 23:50:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2M4fXd15276 for ietf-calendar-bks; Thu, 21 Mar 2002 20:41:33 -0800 (PST) Received: from mx.infradig.com (c17802.fitzg1.qld.optusnet.com.au [210.49.37.156]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2M4fV415272 for ; Thu, 21 Mar 2002 20:41:32 -0800 (PST) Received: from localhost ([127.0.0.1]) by localhost with ESMTP id <3C9AB5CD.000000A6@infradig.com> for ; Fri, 22 Mar 2002 04:40:45 GMT Date: Fri, 22 Mar 2002 14:40:44 +1000 From: Andrew Davison Organization: Infradig Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> Content-Type: multipart/alternative; boundary="------------060701080505010209080903" Message-ID: <3C9AB5CD.000000A6@infradig.com> X-Authenticated-Sender: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------060701080505010209080903 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Steve Mansour wrote: > Hey All, > > While here in Minneapolis, several people brought up that there was > concern over the use of XML with BEEP. I did a quick search through > the messages since Jan 12. I can't really tell if there is a problem > or not. I'd like to resolve this asap because there are other issues > surrounding the transport / application layer separation that we need > to work through. If anyone has an issue with the following, please > bring it up on the list so we can work through it. Otherwise, we can > press on with the other issues for draft 07. > > CAP defines a Transport protocol layer and an Application > protocol layer. The data content type used in the Application > protocol is text/iCalendar. The data format for the Transport > protocol is application/beep+xml. > > Is everyone OK with this? If you're not OK with this, can you please > describe the problem? why does CAP have to mention this. surely just saying the transport protocol layer is BEEP implies the data format (and much else). it doesn't even have to know the details. i'm new to this (the last time i looked at CAP it was still CSTP) so maybe i'm missing something. my implementation of CAP will use BEEP purely as an API and so will not know anything about how it works. andrew --------------060701080505010209080903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote:

Hey All,

While here in Minneapolis, several people brought up that there was concern over the use of  XML with BEEP. I did a quick search through the messages since Jan 12. I can't really tell if there is a problem or not. I'd like to resolve this asap because there are other issues surrounding the transport / application layer separation that we need to work through. If anyone has an issue with the following, please bring it up on the list so we can work through it. Otherwise, we can press on with the other issues for draft 07.

CAP defines a Transport  protocol layer and an Application protocol layer.  The data content type used in the Application protocol is text/iCalendar.  The data format for the Transport protocol is application/beep+xml.
Is everyone OK with this?  If you're not OK with this, can you please describe the problem?
why does CAP have to mention this. surely just saying the transport protocol layer is BEEP implies the data format (and much else). it doesn't even have to know the details.

i'm new to this (the last time i looked at CAP it was still CSTP) so maybe i'm missing something. my implementation of CAP will use BEEP purely as an API and so will not know anything about how it works.

andrew


--------------060701080505010209080903-- From owner-ietf-calendar@mail.imc.org Fri Mar 22 10:30:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23736 for ; Fri, 22 Mar 2002 10:30:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2MF92k08378 for ietf-calendar-bks; Fri, 22 Mar 2002 07:09:02 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MF8t408374 for ; Fri, 22 Mar 2002 07:09:00 -0800 (PST) To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 22 Mar 2002 10:18:56 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/22/2002 10:19:13 AM, Serialize complete at 03/22/2002 10:19:13 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >surely just saying the transport protocol layer is BEEP implies the data format (and much else). No, BEEP carries arbitrary MIME messages. It could carry native text/calendar just fine; the current draft doesn't largely because people looked at existing BEEP usage and though, "Oh, BEEP means we have to use XML". /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Vote for Ron, and nobody gets hurt! --actual campaign poster from| |Chicago | \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 22 10:30: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 KAA23759 for ; Fri, 22 Mar 2002 10:30:41 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2MFANG08411 for ietf-calendar-bks; Fri, 22 Mar 2002 07:10:23 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MFAL408407 for ; Fri, 22 Mar 2002 07:10:21 -0800 (PST) To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 22 Mar 2002 10:20:23 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/22/2002 10:20:34 AM, Serialize complete at 03/22/2002 10:20:34 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Looking at the OSI >model ...is rarely useful. Even OSI eventually had to break the OSI model. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Vote for Ron, and nobody gets hurt! --actual campaign poster from| |Chicago | \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 22 11:02: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 LAA24651 for ; Fri, 22 Mar 2002 11:02:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2MFg1k09028 for ietf-calendar-bks; Fri, 22 Mar 2002 07:42: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 g2MFg0409023 for ; Fri, 22 Mar 2002 07:42:00 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2MFfjdx025372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 22 Mar 2002 07:41:49 -0800 (PST) Message-ID: <3C9B50B6.4020307@Royer.com> Date: Fri, 22 Mar 2002 08:41:42 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.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 Steve Mansour wrote: > Hey All, > > While here in Minneapolis, several people brought up that there was > concern over the use of XML with BEEP. I did a quick search through the > messages since Jan 12. I can't really tell if there is a problem or not. > I'd like to resolve this asap because there are other issues surrounding > the transport / application layer separation that we need to work > through. If anyone has an issue with the following, please bring it up > on the list so we can work through it. Otherwise, we can press on with > the other issues for draft 07. > > CAP defines a Transport protocol layer and an Application protocol > layer. The data content type used in the Application protocol is > text/iCalendar. The data format for the Transport protocol is > application/beep+xml. > > Is everyone OK with this? If you're not OK with this, can you please > describe the problem? There are two layers. For CS commands lets go with application/cap+xml (or better yet ical-xml). For ALL iTIP objects there is NEVER a need to add another layer or two wrap the the data in CDATA, lets just send text/calendar and as we already added CMDID to the iCalendar object pre-beep anyway. Then we make (as in 07) SEARCH, DELETE, MOVE, MODIFY, a valid method (and any I missed here). Then the only time we need appliction/ical+xml is when we send CAP only commands. For all other objects they are iCalendar objects (in CDATA or future xCal). Then in xCal - we specify the XML binding for the iCalendar objects. This is out of scope for CAP and is only going to confuse things when xCal is in the hot seat. -> Why cap+xml (or ical+xml) and not beep+xml? So we can use ical+xml in xCal and it means the same thing - that a xCal object or a CDATA text/calendar object is in the XML blob. If we use beep+xml, then we have to invent the same thing again so that we can transport xCal objects via non-CAP where their MIME type can NOT be beep+xml. We do NOT need two ways to wrap iCalendar or xCal objects. > (our chairs do not view silence as consensus) > > -Steve > From owner-ietf-calendar@mail.imc.org Fri Mar 22 11:12: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 LAA24802 for ; Fri, 22 Mar 2002 11:12:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2MFs9h09293 for ietf-calendar-bks; Fri, 22 Mar 2002 07:54: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 g2MFs8409289 for ; Fri, 22 Mar 2002 07:54:08 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2MFrxdx025541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 22 Mar 2002 07:54:03 -0800 (PST) Message-ID: <3C9B5394.6030508@Royer.com> Date: Fri, 22 Mar 2002 08:53:56 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Lawrence Greenfield CC: CalSched IETF , Steve Mansour Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> 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 Lawrence Greenfield wrote: > Hi Steve, > > I'm one of those people who gets easily confused. Looking at the OSI > model, the "transport layer" is layer 4, and is occupied by TCP. If > anything, BEEP occupies the "presentation" layer. ISO transport died? :-) > My general confusion is why certain things were chosen to be put into > the XML _application_ layer (such as "") and what was put > into the payload (the iCAP CDATA blobs). here's one example from > draft 07: Issues: (1) iCalendar objects are iCalendar - not XML. (2) CAP is a protocol to move iCalendar objects. (3) There are CAP commands and iCalendar objects. We agreed the CAP 'commands' can be XML. (4) xCal will describe how iCalendar objects are mapped 1:1 into XML objects - not CAP. That was never in the scope of CAP. (5) xCal (or a separate draft) will describe how to transport xCal objects with CAP - it was never in scope for CAP. (6) The WG agreed that CAP MUST BE iCalendar objects. (7) Latency and ask are transport issues, not data issues. (8) Small or thin devices (cell phones) must be considered in the protocol. It is more important to transport the data than to develop an elaborate protocol just because someone else did. 07 reduces the byte count significantly over 06. 07 is not as pretty - I agree with that. From owner-ietf-calendar@mail.imc.org Fri Mar 22 11:26: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 LAA25248 for ; Fri, 22 Mar 2002 11:26:51 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2MFwjM09400 for ietf-calendar-bks; Fri, 22 Mar 2002 07:58:45 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MFwi409396 for ; Fri, 22 Mar 2002 07:58:44 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2MFwedx025604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 22 Mar 2002 07:58:44 -0800 (PST) Message-ID: <3C9B54AD.7040704@Royer.com> Date: Fri, 22 Mar 2002 08:58:37 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> <3C9AB5CD.000000A6@infradig.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 Andrew Davison wrote: >> Is everyone OK with this? If you're not OK with this, can you please >> describe the problem? > > why does CAP have to mention this. surely just saying the transport > protocol layer is BEEP implies the data format (and much else). it > doesn't even have to know the details. It is not sufficient because I MUST know exactly what you are sending. Many people seemed to have just copied the BEEP examples and tweaked them. iCalendar objects exist outside of BEEP and so will xCal objects. Which is why I want the MIME type to be application/ical+xml (or what ever) and not appliction/beep+xml for any XML iCal objects. And why I want to keep text/calendar for any object that can be transported via iTIP. > i'm new to this (the last time i looked at CAP it was still CSTP) so > maybe i'm missing something. my implementation of CAP will use BEEP > purely as an API and so will not know anything about how it works. BEEP is not an API. So we have to describe the model. From owner-ietf-calendar@mail.imc.org Fri Mar 22 11:44: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 LAA25812 for ; Fri, 22 Mar 2002 11:44:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2MGXuQ11932 for ietf-calendar-bks; Fri, 22 Mar 2002 08:33:56 -0800 (PST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MGXt411924 for ; Fri, 22 Mar 2002 08:33:55 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3.Beta0/8.12.2.Beta3) with ESMTP id g2MGXi4F001912; Fri, 22 Mar 2002 11:33:44 -0500 Date: Fri, 22 Mar 2002 11:33:44 -0500 Message-Id: <200203221633.g2MGXi4F001912@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Doug Royer Cc: Steve Mansour , CalSched IETF In-reply-to: <3C9B5394.6030508@Royer.com> Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9B5394.6030508@Royer.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Fri, 22 Mar 2002 08:53:56 -0700 From: Doug Royer [...] ISO transport died? :-) The word "transport" was used. I don't know what definition was being applied. (3) There are CAP commands and iCalendar objects. We agreed the CAP 'commands' can be XML. (6) The WG agreed that CAP MUST BE iCalendar objects. I don't understand how these two points cooperate. I think my message was asking why CAP 'commands' are XML; the iCalendar object appears to contain all of the information necessary. I am _not_ arguing that the WG should adapt xCal objects. Larry From owner-ietf-calendar@mail.imc.org Fri Mar 22 12:08: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 MAA26239 for ; Fri, 22 Mar 2002 12:08:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2MGvai13346 for ietf-calendar-bks; Fri, 22 Mar 2002 08:57:36 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MGvZ413341 for ; Fri, 22 Mar 2002 08:57:35 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2MGvUdx026380 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 22 Mar 2002 08:57:34 -0800 (PST) Message-ID: <3C9B6276.3010909@Royer.com> Date: Fri, 22 Mar 2002 09:57:26 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9B5394.6030508@Royer.com> <200203221633.g2MGXi4F001912@lin2.andrew.cmu.edu> 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 Lawrence Greenfield wrote: > > (3) There are CAP commands and iCalendar objects. > We agreed the CAP 'commands' can be XML. > > (6) The WG agreed that CAP MUST BE iCalendar objects. > > I don't understand how these two points cooperate. > > I think my message was asking why CAP 'commands' are XML; the > iCalendar object appears to contain all of the information necessary. I agree - it is called compromise. I would prefer if EVERYTHING was a iCalendar object in CAP. Then xCal (or an add on) could specify an optional capability for a CS. Pre-BEEP, the CAP commands were non-iCalendar objects. So it looked like a good place to split. > I am _not_ arguing that the WG should adapt xCal objects. Thanks. From owner-ietf-calendar@mail.imc.org Fri Mar 22 16:50:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02555 for ; Fri, 22 Mar 2002 16:50:34 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2MLaCH25913 for ietf-calendar-bks; Fri, 22 Mar 2002 13:36:12 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MLaA425908 for ; Fri, 22 Mar 2002 13:36:10 -0800 (PST) To: Doug Royer Cc: CalSched IETF , Lawrence Greenfield , owner-ietf-calendar@mail.imc.org, Steve Mansour Subject: Re: CAP / BEEP / XML / iCalendar MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 22 Mar 2002 16:35:52 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.8 |June 18, 2001) at 03/22/2002 04:36:13 PM, Serialize complete at 03/22/2002 04:36:13 PM Content-Type: multipart/alternative; boundary="=_alternative 0076A42005256B84_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076A42005256B84_= Content-Type: text/plain; charset="us-ascii" In your note you said, under issues: >> (3) There are CAP commands and iCalendar objects. We agreed the CAP 'commands' can be XML. I know we said we would use XML to represent BEEP objects. I don't remember saying we agreed all CAP commands would be XML. Or am I missing something? --=_alternative 0076A42005256B84_= Content-Type: text/html; charset="us-ascii"
In your note you said, under issues:

>>  (3) There are CAP commands and iCalendar objects.
      We agreed the CAP 'commands' can be XML.

I know we said we would use XML to represent BEEP objects.  I don't remember saying we agreed all CAP commands would be XML.  Or am I missing something?

--=_alternative 0076A42005256B84_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 22 17:04: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 RAA02809 for ; Fri, 22 Mar 2002 17:04:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2MLkqL26228 for ietf-calendar-bks; Fri, 22 Mar 2002 13:46:52 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MLkp426221 for ; Fri, 22 Mar 2002 13:46:51 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2MLkmdx000329 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 22 Mar 2002 13:46:53 -0800 (PST) Message-ID: <3C9BA642.3070403@Royer.com> Date: Fri, 22 Mar 2002 14:46:42 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar 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 Glad to hear that! I did not want them at all. I think they can be in all cases the METHOD: BEGIN:VCALENDAR VERSION:2.0 METHOD:GET-CAPABILITIES END:VCALENDAR And so on ... pregen@egenconsulting.com wrote: > > In your note you said, under issues: > > >> (3) There are CAP commands and iCalendar objects. > We agreed the CAP 'commands' can be XML. > > I know we said we would use XML to represent BEEP objects. I don't > remember saying we agreed all CAP commands would be XML. Or am I > missing something? > From owner-ietf-calendar@mail.imc.org Fri Mar 22 17:58: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 RAA03697 for ; Fri, 22 Mar 2002 17:58:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2MMiXj27570 for ietf-calendar-bks; Fri, 22 Mar 2002 14:44:33 -0800 (PST) Received: from mx.infradig.com (c17802.fitzg1.qld.optusnet.com.au [210.49.37.156]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MMiK427560 for ; Fri, 22 Mar 2002 14:44:31 -0800 (PST) Received: from localhost ([127.0.0.1]) by localhost with ESMTP id <3C9BB36A.0000006E@infradig.com> for ; Fri, 22 Mar 2002 22:42:50 GMT Date: Sat, 23 Mar 2002 08:42:50 +1000 From: Andrew Davison Organization: Infradig Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> <3C9AB5CD.000000A6@infradig.com> <3C9B54AD.7040704@Royer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3C9BB36A.0000006E@infradig.com> X-Authenticated-Sender: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Andrew Davison wrote: > >> i'm new to this (the last time i looked at CAP it was still CSTP) so >> maybe i'm missing something. my implementation of CAP will use BEEP >> purely as an API and so will not know anything about how it works. > > > BEEP is not an API. So we have to describe the model. why not, it's how i implemented it? if the content-type is 'application/beep+xml' then it's a beep control message and the BEEP API (or transport layer) processes it, anything else is passed up to the application layer, in this case CAP. so CAP needs knows nothing about how BEEP works and knows nothing about 'application/beep+xml' types. in my implementation it never even sees MSG or RPY or ANS or NUL or SEQ or 'application/beep+xml' stuff, CAP is just payload data. other applications may also choose to layer themselves over BEEP. i don't really care about whether CAP uses XML itself (ie. 'application/cap+xml'). my only issue is that CAP spec seems to concern itself with how BEEP works, when there is no need for it. From owner-ietf-calendar@mail.imc.org Fri Mar 22 18:18: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 SAA03977 for ; Fri, 22 Mar 2002 18:18:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2MN5xP27887 for ietf-calendar-bks; Fri, 22 Mar 2002 15:05:59 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MN5v427876 for ; Fri, 22 Mar 2002 15:05:57 -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 g2MN5rO19691 for ; Fri, 22 Mar 2002 15:05:53 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTEDHK00.J6B for ; Fri, 22 Mar 2002 15:05:44 -0800 Message-ID: <3C9BADAD.A6132667@netscape.com> Date: Fri, 22 Mar 2002 14:18:21 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9BA642.3070403@Royer.com> Content-Type: multipart/mixed; boundary="------------B590BC5A0B30621A216DD812" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B590BC5A0B30621A216DD812 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Glad to hear that! > > I did not want them at all. I think they can be in all cases the > METHOD: > > BEGIN:VCALENDAR > VERSION:2.0 > METHOD:GET-CAPABILITIES > > END:VCALENDAR > > And so on ... I agree. This is where it needs to go. -Steve --------------B590BC5A0B30621A216DD812 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;AOL / Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Director of Engineering fn:Steve Mansour end:vcard --------------B590BC5A0B30621A216DD812-- From owner-ietf-calendar@mail.imc.org Fri Mar 22 18:18: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 SAA03989 for ; Fri, 22 Mar 2002 18:18:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2MN5xu27888 for ietf-calendar-bks; Fri, 22 Mar 2002 15:05:59 -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 g2MN5w427880 for ; Fri, 22 Mar 2002 15:05:58 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g2MN5s725306 for ; Fri, 22 Mar 2002 15:05:55 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTEDHJ00.8FV; Fri, 22 Mar 2002 15:05:43 -0800 Message-ID: <3C9BACAC.BEFED078@netscape.com> Date: Fri, 22 Mar 2002 14:14:04 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> Content-Type: multipart/mixed; boundary="------------1A907B8E55175C96963B2550" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1A907B8E55175C96963B2550 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lawrence Greenfield wrote: > Hi Steve, > > I'm one of those people who gets easily confused. Looking at the OSI > model, the "transport layer" is layer 4, and is occupied by TCP. If > anything, BEEP occupies the "presentation" layer. Larry, we're not thinking of the OSI model. We're thinking very CAP-centric. We're using transport to mean something that gets a blob of iCalendar information from here to there; it doesn't attempt to crack open what's in the blob or make sense of it. The transport's only responsibility is to shuttle iCalendar blobs. Originally, we rolled our own (remember the old SENDDATA command?). We were asked to look at BEEP so that we wouldn't have to create yet another transport. BEEP provides everything we need to shuttle iCalendar blobs, multiple channels, etc. > My general confusion is why certain things were chosen to be put into > the XML _application_ layer (such as "") and what was put > into the payload (the iCAP CDATA blobs). here's one example from > draft 07: OK, I agree. It's not exactly the point I wanted to nail, but I can see why you brought it up here. We're providing hints about what's inside the blob -- yet, as I stated above, the transport should not know anything about what's inside the blob. So, We need to fix that. We should probably stick with something generic like . There should not be any requirement to see what command we're executing from the transport layer. > Lines 4-19 are specified by CAP and are in the application layer. > These lines consist of a single command, "search". The search command > appears to have three parameters: two of them are attributes > ("latency" and "ask") and one of them is in the body (the CDATA iCAP > object). The fact that we put the command name in the transport mislead you. "latency" and "ask" are purely transport functions from CAP's point of view. They apply to all the blobs that a CUA sends to a CS over BEEP. > At this point, there appears to be much more investment into making > more iCal objects; in fact, the examples in 6.2.2.5 don't even show > the XML! Is there any reason for any of the XML fragments besides > that BEEP uses XML messages for some of it's presentation? We needed some syntax for the transport. BEEP used XML. So, we used it too. No deeper reason than that. I'm hoping that we can put the XML portion of this problem into perspective. It is a *very* small part of what we're doing with CAP. It's just a detail that goes along with using BEEP. We haven't done a good enough job at making clear the distinction between CAPs transport and application layers. Your suggestion about the command names will help make the distinction clearer. The other thing is that the XML part of the protocol is going to be a very, very minor part. Probably two or three lines, compared to hundreds or thousands of lines of iCalendar. Do you still have concerns if the example you sent looked more like this: 1 C: MSG 1 4 . 2043 680 2 C: Content-Type: application/cap+xml 3 C: 4 C: 5 C: = '19990714T080000Z' AND 15 C: DTSTART <= '19990715T080000Z' 16 C: END:VQUERY 17 C: END:VCALENDAR 18 C: ]]> 19 C: 20 C: END -Steve --------------1A907B8E55175C96963B2550 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;AOL / Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Director of Engineering fn:Steve Mansour end:vcard --------------1A907B8E55175C96963B2550-- From owner-ietf-calendar@mail.imc.org Fri Mar 22 19:05: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 TAA04612 for ; Fri, 22 Mar 2002 19:05:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2MNm6928518 for ietf-calendar-bks; Fri, 22 Mar 2002 15:48:06 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2MNm4428514 for ; Fri, 22 Mar 2002 15:48:04 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2MNm2dx001962 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 22 Mar 2002 15:48:07 -0800 (PST) Message-ID: <3C9BC2AB.5000309@Royer.com> Date: Fri, 22 Mar 2002 16:47:55 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar References: <3C9AA7B6.2D4459DF@netscape.com> <3C9AB5CD.000000A6@infradig.com> <3C9B54AD.7040704@Royer.com> <3C9BB36A.0000006E@infradig.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 Andrew Davison wrote: > > > Doug Royer wrote: > >> Andrew Davison wrote: >> >>> i'm new to this (the last time i looked at CAP it was still CSTP) so >>> maybe i'm missing something. my implementation of CAP will use BEEP >>> purely as an API and so will not know anything about how it works. >> >> >> >> BEEP is not an API. So we have to describe the model. > why not, it's how i implemented it? You have implemented an API (Application Programming Interface) for your BEEP protocol implementation. But BEEP is a protocol not an API. If BEEP were an API it would have specified function calls, and it does not specify any. send_data(char * blob); get_data() ... BEEP has some options and we must agree which options we have to use in order for it to be compatible with every other CAP implementation. Other than that, I agree - just say use BEEP, and I think that 07 is closer to that goal. From owner-ietf-calendar@mail.imc.org Sat Mar 23 21:59: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 VAA29286 for ; Sat, 23 Mar 2002 21:59:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2O2k6o18620 for ietf-calendar-bks; Sat, 23 Mar 2002 18:46:06 -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 g2O2k5418614 for ; Sat, 23 Mar 2002 18:46:05 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g2O2k1O12746 for ; Sat, 23 Mar 2002 18:46:01 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTGICQ00.2TM for ; Sat, 23 Mar 2002 18:46:02 -0800 Message-ID: <3C9D3EEC.E47D70A0@netscape.com> Date: Sat, 23 Mar 2002 18:50:20 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP issues, Sections 1 and 2 Content-Type: multipart/mixed; boundary="------------179A7BE53626847BD14C7E08" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------179A7BE53626847BD14C7E08 Content-Type: multipart/alternative; boundary="------------C47DC2296AA39C65DCBCECD7" --------------C47DC2296AA39C65DCBCECD7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All, Here are some issues I found in reviewing draft 07 sections 1 and 2. Pat (or a designate) will be keeping track of them and we'll plow through 'em. Comments ABNF for new iCalendar components needs to be presented early in the draft, before we use them. We currently make use of many components in the draft before they have been defined. The diagram that described the mental model for Scheduled events versus Booked events on the store was lost, and no discussion was present. We need to explain it. Why was it removed? Section 1.3 "A marked for delete component has its METHOD property set to DELETE". We need to update components to include a METHOD property. METHOD is probably a misnomer for what we're doing. METHOD is an action. We store state and values in components. Something like WORKFLOWSTATE is probably more relevant (if not a mouthful). We have not stated what properties MUST be maintained for DELETEd components. I think, at a minimum, we need to save the UID for everything and the RECURRENCE-ID if it makes sense. For the definition of Calendar Identifier -- the last sentence states "All CaliIDs start with cap:". Do we really want the CalID to indicate the protocol? Seems like the CSID and RelativeCalID would be enough. Section 2.2 I cannot figure out how stored queries are going to be useful. It seems like some values in every query are going to need to be tweeked everytime someone tries to use them. Most queries will include a time range or a specific UID (and RECURRENC-ID). The date, time will certainly need to be changed for each query over a time range. Same for queries that involve a particular UID. These two types of queries seem to me to be the ones that a CAP server will need to process most of the time. I suppose that since the TARGET can be specified outside the query, there will be some queries that will not change. But these seem to me to be in th 5 to 10% range for all the queries that a CAP server will process. Are stored queries worth it? Section 2.3 I recommend we just have a simple transport protocol command like or or something like that. The commands we list are Application Protocol commands, their names suggest more than just a command to move a bundle of data between a CUA and a CS. Section 2.4.2 This is a big change proposal. Currently the access control model is to deny access to anything unless it is explicitly granted. Paul Hill has proposed that we change this model to grant access to everything unless specifically denied. Paul will follow this up with a more detailed poposal, but the gist of it is as follows: * It will be quicker to process. With the current model, you have to process all the grants and all the denies to see whether or not you're left with access to something. With the newly proposed model, once you find a VCAR that denies access to something, you can stop processing and reject access. * More storage efficient (I'll let Paul field this one) * Usability - Paul can speak to this point better, but the idea is that in a model where you have to explicitly grant access to things, new VCARs will need to be added to grant access to them. * Mimicks other systems, for example the Windows 2000 file system. * may obviate the need for DECREED VCARs (even more). Section 2.4.2.2 Why do we need CAR-MIN ? Is it to support things like CRISP? We need to discuss why we need it. Are the predefined VCARs in this section meant to be the definition of CAR-MIN. If so, we should explicitly state it. For the VCAR with CARID UPDATEPARTSTATUS, I do not understand the SCOPE section and the next few lines. If the example is correct, then we need and explanation. If it is not correct, we need to fix it. We may need to rewrite these VCARs if the big change in 2.4.2 is made. Section 2.4.2.3 Can someone explain why we need DECREED VCARs? Unless there is something that we really can't do with VCARs we should just remove this section and the notion of DECREED VCARs. Implementations will already have to do an administrative tool to put DECREED VCARs on the store. Why not just have them write regular old VCARs and secure these VCARs so that no one can change them? If, for some reason, we need to keep DECREED VCARs then there are some misleading things between the second and fourth paragraphs. The fourth paragraph states that "The DENY property disallows anyone from being able to delete or modify this VCAR". But the second paragraph states that users cannot modify or override DECREED VCARs. Section 2.4.3 I recommend we change the last sentence of the 3rd paragraph to read: A UPN with a non-null Username and null Realm, such as "bob@", could be a security risk and MUST be treated as anonymous. Section 2.5 Roles are defined in iTIP. We have not added anything. Let's remove this section. Section 2.6 The capurl syntax provided allows for the following: cap:/abcd1234 cap: These just look like a mistakes. I recommend: capurl = scheme ":" "//" csid [ "/" ] [relcalid] Examples: cap://cal.example.com/ # this is a CS cap://cal.example.com/asdf12345 # this is a VAGENDA (a calendar) If we leave in the note about relative calids I think we'll have everything covered. --------------C47DC2296AA39C65DCBCECD7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All,

Here are some issues I found in reviewing draft 07 sections 1 and 2. Pat (or a designate) will be keeping track of them and we'll plow through 'em.

Comments

ABNF for new iCalendar components needs to be presented early in the draft, before we use them. We currently make use of many components in the draft before they have been defined.

The diagram that described the mental model for Scheduled events versus Booked events on the store was lost, and no discussion was present. We need to explain it. Why was it removed?


Section 1.3

"A marked for delete component has its METHOD property set to DELETE".  We need to update components to include a METHOD property.  METHOD is probably a misnomer for what we're doing.  METHOD is an action. We store state and values in components.  Something like WORKFLOWSTATE is probably more relevant (if not a mouthful).

We have not stated what properties MUST be maintained for DELETEd components.  I think, at a minimum, we need to save the UID for everything and the RECURRENCE-ID if it makes sense.

For the definition of Calendar Identifier -- the last sentence states "All CaliIDs start with cap:".  Do we really want the CalID to indicate the protocol?  Seems like the CSID and RelativeCalID would be enough.

Section 2.2
I cannot figure out how stored queries are going to be useful. It seems like some values in every query are going to need to be tweeked everytime someone tries to use them.  Most queries will include a time range or a specific UID (and RECURRENC-ID). The date, time will certainly need to be changed for each query over a time range. Same for queries that involve a particular UID. These two types of queries seem to me to be the ones that a CAP server will need to process most of the time. I suppose that since the TARGET can be specified outside the query, there will be some queries that will not change. But these seem to me to be in th 5 to 10% range for all the queries that a CAP server will process.  Are stored queries worth it?
Section 2.3
I recommend we just have a simple transport protocol command like <senddata> or <cap> or something like that. The commands we list are Application Protocol commands, their names suggest more than just a command to move a bundle of data between a CUA and a CS.
Section 2.4.2
This is a big change proposal. Currently the access control model is to deny access to anything unless it is explicitly granted. Paul Hill has proposed that we change this model to grant access to everything unless specifically denied. Paul will follow this up with a more detailed poposal, but the gist of it is as follows:
  • It will be quicker to process.  With the current model, you have to process all the grants and all the denies to see whether or not you're left with access to something. With the newly proposed model, once you find a VCAR that denies access to something, you can stop processing and reject access.
  • More storage efficient (I'll let Paul field this one)
  • Usability - Paul can speak to this point better, but the idea is that in a model where you have to explicitly grant access to things, new VCARs will need to be added to grant access to them.
  • Mimicks other systems, for example the Windows 2000 file system.
  • may obviate the need for DECREED VCARs (even more).
Section 2.4.2.2
Why do we need CAR-MIN ?  Is it to support things like CRISP? We need to discuss why we need it.

Are the predefined VCARs in this section meant to be the definition of CAR-MIN.  If so, we should explicitly state it.

For the VCAR with CARID UPDATEPARTSTATUS, I do not understand the SCOPE section and the next few lines. If the example is correct, then we need and explanation. If it is not correct, we need to fix it.

We may need to rewrite these VCARs if the big change in 2.4.2 is made.

Section 2.4.2.3
Can someone explain why we need DECREED VCARs?  Unless there is something that we really can't do with VCARs  we should just remove this section and the notion of DECREED VCARs.  Implementations will already have to do an administrative tool to put DECREED VCARs on the store. Why not just have them write regular old VCARs and secure these VCARs so that no one can change them?

If, for some reason, we need to keep DECREED VCARs then there are some misleading things between the second and fourth paragraphs. The fourth paragraph states that "The DENY property disallows anyone from being able to delete or modify this VCAR". But the second paragraph states that users cannot modify or override DECREED VCARs.

Section 2.4.3
I recommend we change the last sentence of the 3rd paragraph to read:
A UPN with a non-null Username and null Realm, such as "bob@", could be a security risk and MUST be treated as anonymous.
Section 2.5
Roles are defined in iTIP. We have not added anything. Let's remove this section.
Section 2.6
The capurl syntax provided allows for the following:
cap:/abcd1234
cap:
These just look like a mistakes. I recommend:
capurl   = scheme ":" "//" csid [ "/" ] [relcalid]

Examples:

cap://cal.example.com/             # this is a CS
cap://cal.example.com/asdf12345    # this is a VAGENDA (a calendar)
If we leave in the note about relative calids I think we'll have everything covered.
--------------C47DC2296AA39C65DCBCECD7-- --------------179A7BE53626847BD14C7E08 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;AOL / Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Director of Engineering fn:Steve Mansour end:vcard --------------179A7BE53626847BD14C7E08-- From owner-ietf-calendar@mail.imc.org Sun Mar 24 13:35: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 NAA16567 for ; Sun, 24 Mar 2002 13:35:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2OINBQ18921 for ietf-calendar-bks; Sun, 24 Mar 2002 10:23:11 -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 g2OIN9418917 for ; Sun, 24 Mar 2002 10:23:09 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id g2OIMvO15873 for ; Sun, 24 Mar 2002 10:23:03 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTHPQC00.UY0 for ; Sun, 24 Mar 2002 10:23:00 -0800 Message-ID: <3C9E1A87.7B45A819@netscape.com> Date: Sun, 24 Mar 2002 10:27:19 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 References: <3C9D3EEC.E47D70A0@netscape.com> Content-Type: multipart/mixed; boundary="------------58E88DDF77D4859FD91CB2F0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------58E88DDF77D4859FD91CB2F0 Content-Type: multipart/alternative; boundary="------------70FAE61D44AB8B48177CA866" --------------70FAE61D44AB8B48177CA866 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit slight correction... Steve Mansour wrote: > Section 2.6 > > The capurl syntax provided allows for the following: > > cap:/abcd1234 > cap: > > These just look like a mistakes. I recommend: > capurl = scheme ":" "//" csid [[ "/" ] relcalid] -Steve --------------70FAE61D44AB8B48177CA866 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit slight correction...

Steve Mansour wrote:

Section 2.6
The capurl syntax provided allows for the following:
cap:/abcd1234
cap:
These just look like a mistakes. I recommend:
capurl   = scheme ":" "//" csid [[ "/" ] relcalid]
-Steve --------------70FAE61D44AB8B48177CA866-- --------------58E88DDF77D4859FD91CB2F0 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;AOL / Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Director of Engineering fn:Steve Mansour end:vcard --------------58E88DDF77D4859FD91CB2F0-- From owner-ietf-calendar@mail.imc.org Sun Mar 24 14:55: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 OAA17135 for ; Sun, 24 Mar 2002 14:55:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2OJjIa20769 for ietf-calendar-bks; Sun, 24 Mar 2002 11:45:18 -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 g2OJjH420765 for ; Sun, 24 Mar 2002 11:45:17 -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 g2OJix714712 for ; Sun, 24 Mar 2002 11:45:01 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTHTIX00.FUO for ; Sun, 24 Mar 2002 11:44:57 -0800 Message-ID: <3C9E2DB5.A1BD673B@netscape.com> Date: Sun, 24 Mar 2002 11:49:09 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> Content-Type: multipart/mixed; boundary="------------BF41B03DC4FF420E343B4FF1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BF41B03DC4FF420E343B4FF1 Content-Type: multipart/alternative; boundary="------------8DFBA95FF13AFD1D3D85D451" --------------8DFBA95FF13AFD1D3D85D451 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, After thinking about some of the feedback on this, I think that the XML encoding, while harmless, is superfluous. At the meeting in Minneapolis, we were thinking along these lines: ENCAPSULATION A C: MSG 1 2 . 1234 123 C: Content-type: application/cap+xml C: C: C: C: C: END The XML encapsulation is innocuous, but it adds nothing. Further, it tempts us to move things out of the Application layer and into the Transport layer (such as the command names, and attributes such as "latency" and "action" -- undermining the transport/application separation and leading us down slippery slopes. Here is a simpler alternative (and yes, I know some of you have been pushing for something like this all along :-) : ENCAPSULATION B C: MSG 1 2 . 1234 123 C: Content-type: text/calendar C: C: BEGIN:VCALENDAR C: METHOD:SEARCH C: LATENCY:3 C: ACTION:ASK ... C: END:VCALENDAR C: END The advantage of encapsulation B is that it represents exactly the same content as encapsulation A, but it uses one rather than two encapsulations and there are no hints about the calendaring commands in the transport. We could substitute *any* transport. Can anyone suggest why we would want to use encapsulation A rather than B ? Are there any objections to moving forward with encapsulations as specified in B ? -Steve --------------8DFBA95FF13AFD1D3D85D451 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Folks,

After thinking about some of the feedback on this, I think that the XML encoding, while harmless, is superfluous. At the meeting in Minneapolis, we were thinking along these lines:

ENCAPSULATION A

C: MSG 1 2 . 1234 123
C: Content-type: application/cap+xml
C:
C: <cap latency="3" action="ask">
C: <![CDATA[
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: METHOD:SEARCH
...
C: END:VCALENDAR
C: ]]>
C: </cap>
C: END

The XML encapsulation is innocuous, but it adds nothing. Further, it tempts us to move things out of the Application layer and into the Transport layer (such as the command names, and attributes such as "latency" and "action" -- undermining the transport/application separation and leading us down slippery slopes.  Here is a simpler alternative (and yes, I know some of you have been pushing for something like this all along :-) :
ENCAPSULATION B

C: MSG 1 2 . 1234 123
C: Content-type: text/calendar
C:
C: BEGIN:VCALENDAR
C: METHOD:SEARCH
C: LATENCY:3
C: ACTION:ASK
...
C: END:VCALENDAR
C: END

The advantage of encapsulation B is that it represents exactly the same content as encapsulation A, but it uses one rather than two encapsulations and there are no hints about the calendaring commands in the transport. We could substitute *any* transport.

Can anyone suggest why we would want to use encapsulation A rather than B ?

Are there any objections to moving forward with encapsulations as specified in B ?

-Steve --------------8DFBA95FF13AFD1D3D85D451-- --------------BF41B03DC4FF420E343B4FF1 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;AOL / Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Director of Engineering fn:Steve Mansour end:vcard --------------BF41B03DC4FF420E343B4FF1-- From owner-ietf-calendar@mail.imc.org Sun Mar 24 15:28: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 PAA17370 for ; Sun, 24 Mar 2002 15:28:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2OKJ6s22516 for ietf-calendar-bks; Sun, 24 Mar 2002 12:19:06 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2OKJ5422510 for ; Sun, 24 Mar 2002 12:19:05 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2OKJ0dx006924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 24 Mar 2002 12:19:06 -0800 (PST) Message-ID: <3C9E34AF.8080706@Royer.com> Date: Sun, 24 Mar 2002 13:18:55 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.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 Steve Mansour wrote: > > > The XML encapsulation is innocuous, but it adds nothing. Further, it > tempts us to move things out of the Application layer and into the > Transport layer (such as the command names, and attributes such as > "latency" and "action" -- undermining the transport/application > separation and leading us down slippery slopes. Here is a simpler > alternative (and yes, I know some of you have been pushing for something > like this all along :-) : > C: LATENCY:3 > C: ACTION:ASK Or perhaps: LATENCY;ACTION="ask":3 And YES - XML is not needed in CAP. From owner-ietf-calendar@mail.imc.org Sun Mar 24 15:28: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 PAA17382 for ; Sun, 24 Mar 2002 15:28:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2OKGX822126 for ietf-calendar-bks; Sun, 24 Mar 2002 12:16:33 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2OKGV422119 for ; Sun, 24 Mar 2002 12:16:31 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2OKGRdx006886 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 24 Mar 2002 12:16:32 -0800 (PST) Message-ID: <3C9E3416.1030605@Royer.com> Date: Sun, 24 Mar 2002 13:16:22 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF CC: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 References: <3C9D3EEC.E47D70A0@netscape.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 Steve Mansour wrote: > Section 1.3 > > "A marked for delete component has its METHOD property set to > DELETE". We need to update components to include a METHOD > property. METHOD is probably a misnomer for what we're doing. > METHOD is an action. We store state and values in components. > Something like WORKFLOWSTATE is probably more relevant (if not a > mouthful). How about CURRENTSTATE ? > We have not stated what properties MUST be maintained for DELETEd > components. I think, at a minimum, we need to save the UID for > everything and the RECURRENCE-ID if it makes sense. I had thought all of the component would be saved until it was removed. They are cleaned up later out of band to CAP. I don't recall there ever being a discussion about marked for delete meaning, 'part of them is removed'. > Section 2.2 > > I cannot figure out how stored queries are going to be useful. The TARGET is outside the stored QUERY, so just change the TARGET value and... ... QUERYNAME:Get all non-booked entries. SELECT * FROM VEVENT WHERE METHOD != BOOKED SELECT * FROM VTODO WHERE METHOD != BOOKED ... Similar for booked entries. Similar for all VCARs that effect me. Similar for all OWNED calendars. ... > ... Are stored queries > worth it? Yes for PDA's and other small devices that just get by query name. Also, I don't see any reason that a specific implementation can't have non-standard queries for 'get me today's stuff'. > Section 2.3 > > I recommend we just have a simple transport protocol command like > or or something like that. The commands we list are > Application Protocol commands, their names suggest more than just a > command to move a bundle of data between a CUA and a CS. I am still in favor of removing all XML from the CAP protocol and placing everything in VCALENDAR objects. > Section 2.4.2 > > This is a big change proposal. Currently the access control model is > to deny access to anything unless it is explicitly granted. Paul > Hill has proposed that we change this model to grant access to > everything unless specifically denied. Paul will follow this up with > a more detailed poposal, but the gist of it is as follows: > * It will be quicker to process. With the current model, you > have to process all the grants and all the denies to see > whether or not you're left with access to something. Or your CS can cache the net result as they are modified. Most CUA's are not going to change VCARs frequently. And you can 'hide' the cache or pointer to it in your stored object. Plus, for EVERY property and parameter I would have to deny you permission? Else it is public to everyone? Including the right to change them out from under me? Does not sound secure to me. > With the > newly proposed model, once you find a VCAR that denies access > to something, you can stop processing and reject access. We had been told in the past that that was not a good security model. > * Usability - Paul can speak to this point better, but the idea > is that in a model where you have to explicitly grant access > to things, new VCARs will need to be added to grant access to > them. Why? I grant you the right to see everything marked PUBLIC. Now I can add as many PUBLIC entries as I want and never change or add any VCAR. > * Mimicks other systems, for example the Windows 2000 file system. Windows is one of the worst OS when it comes to security. I don't see this as persuasive. > * may obviate the need for DECREED VCARs (even more). No, DECREED VCARs are administrative VCARs that can not be overridden by the UPN/CUA. How would it eliminate any administrative VCARs? One of the requirement from the LA meeting was that the admin gets to override permissions - thus decreed to a CUA/UPN. I would agree that the property named DECREED can go away. But not the concept of 'you can't change it'. > Section 2.4.2.2 > > Why do we need CAR-MIN ? Is it to support things like CRISP? We > need to discuss why we need it. The reason is that they include ONLY the pre-defined VCARS for devices like PDA's that will never be a full service CS. They will only use predefined VCARs and will never parse QUERY. > Are the predefined VCARs in this section meant to be the definition > of CAR-MIN. If so, we should explicitly state it. It used to say that they were the minimum set required and in CAP 1.0, it was 'the' set currently defined, and that they could be extended. > For the VCAR with CARID UPDATEPARTSTATUS, I do not understand the > SCOPE section and the next few lines. If the example is correct, > then we need and explanation. If it is not correct, we need to fix it. > It looks correct. It creates non-owner VCAR. And that VCAR allows them to ONLY update their participation status in the target calendar (and it grants nothing else). > We may need to rewrite these VCARs if the big change in 2.4.2 is made. > > Section 2.4.2.3 > > Can someone explain why we need DECREED VCARs? Unless there is > something that we really can't do with VCARs we should just remove > this section and the notion of DECREED VCARs. Implementations will > already have to do an administrative tool to put DECREED VCARs on > the store. Why not just have them write regular old VCARs and secure > these VCARs so that no one can change them? There are predefined VCARs for minimum CS's like PDA's. And YES there is no reason that a DECREED VCAR can't be represented by standard VCARs. And they can be dynamic. For non-owners, anything they can not change is DECREED to them, so I'll merge their results and just give them a dynamic VCAR who's CARID will be DECREED and they will never know that another UPN has access. I agree that I also don't see the need for a separate property. When as part of any dynamic (or static) VCAR, they can be denied permission in that same VCAR to modify it. So I think we agree that the property 'DECREED' goes away. But not the idea of admin hard coded VCARS - that used to be what we called DECREED. > If, for some reason, we need to keep DECREED VCARs then there are > some misleading things between the second and fourth paragraphs. The > fourth paragraph states that "The DENY property disallows anyone > from being able to delete or modify this VCAR". But the second > paragraph states that users cannot modify or override DECREED VCARs. I don't see a conflict between those two statements. By definition DECREED VCARs can not be changed by the CUA. True. But an administration process out side of CAP can change and modify them. I agree - there is NO need for a DECREED property. Just tag the VCAR itself as non-alterable when it is sent to the CUA. > Section 2.4.3 > > I recommend we change the last sentence of the 3rd paragraph to read: > > A UPN with a non-null Username and null Realm, such as "bob@", > could be a security risk and MUST be treated as anonymous. I don't like them ether, but if they can authenticate. So should we not allow them to then be subject to VCAR restrictions and not call them anonymous? Perhaps 'bob@' has more restrictions that anonymous once the VCARs are applied. > Section 2.5 > > Roles are defined in iTIP. We have not added anything. Let's remove > this section. I agree. > Section 2.6 > > The capurl syntax provided allows for the following: > > cap:/abcd1234 > cap: > > These just look like a mistakes. I recommend: > > capurl = scheme ":" "//" csid [[ "/" ] relcalid] And where 'scheme' is 'cap' - yes I agree. > If we leave in the note about relative calids I think we'll have > everything covered. > Yes. From owner-ietf-calendar@mail.imc.org Sun Mar 24 15:42: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 PAA17528 for ; Sun, 24 Mar 2002 15:42:23 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2OKXFu23542 for ietf-calendar-bks; Sun, 24 Mar 2002 12:33:15 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2OKXD423537 for ; Sun, 24 Mar 2002 12:33:13 -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 g2OKX9710939; Sun, 24 Mar 2002 12:33:09 -0800 (PST) Received: from sman-cpi ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTHVR900.0YV; Sun, 24 Mar 2002 12:33:10 -0800 Date: Sun, 24 Mar 2002 12:30:33 -0800 (Pacific Standard Time) From: sman@netscape.com (Steve Mansour) Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal To: CalSched IETF cc: CalSched IETF In-Reply-To: <3C9E34AF.8080706@Royer.com> Message-ID: <3C9E3769.5050408@netscape.com> References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9E34AF.8080706@Royer.com> X-Mailer: Photon, lighting the way, build 2002-03-07-13:57:16 (built by rogc) MIME-Version: 1.0 Content-Type: TEXT/HTML; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: QUOTED-PRINTABLE Doug Royer wrote:=20

Steve Mansour wrote: 

> The XML encapsulation is=20 innocuous, but it adds nothing. Further, it
> tempts us to move th= ings=20 out of the Application layer and into the
> Transport layer (such = as=20 the command names, and attributes such as
> "latency" and "action"= --=20 undermining the transport/application
> separation and leading us = down=20 slippery slopes.  Here is a simpler
> alternative (and yes, I= know=20 some of you have been pushing for something
> like this all along = :-) :=20

>     C: LATENCY:3=20
>     C: ACTION:ASK


Or perhaps:=20

       =20         LATENCY;ACTION=3D"ask":3=20

yep. this is better than two separate properties.

-Steve

S= teve=20 Mansour
Director of Engineering
AOL / Netscape
AIM=20 StMansour

From owner-ietf-calendar@mail.imc.org Sun Mar 24 19:11: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 TAA20052 for ; Sun, 24 Mar 2002 19:11:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2P01C526350 for ietf-calendar-bks; Sun, 24 Mar 2002 16:01:12 -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 g2P01A426345 for ; Sun, 24 Mar 2002 16:01:10 -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 g2P015O02438 for ; Sun, 24 Mar 2002 16:01:06 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTI5DV00.K42 for ; Sun, 24 Mar 2002 16:01:07 -0800 Message-ID: <3C9E69C6.685D0550@netscape.com> Date: Sun, 24 Mar 2002 16:05:26 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP draft 07 issues - sections 3 and 4 Content-Type: multipart/mixed; boundary="------------19C81AD2E66B12E13C2EC032" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------19C81AD2E66B12E13C2EC032 Content-Type: multipart/alternative; boundary="------------A52F29FCDB8194235131BC75" --------------A52F29FCDB8194235131BC75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ... continued: Section 3.1 seems superfluous and covered in BEEP. do we really need this? Section 3.2 (already posted to the list because we're trying to resolve this now). The XML encoding, while harmless, is superfluous. At the meeting in Minneapolis, we were thinking along these lines: ENCAPSULATION A C: MSG 1 2 . 1234 123 C: Content-type: application/cap+xml C: C: C: C: C: END The XML encapsulation is innocuous, but it adds nothing. Further, it tempts us to move things out of the Application layer and into the Transport layer (such as the command names, and attributes such as "latency" and "action" -- undermining the transport/application separation and leading us down slippery slopes. Here is a simpler alternative (and yes, I know some of you have been pushing for something like this all along :-) : ENCAPSULATION B C: MSG 1 2 . 1234 123 C: Content-type: text/calendar C: C: BEGIN:VCALENDAR C: METHOD:SEARCH C: LATENCY:3 C: ACTION:ASK ... C: END:VCALENDAR C: END The advantage of encapsulation B is that it represents exactly the same content as encapsulation A, but it uses one rather than two encapsulations and there are no hints about the calendaring commands in the transport. We could substitute *any* transport. Section 3.3 Second paragraph should end with a sentence describing what happens on an aborted command. The easy thing to do is something like this: Partial results indicating homw much of the command completed MAY be returned. Or we may want to get more ambitious require a precise reply. The third and fourth paragraphs will need to go wherever we define Latency and Action. The last RPY message on the last example of the section. This should probably become an application level error reply rather than a transport level reply. Section 4.1 bullet (1) -- we should state how to handle Parameters, and how to handle components that contain other components. bullet (3) -- what is the reasoning behind this limitation? bullet (7) -- I'm not sure I understand the problem here. Can someone illustrate the point we're trying to make with an example? bullet (7) -- do we really need USING_PROPERTIES and USING_COMPONENTS ? I don't see the value based on the examples. Is it just a shorthand to save characters? Section 4.1.1 - FLOATING TIME EVENTS We need to clarify how we search for floating time events. If we're going to send UTC times in queries, then I don't see how we can search for floating time events. Seems like the only way to get the "floaters" is to do a separate query for them where we specify the floating time range for the query. Section 4.1.1 I'm just confused by reading it. I think it needs to be made clearer. The examples are throwing me off. Section 4.1.1 bullet (7) - There's still a reference to CONTAINS(). Also, the next to the last paragraph seems like it will be a problem. When the schema is updated, servers won't know whether a new component / property is multivalued or not. Section 4.1.1 bullet (8) - There were some typos fixed, but it seems like there are two logic errors. '%,%' IN parameter should match NONE -- currently says it matches (d) and (e) LIKE(parameter, ',') should match (e) -- currently says it would NOT match any Section 4.3 This is really not an issue with section 4.3. It just became clear when I read the example. I don't think we've defined anywhere that we're moving METHOD into components. We need to define this property somewhere. Also, as we're using it in the VEVENT, VTODO, and VJOURNAL, it is less an action and more a state. It's name should reflect its use. So, something like WORKFLOWSTATE is probably better. We need to define when it is set, especially in the iTIP workflow. I recommend that the CUA be responsible for explicitly setting this Another problem associated with this is that when data is migrated out of an ITIP wrapper and into a component, it will be a lossy transformation as things stand today. For example, consider the following ITIP request: BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ... END:VEVENT END:VCALENDAR We are talking about migrating the METHOD:REQUEST value into a new component property like WORKFLOWSTATE. But what about information like PRODID and VERSION ? Might those or other values contained in the VCALENDAR become significant over time? Do we just toss them? One suggestion in Minneapolis was to create a new component called VITIP that would contain everything in the ITIP request. Do we need something like VITIP ? or is migrating the METHOD value into WORKFLOWSTATE good enough? Section 4.7 In the example: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT USING_COMPONENT VALARM my-alarm WHERE my-alarm.TRIGGER >= '20000101T030405Z' AND my-alarm.TRIGGER <= '20001231T235959Z' AND METHOD = 'CREATE' END:VQUERY use of "USING_COMPONENT" seems like it's not buying us much. Seems like this example could actually be shortened by writing it without the USING_COMPONENT line: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT WHERE VALARM.TRIGGER >= '20000101T030405Z' AND VALARM.TRIGGER <= '20001231T235959Z' AND METHOD = 'CREATE' END:VQUERY The example may simply not constructed to show the real value of "USING_COMPONENT". Can someone describe the real value of this? Or can we drop it? Same thing for "USING_PROPERTY". Section 4.7 The example just reminded me: I propose that we add a UID property to VALARM. We (Netscape) have implemented a calendar server where this value is very useful. Our experience has been that you have to jump through hoops to figure out which of multiple alarms you need to work on if you don't have this UID value. --------------A52F29FCDB8194235131BC75 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ... continued:

Section 3.1

seems superfluous and covered in BEEP. do we really need this?
Section 3.2
(already posted to the list because we're trying to resolve this now). The XML encoding, while harmless, is superfluous. At the meeting in Minneapolis, we were thinking along these lines:
ENCAPSULATION A

C: MSG 1 2 . 1234 123
C: Content-type: application/cap+xml
C:
C: <cap latency="3" action="ask">
C: <![CDATA[
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: METHOD:SEARCH
...
C: END:VCALENDAR
C: ]]>
C: </cap>
C: END

The XML encapsulation is innocuous, but it adds nothing. Further, it tempts us to move things out of the Application layer and into the Transport layer (such as the command names, and attributes such as "latency" and "action" -- undermining the transport/application separation and leading us down slippery slopes.  Here is a simpler alternative (and yes, I know some of you have been pushing for something like this all along :-) :
ENCAPSULATION B

C: MSG 1 2 . 1234 123
C: Content-type: text/calendar
C:
C: BEGIN:VCALENDAR
C: METHOD:SEARCH
C: LATENCY:3
C: ACTION:ASK
...
C: END:VCALENDAR
C: END

The advantage of encapsulation B is that it represents exactly the same content as encapsulation A, but it uses one rather than two encapsulations and there are no hints about the calendaring commands in the transport. We could substitute *any* transport.
Section 3.3
Second paragraph should end with a sentence describing what happens on an aborted command. The easy thing to do is something like this:
Partial results indicating homw much of the command completed MAY be returned.
Or we may want to get more ambitious require a precise reply.

The third and fourth paragraphs will need to go wherever we define Latency and Action.

The last RPY message on the last example of the section. This should probably become an application level error reply rather than a transport level reply.

Section 4.1
bullet (1) -- we should state how to handle Parameters, and how to handle components that contain other components.

bullet (3) -- what is the reasoning behind this limitation?

bullet (7) -- I'm not sure I understand the problem here. Can someone illustrate the point we're trying to make with an example?

bullet (7) -- do we really need USING_PROPERTIES and USING_COMPONENTS ?  I don't see the value based on the examples.  Is it just a shorthand to save characters?
 

Section 4.1.1 - FLOATING TIME EVENTS
We need to clarify how we search for floating time events. If we're going to send UTC times in queries, then I don't see how we can search for floating time events.  Seems like the only way to get the "floaters" is to do a separate query for them where we specify the floating time range for the query.
Section 4.1.1
I'm just confused by reading it. I think it needs to be made clearer. The examples are throwing me off.
Section 4.1.1
bullet (7) -  There's still a reference to CONTAINS().  Also, the next to the last paragraph seems like it will be a problem. When the schema is updated, servers won't know whether a new component / property is multivalued or not.
Section 4.1.1
bullet (8) - There were some typos fixed, but it seems like there are two logic errors.
'%,%' IN parameter  should match NONE -- currently says it matches (d) and (e)
LIKE(parameter, ',')  should match (e) -- currently says it would NOT match any
Section 4.3
This is really not an issue with section 4.3. It just became clear when I read the example. I don't think we've defined anywhere that we're moving METHOD into components. We need to define this property somewhere. Also, as we're using it in the VEVENT, VTODO, and VJOURNAL, it is less an action and more a state. It's name should reflect its use.  So, something like WORKFLOWSTATE is probably better.

We need to define when it is set, especially in the iTIP workflow. I recommend that the CUA be responsible for explicitly setting this

Another problem associated with this is that when data is migrated out of an ITIP wrapper and into a component, it will be a lossy transformation as things stand today.  For example, consider the following ITIP request:

BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
...
END:VEVENT
END:VCALENDAR
We are talking about migrating the METHOD:REQUEST value into a new component property like WORKFLOWSTATE. But what about information like PRODID and VERSION ?  Might those or other values contained in the VCALENDAR become significant over time?  Do we just toss them?

One suggestion in Minneapolis was to create a new component called VITIP that would contain everything in the ITIP request.

Do we need something like VITIP ?   or is migrating the METHOD value into WORKFLOWSTATE good enough?

Section 4.7
In the example:
BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
  USING_COMPONENT VALARM my-alarm
  WHERE my-alarm.TRIGGER >= '20000101T030405Z'
  AND my-alarm.TRIGGER <= '20001231T235959Z'
  AND METHOD = 'CREATE'
END:VQUERY
use of "USING_COMPONENT" seems like it's not buying us much. Seems like this example could actually be shortened by writing it without the USING_COMPONENT line:
BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
  WHERE VALARM.TRIGGER >= '20000101T030405Z'
  AND VALARM.TRIGGER <= '20001231T235959Z'
  AND METHOD = 'CREATE'
END:VQUERY
The example may simply not constructed to show the real value of "USING_COMPONENT".  Can someone describe the real value of this?  Or can we drop it?   Same thing for "USING_PROPERTY".
Section 4.7
The example just reminded me: I propose that we add a UID property to VALARM.  We (Netscape) have implemented a calendar server where this value is very useful. Our experience has been that you have to jump through hoops to figure out which of multiple alarms you need to work on if you don't have this UID value.
--------------A52F29FCDB8194235131BC75-- --------------19C81AD2E66B12E13C2EC032 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;AOL / Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Director of Engineering fn:Steve Mansour end:vcard --------------19C81AD2E66B12E13C2EC032-- From owner-ietf-calendar@mail.imc.org Mon Mar 25 07:39: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 HAA07638 for ; Mon, 25 Mar 2002 07:39:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PCSix19164 for ietf-calendar-bks; Mon, 25 Mar 2002 04:28:44 -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 g2PCSh419160 for ; Mon, 25 Mar 2002 04:28:43 -0800 (PST) Received: from jsoft.com (IDENT:iJAMseQiZFBr0sYQ3v/aG02S87IJByt4@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2PCRTV08560; Mon, 25 Mar 2002 06:27:29 -0600 Message-ID: <3C9F17B0.3030607@jsoft.com> Date: Mon, 25 Mar 2002 06:27:28 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.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 What would the XML version of encapsulation B look like? Gary Steve Mansour wrote: > Folks, > > After thinking about some of the feedback on this, I think that the XML > encoding, while harmless, is superfluous. At the meeting in Minneapolis, > we were thinking along these lines: > > ENCAPSULATION A > > C: MSG 1 2 . 1234 123 > C: Content-type: application/cap+xml > C: > C: > C: C: Content-Type: text/calendar > C: > C: BEGIN:VCALENDAR > C: METHOD:SEARCH > ... > C: END:VCALENDAR > C: ]]> > C: > C: END > > The XML encapsulation is innocuous, but it adds nothing. Further, it > tempts us to move things out of the Application layer and into the > Transport layer (such as the command names, and attributes such as > "latency" and "action" -- undermining the transport/application > separation and leading us down slippery slopes. Here is a simpler > alternative (and yes, I know some of you have been pushing for something > like this all along :-) : > > ENCAPSULATION B > > C: MSG 1 2 . 1234 123 > C: Content-type: text/calendar > C: > C: BEGIN:VCALENDAR > C: METHOD:SEARCH > C: LATENCY:3 > C: ACTION:ASK > ... > C: END:VCALENDAR > C: END > > The advantage of encapsulation B is that it represents exactly the same > content as encapsulation A, but it uses one rather than two > encapsulations and there are no hints about the calendaring commands in > the transport. We could substitute *any* transport. > > Can anyone suggest why we would want to use encapsulation A rather than B ? > > Are there any objections to moving forward with encapsulations as > specified in B ? > > -Steve > From owner-ietf-calendar@mail.imc.org Mon Mar 25 07:39: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 HAA07650 for ; Mon, 25 Mar 2002 07:39:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PCQt019136 for ietf-calendar-bks; Mon, 25 Mar 2002 04:26:55 -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 g2PCQs419132 for ; Mon, 25 Mar 2002 04:26:54 -0800 (PST) Received: from jsoft.com (IDENT:xml2vLSBRK7GcwJ2bNBCXTjTCsGV7yjn@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2PCPYV08548; Mon, 25 Mar 2002 06:25:34 -0600 Message-ID: <3C9F173E.8020602@jsoft.com> Date: Mon, 25 Mar 2002 06:25:34 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: <3C9E69C6.685D0550@netscape.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 Are we to just focusing on the "CAP / BEEP / XML / iCalendar - updated proposal"? Would it be useful to take your list of issues and 'schedule' them? Gary Steve Mansour wrote: > ... continued: > > Section 3.1 > > seems superfluous and covered in BEEP. do we really need this? > > Section 3.2 > > (already posted to the list because we're trying to resolve this > now). The XML encoding, while harmless, is superfluous. At the > meeting in Minneapolis, we were thinking along these lines: > > ENCAPSULATION A > > C: MSG 1 2 . 1234 123 > C: Content-type: application/cap+xml > C: > C: > C: C: Content-Type: text/calendar > C: > C: BEGIN:VCALENDAR > C: METHOD:SEARCH > ... > C: END:VCALENDAR > C: ]]> > C: > C: END > > The XML encapsulation is innocuous, but it adds nothing. Further, it > tempts us to move things out of the Application layer and into the > Transport layer (such as the command names, and attributes such as > "latency" and "action" -- undermining the transport/application > separation and leading us down slippery slopes. Here is a simpler > alternative (and yes, I know some of you have been pushing for > something like this all along :-) : > > ENCAPSULATION B > > C: MSG 1 2 . 1234 123 > C: Content-type: text/calendar > C: > C: BEGIN:VCALENDAR > C: METHOD:SEARCH > C: LATENCY:3 > C: ACTION:ASK > ... > C: END:VCALENDAR > C: END > > The advantage of encapsulation B is that it represents exactly the > same content as encapsulation A, but it uses one rather than two > encapsulations and there are no hints about the calendaring commands > in the transport. We could substitute *any* transport. > > Section 3.3 > > Second paragraph should end with a sentence describing what happens > on an aborted command. The easy thing to do is something like this: > > Partial results indicating homw much of the command completed > MAY be returned. > > Or we may want to get more ambitious require a precise reply. > > The third and fourth paragraphs will need to go wherever we define > Latency and Action. > > The last RPY message on the last example of the section. This should > probably become an application level error reply rather than a > transport level reply. > > Section 4.1 > > bullet (1) -- we should state how to handle Parameters, and how to > handle components that contain other components. > > bullet (3) -- what is the reasoning behind this limitation? > > bullet (7) -- I'm not sure I understand the problem here. Can > someone illustrate the point we're trying to make with an example? > > bullet (7) -- do we really need USING_PROPERTIES and > USING_COMPONENTS ? I don't see the value based on the examples. Is > it just a shorthand to save characters? > > > Section 4.1.1 - FLOATING TIME EVENTS > > We need to clarify how we search for floating time events. If we're > going to send UTC times in queries, then I don't see how we can > search for floating time events. Seems like the only way to get the > "floaters" is to do a separate query for them where we specify the > floating time range for the query. > > Section 4.1.1 > > I'm just confused by reading it. I think it needs to be made > clearer. The examples are throwing me off. > > Section 4.1.1 > > bullet (7) - There's still a reference to CONTAINS(). Also, the > next to the last paragraph seems like it will be a problem. When the > schema is updated, servers won't know whether a new component / > property is multivalued or not. > > Section 4.1.1 > > bullet (8) - There were some typos fixed, but it seems like there > are two logic errors. > > '%,%' IN parameter should match NONE -- currently says it > matches (d) and (e) > LIKE(parameter, ',') should match (e) -- currently says it > would NOT match any > > Section 4.3 > > This is really not an issue with section 4.3. It just became clear > when I read the example. I don't think we've defined anywhere that > we're moving METHOD into components. We need to define this property > somewhere. Also, as we're using it in the VEVENT, VTODO, and > VJOURNAL, it is less an action and more a state. It's name should > reflect its use. So, something like WORKFLOWSTATE is probably better. > > We need to define when it is set, especially in the iTIP workflow. I > recommend that the CUA be responsible for explicitly setting this > > Another problem associated with this is that when data is migrated > out of an ITIP wrapper and into a component, it will be a lossy > transformation as things stand today. For example, consider the > following ITIP request: > > BEGIN:VCALENDAR > PRODID:-//ACME/DesktopCalendar//EN > METHOD:REQUEST > VERSION:2.0 > BEGIN:VEVENT > ... > END:VEVENT > END:VCALENDAR > > We are talking about migrating the METHOD:REQUEST value into a new > component property like WORKFLOWSTATE. But what about information > like PRODID and VERSION ? Might those or other values contained in > the VCALENDAR become significant over time? Do we just toss them? > > One suggestion in Minneapolis was to create a new component called > VITIP that would contain everything in the ITIP request. > > Do we need something like VITIP ? or is migrating the METHOD value > into WORKFLOWSTATE good enough? > > Section 4.7 > > In the example: > > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT > USING_COMPONENT VALARM my-alarm > WHERE my-alarm.TRIGGER >= '20000101T030405Z' > AND my-alarm.TRIGGER <= '20001231T235959Z' > AND METHOD = 'CREATE' > END:VQUERY > > use of "USING_COMPONENT" seems like it's not buying us much. Seems > like this example could actually be shortened by writing it without > the USING_COMPONENT line: > > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT > WHERE VALARM.TRIGGER >= '20000101T030405Z' > AND VALARM.TRIGGER <= '20001231T235959Z' > AND METHOD = 'CREATE' > END:VQUERY > > The example may simply not constructed to show the real value of > "USING_COMPONENT". Can someone describe the real value of this? Or > can we drop it? Same thing for "USING_PROPERTY". > > Section 4.7 > > The example just reminded me: I propose that we add a UID property > to VALARM. We (Netscape) have implemented a calendar server where > this value is very useful. Our experience has been that you have to > jump through hoops to figure out which of multiple alarms you need > to work on if you don't have this UID value. > From owner-ietf-calendar@mail.imc.org Mon Mar 25 10:39: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 KAA14805 for ; Mon, 25 Mar 2002 10:39:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PFNDn02815 for ietf-calendar-bks; Mon, 25 Mar 2002 07:23:13 -0800 (PST) Received: from lin2.andrew.cmu.edu (LIN2.ANDREW.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PFNB402808 for ; Mon, 25 Mar 2002 07:23:11 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3.Beta0/8.12.2.Beta3) with ESMTP id g2PFN1eP010511; Mon, 25 Mar 2002 10:23:01 -0500 Date: Mon, 25 Mar 2002 10:23:01 -0500 Message-Id: <200203251523.g2PFN1eP010511@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: CalSched IETF , Steve Mansour In-reply-to: <3C9E2DB5.A1BD673B@netscape.com> Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree that this is preferable. This removes the redundant application layer. This should make the protocol easier to understand and simplify the document. Larry Date: Sun, 24 Mar 2002 11:49:09 -0800 From: sman@netscape.com (Steve Mansour) [...] ENCAPSULATION B C: MSG 1 2 . 1234 123 C: Content-type: text/calendar C: C: BEGIN:VCALENDAR C: METHOD:SEARCH C: LATENCY:3 C: ACTION:ASK ... C: END:VCALENDAR C: END From owner-ietf-calendar@mail.imc.org Mon Mar 25 10:39: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 KAA14815 for ; Mon, 25 Mar 2002 10:39:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PFQKm03029 for ietf-calendar-bks; Mon, 25 Mar 2002 07:26:20 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PFQC403024 for ; Mon, 25 Mar 2002 07:26:15 -0800 (PST) To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 10:32:32 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 10:36:42 AM, Serialize complete at 03/25/2002 10:36:42 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Also, I don't see any reason that a specific implementation can't have >non-standard queries for 'get me today's stuff'. How does a CUA find out whether these non-standard queries exist? Perhaps we need a SYSDATE (SQL constant meaning "now"); then stored queries could be relative to SYSDATE. Something like WHERE DATE(DTSTART)=DATE(SYSDATE) >I am still in favor of removing all XML from the CAP protocol >and placing everything in VCALENDAR objects. Me, too. >I don't like them ether, but if they can authenticate. So should we not >allow them to then be subject to VCAR restrictions and not call them >anonymous? Perhaps 'bob@' has more restrictions that anonymous once >the VCARs are applied. But setting VCARs like that wouldn't make sense; then bob@example.com can just log in as anonymous. I think Steve's right; if I grant permissions to "bob@", then an attacker has too much leeway. But declaring it equivalent to anonymous doesn't seem to make sense, either--once they're equivalent, why do we need both? We should ban such UPNs altogether. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |They prayed for their fates to be quick, painless, and, ideally,| |someone else's. | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 10:41: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 KAA14989 for ; Mon, 25 Mar 2002 10:41:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PFR8r03042 for ietf-calendar-bks; Mon, 25 Mar 2002 07:27:08 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PFQJ403028 for ; Mon, 25 Mar 2002 07:26:20 -0800 (PST) To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 10:33:20 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 10:37:30 AM, Serialize complete at 03/25/2002 10:37:30 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Section 2.4.2.2 >Why do we need CAR-MIN ? Is it to support things like CRISP? No; CRISP doesn't need any queries at all. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |"Fly Heisenberg Airlines! We may not know where we are, but we're| |making real good time." -- _Synners_ by Pat Cadigan | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 11:12: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 LAA17327 for ; Mon, 25 Mar 2002 11:12:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PG1IP05627 for ietf-calendar-bks; Mon, 25 Mar 2002 08:01:18 -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 g2PG1G405621 for ; Mon, 25 Mar 2002 08:01:16 -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 g2PG1BO23940 for ; Mon, 25 Mar 2002 08:01:11 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTJDTZ00.3BZ; Mon, 25 Mar 2002 08:01:11 -0800 Message-ID: <3C9F4ACC.2EEC008@netscape.com> Date: Mon, 25 Mar 2002 08:05:32 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Frederick CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.com> Content-Type: multipart/mixed; boundary="------------B233379EA047754EC671EF26" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B233379EA047754EC671EF26 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Frederick wrote: > What would the XML version of encapsulation B look like? There's no need for an XML encapsulation. We MUST have an iCalendar encapsulation because that's how our application data is defined. The point of B was to show that the iCalendar encapsulation is the only one needed. -Steve > > > Gary > > Steve Mansour wrote: > > Folks, > > > > After thinking about some of the feedback on this, I think that the XML > > encoding, while harmless, is superfluous. At the meeting in Minneapolis, > > we were thinking along these lines: > > > > ENCAPSULATION A > > > > C: MSG 1 2 . 1234 123 > > C: Content-type: application/cap+xml > > C: > > C: > > C: > C: Content-Type: text/calendar > > C: > > C: BEGIN:VCALENDAR > > C: METHOD:SEARCH > > ... > > C: END:VCALENDAR > > C: ]]> > > C: > > C: END > > > > The XML encapsulation is innocuous, but it adds nothing. Further, it > > tempts us to move things out of the Application layer and into the > > Transport layer (such as the command names, and attributes such as > > "latency" and "action" -- undermining the transport/application > > separation and leading us down slippery slopes. Here is a simpler > > alternative (and yes, I know some of you have been pushing for something > > like this all along :-) : > > > > ENCAPSULATION B > > > > C: MSG 1 2 . 1234 123 > > C: Content-type: text/calendar > > C: > > C: BEGIN:VCALENDAR > > C: METHOD:SEARCH > > C: LATENCY:3 > > C: ACTION:ASK > > ... > > C: END:VCALENDAR > > C: END > > > > The advantage of encapsulation B is that it represents exactly the same > > content as encapsulation A, but it uses one rather than two > > encapsulations and there are no hints about the calendaring commands in > > the transport. We could substitute *any* transport. > > > > Can anyone suggest why we would want to use encapsulation A rather than B ? > > > > Are there any objections to moving forward with encapsulations as > > specified in B ? > > > > -Steve > > --------------B233379EA047754EC671EF26 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;AOL / Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Director of Engineering fn:Steve Mansour end:vcard --------------B233379EA047754EC671EF26-- From owner-ietf-calendar@mail.imc.org Mon Mar 25 11:16: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 LAA17497 for ; Mon, 25 Mar 2002 11:16:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PG7W106991 for ietf-calendar-bks; Mon, 25 Mar 2002 08:07:32 -0800 (PST) Received: from esmtp.starfish.com (esmtp.starfish.com [66.35.205.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PG7U406983 for ; Mon, 25 Mar 2002 08:07:30 -0800 (PST) Received: from pthompson509 ([63.249.86.47]) by esmtp.starfish.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Mar 2002 07:49:17 -0800 From: "Peter Thompson" To: "CalSched IETF" Subject: RE: CAP / BEEP / XML / iCalendar - updated proposal Date: Mon, 25 Mar 2002 08:06:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200203251523.g2PFN1eP010511@lin2.andrew.cmu.edu> Importance: Normal X-OriginalArrivalTime: 25 Mar 2002 15:49:18.0124 (UTC) FILETIME=[9F5DBEC0:01C1D414] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit So you are putting transport dependancies into the data area? I'm sorry if I'm confused about this, but I really hope that you are keeping data separate from transport, as the iCalendar data is used by other transports. Cheers, Peter > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Lawrence > Greenfield > Sent: Monday, March 25, 2002 7:23 AM > To: CalSched IETF; Steve Mansour > Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal > > > > I agree that this is preferable. This removes the redundant > application layer. This should make the protocol easier to understand > and simplify the document. > > Larry > > Date: Sun, 24 Mar 2002 11:49:09 -0800 > From: sman@netscape.com (Steve Mansour) > [...] > ENCAPSULATION B > > C: MSG 1 2 . 1234 123 > C: Content-type: text/calendar > C: > C: BEGIN:VCALENDAR > C: METHOD:SEARCH > C: LATENCY:3 > C: ACTION:ASK > ... > C: END:VCALENDAR > C: END > > From owner-ietf-calendar@mail.imc.org Mon Mar 25 12:10: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 MAA20449 for ; Mon, 25 Mar 2002 12:10:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PGstp10180 for ietf-calendar-bks; Mon, 25 Mar 2002 08:54: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 g2PGss410176 for ; Mon, 25 Mar 2002 08:54:54 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PGspdx023146 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 08:54:55 -0800 (PST) Message-ID: <3C9F5657.8090305@Royer.com> Date: Mon, 25 Mar 2002 09:54:47 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.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 Gary Frederick wrote: > > What would the XML version of encapsulation B look like? NONE - use text/calendar ONLY. From owner-ietf-calendar@mail.imc.org Mon Mar 25 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 MAA20474 for ; Mon, 25 Mar 2002 12:10:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PGt6i10191 for ietf-calendar-bks; Mon, 25 Mar 2002 08:55:06 -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 g2PGt5410187 for ; Mon, 25 Mar 2002 08:55:05 -0800 (PST) Received: from jsoft.com (IDENT:NvgtMoo58XoXxxjCUtyvFBnxgTWBsAgl@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2PGrkV09588; Mon, 25 Mar 2002 10:53:47 -0600 Message-ID: <3C9F561A.8000302@jsoft.com> Date: Mon, 25 Mar 2002 10:53:46 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.com> <3C9F4ACC.2EEC008@netscape.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 Let me try again... Steve, you gave an example that used good ol iCalendar in the application part of the message. I wanted to know what it would look like if the application part was XML/XCS rather than iCalendar. ENCAPSULATION B - XCS version C: MSG 1 2 . 1234 123 C: Content-type: the correct type for xcs... C: C: C: C: ask ... C: C: END The above is NOT an attempt to show what the XML/XCS should be. It's to clarify that I was asking what an encapsulation that used XCS rather than iCalendar would look like. Gary Steve Mansour wrote: > Gary Frederick wrote: > > >>What would the XML version of encapsulation B look like? > > > There's no need for an XML encapsulation. We MUST have an iCalendar encapsulation > because that's how our application data is defined. The point of B was to show > that the iCalendar encapsulation is the only one needed. > > -Steve > > >> >>Gary >> >>Steve Mansour wrote: >> >>>Folks, >>> >>>After thinking about some of the feedback on this, I think that the XML >>>encoding, while harmless, is superfluous. At the meeting in Minneapolis, >>>we were thinking along these lines: >>> >>> ENCAPSULATION A >>> >>> C: MSG 1 2 . 1234 123 >>> C: Content-type: application/cap+xml >>> C: >>> C: >>> C: >> C: Content-Type: text/calendar >>> C: >>> C: BEGIN:VCALENDAR >>> C: METHOD:SEARCH >>> ... >>> C: END:VCALENDAR >>> C: ]]> >>> C: >>> C: END >>> >>>The XML encapsulation is innocuous, but it adds nothing. Further, it >>>tempts us to move things out of the Application layer and into the >>>Transport layer (such as the command names, and attributes such as >>>"latency" and "action" -- undermining the transport/application >>>separation and leading us down slippery slopes. Here is a simpler >>>alternative (and yes, I know some of you have been pushing for something >>>like this all along :-) : >>> >>> ENCAPSULATION B >>> >>> C: MSG 1 2 . 1234 123 >>> C: Content-type: text/calendar >>> C: >>> C: BEGIN:VCALENDAR >>> C: METHOD:SEARCH >>> C: LATENCY:3 >>> C: ACTION:ASK >>> ... >>> C: END:VCALENDAR >>> C: END >>> >>>The advantage of encapsulation B is that it represents exactly the same >>>content as encapsulation A, but it uses one rather than two >>>encapsulations and there are no hints about the calendaring commands in >>>the transport. We could substitute *any* transport. >>> >>>Can anyone suggest why we would want to use encapsulation A rather than B ? >>> >>>Are there any objections to moving forward with encapsulations as >>>specified in B ? >>> >>>-Steve >>> >> From owner-ietf-calendar@mail.imc.org Mon Mar 25 12:11:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20512 for ; Mon, 25 Mar 2002 12:11:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PGrRj10123 for ietf-calendar-bks; Mon, 25 Mar 2002 08:53: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 g2PGrP410119 for ; Mon, 25 Mar 2002 08:53:25 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PGrLdx023121 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 08:53:25 -0800 (PST) Message-ID: <3C9F55FE.2060509@Royer.com> Date: Mon, 25 Mar 2002 09:53:18 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: <3C9E69C6.685D0550@netscape.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 Steve Mansour wrote: > ... continued: > > Section 3.1 > > seems superfluous and covered in BEEP. do we really need this? I agree. > Section 3.3 > > Second paragraph should end with a sentence describing what happens > on an aborted command. The easy thing to do is something like this: > > Partial results indicating how much of the command completed > MAY be returned. I don't follow. What do you mean by partial result? I think that BEEP covers that. We may need some text to say that the CS MUST send a final '.' RPY (ANS, NUL, or whatever). > Section 4.1 > > bullet (1) -- we should state how to handle Parameters, and how to > handle components that contain other components. Bullet (1) does not describe how anything is handled. It describes a virtual view of a virtual schema. In one of the edit versions, it also said the same thing about properties (tables) vs parameters (columns). Someone suggested that it be split into two paragraphs. Perhaps the second part was just accidentally dropped. > bullet (3) -- what is the reasoning behind this limitation? If you had followed the list, several people seem to be terrified that this might actually be SQL. This limit was placed when there was pressure to eliminate SQL-MIN vs SQL-FULL. Small devices are not going to implement a full SQL server just to say they are a CS. So the easiest thing to compromise on was joins. If you recall SQL-MIN used to be an exact syntax for a minimum query. And SQL-FULL was SQL-92 that allowed joins. If we are going to allow joins, I think we must recall SQL-MIN for small devices. > bullet (7) -- I'm not sure I understand the problem here. Can > someone illustrate the point we're trying to make with an example? It allows: BEGIN:VQUERY QUERY: ...1.... QUERY: ....2.... QUERY:...N... END:VQUERY Rather than having to have N separate BEGIN/END VCALENDAR, each with its own BEGIN/END VQUERY. (7) just says that the results are returned the same as if you had done N different SEARCHs. > bullet (7) -- do we really need USING_PROPERTIES and > USING_COMPONENTS ? I don't see the value based on the examples. Is > it just a shorthand to save characters? Your mean (4)? I agree that they need to be tossed. I really wish you had been active on the list a few months ago. > > Section 4.1.1 - FLOATING TIME EVENTS > > We need to clarify how we search for floating time events. If we're > going to send UTC times in queries, then I don't see how we can > search for floating time events. Seems like the only way to get the > "floaters" is to do a separate query for them where we specify the > floating time range for the query. If the CUA wishes to search for 'today', the CUA knows the begin and end UTC times for its 'today' and that will be shown in its QUERY (from UTC-7 to UTC-7 + 24 for 'today'). That will return all components including floating time components for the CUAs view of 'today' in UTC. Why would floating time components be any different? > Section 4.1.1 > > I'm just confused by reading it. I think it needs to be made > clearer. The examples are throwing me off. > > Section 4.1.1 > > bullet (7) - There's still a reference to CONTAINS(). > Yep - missed. > Also, the > next to the last paragraph seems like it will be a problem. When the > schema is updated, servers won't know whether a new component / > property is multivalued or not. True, but because 2445 did not stick to one method, or mandate some rule. There is no way other than to guess for something new. I hope we stick to the requirement in 2445 that they are multivalued and any value that contains a comma, MUST BE enclosed in quotes. The problem is that some may be both multi instances and multi valued. A bug in 2445 that needs to be fixed, not a bug in CAP. I think that we need the 'method reviewer' and this WG to force newly registered values to be multi valued, use quotes, and allow multi instances. At one point we had said (and in is not in 2445): X-FOO:1,2 is the same as: X-FOO:1 X-FOO:2 I think the only compatible way to fix this is to make that true and just have to live with the 2445 exceptions (like RRULE). > Section 4.1.1 > > bullet (8) - There were some typos fixed, but it seems like there > are two logic errors. > > '%,%' IN parameter should match NONE -- currently says it > matches (d) and (e) NO - (d) and (e) are parameters, it says 'IN property'. It does not say 'IN parameter'. And (e) needs a ':value'. > LIKE(parameter, ',') should match (e) -- currently says it > would NOT match any Yes. > Section 4.3 > > This is really not an issue with section 4.3. It just became clear > when I read the example. I don't think we've defined anywhere that > we're moving METHOD into components. We are not moving METHOD in component. We are just saying that a components current state is whatever the METHOD was that last deposited or tweaked its values. > We need to define this property > somewhere. Also, as we're using it in the VEVENT, VTODO, and > VJOURNAL, it is less an action and more a state. It's name should > reflect its use. So, something like WORKFLOWSTATE is probably better. I can't find it in ANY VEVENT, VTODO, or VJOURNAL in the spec. I do see it in the VCALENDAR just like in iTIP. > We need to define when it is set, especially in the iTIP workflow. I > recommend that the CUA be responsible for explicitly setting this. So I can't just send down iTIP objects? No. I would not like that. > Another problem associated with this is that when data is migrated > out of an ITIP wrapper and into a component, it will be a lossy > transformation as things stand today. For example, consider the > following ITIP request: > > BEGIN:VCALENDAR > PRODID:-//ACME/DesktopCalendar//EN > METHOD:REQUEST > VERSION:2.0 > BEGIN:VEVENT > ... > END:VEVENT > END:VCALENDAR > > We are talking about migrating the METHOD:REQUEST value into a new > component property like WORKFLOWSTATE. But what about information > like PRODID and VERSION ? Might those or other values contained in > the VCALENDAR become significant over time? Do we just toss them? Not migrating them, just tagging them with their workflow state. I for one will not be storing the entire iTIP object intact. > One suggestion in Minneapolis was to create a new component called > VITIP that would contain everything in the ITIP request. Why? It already contains everything it needs. > Do we need something like VITIP ? or is migrating the METHOD value > into WORKFLOWSTATE good enough? I say NO to VITIP, iTIP objects are already self contained objects. I also say NO to specifically adding any new property to the component over the wire. Moving METHOD into the component is just a conceptual thing used for finding things that were deposited into the CS. > Section 4.7 > > In the example: > > BEGIN:VQUERY > EXPAND:TRUE > QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT > USING_COMPONENT VALARM my-alarm > WHERE my-alarm.TRIGGER >= '20000101T030405Z' > AND my-alarm.TRIGGER <= '20001231T235959Z' > AND METHOD = 'CREATE' > END:VQUERY > ... > > > The example may simply not constructed to show the real value of > "USING_COMPONENT". Can someone describe the real value of this? Or > can we drop it? Same thing for "USING_PROPERTY". This was added when some were confused as to how the CS would know when the VEVENT contained multiple VALARMS that each of the logical comparisons were from the same VALARM. I gave up the argument - wish you had read the WG list at that time. > Section 4.7 > > The example just reminded me: I propose that we add a UID property > to VALARM. We (Netscape) have implemented a calendar server where > this value is very useful. Our experience has been that you have to > jump through hoops to figure out which of multiple alarms you need > to work on if you don't have this UID value. Steve - you really need to follow the list :-) There was (and i ~think~ generally accepted) debate about how to tag VALARMs as LOCAL and non-LOCAL, which included adding SEQUENCE to VALARMS in order to make them unique. I'll look for the post and forward it to you. The problem (in addition to your point) was that if the ORGANIZER includes VALARMs in a VEVENT (or any component), and the CU does NOT wish to use those VALARMS (I have to drive 1 hour and you sent the alarm to 15 minute notice). The proposal allowed for the CUA to tag VALARMs and enabled or disabled. And how to tag VALARMs so that the CUA knows they are local and are NOT to be forwarded to any non-owner. From owner-ietf-calendar@mail.imc.org Mon Mar 25 12:15: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 MAA20673 for ; Mon, 25 Mar 2002 12:15:18 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PH18110348 for ietf-calendar-bks; Mon, 25 Mar 2002 09:01:08 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PH17410344 for ; Mon, 25 Mar 2002 09:01:07 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PH10dx023275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 09:01:07 -0800 (PST) Message-ID: <3C9F57C9.5030203@Royer.com> Date: Mon, 25 Mar 2002 10:00:57 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>Also, I don't see any reason that a specific implementation can't have >>non-standard queries for 'get me today's stuff'. >> > > How does a CUA find out whether these non-standard queries exist? Okay - 'x-get-me-today's-stuff', now it is a vendor only thing. > Perhaps we need a SYSDATE (SQL constant meaning "now"); then stored > queries could be relative to SYSDATE. Something like ... My point was not that we need that query, it was that implementations MAY elect to have stored queries that fulfill the same vendor needs (PDAs for example) for CUAs (or CS's) and the CUA can say 'just get met that stuff we agreed'. >>I don't like them ether, but if they can authenticate. So should we not >>allow them to then be subject to VCAR restrictions and not call them >>anonymous? Perhaps 'bob@' has more restrictions that anonymous once >>the VCARs are applied. >> > > But setting VCARs like that wouldn't make sense; then bob@example.com can > just log in as anonymous. So can anyone, even if we accept Steve's proposal. What is the difference? > I think Steve's right; if I grant permissions to "bob@", then an attacker > has too much leeway. But declaring it equivalent to anonymous doesn't > seem to make sense, either--once they're equivalent, why do we need both? > We should ban such UPNs altogether. I agree - ban 'user@' . From owner-ietf-calendar@mail.imc.org Mon Mar 25 12:22: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 MAA20987 for ; Mon, 25 Mar 2002 12:22:23 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PH7wQ11066 for ietf-calendar-bks; Mon, 25 Mar 2002 09:07: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 g2PH7u411059 for ; Mon, 25 Mar 2002 09:07:56 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PH7rdx023421 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 09:07:57 -0800 (PST) Message-ID: <3C9F5965.4050705@Royer.com> Date: Mon, 25 Mar 2002 10:07:49 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal 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 Peter Thompson wrote: > So you are putting transport dependancies into the data area? CAP is not the transport. BEEP is the transport and BEEP does not have LATENCY. And it won't break iTIP, iMIP, or iCalendar. > I'm sorry if I'm confused about this, but I really hope that > you are keeping data separate from transport, as the iCalendar > data is used by other transports. BEEP is not the only transport for iCalendar objects. I don't see any reason that I could not add A LATENCY of "5 days" to an iMIP object. I hope you can accept any PROPERTY;paramaters="foo":value even if you don't understand what they do. If you can, it has no meaning as they are still valid iCalendar objects. From owner-ietf-calendar@mail.imc.org Mon Mar 25 12:24: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 MAA21084 for ; Mon, 25 Mar 2002 12:24:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PHAhS11140 for ietf-calendar-bks; Mon, 25 Mar 2002 09:10: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 g2PHAg411135 for ; Mon, 25 Mar 2002 09:10:42 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PHAddx023456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 09:10:43 -0800 (PST) Message-ID: <3C9F5A0B.7080507@Royer.com> Date: Mon, 25 Mar 2002 10:10:35 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>Section 2.4.2.2 >>Why do we need CAR-MIN ? Is it to support things like CRISP? >> > > No; CRISP doesn't need any queries at all. We added query-level of 'NONE' for crisp. From owner-ietf-calendar@mail.imc.org Mon Mar 25 13: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 NAA23292 for ; Mon, 25 Mar 2002 13:08:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PHnQu12384 for ietf-calendar-bks; Mon, 25 Mar 2002 09:49:26 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PHnP412380 for ; Mon, 25 Mar 2002 09:49:25 -0800 (PST) To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 12:59:41 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 12:59:49 PM, Serialize complete at 03/25/2002 12:59:49 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I wanted to know what it would look >like if the application part was XML/XCS rather than iCalendar. If by "XCS" you mean "the XML representation of iCalendar", then nobody knows, because we haven't defined an XML representation of iCalendar yet. Anyway, why do you want to know? It's not important. >It's to >clarify that I was asking what an encapsulation that used XCS rather >than iCalendar would look like. You are drawing an illegitimate distinction. The XML representation of iCalendar, if it is ever standardized, will be a transliteration of text/calendar; any VEVENT, say, represented in XML will still be iCalendar. So the phrase "XCS rather than iCalendar" is not meaningful. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Linux: the Unix defragmentation tool. | \========================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 13:11: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 NAA23446 for ; Mon, 25 Mar 2002 13:11:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PHsnd12571 for ietf-calendar-bks; Mon, 25 Mar 2002 09:54:49 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PHsl412567 for ; Mon, 25 Mar 2002 09:54:48 -0800 (PST) To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 13:05:03 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 01:05:12 PM, Serialize complete at 03/25/2002 01:05:12 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >John Stracke wrote: >> How does a CUA find out whether these non-standard queries exist? > >Okay - 'x-get-me-today's-stuff', now it is a vendor only thing. Again, how do you find out the CS implements x-get-me-todays-stuff? More importantly, what happens when I want to replace my CS with one from another vendor? If stored queries are a real need, then the standard must support the ones that are needed; if we push them off to vendor extensions, then we're shooting interop in the foot. >>>anonymous? Perhaps 'bob@' has more restrictions that anonymous once >>>the VCARs are applied. >> >> But setting VCARs like that wouldn't make sense; then bob@example.com can >> just log in as anonymous. > >So can anyone, even if we accept Steve's proposal. What is the >difference? The point is just that giving any person less rights than Anonymous does not increase security, because they can always come back as Anonymous. >I agree - ban 'user@' . /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |"No, no, that's *not* a boat, that's Queen Victoria." | \========================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 13:21: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 NAA24169 for ; Mon, 25 Mar 2002 13:21:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PI6s514708 for ietf-calendar-bks; Mon, 25 Mar 2002 10:06:54 -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 g2PI6q414698 for ; Mon, 25 Mar 2002 10:06:53 -0800 (PST) Received: from jsoft.com (IDENT:Rr/D0QdgtnwFFdP3/fVfevi7zC+4AVn0@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2PI5dV09884 for ; Mon, 25 Mar 2002 12:05:39 -0600 Message-ID: <3C9F66F2.9060400@jsoft.com> Date: Mon, 25 Mar 2002 12:05:38 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.com> <3C9F5657.8090305@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 So we are dropping the XML version of iCalendar? Gee, I must have missed that e-mail. Gary Doug Royer wrote: > > > > Gary Frederick wrote: > >> >> What would the XML version of encapsulation B look like? > > > > NONE - use text/calendar ONLY. > From owner-ietf-calendar@mail.imc.org Mon Mar 25 13:54: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 NAA26191 for ; Mon, 25 Mar 2002 13:54:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PIcH916343 for ietf-calendar-bks; Mon, 25 Mar 2002 10:38:17 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PIcF416338 for ; Mon, 25 Mar 2002 10:38:16 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2PIcEdl015846 for ; Mon, 25 Mar 2002 13:38:14 -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 g2PIcAQ19733 for ; Mon, 25 Mar 2002 13:38:10 -0500 (EST) Message-Id: <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 13:41:39 -0500 To: CalSched IETF From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 In-Reply-To: <3C9F55FE.2060509@Royer.com> References: <3C9E69C6.685D0550@netscape.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 09:53 AM 25/03/2002 -0700, Doug Royer wrote: >> bullet (3) -- what is the reasoning behind this limitation? > >If you had followed the list, several people seem to be terrified that >this might actually be SQL. This limit was placed when there was >pressure to eliminate SQL-MIN vs SQL-FULL. Small devices are >not going to implement a full SQL server just to say they are >a CS. So the easiest thing to compromise on was joins. > >If you recall SQL-MIN used to be an exact syntax for a minimum >query. And SQL-FULL was SQL-92 that allowed joins. If we >are going to allow joins, I think we must recall SQL-MIN for >small devices. Do you mean recall in name only, or recall the specification that existed previously as SQL-MIN? >> bullet (7) -- do we really need USING_PROPERTIES and >> USING_COMPONENTS ? I don't see the value based on the examples. Is >> it just a shorthand to save characters? > >Your mean (4)? > >I agree that they need to be tossed. I really wish you had been >active on the list a few months ago. The examples referred to were simple, and did not demonstrate the value of these clauses. USING_PROPERTIES and USING_COMPONENTS allow instances of multiple properties/sub-components to be referenced by name. As an example, and at the risk of repeating posts from a few months back, here are 2 simple queries: SELECT * FROM VEVENT WHERE ATTENDEE = "foo@example.com" AND ATTENDEE = "bar@example.com" SELECT * FROM VEVENT WHERE ATTENDEE = "foo@example.com" AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED (there is not a single example in cap-07 that uses PARAM(), btw) To a human, the meaning seems obvious; the first is asking for all VEVENTS which are attended by the two specified CUs, the second is asking for all events that a specified CU has accepted. But CAP isn't parsed by humans, and the two queries have referred to instances of the ATTENDEE property in different ways; the first was referring to two _different_ ATTENDEEs, while the second was referring to the _same_ ATTENDEE. With the USING_PROPERTIES clause, the two queries could be disambiguated as follows: SELECT * FROM VEVENT WHERE USING_PROPERTIES ATTENDEE my-att1, ATTENDEE my-att2 WHERE my-att1 = "foo@example.com" AND my-att2 = "bar@example.com" SELECT * FROM VEVENT WHERE USING_PROPERTIES ATTENDEE my-att WHERE my-att = "foo@example.com" AND PARAM(my-att, PARTSTAT) = ACCEPTED If the two clauses are 'tossed', they should be replaced with a clear, unambiguous explanation of the meaning of querying a multi-instance just by property name (i.e. does it mean 'any' instance of that property, or 'all' instances of that property), rather than ignoring the issue as SQL-MIN did. It should also be noted that only 1 of the above queries could be represented if the clauses were 'tossed' (we would have to choose whether the two references to ATTENDEE in the first two examples would refer to the same or different properties). --Alan From owner-ietf-calendar@mail.imc.org Mon Mar 25 14:03:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26629 for ; Mon, 25 Mar 2002 14:03:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PImBI16948 for ietf-calendar-bks; Mon, 25 Mar 2002 10:48:11 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PImA416940 for ; Mon, 25 Mar 2002 10:48:10 -0800 (PST) To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 13:58:25 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 01:58:34 PM, Serialize complete at 03/25/2002 01:58:34 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >So we are dropping the XML version of iCalendar? We are not dropping it. It does not exist. It might exist at some point in the future, but not until we're done with CAP. It is not in the WG charter. There is actually contention over whether or not it ought to exist at all; a case can be made that creating an alternate rendering of the same data cannot improve interop, and will probably harm it. /=========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=========================================================| |Peace, justice, morality, culture, family, sport, and the| |extinction of all other life forms! | \=========================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 14:08: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 OAA26964 for ; Mon, 25 Mar 2002 14:08:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PIqbZ17176 for ietf-calendar-bks; Mon, 25 Mar 2002 10:52:37 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PIqZ417171 for ; Mon, 25 Mar 2002 10:52:36 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2PIqbdl016023 for ; Mon, 25 Mar 2002 13:52:37 -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 g2PIqSQ21339 for ; Mon, 25 Mar 2002 13:52:29 -0500 (EST) Message-Id: <5.1.0.14.0.20020325134313.0ab464e8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 13:55:57 -0500 To: CalSched IETF From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 In-Reply-To: <3C9E69C6.685D0550@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:05 PM 24/03/2002 -0800, Steve Mansour wrote: >Section 4.7 >In the example: >BEGIN:VQUERY >EXPAND:TRUE >QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT > USING_COMPONENT VALARM my-alarm > WHERE my-alarm.TRIGGER >= '20000101T030405Z' > AND my-alarm.TRIGGER <= '20001231T235959Z' > AND METHOD = 'CREATE' >END:VQUERY > >use of "USING_COMPONENT" seems like it's not buying us much. Seems like >this example could actually be shortened by writing it without the >USING_COMPONENT line: >BEGIN:VQUERY >EXPAND:TRUE >QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT > WHERE VALARM.TRIGGER >= '20000101T030405Z' > AND VALARM.TRIGGER <= '20001231T235959Z' > AND METHOD = 'CREATE' >END:VQUERY > >The example may simply not constructed to show the real value of >"USING_COMPONENT". Can someone describe the real value of this? Or can >we drop it? Same thing for "USING_PROPERTY". Your rewritten query could be specifying a VEVENT which contains a VALARM whose TRIGGER falls within a given time range, or a VEVENT that contains multiple VALARMs, one of which has a TRIGGER >= '20000101T030405Z', and another VALARM which has a TRIGGER <= '20001231T235959Z'. I'm not sure which it does specify, as I can't remember offhand the chosen interpretation, and can't find any text in cap-07 that mentions this. I would think the clearest interpretation would be for each reference to VALARM to mean "any VALARM sub-component", in which case USING_COMPONENT is necessary in the query (although perhaps a clearer example could be found, or some explanatory text added). --Alan From owner-ietf-calendar@mail.imc.org Mon Mar 25 14:26: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 OAA27801 for ; Mon, 25 Mar 2002 14:26:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PJBS618409 for ietf-calendar-bks; Mon, 25 Mar 2002 11:11: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 g2PJBQ418405 for ; Mon, 25 Mar 2002 11:11:26 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PJBNdx025055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 11:11:28 -0800 (PST) Message-ID: <3C9F7657.7020904@Royer.com> Date: Mon, 25 Mar 2002 12:11:19 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.com> <3C9F4ACC.2EEC008@netscape.com> <3C9F561A.8000302@jsoft.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 Gary Frederick wrote: > > Let me try again... > > Steve, you gave an example that used good ol iCalendar in the > application part of the message. I wanted to know what it would look > like if the application part was XML/XCS rather than iCalendar. The xCal draft, draft-ietf-calsch-many-xcal-01.txt Is the 2nd pass at mapping iCalendar into XML. It is changing. Once done, any component, property, or parameter can be mapped between iCalendar and XML format. XML is out of scope for CAP and I think that is what Steve is also saying. XML does nothing for CAP for iCalendar objects. From owner-ietf-calendar@mail.imc.org Mon Mar 25 14:30:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28057 for ; Mon, 25 Mar 2002 14:30:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PJFSt18517 for ietf-calendar-bks; Mon, 25 Mar 2002 11:15: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 g2PJFR418513 for ; Mon, 25 Mar 2002 11:15:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PJFOdx025112 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 11:15:29 -0800 (PST) Message-ID: <3C9F7748.3090004@Royer.com> Date: Mon, 25 Mar 2002 12:15:20 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>John Stracke wrote: >> > >>>How does a CUA find out whether these non-standard queries exist? >>> >>Okay - 'x-get-me-today's-stuff', now it is a vendor only thing. >> > > Again, how do you find out if the CS implements x-get-me-todays-stuff? Query for stored quires just like any other stored object. We can add predefined ones if we want - as a standard. Or ANY CUA can save a QUERY and use it later. They do NOT need to be defined in advance. Works both ways. From owner-ietf-calendar@mail.imc.org Mon Mar 25 14:37: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 OAA28781 for ; Mon, 25 Mar 2002 14:37:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PJIra18610 for ietf-calendar-bks; Mon, 25 Mar 2002 11:18:53 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PJIq418606 for ; Mon, 25 Mar 2002 11:18:52 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PJImdx025155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 11:18:53 -0800 (PST) Message-ID: <3C9F7814.1070705@Royer.com> Date: Mon, 25 Mar 2002 12:18:44 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.com> <3C9F5657.8090305@Royer.com> <3C9F66F2.9060400@jsoft.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 Gary Frederick wrote: > > So we are dropping the XML version of iCalendar? > > Gee, I must have missed that e-mail. NO - We are dropping that CAP encapsulates iCalendar objects in XML. The xCal draft is going forward. I would suspect that there can be a draft on how a CS can optionally support xCal objects. It won't be hard as xCal is a 1:1 mapping of iCalendar. From owner-ietf-calendar@mail.imc.org Mon Mar 25 14:43: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 OAA29057 for ; Mon, 25 Mar 2002 14:43:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PJOlC18844 for ietf-calendar-bks; Mon, 25 Mar 2002 11:24: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 g2PJOk418840 for ; Mon, 25 Mar 2002 11:24:46 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PJOhdx025237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 11:24:48 -0800 (PST) Message-ID: <3C9F7977.6010600@Royer.com> Date: Mon, 25 Mar 2002 12:24:39 -0700 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF CC: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.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 Alan Davies wrote: >> Your mean (4)? >> >> I agree that they need to be tossed. I really wish you had been >> active on the list a few months ago. > > > If the two clauses are 'tossed', they should be replaced with a clear, > unambiguous explanation of the meaning of querying a multi-instance > just by property name (i.e. does it mean 'any' instance of that property, > or 'all' instances of that property), rather than ignoring the issue > as SQL-MIN did. We agree - lets clear up the text. > It should also be noted that only 1 of the above queries could be > represented if the clauses were 'tossed' (we would have to choose > whether the two references to ATTENDEE in the first two examples > would refer to the same or different properties). In what case would 'two' ATTENDEEs be from the 'same' property? ATTENDEE is a single valued, multiinstance property. From owner-ietf-calendar@mail.imc.org Mon Mar 25 15:22:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01365 for ; Mon, 25 Mar 2002 15:22:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PK6TD19962 for ietf-calendar-bks; Mon, 25 Mar 2002 12:06:29 -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 g2PK6R419956 for ; Mon, 25 Mar 2002 12:06:27 -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 g2PK6JO00364 for ; Mon, 25 Mar 2002 12:06:19 -0800 (PST) Received: from netscape.com ([10.169.59.141]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTJP6L00.JCC; Mon, 25 Mar 2002 12:06:21 -0800 Message-ID: <3C9F833D.E9BEDE9E@netscape.com> Date: Mon, 25 Mar 2002 12:06:21 -0800 From: Steve Mansour Organization: Netscape X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Peter Thompson CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: Content-Type: multipart/mixed; boundary="------------782E3AFC8C18884F82C901CB" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------782E3AFC8C18884F82C901CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Thompson wrote: > > So you are putting transport dependancies into the data area? Peter, I don't understand. What transport dependancies do you see in the data area? If you're referring to LATENCY and ACTION, I would claim that those are values that we want to send to the server independent of transport. That is, we would want to bound the latency on the command whether we send the command via BEEP, or any other transport. -Steve > I'm sorry if I'm confused about this, but I really hope that > you are keeping data separate from transport, as the iCalendar > data is used by other transports. > > Cheers, > Peter > > > -----Original Message----- > > From: owner-ietf-calendar@mail.imc.org > > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Lawrence > > Greenfield > > Sent: Monday, March 25, 2002 7:23 AM > > To: CalSched IETF; Steve Mansour > > Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal > > > > > > > > I agree that this is preferable. This removes the redundant > > application layer. This should make the protocol easier to understand > > and simplify the document. > > > > Larry > > > > Date: Sun, 24 Mar 2002 11:49:09 -0800 > > From: sman@netscape.com (Steve Mansour) > > [...] > > ENCAPSULATION B > > > > C: MSG 1 2 . 1234 123 > > C: Content-type: text/calendar > > C: > > C: BEGIN:VCALENDAR > > C: METHOD:SEARCH > > C: LATENCY:3 > > C: ACTION:ASK > > ... > > C: END:VCALENDAR > > C: END > > > > --------------782E3AFC8C18884F82C901CB Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:(415) 428-4059 tel;work:(415) 937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Director of Engineering adr;quoted-printable:;;501 East Middlefield Road=0D=0A;Mountain View;CA;94043; x-mozilla-cpt:;-1096 fn:Steve Mansour end:vcard --------------782E3AFC8C18884F82C901CB-- From owner-ietf-calendar@mail.imc.org Mon Mar 25 15: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 PAA01741 for ; Mon, 25 Mar 2002 15:28:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PKBnL20306 for ietf-calendar-bks; Mon, 25 Mar 2002 12:11:49 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PKBj420302 for ; Mon, 25 Mar 2002 12:11:46 -0800 (PST) To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 15:06:56 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 03:22:12 PM, Serialize complete at 03/25/2002 03:22:12 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Again, how do you find out if the CS implements x-get-me-todays-stuff? > >Query for stored quires But how does that response represent a query such as "today's stuff", if it can't be expressed in the normal CAP syntax? /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |"If there's anything The Flintstones have taught us, it's that| |pelicans can be used to mix cement." -- Homer Simpson | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 15:37: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 PAA02182 for ; Mon, 25 Mar 2002 15:37:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PKKSK21206 for ietf-calendar-bks; Mon, 25 Mar 2002 12:20:28 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PKKR421200 for ; Mon, 25 Mar 2002 12:20:27 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2PKKMdl017550 for ; Mon, 25 Mar 2002 15:20:26 -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 g2PKKJQ01465 for ; Mon, 25 Mar 2002 15:20:19 -0500 (EST) Message-ID: <01f501c1d43a$b35c8020$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <3C9F7977.6010600@Royer.com> Subject: Re: CAP draft 07 issues - sections 3 and 4 Date: Mon, 25 Mar 2002 15:21:52 -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: "CalSched IETF" Cc: "CalSched IETF" Sent: Monday, March 25, 2002 2:24 PM Subject: Re: CAP draft 07 issues - sections 3 and 4 > > > > Alan Davies wrote: > > > >> Your mean (4)? > >> > >> I agree that they need to be tossed. I really wish you had been > >> active on the list a few months ago. > > > > > > > If the two clauses are 'tossed', they should be replaced with a clear, > > unambiguous explanation of the meaning of querying a multi-instance > > just by property name (i.e. does it mean 'any' instance of that property, > > or 'all' instances of that property), rather than ignoring the issue > > as SQL-MIN did. > > > We agree - lets clear up the text. > > > > It should also be noted that only 1 of the above queries could be > > represented if the clauses were 'tossed' (we would have to choose > > whether the two references to ATTENDEE in the first two examples > > would refer to the same or different properties). > > > > In what case would 'two' ATTENDEEs be from the 'same' property? > ATTENDEE is a single valued, multiinstance property. Alan wasn't referring to two ATTENDEE values on the same property; he was referring to two references to a single ATTENDEE property, as in this example he gave: SELECT * FROM VEVENT WHERE ATTENDEE = "foo@example.com" AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED Notice that on the 2rd line of the above example, the property value is referenced (the first ATTENDEE reference), and on the 3rd line, a parameter of the property is referenced (the second ATTENDEE reference). To reiterate Alan's point, without the USING_PROPERTIES, it is ambiguous whether the second ATTENDEE reference refers to the PARTSTAT parameter of same ATTENDEE property referenced on the 2nd line or the PARTSTAT parameter of some other ATTENDEE property. This is disambiguated as follows: SELECT * FROM VEVENT WHERE USING_PROPERTIES ATTENDEE my-att WHERE my-att = "foo@example.com" AND PARAM(my-att, PARTSTAT) = ACCEPTED By naming the ATTENDEE property whose value = "foo@example.com" as 'my-att' on lines 2 & 3, we can be sure that the second reference (on line 4) refers to the same ATTENDEE property by using the name we've assigned. Graham From owner-ietf-calendar@mail.imc.org Mon Mar 25 15:37: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 PAA02212 for ; Mon, 25 Mar 2002 15:37:58 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PKJo821100 for ietf-calendar-bks; Mon, 25 Mar 2002 12:19:50 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PKJh421084 for ; Mon, 25 Mar 2002 12:19:44 -0800 (PST) To: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 15:26:27 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 03:30:13 PM, Serialize complete at 03/25/2002 03:30:13 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> whether the two references to ATTENDEE in the first two examples >> would refer to the same or different properties). > >In what case would 'two' ATTENDEEs be from the 'same' property? >ATTENDEE is a single valued, multiinstance property. Yes, but the SQL syntax can't know that, since it has to be able to cope with properties added in the future. If we dropped USING_PROPERTY, we'd be left with three choices for how to deal with "property relop1 value1 AND property relop2 value2" (where relop is a relational operator such as = or <=): (a) Both references to "property" always refer to the same instance. In this case, "ATTENDEE='foo@example.com' AND ATTENDEE='bar@example.com'" will always be false--not very useful. (b) "property relop value" always means "there exists some instance of property such that property relop value". In this case, "VALARM.DTSTART>=20020325T000000Z AND VALARM.DTSTART<=20020325T235959Z" means "there exists a VALARM A that starts after 20020325T000000Z and another VALARM B, possibly the same as A, that starts before 20020325T235959Z". Again, not very useful. (c) Define, on a property-by-property basis, which of (a) or (b) applies for each property in 2445. Lots of work, lots of potential for error, difficult to maintain as 2445 evolves. I don't think any of these is viable; I think we need to keep USING_PROPERTY (and USING_PARAMETER, too, by the same reasoning). /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |"I'm sorry, Wizowsky, Randall says I'm not supposed to talk to| |victims of his evil plots." -- _Monsters, Inc._ | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 15:44:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02594 for ; Mon, 25 Mar 2002 15:44:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PKT9E21498 for ietf-calendar-bks; Mon, 25 Mar 2002 12:29:09 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PKT8421494 for ; Mon, 25 Mar 2002 12:29:08 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2PKT7dl017663 for ; Mon, 25 Mar 2002 15:29:07 -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 g2PKSxQ02227; Mon, 25 Mar 2002 15:28:59 -0500 (EST) Message-Id: <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 15:32:27 -0500 To: CalSched IETF From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 Cc: CalSched IETF In-Reply-To: <3C9F7977.6010600@Royer.com> References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@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 12:24 PM 25/03/2002 -0700, Doug Royer wrote: >>It should also be noted that only 1 of the above queries could be >>represented if the clauses were 'tossed' (we would have to choose >>whether the two references to ATTENDEE in the first two examples >>would refer to the same or different properties). > >In what case would 'two' ATTENDEEs be from the 'same' property? >ATTENDEE is a single valued, multiinstance property. That's not what I was trying to say. Perhaps an example would help; consider the following snippet from an iCalendar object: BEGIN:VEVENT [...] ATTENDEE;PARTSTAT=NEEDS-ACTION:foo@example.com ATTENDEE;PARTSTAT=ACCEPTED:bar@example.com END:VEVENT My point is that it's not clear whether the following query would match that VEVENT or not: SELECT * FROM VEVENT WHERE ATTENDEE = "foo@example.com" AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED You see the VEVENT contains an ATTENDEE whose value matches "foo@example.com", and an ATTENDEE whose PARTSTAT matches "ACCEPTED", so it would be considered a match if each time the ATTENDEE property was used, it was taken to mean "any ATTENDEE of the VEVENT". --Alan From owner-ietf-calendar@mail.imc.org Mon Mar 25 16:35:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04474 for ; Mon, 25 Mar 2002 16:35:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PLGGO23999 for ietf-calendar-bks; Mon, 25 Mar 2002 13:16:16 -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 g2PLGF423995 for ; Mon, 25 Mar 2002 13:16:15 -0800 (PST) Received: from jsoft.com (IDENT:8RjitSCi8qIxiYeXk58mdnHz6dl16UJe@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2PLEvV10624 for ; Mon, 25 Mar 2002 15:14:57 -0600 Message-ID: <3C9F9351.4050400@jsoft.com> Date: Mon, 25 Mar 2002 15:14:57 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.com> <3C9F5657.8090305@Royer.com> <3C9F66F2.9060400@jsoft.com> <3C9F7814.1070705@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'll go back to no comment mode. Gary Doug Royer wrote: > > > > Gary Frederick wrote: > >> >> So we are dropping the XML version of iCalendar? >> >> Gee, I must have missed that e-mail. > > > > NO - We are dropping that CAP encapsulates iCalendar objects in XML. > > The xCal draft is going forward. I would suspect that there can > be a draft on how a CS can optionally support xCal objects. It > won't be hard as xCal is a 1:1 mapping of iCalendar. > > > From owner-ietf-calendar@mail.imc.org Mon Mar 25 16:35: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 QAA04528 for ; Mon, 25 Mar 2002 16:35:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PLKoh24089 for ietf-calendar-bks; Mon, 25 Mar 2002 13:20: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 g2PLKn424085 for ; Mon, 25 Mar 2002 13:20:49 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PLKkdx027023 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 13:20:51 -0800 (PST) Message-ID: <3C9F94A9.9030502@Royer.com> Date: Mon, 25 Mar 2002 14:20:41 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>>Again, how do you find out if the CS implements x-get-me-todays-stuff? >>> >>Query for stored quires >> > > But how does that response represent a query such as "today's stuff", if > it can't be expressed in the normal CAP syntax? Who cares? It is vendor specific. Non-vendor specific stored can also be stored. Such as get-all-booked VEVENTs, Get all VCARs that effect me, ..., and VENDOR specific queries. From owner-ietf-calendar@mail.imc.org Mon Mar 25 16:42: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 QAA04738 for ; Mon, 25 Mar 2002 16:42:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PLQG324176 for ietf-calendar-bks; Mon, 25 Mar 2002 13:26:16 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PLQF424172 for ; Mon, 25 Mar 2002 13:26:15 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PLQDdx027092 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 13:26:17 -0800 (PST) Message-ID: <3C9F95EF.8080705@Royer.com> Date: Mon, 25 Mar 2002 14:26:07 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.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 Alan Davies wrote: > > My point is that it's not clear whether the following query > would match that VEVENT or not: > > SELECT * FROM VEVENT WHERE > ATTENDEE = "foo@example.com" > AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED > > You see the VEVENT contains an ATTENDEE whose value matches > "foo@example.com", and an ATTENDEE whose PARTSTAT matches > "ACCEPTED", so it would be considered a match if each time > the ATTENDEE property was used, it was taken to mean > "any ATTENDEE of the VEVENT". BEGIN:VEVENT [...] ATTENDEE;PARTSTAT=NEEDS-ACTION:foo@example.com ATTENDEE;PARTSTAT=ACCEPTED:bar@example.com END:VEVENT When would you ever want it to match a value of one property, and parameter of another property for the same property name? From owner-ietf-calendar@mail.imc.org Mon Mar 25 16:43: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 QAA04762 for ; Mon, 25 Mar 2002 16:42:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PLScV24229 for ietf-calendar-bks; Mon, 25 Mar 2002 13:28:38 -0800 (PST) Received: from ismtp.starfish.com (ismtp.starfish.com.209.120.66.in-addr.arpa [66.120.209.21] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PLSb424225 for ; Mon, 25 Mar 2002 13:28:37 -0800 (PST) Received: from pthompson509 ([10.79.194.27]) by ismtp.starfish.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 25 Mar 2002 13:28:32 -0800 From: "Peter Thompson" To: "CalSched IETF" Subject: RE: CAP / BEEP / XML / iCalendar - updated proposal Date: Mon, 25 Mar 2002 13:28:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3C9F833D.E9BEDE9E@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 25 Mar 2002 21:28:32.0241 (UTC) FILETIME=[035D8610:01C1D444] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit If that is the intent with LATENCY, that is fine. How about ACTION? That seems be beyond the realm of calendar data... Cheers, Peter > -----Original Message----- > From: sman@netscape.com [mailto:sman@netscape.com] > Sent: Monday, March 25, 2002 12:06 PM > To: Peter Thompson > Cc: CalSched IETF > Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal > > > Peter Thompson wrote: > > > > So you are putting transport dependancies into the data area? > > Peter, I don't understand. What transport dependancies do you see in the > data area? > > If you're referring to LATENCY and ACTION, I would claim that those are > values that we want to send to the server independent of transport. That > is, we would want to bound the latency on the command whether we send > the command via BEEP, or any other transport. > > -Steve > > > I'm sorry if I'm confused about this, but I really hope that > > you are keeping data separate from transport, as the iCalendar > > data is used by other transports. > > > > Cheers, > > Peter > > > > > -----Original Message----- > > > From: owner-ietf-calendar@mail.imc.org > > > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Lawrence > > > Greenfield > > > Sent: Monday, March 25, 2002 7:23 AM > > > To: CalSched IETF; Steve Mansour > > > Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal > > > > > > > > > > > > I agree that this is preferable. This removes the redundant > > > application layer. This should make the protocol easier to understand > > > and simplify the document. > > > > > > Larry > > > > > > Date: Sun, 24 Mar 2002 11:49:09 -0800 > > > From: sman@netscape.com (Steve Mansour) > > > [...] > > > ENCAPSULATION B > > > > > > C: MSG 1 2 . 1234 123 > > > C: Content-type: text/calendar > > > C: > > > C: BEGIN:VCALENDAR > > > C: METHOD:SEARCH > > > C: LATENCY:3 > > > C: ACTION:ASK > > > ... > > > C: END:VCALENDAR > > > C: END > > > > > > From owner-ietf-calendar@mail.imc.org Mon Mar 25 16:44: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 QAA04825 for ; Mon, 25 Mar 2002 16:44:25 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PLSNX24219 for ietf-calendar-bks; Mon, 25 Mar 2002 13:28:23 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PLSM424215 for ; Mon, 25 Mar 2002 13:28:22 -0800 (PST) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2PLSOo27635 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 25 Mar 2002 13:28:24 -0800 (PST) Received: from sendmail.com (pcp01331772pcs.columb01.pa.comcast.net [68.81.15.221]) by foon.sendmail.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PLS9705210 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified OK); Mon, 25 Mar 2002 13:28:11 -0800 Message-ID: <3C9F9680.7070104@sendmail.com> Date: Mon, 25 Mar 2002 16:28:32 -0500 From: Robert Lusardi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: Alan Davies CC: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Filtered: Sendmail MIME Filter v1.0.7 foon.sendmail.com g2PLS9705210 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've been holding back my responses to this thread because I have not gotten to this section of CAP, but I can't hold back anymore ... I'm sorry if I'm stating something that's blatenly stated in the document. As far as I've been following all the threads, CAP's query requests follow SQL. If that's true, then the examples that Alan uses are *not* ambiguous at all. The use of AND in the statements means that the query below would fail. If you wanted it to pass, then you would need an OR. The example query with VALARM would *only* return VEVENTS whose alarm values were between those two dates. Again, not ambiguous at all. As someone who is very familiar to SQL the use of USING_PROPERTY and USING PARAMETER are just needlessly confusing. Is there something I'm missing? If there's a point where CAP clearly breaks from SQL standard and this is stated in CAP (and this is where USING_PROPERTY and USING_PARAMETER have been introduced), then again I apologize. I will read through this section ASAP. rob Alan Davies wrote: > > At 12:24 PM 25/03/2002 -0700, Doug Royer wrote: > >>> It should also be noted that only 1 of the above queries could be >>> represented if the clauses were 'tossed' (we would have to choose >>> whether the two references to ATTENDEE in the first two examples >>> would refer to the same or different properties). >> >> >> In what case would 'two' ATTENDEEs be from the 'same' property? >> ATTENDEE is a single valued, multiinstance property. > > > That's not what I was trying to say. > > Perhaps an example would help; consider the following > snippet from an iCalendar object: > > BEGIN:VEVENT > [...] > ATTENDEE;PARTSTAT=NEEDS-ACTION:foo@example.com > ATTENDEE;PARTSTAT=ACCEPTED:bar@example.com > END:VEVENT > > My point is that it's not clear whether the following query > would match that VEVENT or not: > > SELECT * FROM VEVENT WHERE > ATTENDEE = "foo@example.com" > AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED > > You see the VEVENT contains an ATTENDEE whose value matches > "foo@example.com", and an ATTENDEE whose PARTSTAT matches > "ACCEPTED", so it would be considered a match if each time > the ATTENDEE property was used, it was taken to mean > "any ATTENDEE of the VEVENT". > > --Alan > From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:01:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05322 for ; Mon, 25 Mar 2002 17:01:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PLkTW24606 for ietf-calendar-bks; Mon, 25 Mar 2002 13:46:29 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PLkS424602 for ; Mon, 25 Mar 2002 13:46:28 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2PLkNdl018763; Mon, 25 Mar 2002 16:46:24 -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 g2PLkKQ10711; Mon, 25 Mar 2002 16:46:20 -0500 (EST) Message-Id: <5.1.0.14.0.20020325164315.0ab57508@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 16:49:49 -0500 To: Robert Lusardi From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 Cc: CalSched IETF In-Reply-To: <3C9F9680.7070104@sendmail.com> References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@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: I think what you're missing is that iCalendar's data model is not that of a simple relational database. The first attempt at a CAP query language made the assumption that mapping iCalendar components and properties to SQL-92 tables and columns was a simple problem, and went on to use SQL-92 to query those 'virtual' tables and columns. iCalendar's data model differs from this in these important respects: 1) A component may contain multiple sub-components (SQL-92 tables may not have sub-tables). 2) Multiple instances of the same property may exist within a component (a table may have only one instance of each column). Searching through the archives at http://www.imc.org/ietf-calendar will show that there has been much discussion on this, and as yet no better workable suggestions. No need to apologize, with this information in mind, we'd welcome a cleaner, simpler way to query iCalendar's data model without ambiguosity. --Alan At 04:28 PM 25/03/2002 -0500, Robert Lusardi wrote: >I've been holding back my responses to this thread because I have not >gotten to this section of CAP, but I can't hold back anymore ... I'm sorry >if I'm stating something that's blatenly stated in the document. > >As far as I've been following all the threads, CAP's query requests follow >SQL. If that's true, then the examples that Alan uses are *not* ambiguous >at all. > >The use of AND in the statements means that the query below would fail. If >you wanted it to pass, then you would need an OR. > >The example query with VALARM would *only* return VEVENTS whose alarm >values were between those two dates. Again, not ambiguous at all. > >As someone who is very familiar to SQL the use of USING_PROPERTY and USING >PARAMETER are just needlessly confusing. > >Is there something I'm missing? If there's a point where CAP clearly >breaks from SQL standard and this is stated in CAP (and this is where >USING_PROPERTY and USING_PARAMETER have been introduced), then again I >apologize. I will read through this section ASAP. > >rob > > > >Alan Davies wrote: > >> >>At 12:24 PM 25/03/2002 -0700, Doug Royer wrote: >> >>>>It should also be noted that only 1 of the above queries could be >>>>represented if the clauses were 'tossed' (we would have to choose >>>>whether the two references to ATTENDEE in the first two examples >>>>would refer to the same or different properties). >>> >>> >>>In what case would 'two' ATTENDEEs be from the 'same' property? >>>ATTENDEE is a single valued, multiinstance property. >> >> >>That's not what I was trying to say. >> >>Perhaps an example would help; consider the following >>snippet from an iCalendar object: >> >> BEGIN:VEVENT >> [...] >> ATTENDEE;PARTSTAT=NEEDS-ACTION:foo@example.com >> ATTENDEE;PARTSTAT=ACCEPTED:bar@example.com >> END:VEVENT >> >>My point is that it's not clear whether the following query >>would match that VEVENT or not: >> >> SELECT * FROM VEVENT WHERE >> ATTENDEE = "foo@example.com" >> AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED >> >>You see the VEVENT contains an ATTENDEE whose value matches >>"foo@example.com", and an ATTENDEE whose PARTSTAT matches >>"ACCEPTED", so it would be considered a match if each time >>the ATTENDEE property was used, it was taken to mean >>"any ATTENDEE of the VEVENT". >> >>--Alan > > > From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:02: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 RAA05369 for ; Mon, 25 Mar 2002 17:02:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PLlxV24642 for ietf-calendar-bks; Mon, 25 Mar 2002 13:47:59 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PLlv424636 for ; Mon, 25 Mar 2002 13:47:57 -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 g2PLloO03061 for ; Mon, 25 Mar 2002 13:47:50 -0800 (PST) Received: from netscape.com ([10.169.59.204]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTJTVQ00.CME; Mon, 25 Mar 2002 13:47:50 -0800 Message-ID: <3C9F9A66.B956EE92@netscape.com> Date: Mon, 25 Mar 2002 13:45:10 -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: Gary Frederick CC: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: <3C9E69C6.685D0550@netscape.com> <3C9F173E.8020602@jsoft.com> Content-Type: multipart/mixed; boundary="------------7DC7B5C80A5E5FE89C2DD5FD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7DC7B5C80A5E5FE89C2DD5FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pat? You're driving this? -Steve Gary Frederick wrote: > Are we to just focusing on the "CAP / BEEP / XML / iCalendar - updated > proposal"? > > Would it be useful to take your list of issues and 'schedule' them? > > Gary > > Steve Mansour wrote: > > ... continued: > > > > Section 3.1 > > > > seems superfluous and covered in BEEP. do we really need this? > > ... --------------7DC7B5C80A5E5FE89C2DD5FD 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 --------------7DC7B5C80A5E5FE89C2DD5FD-- From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:12: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 RAA05844 for ; Mon, 25 Mar 2002 17:12:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PLwCq24836 for ietf-calendar-bks; Mon, 25 Mar 2002 13:58:12 -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 g2PLwA424832 for ; Mon, 25 Mar 2002 13:58:10 -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 g2PLw7708677 for ; Mon, 25 Mar 2002 13:58:07 -0800 (PST) Received: from netscape.com ([10.169.59.204]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTJUCV00.VQ3; Mon, 25 Mar 2002 13:58:07 -0800 Message-ID: <3C9F9CD0.D26A9427@netscape.com> Date: Mon, 25 Mar 2002 13:55:28 -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: Gary Frederick CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.com> <3C9F4ACC.2EEC008@netscape.com> <3C9F561A.8000302@jsoft.com> Content-Type: multipart/mixed; boundary="------------ADE91DB79A04C8E6D61F2162" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ADE91DB79A04C8E6D61F2162 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yipes! I would not want to promote that. For better or worse, RFC2445 is not XML based. We spent several years trying to get that RFC through. People have built software expecting iCalendar syntax. To change CAP now and and promote the use of XMLized icalendar would open up a huge can of worms, and it would be unfair to people who have invested in iCalendar. Let's please not go there. Such a move is really out of the scope of CAP. -Steve Gary Frederick wrote: > Let me try again... > > Steve, you gave an example that used good ol iCalendar in the > application part of the message. I wanted to know what it would look > like if the application part was XML/XCS rather than iCalendar. > > ENCAPSULATION B - XCS version > > C: MSG 1 2 . 1234 123 > C: Content-type: the correct type for xcs... > C: > C: > C: > C: ask > ... > C: > C: END > > The above is NOT an attempt to show what the XML/XCS should be. It's to > clarify that I was asking what an encapsulation that used XCS rather > than iCalendar would look like. > > Gary > > Steve Mansour wrote: > > Gary Frederick wrote: > > > > > >>What would the XML version of encapsulation B look like? > > > > > > There's no need for an XML encapsulation. We MUST have an iCalendar encapsulation > > because that's how our application data is defined. The point of B was to show > > that the iCalendar encapsulation is the only one needed. > > > > -Steve > > > > > >> > >>Gary > >> > >>Steve Mansour wrote: > >> > >>>Folks, > >>> > >>>After thinking about some of the feedback on this, I think that the XML > >>>encoding, while harmless, is superfluous. At the meeting in Minneapolis, > >>>we were thinking along these lines: > >>> > >>> ENCAPSULATION A > >>> > >>> C: MSG 1 2 . 1234 123 > >>> C: Content-type: application/cap+xml > >>> C: > >>> C: > >>> C: >>> C: Content-Type: text/calendar > >>> C: > >>> C: BEGIN:VCALENDAR > >>> C: METHOD:SEARCH > >>> ... > >>> C: END:VCALENDAR > >>> C: ]]> > >>> C: > >>> C: END > >>> > >>>The XML encapsulation is innocuous, but it adds nothing. Further, it > >>>tempts us to move things out of the Application layer and into the > >>>Transport layer (such as the command names, and attributes such as > >>>"latency" and "action" -- undermining the transport/application > >>>separation and leading us down slippery slopes. Here is a simpler > >>>alternative (and yes, I know some of you have been pushing for something > >>>like this all along :-) : > >>> > >>> ENCAPSULATION B > >>> > >>> C: MSG 1 2 . 1234 123 > >>> C: Content-type: text/calendar > >>> C: > >>> C: BEGIN:VCALENDAR > >>> C: METHOD:SEARCH > >>> C: LATENCY:3 > >>> C: ACTION:ASK > >>> ... > >>> C: END:VCALENDAR > >>> C: END > >>> > >>>The advantage of encapsulation B is that it represents exactly the same > >>>content as encapsulation A, but it uses one rather than two > >>>encapsulations and there are no hints about the calendaring commands in > >>>the transport. We could substitute *any* transport. > >>> > >>>Can anyone suggest why we would want to use encapsulation A rather than B ? > >>> > >>>Are there any objections to moving forward with encapsulations as > >>>specified in B ? > >>> > >>>-Steve > >>> > >> --------------ADE91DB79A04C8E6D61F2162 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 --------------ADE91DB79A04C8E6D61F2162-- From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:20: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 RAA06120 for ; Mon, 25 Mar 2002 17:20:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PM5op25073 for ietf-calendar-bks; Mon, 25 Mar 2002 14:05:50 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PM5m425068 for ; Mon, 25 Mar 2002 14:05:49 -0800 (PST) To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 17:16:06 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 05:16:14 PM, Serialize complete at 03/25/2002 05:16:14 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> But how does that response represent a query such as "today's stuff", if >> it can't be expressed in the normal CAP syntax? > >Who cares? It is vendor specific. I'm sorry, but that's a bad answer. If we're going to include stored queries in CAP, we have to have cases in mind where they're useful without relying on proprietary extensions. Otherwise, we can leave them out, and people who are inclined to get proprietary can add whole new commands--that's essentially what a proprietary stored query would be, after all. >Such as get-all-booked >VEVENTs If you've got a CUA that doesn't want to spend the bandwidth to send the query inline, then you definitely don't want "all booked events"; you want "all booked events in this time range". As things stand, that time range would have to be hard-coded in the query, which is pretty useless. I see two viable paths: either we drop stored queries, or we add something like SYSDATE (and functions to parse out the year, month, etc.) to the query language. Personally, I'd prefer to drop stored queries. I really don't see the point, even for a PDA; the data that comes back is going to be potentially much larger than the query. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |Using strong crypto on the Internet is like using an armored car| |to transport money from someone living in a tent to someone | |living in a cardboard box. | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:23: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 RAA06206 for ; Mon, 25 Mar 2002 17:23:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PM9Xm25162 for ietf-calendar-bks; Mon, 25 Mar 2002 14:09:33 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PM9V425158 for ; Mon, 25 Mar 2002 14:09:31 -0800 (PST) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2PM9Vo01572 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 25 Mar 2002 14:09:32 -0800 (PST) Received: from sendmail.com (pcp01331772pcs.columb01.pa.comcast.net [68.81.15.221]) by foon.sendmail.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PM9S711901 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified OK); Mon, 25 Mar 2002 14:09:30 -0800 Message-ID: <3C9FA02C.3050208@sendmail.com> Date: Mon, 25 Mar 2002 17:09:48 -0500 From: Robert Lusardi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: Alan Davies CC: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> <5.1.0.14.0.20020325164315.0ab57508@imap1.in.steltor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Filtered: Sendmail MIME Filter v1.0.7 foon.sendmail.com g2PM9S711901 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alan Davies wrote: > I think what you're missing is that iCalendar's data model > is not that of a simple relational database. I'll definitely agree to that ... > iCalendar's data model differs from this in these important > respects: > > 1) A component may contain multiple sub-components (SQL-92 > tables may not have sub-tables). Not true (although this is really just a matter of semantics). Take VEVENTS and VALARMS. You could have alarms that exist outside the realm of an event, but for our case alarms are "sub-components" of an event. If alarms are implemented in a different table, then this table becomes a "sub-table" (I prefer "child table", but it doesn't matter), to the event table. The alarms only exist to the extent that the event exists. > 2) Multiple instances of the same property may exist within > a component (a table may have only one instance of each > column). Here I agree completely, especially in the case of a "simple" rdb. You could "overload" the column with multiple values and deliminters, but that's not really the point. If this were the case though, the structure should have been designed as in 1) above. > Searching through the archives at http://www.imc.org/ietf-calendar This I need to do, but first finish CAP ... > No need to apologize, with this information in mind, we'd welcome > a cleaner, simpler way to query iCalendar's data model > without ambiguosity. Thanks :-) From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:27: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 RAA06351 for ; Mon, 25 Mar 2002 17:27:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PMD5K25411 for ietf-calendar-bks; Mon, 25 Mar 2002 14:13: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 g2PMD3425406 for ; Mon, 25 Mar 2002 14:13:03 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PMD1dx027728 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 14:13:05 -0800 (PST) Message-ID: <3C9FA0E7.4020101@Royer.com> Date: Mon, 25 Mar 2002 15:12:55 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal 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 Peter Thompson wrote: > If that is the intent with LATENCY, that is fine. > How about ACTION? That seems be beyond the realm of > calendar data... ACTION is the action to take when LATENCY times out. In addition to 'data' there is what I will all 'control and workflow data' that is independent of transport. I see ACTION and LATENCY as falling into that category. From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:31: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 RAA06440 for ; Mon, 25 Mar 2002 17:31:22 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PMGXi25700 for ietf-calendar-bks; Mon, 25 Mar 2002 14:16:33 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PMGW425696 for ; Mon, 25 Mar 2002 14:16:32 -0800 (PST) To: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 17:26:50 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 05:26:58 PM, Serialize complete at 03/25/2002 05:26:58 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >As far as I've been following all the threads, CAP's query requests >follow SQL. The problem is that the iCalendar data model contains many multivalued properties (etc.), which means that we can't quite use standard SQL to query them. For example: >The example query with VALARM would *only* return VEVENTS whose alarm >values were between those two dates. Again, not ambiguous at all. There could be more than one VALARM on the same VEVENT, though. >As someone who is very familiar to SQL (BTW, everybody, I can vouch for that; Rob was one of the SQL gurus at eCal.) >the use of USING_PROPERTY and >USING PARAMETER are just needlessly confusing. Unfortunately, they're needfully confusing. I tried to get the group to drop SQL a couple of months back, and posted a proposal that mapped better to the iCalendar data model; but nobody was interested (and I didn't have time to push it, because that was the day my wife went into labor :-). The USING stuff was developed as a workaround. /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |"The struggle is always worthwhile, if the end be worthwhile and| |the means honorable; foreknowledge of defeat is not sufficient | |reason to withdraw from the contest." -- Adron e'Kieron, by | |Steven Brust | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:37: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 RAA06538 for ; Mon, 25 Mar 2002 17:37:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PMJjr25876 for ietf-calendar-bks; Mon, 25 Mar 2002 14:19:45 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PMJi425867 for ; Mon, 25 Mar 2002 14:19:44 -0800 (PST) To: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 25 Mar 2002 17:30:01 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/25/2002 05:30:10 PM, Serialize complete at 03/25/2002 05:30:10 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> SELECT * FROM VEVENT WHERE >> ATTENDEE = "foo@example.com" >> AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED >> >> You see the VEVENT contains an ATTENDEE whose value matches >> "foo@example.com", and an ATTENDEE whose PARTSTAT matches >> "ACCEPTED", so it would be considered a match if each time >> the ATTENDEE property was used, it was taken to mean >> "any ATTENDEE of the VEVENT". > > BEGIN:VEVENT > [...] > ATTENDEE;PARTSTAT=NEEDS-ACTION:foo@example.com > ATTENDEE;PARTSTAT=ACCEPTED:bar@example.com > END:VEVENT > >When would you ever want it to match a value of one property, and parameter >of another property for the same property name? Well, for example, the query above could usefully mean, "give me all events where Fred is invited and at least one person has accepted". Also, consider this: SELECT * FROM VEVENT WHERE ATTENDEE = 'foo@example.com' AND PARAM(ATTENDEE, PARTSTAT) = 'ACCEPTED' AND ATTENDEE='bar@example.com' Which ATTENDEE does the PARAM go with now? /================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |================================================================| |I'm on a Mission From God to Save The World from megalomania! | |(Question: which God? Answer: Milhouse, God of Humility. You | |probably haven't heard of him; he doesn't put himself forward.) | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:40:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06608 for ; Mon, 25 Mar 2002 17:40:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PMQ0326139 for ietf-calendar-bks; Mon, 25 Mar 2002 14:26:00 -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 g2PMPx426135 for ; Mon, 25 Mar 2002 14:25:59 -0800 (PST) Received: from jsoft.com (IDENT:ZZy6UnX/59gI0BrHwlH4EewxoVGkpaFT@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2PMOZV10938; Mon, 25 Mar 2002 16:24:43 -0600 Message-ID: <3C9FA3A3.1060603@jsoft.com> Date: Mon, 25 Mar 2002 16:24:35 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3C9E2DB5.A1BD673B@netscape.com> <3C9F17B0.3030607@jsoft.com> <3C9F4ACC.2EEC008@netscape.com> <3C9F561A.8000302@jsoft.com> <3C9F9CD0.D26A9427@netscape.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 No problem - I went back to no comment mode That's in XML Gary Steve Mansour wrote: > Yipes! I would not want to promote that. For better or worse, RFC2445 is not XML > based. We spent several years trying to get that RFC through. People have built > software expecting iCalendar syntax. To change CAP now and and promote the use of > XMLized icalendar would open up a huge can of worms, and it would be unfair to people > who have invested in iCalendar. Let's please not go there. Such a move is really out > of the scope of CAP. > > -Steve > > Gary Frederick wrote: > > >>Let me try again... >> >>Steve, you gave an example that used good ol iCalendar in the >>application part of the message. I wanted to know what it would look >>like if the application part was XML/XCS rather than iCalendar. >> >> ENCAPSULATION B - XCS version >> >> C: MSG 1 2 . 1234 123 >> C: Content-type: the correct type for xcs... >> C: >> C: >> C: >> C: ask >> ... >> C: >> C: END >> >>The above is NOT an attempt to show what the XML/XCS should be. It's to >>clarify that I was asking what an encapsulation that used XCS rather >>than iCalendar would look like. >> >>Gary >> >>Steve Mansour wrote: >> >>>Gary Frederick wrote: >>> >>> >>> >>>>What would the XML version of encapsulation B look like? >>> >>> >>>There's no need for an XML encapsulation. We MUST have an iCalendar encapsulation >>>because that's how our application data is defined. The point of B was to show >>>that the iCalendar encapsulation is the only one needed. >>> >>>-Steve >>> >>> >>> >>>>Gary >>>> >>>>Steve Mansour wrote: >>>> >>>> >>>>>Folks, >>>>> >>>>>After thinking about some of the feedback on this, I think that the XML >>>>>encoding, while harmless, is superfluous. At the meeting in Minneapolis, >>>>>we were thinking along these lines: >>>>> >>>>> ENCAPSULATION A >>>>> >>>>> C: MSG 1 2 . 1234 123 >>>>> C: Content-type: application/cap+xml >>>>> C: >>>>> C: >>>>> C: >>>> C: Content-Type: text/calendar >>>>> C: >>>>> C: BEGIN:VCALENDAR >>>>> C: METHOD:SEARCH >>>>> ... >>>>> C: END:VCALENDAR >>>>> C: ]]> >>>>> C: >>>>> C: END >>>>> >>>>>The XML encapsulation is innocuous, but it adds nothing. Further, it >>>>>tempts us to move things out of the Application layer and into the >>>>>Transport layer (such as the command names, and attributes such as >>>>>"latency" and "action" -- undermining the transport/application >>>>>separation and leading us down slippery slopes. Here is a simpler >>>>>alternative (and yes, I know some of you have been pushing for something >>>>>like this all along :-) : >>>>> >>>>> ENCAPSULATION B >>>>> >>>>> C: MSG 1 2 . 1234 123 >>>>> C: Content-type: text/calendar >>>>> C: >>>>> C: BEGIN:VCALENDAR >>>>> C: METHOD:SEARCH >>>>> C: LATENCY:3 >>>>> C: ACTION:ASK >>>>> ... >>>>> C: END:VCALENDAR >>>>> C: END >>>>> >>>>>The advantage of encapsulation B is that it represents exactly the same >>>>>content as encapsulation A, but it uses one rather than two >>>>>encapsulations and there are no hints about the calendaring commands in >>>>>the transport. We could substitute *any* transport. >>>>> >>>>>Can anyone suggest why we would want to use encapsulation A rather than B ? >>>>> >>>>>Are there any objections to moving forward with encapsulations as >>>>>specified in B ? >>>>> >>>>>-Steve >>>>> >>>> From owner-ietf-calendar@mail.imc.org Mon Mar 25 17:49: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 RAA06919 for ; Mon, 25 Mar 2002 17:49:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PMV3826263 for ietf-calendar-bks; Mon, 25 Mar 2002 14:31:03 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PMV2426257 for ; Mon, 25 Mar 2002 14:31:03 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2PMUrdl019202; Mon, 25 Mar 2002 17:30:53 -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 g2PMUmQ15119; Mon, 25 Mar 2002 17:30:49 -0500 (EST) Message-Id: <5.1.0.14.0.20020325171935.0aaa7cf8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 17:34:17 -0500 To: Robert Lusardi From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 Cc: CalSched IETF In-Reply-To: <3C9FA02C.3050208@sendmail.com> References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> <5.1.0.14.0.20020325164315.0ab57508@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 05:09 PM 25/03/2002 -0500, Robert Lusardi wrote: >>iCalendar's data model differs from this in these important >>respects: >> >> 1) A component may contain multiple sub-components (SQL-92 >> tables may not have sub-tables). > >Not true (although this is really just a matter of semantics). Take >VEVENTS and VALARMS. You could have alarms that exist outside the realm of >an event, but for our case alarms are "sub-components" of an event. If >alarms are implemented in a different table, then this table becomes a >"sub-table" (I prefer "child table", but it doesn't matter), to the event >table. The alarms only exist to the extent that the event exists. That's true; Calendar could have been structured something like this. However, a "child table" such as VALARM contains no column that allows it to be joined with it's parent, in the way that an SQL child table would probably contain it's parent's primary key. Someone storing iCalendar in a relational DB would probably add in this "parent id", but as it's not part of the iCalendar model, we can't query on it in CAP-QL. --Alan From owner-ietf-calendar@mail.imc.org Mon Mar 25 18:08: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 SAA07393 for ; Mon, 25 Mar 2002 18:08:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PMsc726839 for ietf-calendar-bks; Mon, 25 Mar 2002 14:54: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 g2PMsb426835 for ; Mon, 25 Mar 2002 14:54:37 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PMsYdx028365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 14:54:39 -0800 (PST) Message-ID: <3C9FAAA4.3070006@Royer.com> Date: Mon, 25 Mar 2002 15:54:28 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>>But how does that response represent a query such as "today's stuff", >>> > if > >>>it can't be expressed in the normal CAP syntax? >>> >>Who cares? It is vendor specific. >> > > I'm sorry, but that's a bad answer. Okay fine, here is an answer for my private 'today' query: BEGIN:VCALENDAR VERSION:2.0 METHOD:REPLY BEGIN:VQUERY QUERID:my private query QUERY:SELECT * FROM VEVENT where X-virtual-col = 'today' END:VQUERY END:VCALENDAR Does that help? :-) Now ANY CUA can query for it to see of they exits, and ANY CUA can query for the details. I'll bet my CS returns an empty set or permission denied when non-me-CUAs try to find out what that query does and the contents of the stored value. I can think of several other canned queries that I use. However your CUA would still be free to store queries in my CS. And my CS will not care what they do as long as they are CAP and iCalendar compliant objects and you otherwise have permission. From owner-ietf-calendar@mail.imc.org Mon Mar 25 18:17:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07627 for ; Mon, 25 Mar 2002 18:17:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PN33e27021 for ietf-calendar-bks; Mon, 25 Mar 2002 15:03:03 -0800 (PST) Received: from novonyx.com (mail.novonyx.com [192.233.80.150]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PN32427017 for ; Mon, 25 Mar 2002 15:03:02 -0800 (PST) Received: from angelw2k Micah@novonyx.com [137.65.47.155] by novonyx.com with Novell NIMS $Revision: 2.88 $ on Linux; Mon, 25 Mar 2002 16:12:37 -0700 Message-ID: <027401c1d451$d95e9b20$9b2f4189@angelw2k> From: "Micah Gorrell" To: "CalSched IETF" Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal Date: Mon, 25 Mar 2002 16:07:34 -0700 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 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes thank you! A lot of us (myself included) have already written a lot of code around the iCalendar syntax. I really don't want to have to do all of that again for an xml version. I'm not saying there is anything wrong with xml. I'm just saying there is no added benifit. Micah -----Original Message----- From: "Steve Mansour" To: "Gary Frederick" Cc: "CalSched IETF" Date: Monday, March 25, 2002 3:21 PM Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal >Yipes! I would not want to promote that. For better or worse, RFC2445 is not XML >based. We spent several years trying to get that RFC through. People have built >software expecting iCalendar syntax. To change CAP now and and promote the use of >XMLized icalendar would open up a huge can of worms, and it would be unfair to people >who have invested in iCalendar. Let's please not go there. Such a move is really out >of the scope of CAP. > >-Steve > >Gary Frederick wrote: > >> Let me try again... >> >> Steve, you gave an example that used good ol iCalendar in the >> application part of the message. I wanted to know what it would look >> like if the application part was XML/XCS rather than iCalendar. >> >> ENCAPSULATION B - XCS version >> >> C: MSG 1 2 . 1234 123 >> C: Content-type: the correct type for xcs... >> C: >> C: >> C: >> C: ask >> ... >> C: >> C: END >> >> The above is NOT an attempt to show what the XML/XCS should be. It's to >> clarify that I was asking what an encapsulation that used XCS rather >> than iCalendar would look like. >> >> Gary >> >> Steve Mansour wrote: >> > Gary Frederick wrote: >> > >> > >> >>What would the XML version of encapsulation B look like? >> > >> > >> > There's no need for an XML encapsulation. We MUST have an iCalendar encapsulation >> > because that's how our application data is defined. The point of B was to show >> > that the iCalendar encapsulation is the only one needed. >> > >> > -Steve >> > >> > >> >> >> >>Gary >> >> >> >>Steve Mansour wrote: >> >> >> >>>Folks, >> >>> >> >>>After thinking about some of the feedback on this, I think that the XML >> >>>encoding, while harmless, is superfluous. At the meeting in Minneapolis, >> >>>we were thinking along these lines: >> >>> >> >>> ENCAPSULATION A >> >>> >> >>> C: MSG 1 2 . 1234 123 >> >>> C: Content-type: application/cap+xml >> >>> C: >> >>> C: >> >>> C: > >>> C: Content-Type: text/calendar >> >>> C: >> >>> C: BEGIN:VCALENDAR >> >>> C: METHOD:SEARCH >> >>> ... >> >>> C: END:VCALENDAR >> >>> C: ]]> >> >>> C: >> >>> C: END >> >>> >> >>>The XML encapsulation is innocuous, but it adds nothing. Further, it >> >>>tempts us to move things out of the Application layer and into the >> >>>Transport layer (such as the command names, and attributes such as >> >>>"latency" and "action" -- undermining the transport/application >> >>>separation and leading us down slippery slopes. Here is a simpler >> >>>alternative (and yes, I know some of you have been pushing for something >> >>>like this all along :-) : >> >>> >> >>> ENCAPSULATION B >> >>> >> >>> C: MSG 1 2 . 1234 123 >> >>> C: Content-type: text/calendar >> >>> C: >> >>> C: BEGIN:VCALENDAR >> >>> C: METHOD:SEARCH >> >>> C: LATENCY:3 >> >>> C: ACTION:ASK >> >>> ... >> >>> C: END:VCALENDAR >> >>> C: END >> >>> >> >>>The advantage of encapsulation B is that it represents exactly the same >> >>>content as encapsulation A, but it uses one rather than two >> >>>encapsulations and there are no hints about the calendaring commands in >> >>>the transport. We could substitute *any* transport. >> >>> >> >>>Can anyone suggest why we would want to use encapsulation A rather than B ? >> >>> >> >>>Are there any objections to moving forward with encapsulations as >> >>>specified in B ? >> >>> >> >>>-Steve >> >>> >> >> > From owner-ietf-calendar@mail.imc.org Mon Mar 25 18:27: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 SAA07856 for ; Mon, 25 Mar 2002 18:27:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PND2k27433 for ietf-calendar-bks; Mon, 25 Mar 2002 15:13:02 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PND1427429 for ; Mon, 25 Mar 2002 15:13:01 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PNCxdx028605 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 15:13:03 -0800 (PST) Message-ID: <3C9FAEF5.5020005@Royer.com> Date: Mon, 25 Mar 2002 16:12:53 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>> SELECT * FROM VEVENT WHERE >>> ATTENDEE = "foo@example.com" >>> AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED >>> >>>You see the VEVENT contains an ATTENDEE whose value matches >>>"foo@example.com", and an ATTENDEE whose PARTSTAT matches >>>"ACCEPTED", so it would be considered a match if each time >>>the ATTENDEE property was used, it was taken to mean >>>"any ATTENDEE of the VEVENT". >>> >> BEGIN:VEVENT >> [...] >> ATTENDEE;PARTSTAT=NEEDS-ACTION:foo@example.com >> ATTENDEE;PARTSTAT=ACCEPTED:bar@example.com >> END:VEVENT >> >>When would you ever want it to match a value of one property, and >> > parameter > >>of another property for the same property name? >> > > Well, for example, the query above could usefully mean, "give me all > events where Fred is invited and at least one person has accepted". Also, > consider this: We decided on no cross-table joins, and that is what it looks like to me. We stated that all parameters look like columns in a conceptional property table. So you are asking to join from the value of one component table (table=vevent col=attendee, value=fred) to the value in another table (table = attendee, col = partstat, value = accepted). That is a cross table join - no you can not do that in CAP-QL. From owner-ietf-calendar@mail.imc.org Mon Mar 25 18:55: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 SAA08646 for ; Mon, 25 Mar 2002 18:55:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PNeoB27986 for ietf-calendar-bks; Mon, 25 Mar 2002 15:40: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 g2PNem427981 for ; Mon, 25 Mar 2002 15:40:48 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2PNcfdx028924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 15:38:45 -0800 (PST) Message-ID: <3C9FB4FA.4030801@Royer.com> Date: Mon, 25 Mar 2002 16:38:34 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> <5.1.0.14.0.20020325164315.0ab57508@imap1.in.steltor.com> <3C9FA02C.3050208@sendmail.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 Robert Lusardi wrote: > > Not true (although this is really just a matter of semantics). Take > VEVENTS and VALARMS. You could have alarms that exist outside the realm > of an event, but for our case alarms are "sub-components" of an event. > If alarms are implemented in a different table, then this table becomes > a "sub-table" (I prefer "child table", but it doesn't matter), to the > event table. The alarms only exist to the extent that the event exists. Yes that is what we are doing in CAP-QL. Components are virtual tables and their continued properties are columns. Properties are virtual tables and their parameters are columns. These are somehow magically merged by the CS (out of scope for CAP) by some implementation specific 'parent-id'. We eliminated what we call cross-table joins. So it keeps the model simple. That is I can say component.property, but not component.propert.paramater. We invented the PARAM() function to extract out parameters from properties as the exception. > > Here I agree completely, especially in the case of a "simple" rdb. You > could "overload" the column with multiple values and deliminters, but > that's not really the point. If this were the case though, the > structure should have been designed as in 1) above. The effect is the same. Each virtual table exists for each property. It really does not matter what the over the wire format is. If component.property exists 4 times, it exists and the values are unique in iCalendar, so it does not matter if the over the wire format is or is not flat. In this virtual db, the colum exists with 4 entries in the table for that property with the 'parent-id' all the same. As far as a query goes, x = value or it does not. x = condition or it does not. We don't allow cross component joins in our virtual tables (outside of the PARAM() function). And as the values are unique to their scope, they could all exist in one virtual table and the effect is the same for query for a given component. For a query these are the same: PROPERTY:value1 PROPERTY:value2 and PROPERTY:value1,valule2 Where both can be represented in the same virtual table as: a vitrtual COMPONET-table prop-1-col prop-2-col PROPERTY-col ---------- ---------- ------------- xxx yyy value1 value2 There is NO case in iCalendar where those two could exists (even if the ABNF allowed) where the values in the same component would not be unique. Not when they are multi-instance, not when they are multi-valued, not when both are allowed. The same query can return all of the correct values. The CS is responsible for makeing the over the wire format valid iCalendar format. The same is true for contained components. They are unique in the CS (but not perhaps on the wire). If you query for them - they will be found. It does not matter if they are both called VALARM or not. We do not allow cross component joins, so you can not say where VALARM(#1) value [= < > ...condition] VALARAM(#2) value From owner-ietf-calendar@mail.imc.org Mon Mar 25 19:03: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 TAA08873 for ; Mon, 25 Mar 2002 19:03:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2PNkke28109 for ietf-calendar-bks; Mon, 25 Mar 2002 15:46:46 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PNkj428105 for ; Mon, 25 Mar 2002 15:46:45 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2PNj5dl019684 for ; Mon, 25 Mar 2002 18:45:05 -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 g2PNivQ21641 for ; Mon, 25 Mar 2002 18:44:57 -0500 (EST) Message-Id: <5.1.0.14.0.20020325170050.0aad5500@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 18:48:25 -0500 To: CalSched IETF From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 In-Reply-To: <3C9F95EF.8080705@Royer.com> References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@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: You're asking that now, after agreeing to and typing the proposed text that describes these clauses? That's not to say that we shouldn't rethink whether CAP-QL needs this ability or not though. I can think of reasons for wanting to query more than one instance of a property name within the same object, but the examples might seem a bit contrived. Also, all the queries could be achieved by making multiple queries, and/or calls to the CS, and/or filtering a larger returned data set in the CUA, at the cost of performance. If the consensus is that this ability is really not needed within CAP-QL, then the USING_ clauses could be removed. Some descriptive text would be needed to ensure that the example I gave is not considered ambiguous though. --Alan At 02:26 PM 25/03/2002 -0700, Doug Royer wrote: >>My point is that it's not clear whether the following query >>would match that VEVENT or not: >> SELECT * FROM VEVENT WHERE >> ATTENDEE = "foo@example.com" >> AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED >>You see the VEVENT contains an ATTENDEE whose value matches >>"foo@example.com", and an ATTENDEE whose PARTSTAT matches >>"ACCEPTED", so it would be considered a match if each time >>the ATTENDEE property was used, it was taken to mean >>"any ATTENDEE of the VEVENT". > > BEGIN:VEVENT > [...] > ATTENDEE;PARTSTAT=NEEDS-ACTION:foo@example.com > ATTENDEE;PARTSTAT=ACCEPTED:bar@example.com > END:VEVENT > >When would you ever want it to match a value of one property, and parameter >of another property for the same property name? From owner-ietf-calendar@mail.imc.org Mon Mar 25 19:23: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 TAA09127 for ; Mon, 25 Mar 2002 19:23:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2Q07Br29040 for ietf-calendar-bks; Mon, 25 Mar 2002 16:07:11 -0800 (PST) Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2Q079429036 for ; Mon, 25 Mar 2002 16:07:09 -0800 (PST) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2Q07Ao12797 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 25 Mar 2002 16:07:11 -0800 (PST) Received: from sendmail.com (pcp01331772pcs.columb01.pa.comcast.net [68.81.15.221]) by foon.sendmail.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2Q078731183 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified OK); Mon, 25 Mar 2002 16:07:10 -0800 Message-ID: <3C9FBBC4.6040207@sendmail.com> Date: Mon, 25 Mar 2002 19:07:32 -0500 From: Robert Lusardi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: John Stracke CC: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Filtered: Sendmail MIME Filter v1.0.7 foon.sendmail.com g2Q078731183 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>Well, for example, the query above could usefully mean, "give me all >>events where Fred is invited and at least one person has accepted". Also, >>consider this: >> >> SELECT * FROM VEVENT WHERE >> ATTENDEE = 'foo@example.com' >> AND PARAM(ATTENDEE, PARTSTAT) = 'ACCEPTED' >> AND ATTENDEE='bar@example.com' >> >>Which ATTENDEE does the PARAM go with now? >> Well, I can certainly tell you how SQL would do it, but I don't want to drag the conversation down to that (did I just hear someone say "Too Late!" :-). My point was that I keep hearing in the emails how the query language is "based" on SQL, so the question becomes how much is it based on SQL, and at what point does it deviate? Is (are) the point(s) of deviation the place(s) that make(s) the most sense? And do the resolutions make the most sense? My homework is to read up, and then shut up if I don't have an alternative. rob From owner-ietf-calendar@mail.imc.org Mon Mar 25 19:23: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 TAA09146 for ; Mon, 25 Mar 2002 19:23:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2Q067m28998 for ietf-calendar-bks; Mon, 25 Mar 2002 16:06:07 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2Q066428994 for ; Mon, 25 Mar 2002 16:06:06 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2Q067dl019814 for ; Mon, 25 Mar 2002 19:06:07 -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 g2Q060Q23668 for ; Mon, 25 Mar 2002 19:06:00 -0500 (EST) Message-Id: <5.1.0.14.0.20020325185023.0ab50418@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 19:09:29 -0500 To: CalSched IETF From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 In-Reply-To: <3C9FAEF5.5020005@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 04:12 PM 25/03/2002 -0700, Doug Royer wrote: >We decided on no cross-table joins, and that is what it looks like >to me. We decided against cross-component joins; and it's self-evident that the effect of giving a name to instances of a multi-property could be described as a sort cross-property join (within one component). This was never stated as such on the list though, and so there can have been no consensus either for or against it. >We stated that all parameters look like columns in a >conceptional property table. That may or may not have been discussed at some point in the discussion, but that's not the model that we decided upon. PARAM() looks like an SQL function that takes a column name and a parameter name, and returns a value, in the same way that SQL-92 built in functions are used. >So you are asking to join from >the value of one component table (table=vevent col=attendee, value=fred) >to the value in another table (table = attendee, col = partstat, >value = accepted). I'm afraid that really doesn't make much sense; the issue of joins between properties is nothing to do with the parameters. The values of the properties could just as easily have been used in the query, not the parameters. --Alan From owner-ietf-calendar@mail.imc.org Mon Mar 25 19:39: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 TAA09361 for ; Mon, 25 Mar 2002 19:39:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2Q0OTA29525 for ietf-calendar-bks; Mon, 25 Mar 2002 16:24:29 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2Q0OS429521 for ; Mon, 25 Mar 2002 16:24:28 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2Q0OTdl019904 for ; Mon, 25 Mar 2002 19:24:29 -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 g2Q0OKQ25076 for ; Mon, 25 Mar 2002 19:24:20 -0500 (EST) Message-Id: <5.1.0.14.0.20020325192337.0ab3d310@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Mar 2002 19:27:12 -0500 To: CalSched IETF From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 In-Reply-To: <3C9FB4FA.4030801@Royer.com> References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> <5.1.0.14.0.20020325164315.0ab57508@imap1.in.steltor.com> <3C9FA02C.3050208@sendmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:38 PM 25/03/2002 -0700, Doug Royer wrote: >Components are virtual tables and their continued properties >are columns. > >Properties are virtual tables and their parameters are columns. > >These are somehow magically merged by the CS (out of scope for CAP) >by some implementation specific 'parent-id'. Yes, the implementation of properties/parameters is out of scope for CAP, so how can we disallow something based on a reason that we shouldn't know about because it's out of scope? >We eliminated what we call cross-table joins. So it keeps the >model simple. That is I can say component.property, but not >component.propert.paramater. I've no idea what you mean by that. We decided upon PARAM(component.property, parameter) instead of component.property.parameter as a point of syntactical clarity and consistency; it's got nothing to do with any of the issues we're discussing. --Alan From owner-ietf-calendar@mail.imc.org Mon Mar 25 19:53: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 TAA09543 for ; Mon, 25 Mar 2002 19:53:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2Q0c1F29747 for ietf-calendar-bks; Mon, 25 Mar 2002 16:38: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 g2Q0c0429743 for ; Mon, 25 Mar 2002 16:38:00 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2Q0bwdx029681 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 16:38:02 -0800 (PST) Message-ID: <3C9FC2DF.2030705@Royer.com> Date: Mon, 25 Mar 2002 17:37:51 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Book to help us understand beep. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit (I have no affiliation with Mr Rose at all) This seems to be shipping for anyone that wants to understand how to use BEEP when implementing CAP. -------- Original Message -------- Subject: Your Amazon.com order has shipped (#....) Date: Tue, 26 Mar 2002 00:31:44 +0000 (GMT) Greetings from Amazon.com. We thought you'd like to know that we shipped your items today, and that this completes your order. The following items were included in this shipment: ---------------------------------------- Qty Item ---------------------------------------- 1 BEEP: The Definitive Guide ... ---------------------------------------- From owner-ietf-calendar@mail.imc.org Mon Mar 25 20:28: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 UAA10423 for ; Mon, 25 Mar 2002 20:28:09 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2Q19TW00563 for ietf-calendar-bks; Mon, 25 Mar 2002 17:09: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 g2Q19S400559 for ; Mon, 25 Mar 2002 17:09:28 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2Q19Rdx000104 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Mar 2002 17:09:31 -0800 (PST) Message-ID: <3C9FCA3F.8010102@Royer.com> Date: Mon, 25 Mar 2002 18:09:19 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: I MOVE we simplify the query language. References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> <5.1.0.14.0.20020325164315.0ab57508@imap1.in.steltor.com> <3C9FA02C.3050208@sendmail.com> <5.1.0.14.0.20020325192337.0ab3d310@imap1.in.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 Lets drop CAP-QL and go back to a SQL-MIN ~like~ plus 'IN'. It means that the CUA has to do more work but it can get all of the data. I just don't feel that ALL CUAs and CS's are going to be able to implement all of this and be compatible with each other. We are attempting to invent a very complex query language and we expect CAP to ship soon. I see these two goals as incompatible. Lets go back to the basics and just have CAP do simple queries where the CUA can get the data from the CS. Go back to SQL-MIN plus add the 'IN' function. Then only allow ONE logical operator where they MUST BE from the same component. It will eliminate complex queries - but that seems to be the large part of the debate. Then we can tackle complex queries extensions as an add on draft. From owner-ietf-calendar@mail.imc.org Tue Mar 26 00:27: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 AAA16910 for ; Tue, 26 Mar 2002 00:27:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2Q5DH205635 for ietf-calendar-bks; Mon, 25 Mar 2002 21:13:17 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2Q5DG405626 for ; Mon, 25 Mar 2002 21:13:16 -0800 (PST) To: Gary Frederick Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 00:13:22 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 12:13:20 AM, Serialize complete at 03/26/2002 12:13:20 AM Content-Type: multipart/alternative; boundary="=_alternative 001CB10485256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 001CB10485256B88_= Content-Type: text/plain; charset="us-ascii" We are dropping the XML language in CAP (it was there to support BEEP but we've determined it's not needed). Gary Frederick Sent by: owner-ietf-calendar@mail.imc.org 03/25/02 13:05 To: CalSched IETF cc: Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal So we are dropping the XML version of iCalendar? Gee, I must have missed that e-mail. Gary Doug Royer wrote: > > > > Gary Frederick wrote: > >> >> What would the XML version of encapsulation B look like? > > > > NONE - use text/calendar ONLY. > --=_alternative 001CB10485256B88_= Content-Type: text/html; charset="us-ascii"
We are dropping the XML language in CAP (it was there to support BEEP but we've determined it's not needed).


Gary Frederick <gary.frederick@jsoft.com>
Sent by: owner-ietf-calendar@mail.imc.org

03/25/02 13:05

       
        To:        CalSched IETF <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: CAP / BEEP / XML / iCalendar  -  updated proposal




So we are dropping the XML version of iCalendar?

Gee, I must have missed that e-mail.

Gary

Doug Royer wrote:
>
>
>
> Gary Frederick wrote:
>
>>
>> What would the XML version of encapsulation B look like?
>
>
>
> NONE  - use text/calendar ONLY.
>





--=_alternative 001CB10485256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 00:28: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 AAA16923 for ; Tue, 26 Mar 2002 00:28:12 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2Q5CUg05615 for ietf-calendar-bks; Mon, 25 Mar 2002 21:12:30 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2Q5CS405610 for ; Mon, 25 Mar 2002 21:12:28 -0800 (PST) To: "John Stracke" Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 00:12:24 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 12:12:33 AM, Serialize complete at 03/26/2002 12:12:33 AM Content-Type: multipart/alternative; boundary="=_alternative 001C9A4785256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 001C9A4785256B88_= Content-Type: text/plain; charset="us-ascii" To clarify, there is an XML "interpretation" of iCalendar - in other words, it rides on top of iCalendar - it does not replace it. I believe the draft name is draft--ietf-calsch-many-xcal-00' August 20, 2001. Expires: February 18, 2002. I don't know if it has been "re-sent. I don't believe so. Here's a url that points to some of the xml DTD stuff done previously by Frank Dawson. http://www.oasis-open.org/cover/iCal.html Again, this is not an XML replacement for iCalendar. "John Stracke" Sent by: owner-ietf-calendar@mail.imc.org 03/25/02 13:58 To: CalSched IETF cc: Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal >So we are dropping the XML version of iCalendar? We are not dropping it. It does not exist. It might exist at some point in the future, but not until we're done with CAP. It is not in the WG charter. There is actually contention over whether or not it ought to exist at all; a case can be made that creating an alternate rendering of the same data cannot improve interop, and will probably harm it. /=========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=========================================================| |Peace, justice, morality, culture, family, sport, and the| |extinction of all other life forms! | \=========================================================/ --=_alternative 001C9A4785256B88_= Content-Type: text/html; charset="us-ascii"
To clarify, there is an XML "interpretation" of iCalendar - in other words, it rides on top of iCalendar - it does not replace it.  I believe the draft name is draft--ietf-calsch-many-xcal-00' August 20, 2001. Expires: February 18, 2002.  I don't know if it has been "re-sent.  I don't believe so.  Here's a url that points to some of the xml DTD stuff done previously by Frank Dawson. http://www.oasis-open.org/cover/iCal.html
Again, this is not an XML replacement for iCalendar.  


"John Stracke" <jstracke@incentivesystems.com>
Sent by: owner-ietf-calendar@mail.imc.org

03/25/02 13:58

       
        To:        CalSched IETF <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: CAP / BEEP / XML / iCalendar  -  updated proposal




>So we are dropping the XML version of iCalendar?

We are not dropping it.  It does not exist.  It might exist at some point
in the future, but not until we're done with CAP.  It is not in the WG
charter.

There is actually contention over whether or not it ought to exist at all;
a case can be made that creating an alternate rendering of the same data
cannot improve interop, and will probably harm it.

/=========================================================\
|John Stracke                    |Principal Engineer      |
|jstracke@incentivesystems.com   |Incentive Systems, Inc. |
|http://www.incentivesystems.com |My opinions are my own. |
|=========================================================|
|Peace, justice, morality, culture, family, sport, and the|
|extinction of all other life forms!                      |
\=========================================================/

--=_alternative 001C9A4785256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 00:37: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 AAA17082 for ; Tue, 26 Mar 2002 00:37:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2Q5Mhe05767 for ietf-calendar-bks; Mon, 25 Mar 2002 21:22:43 -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 g2Q5Mf405763 for ; Mon, 25 Mar 2002 21:22: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 g2Q5Me721637 for ; Mon, 25 Mar 2002 21:22:40 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTKEXS00.LUM for ; Mon, 25 Mar 2002 21:22:40 -0800 Message-ID: <3CA004FE.4F35C582@netscape.com> Date: Mon, 25 Mar 2002 21:19:58 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Focus on issues Content-Type: multipart/mixed; boundary="------------0ADA155575E38F05E11AC30C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0ADA155575E38F05E11AC30C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, I'm torn on how to phrase this message. I'll start by saying, it's great to see all the activity on the list. I'm glad to see everyone looking at the issues and posting things. But we need to focus our energy and get closure on things. One of the problems we discussed in Minneapolis is that it is difficult for people to keep up with all the different threads. Speaking for myself... I could not keep up with every thread since December. After I fell a little behind, the prospect of catching up seemed too daunting, so I skipped many threads entirely. The problems we need to get through usually require a fair amount of context. If a few people chime in on one issue, then a few more chime in on another, and so on, we end up with a ton of discussion and no decision. So, the issues stay open, and CAP drags on. Our proposal to address the problem involves dealing with issues one at a time, resolving them, then moving on to the next. This will make it easier to stay up-to-date on the context, and it will help force closure. I realize that I have probably confused everyone by sending a ton of issues to the list. I don't want to send them directly to Pat or Bob or the other editors, it's important that we all see them and work through them. But, I think they need to be collected and dealt out one at a time for us to deal with. Pat volunteered to handle the issues, I'm sure she'll be sending out something soon :-) At this point, we should really try to reach consensus on the XML versus text/icalendar issue. I'll send a separate posting on where we're at with that. -Steve --------------0ADA155575E38F05E11AC30C 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 --------------0ADA155575E38F05E11AC30C-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 00:52: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 AAA17283 for ; Tue, 26 Mar 2002 00:52:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2Q5cTN06007 for ietf-calendar-bks; Mon, 25 Mar 2002 21:38:29 -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 g2Q5cR406003 for ; Mon, 25 Mar 2002 21:38:27 -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 g2Q5cNO09577 for ; Mon, 25 Mar 2002 21:38:24 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GTKFO200.UYO for ; Mon, 25 Mar 2002 21:38:26 -0800 Message-ID: <3CA008B0.BD57E53@netscape.com> Date: Mon, 25 Mar 2002 21:35:44 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: CAP: moving to closure on transport / application layers References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> Content-Type: multipart/alternative; boundary="------------33FF4DD2E21BBCA3BFBD1A44" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------33FF4DD2E21BBCA3BFBD1A44 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, Here's where I think we're at for the transport versus application layer encapsulation C: MSG 1 2 . 1234 123 C: Content-type: text/calendar C: C: BEGIN:VCALENDAR C: METHOD:SEARCH C: LATENCY;ACTION="ask":3 ... C: END:VCALENDAR C: END More detailed writeup This incorporates Doug's suggestion for parameterizing ACTION. Doug, Larry, and I are OK going forward with this. Need to hear from some more folks. Does anyone have issues with this? Can we close this issue and move on? -Steve --------------33FF4DD2E21BBCA3BFBD1A44 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Folks,

Here's where I think we're at for the transport versus application layer encapsulation

C: MSG 1 2 . 1234 123
C: Content-type: text/calendar
C:
C: BEGIN:VCALENDAR
C: METHOD:SEARCH
C: LATENCY;ACTION="ask":3
...
C: END:VCALENDAR
C: END
More detailed writeup

This incorporates Doug's suggestion for parameterizing ACTION.  Doug, Larry, and I are OK going forward with this. Need to hear from some more folks.

Does anyone have issues with this?  Can we close this issue and move on?

-Steve --------------33FF4DD2E21BBCA3BFBD1A44-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 02:59: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 CAA26903 for ; Tue, 26 Mar 2002 02:59:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2Q7icU17488 for ietf-calendar-bks; Mon, 25 Mar 2002 23:44:38 -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 g2Q7ib417484 for ; Mon, 25 Mar 2002 23:44:37 -0800 (PST) Received: from jsoft.com (IDENT:uHY+yH6NBupJUalxSY6z5UTlRrLqAB+5@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2Q7hGV13067; Tue, 26 Mar 2002 01:43:16 -0600 Message-ID: <3CA02694.9090902@jsoft.com> Date: Tue, 26 Mar 2002 01:43:16 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: CAP: moving to closure on transport / application layers References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.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 Great. Gary Steve Mansour wrote: > Folks, > > Here's where I think we're at for the transport versus application layer > encapsulation > > C: MSG 1 2 . 1234 123 > C: Content-type: text/calendar > C: > C: BEGIN:VCALENDAR > C: METHOD:SEARCH > C: LATENCY;ACTION="ask":3 > ... > C: END:VCALENDAR > C: END > > More detailed writeup > > > This incorporates Doug's suggestion for parameterizing ACTION. Doug, > Larry, and I are OK going forward with this. Need to hear from some more > folks. > > Does anyone have issues with this? Can we close this issue and move on? > > -Steve > From owner-ietf-calendar@mail.imc.org Tue Mar 26 03:29: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 DAA27341 for ; Tue, 26 Mar 2002 03:29:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2Q8FUi21570 for ietf-calendar-bks; Tue, 26 Mar 2002 00:15: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 g2Q8FT421566 for ; Tue, 26 Mar 2002 00:15:29 -0800 (PST) Received: from jsoft.com (IDENT:GlQsFZb4JZXnLuKUyTqXoyxVXh1iFHvY@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2Q8E8V13145; Tue, 26 Mar 2002 02:14:08 -0600 Message-ID: <3CA02DD0.1070006@jsoft.com> Date: Tue, 26 Mar 2002 02:14:08 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: Focus on issues References: <3CA004FE.4F35C582@netscape.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 Thanks for posting Steve. I wish I had not asked about this group staying focused. I think you are correct. Gary Steve Mansour wrote: > Folks, > > I'm torn on how to phrase this message. I'll start by saying, it's > great to see all the activity on the list. I'm glad to see everyone > looking at the issues and posting things. But we need to focus our > energy and get closure on things. > > One of the problems we discussed in Minneapolis is that it is difficult > for people to keep up with all the different threads. Speaking for > myself... I could not keep up with every thread since December. After I > fell a little behind, the prospect of catching up seemed too daunting, > so I skipped many threads entirely. The problems we need to get through > usually require a fair amount of context. If a few people chime in on > one issue, then a few more chime in on another, and so on, we end up > with a ton of discussion and no decision. So, the issues stay open, and > CAP drags on. > > Our proposal to address the problem involves dealing with issues one at > a time, resolving them, then moving on to the next. This will make it > easier to stay up-to-date on the context, and it will help force > closure. > > I realize that I have probably confused everyone by sending a ton of > issues to the list. I don't want to send them directly to Pat or Bob or > the other editors, it's important that we all see them and work through > them. But, I think they need to be collected and dealt out one at a time > for us to deal with. Pat volunteered to handle the issues, I'm sure > she'll be sending out something soon :-) > > At this point, we should really try to reach consensus on the XML versus > text/icalendar issue. I'll send a separate posting on where we're at > with that. > > -Steve > From owner-ietf-calendar@mail.imc.org Tue Mar 26 04:03: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 EAA27845 for ; Tue, 26 Mar 2002 04:03:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2Q85Mw20322 for ietf-calendar-bks; Tue, 26 Mar 2002 00:05:22 -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 g2Q85K420306; Tue, 26 Mar 2002 00:05:20 -0800 (PST) Received: from jsoft.com (IDENT:dB4PQsqCN8fY2Xk0dUVs6pU98Nf9gofU@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2Q83xV13113; Tue, 26 Mar 2002 02:03:59 -0600 Message-ID: <3CA02B6E.9070601@jsoft.com> Date: Tue, 26 Mar 2002 02:03:58 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pregen@egenconsulting.com CC: John Stracke , CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal 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 It was re-sent. http://www.imc.org/ietf-calendar/mail-archive/msg04560.html Where is the WG charter documented? Gary pregen@egenconsulting.com wrote: > > To clarify, there is an XML "interpretation" of iCalendar - in other > words, it rides on top of iCalendar - it does not replace it. I believe > the draft name is draft--ietf-calsch-many-xcal-00' August 20, 2001. > Expires: February 18, 2002. I don't know if it has been "re-sent. I > don't believe so. Here's a url that points to some of the xml DTD stuff > done previously by Frank Dawson. http://www.oasis-open.org/cover/iCal.html > > Again, this is not an XML replacement for iCalendar. > > > *"John Stracke" * > Sent by: owner-ietf-calendar@mail.imc.org > > 03/25/02 13:58 > > > To: CalSched IETF > cc: > Subject: Re: CAP / BEEP / XML / iCalendar - updated > proposal > > > > > > >So we are dropping the XML version of iCalendar? > > We are not dropping it. It does not exist. It might exist at some point > in the future, but not until we're done with CAP. It is not in the WG > charter. > > There is actually contention over whether or not it ought to exist at all; > a case can be made that creating an alternate rendering of the same data > cannot improve interop, and will probably harm it. > > /=========================================================\ > |John Stracke |Principal Engineer | > |jstracke@incentivesystems.com |Incentive Systems, Inc. | > |http://www.incentivesystems.com |My opinions are my own. | > |=========================================================| > |Peace, justice, morality, culture, family, sport, and the| > |extinction of all other life forms! | > \=========================================================/ > > From owner-ietf-calendar@mail.imc.org Tue Mar 26 09:11: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 JAA03577 for ; Tue, 26 Mar 2002 09:11:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QDxHp23237 for ietf-calendar-bks; Tue, 26 Mar 2002 05:59:17 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QDxF423221 for ; Tue, 26 Mar 2002 05:59:15 -0800 (PST) To: Gary Frederick Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org, Steve Mansour Subject: Re: Focus on issues MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 08:59:23 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 08:59:16 AM, Serialize complete at 03/26/2002 08:59:16 AM Content-Type: multipart/alternative; boundary="=_alternative 004CD9CF85256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004CD9CF85256B88_= Content-Type: text/plain; charset="us-ascii" Staying focused is a note we have posted often - and is often ignored. I have no problem posting it often - I do have a problem when it's ignored. So, to all of those people who continue to drive an issue into the ground, unless there is a good reason (like the idea breaks the code), let us please try to resolve each and every issue. We all win when this draft goes public. I have posted a comment on the XML issue. I believe we have reached concensus - if I don't hear back a response saying no, then it's a closed deal and will be posted on our Resolved Issues list that will appear on http://www.calsch.org. This list should be there by the end of the week. I am going to adopt a numbering scheme so we can try to keep track of the issues. I am asking everyone on the list to keep to one issue per note and once again, to please try and keep the notes to under 3 threads. Some of the notes get so long, it's dinner time before you get to the end of the thought. And after four >>> indents I lose track. How about you? Thanks for all the dialog. This is not intended to reduce the interest. It is intended to keep it focused. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Gary Frederick Sent by: owner-ietf-calendar@mail.imc.org 03/26/02 03:14 To: Steve Mansour cc: CalSched IETF Subject: Re: Focus on issues Thanks for posting Steve. I wish I had not asked about this group staying focused. I think you are correct. Gary Steve Mansour wrote: > Folks, > > I'm torn on how to phrase this message. I'll start by saying, it's > great to see all the activity on the list. I'm glad to see everyone > looking at the issues and posting things. But we need to focus our > energy and get closure on things. > > One of the problems we discussed in Minneapolis is that it is difficult > for people to keep up with all the different threads. Speaking for > myself... I could not keep up with every thread since December. After I > fell a little behind, the prospect of catching up seemed too daunting, > so I skipped many threads entirely. The problems we need to get through > usually require a fair amount of context. If a few people chime in on > one issue, then a few more chime in on another, and so on, we end up > with a ton of discussion and no decision. So, the issues stay open, and > CAP drags on. > > Our proposal to address the problem involves dealing with issues one at > a time, resolving them, then moving on to the next. This will make it > easier to stay up-to-date on the context, and it will help force > closure. > > I realize that I have probably confused everyone by sending a ton of > issues to the list. I don't want to send them directly to Pat or Bob or > the other editors, it's important that we all see them and work through > them. But, I think they need to be collected and dealt out one at a time > for us to deal with. Pat volunteered to handle the issues, I'm sure > she'll be sending out something soon :-) > > At this point, we should really try to reach consensus on the XML versus > text/icalendar issue. I'll send a separate posting on where we're at > with that. > > -Steve > --=_alternative 004CD9CF85256B88_= Content-Type: text/html; charset="us-ascii"
Staying focused is a note we have posted often - and is often ignored.  I have no problem posting it often - I do have a problem when it's ignored.  So, to all of those people who continue to drive an issue into the ground, unless there is a good reason (like the idea breaks the code), let us please try to resolve each and every issue.  We all win when this draft goes public.  I have posted a comment on the XML issue.  I believe we have reached concensus - if I don't hear back a response saying no, then it's a closed deal and will be posted on our Resolved Issues list that will appear on http://www.calsch.org.  This list should be there by the end of the week.  I am going to adopt a numbering scheme so we can try to keep track of the issues.  I am asking everyone on the list to keep! to one issue per note and once again, to please try and keep the notes to under 3 threads.  Some of the notes get so long, it's dinner time before you get to the end of the thought.  And after four >>> indents I lose track.  How about you?

Thanks for all the dialog.  This is not intended to reduce the interest.  It is intended to keep it focused.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Gary Frederick <gary.frederick@jsoft.com>
Sent by: owner-ietf-calendar@mail.imc.org

03/26/02 03:14

       
        To:        Steve Mansour <sman@netscape.com>
        cc:        CalSched IETF <ietf-calendar@imc.org>
        Subject:        Re: Focus on issues




Thanks for posting Steve. I wish I had not asked about this group
staying focused.

I think you are correct.

Gary


Steve Mansour wrote:
> Folks,
>
> I'm torn on how to phrase this message.  I'll start by saying, it's
> great to see all the activity on the list. I'm glad to see everyone
> looking at the issues and posting things.  But we need to focus our
> energy and get closure on things.
>
> One of the problems we discussed in Minneapolis is that it is difficult
> for people to keep up with all the different threads.  Speaking for
> myself... I could not keep up with every thread since December. After I
> fell a little behind, the prospect of catching up seemed too daunting,
> so I skipped many threads entirely. The problems we need to get through
> usually require a fair amount of context. If a few people chime in on
> one issue, then a few more chime in on another, and so on, we end up
> with a ton of discussion and no decision. So, the issues stay open, and
> CAP drags on.
>
> Our proposal to address the problem involves dealing with issues one at
> a time, resolving them, then moving on to the next. This will make it
> easier to stay up-to-date on the context, and it will help force
> closure.
>
> I realize that I have probably confused everyone by sending a ton of
> issues to the list.  I don't want to send them directly to Pat or Bob or
> the other editors, it's important that we all see them and work through
> them. But, I think they need to be collected and dealt out one at a time
> for us to deal with.  Pat volunteered to handle the issues, I'm sure
> she'll be sending out something soon :-)
>
> At this point, we should really try to reach consensus on the XML versus
> text/icalendar issue. I'll send a separate posting on where we're at
> with that.
>
> -Steve
>





--=_alternative 004CD9CF85256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 09:12:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03598 for ; Tue, 26 Mar 2002 09:12:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QE2Fe23564 for ietf-calendar-bks; Tue, 26 Mar 2002 06:02:15 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QE2D423554 for ; Tue, 26 Mar 2002 06:02:13 -0800 (PST) To: Gary Frederick Cc: CalSched IETF , John Stracke , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 09:02:22 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 09:02:14 AM, Serialize complete at 03/26/2002 09:02:14 AM Content-Type: multipart/alternative; boundary="=_alternative 004D1F6685256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004D1F6685256B88_= Content-Type: text/plain; charset="us-ascii" The charter can be found at http://www.ietf.org/html.charters/calsch-charter.html. An updated charter with adjusted milestones has been sent to the secretariet for update. --=_alternative 004D1F6685256B88_= Content-Type: text/html; charset="us-ascii"
The charter can be found at http://www.ietf.org/html.charters/calsch-charter.html.  An updated charter with adjusted milestones has been sent to the secretariet for update.
 --=_alternative 004D1F6685256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 09:44: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 JAA04608 for ; Tue, 26 Mar 2002 09:44:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QEZGX25105 for ietf-calendar-bks; Tue, 26 Mar 2002 06:35:16 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QEZF425101 for ; Tue, 26 Mar 2002 06:35:15 -0800 (PST) To: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 09:45:35 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 09:45:42 AM, Serialize complete at 03/26/2002 09:45:42 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >We decided on no cross-table joins, Actually, I believe we decided against cross-component joins. If you're going to say you can't query on a property and its parameters at the same time, queries are going to be pretty limited. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |If you're going to walk on thin ice, you might as well *dance*!| \===============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 09:47: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 JAA04679 for ; Tue, 26 Mar 2002 09:47:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QEXv824966 for ietf-calendar-bks; Tue, 26 Mar 2002 06:33:57 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QEXu424959 for ; Tue, 26 Mar 2002 06:33:56 -0800 (PST) To: CalSched IETF Subject: Re: CAP issues, Sections 1 and 2 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 09:44:15 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 09:44:22 AM, Serialize complete at 03/26/2002 09:44:22 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>Who cares? It is vendor specific. >>> >> >> I'm sorry, but that's a bad answer. > > >Okay fine, here is an answer for my private 'today' query: [...] > QUERY:SELECT * FROM VEVENT where X-virtual-col = 'today' >Does that help? :-) No, it doesn't. We still have the same problem: stored queries are no use in the standard; they're useful only if you add proprietary extensions. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |If you're going to walk on thin ice, you might as well *dance*!| \===============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 09: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 JAA04801 for ; Tue, 26 Mar 2002 09:50:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QEfM625499 for ietf-calendar-bks; Tue, 26 Mar 2002 06:41:22 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QEfK425491 for ; Tue, 26 Mar 2002 06:41:20 -0800 (PST) To: CalSched IETF Subject: Re: CAP draft 07 issues - sections 3 and 4 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 09:51:40 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 09:51:47 AM, Serialize complete at 03/26/2002 09:51:47 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >My point was that I keep hearing in the emails how the query language is >"based" on SQL, so the question becomes how much is it based on SQL, and >at what point does it deviate? Is (are) the point(s) of deviation the >place(s) that make(s) the most sense? And do the resolutions make the >most sense? These types of questions are what I was talking about back in January, when I said () that being SQL-like but not actually SQL would be misleading. That's why I eventually wrote up the non-SQL proposal (). /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |If you're going to walk on thin ice, you might as well *dance*!| \===============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 09:55: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 JAA04972 for ; Tue, 26 Mar 2002 09:55:48 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QEl1o26583 for ietf-calendar-bks; Tue, 26 Mar 2002 06:47:01 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QEkx426576 for ; Tue, 26 Mar 2002 06:46:59 -0800 (PST) To: "CalSched IETF" Subject: RE: CAP / BEEP / XML / iCalendar MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 09:57:19 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 09:57:26 AM, Serialize complete at 03/26/2002 09:57:26 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul B. Hill wrote: >I'm OK with the use of beep and the use of XML in the transport protocol. > >The limited use of XML that has been introduced will not require a full >parser to be used by an implementation. I'm not so sure, actually; although the examples in -07 use only a subset of XML, that subset is never specified. As a result, an implementation has to be ready for any legal XML document. This requires a full XML parser--it may not have to be a validating parser, but it does have to be able to parse a DTD, since any XML document can include a DTD subset at the start, which could include entity definitions that will be needed to parse the rest of the document. Having written both (more than once), I can say that an XML parser is at least as complicated as a text/calendar parser. Sticking to just text/calendar (which we have to have anyway) would be a useful simplification. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Organ transplants are best left to the professionals. | \========================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 10:29: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 KAA06615 for ; Tue, 26 Mar 2002 10:29:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QFEAc27660 for ietf-calendar-bks; Tue, 26 Mar 2002 07:14:10 -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 g2QFE9427650; Tue, 26 Mar 2002 07:14:09 -0800 (PST) Received: from jsoft.com (IDENT:d0TcbJYzfVtKrjl9BqO72Jxlvx1OEfcQ@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g2QFCmV15312; Tue, 26 Mar 2002 09:12:49 -0600 Message-ID: <3CA08FF0.7010008@jsoft.com> Date: Tue, 26 Mar 2002 09:12:48 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pregen@egenconsulting.com CC: CalSched IETF , John Stracke , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal 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 Thanks! As I read the charter, the next things are: Jul 01 Request last call on Guide to Internet Calendaring Jul 01 Submit Internet-Draft on Guide to Internet Calendaring for consideration as a Proposed Standard Jul 01 Submit revisions for Internet-Draft for iCalendar, iMIP and iTIP Jul 01 Submit revisions for Internet-Draft for Calendar Access Protocol I understand that you adjusted the milestones and that CAP may be the only thing on the adjusted milestones. If the other tasks are still on the list, it could be a problem if all we do is focus on CAP??? Gary pregen@egenconsulting.com wrote: > > The charter can be found at > http://www.ietf.org/html.charters/calsch-charter.html. An updated > charter with adjusted milestones has been sent to the secretariet for > update. From owner-ietf-calendar@mail.imc.org Tue Mar 26 11: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 LAA08668 for ; Tue, 26 Mar 2002 11:08:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QFsD302620 for ietf-calendar-bks; Tue, 26 Mar 2002 07:54:13 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QFsB402616 for ; Tue, 26 Mar 2002 07:54:12 -0800 (PST) To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 11:04:30 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 11:04:39 AM, Serialize complete at 03/26/2002 11:04:39 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >If the other tasks are still on >the list, it could be a problem if all we do is focus on CAP??? The dates are just goals. Getting CAP right is more important than getting other stuff done fast. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |No matter how subtle the wizard, a knife in the shoulderblades| |will cramp his style. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 11: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 LAA08704 for ; Tue, 26 Mar 2002 11:09:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QFu0402694 for ietf-calendar-bks; Tue, 26 Mar 2002 07:56:00 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QFtx402690 for ; Tue, 26 Mar 2002 07:55:59 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2QFtxdl024359 for ; Tue, 26 Mar 2002 10:55:59 -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 g2QFtoQ13609 for ; Tue, 26 Mar 2002 10:55:50 -0500 (EST) Message-Id: <5.1.0.14.0.20020326105606.0b917d20@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Mar 2002 10:59:17 -0500 To: CalSched IETF From: Alan Davies Subject: Re: I MOVE we simplify the query language. In-Reply-To: <3C9FCA3F.8010102@Royer.com> References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> <5.1.0.14.0.20020325164315.0ab57508@imap1.in.steltor.com> <3C9FA02C.3050208@sendmail.com> <5.1.0.14.0.20020325192337.0ab3d310@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: Simplification sounds good, but how was SQL-MIN simpler than CAP-QL? We've been here before; CAP-QL grew out of pointing out the inconsistencies and ambiguities in SQL-MIN. SQL-MIN, as it existed in previous drafts, could _never_ have worked; most examples that used it in the draft were totally ambiguous. If we're going to simplify something, simplify CAP-QL, which at least has a chance of being understood by a machine, not just a human who glances at it and thinks that it sort of looks correct. --Alan At 06:09 PM 25/03/2002 -0700, Doug Royer wrote: >Lets drop CAP-QL and go back to a SQL-MIN ~like~ plus 'IN'. > >It means that the CUA has to do more work but it can >get all of the data. I just don't feel that ALL CUAs and >CS's are going to be able to implement all of this and >be compatible with each other. We are attempting to >invent a very complex query language and we expect CAP to >ship soon. I see these two goals as incompatible. > >Lets go back to the basics and just have CAP do simple queries >where the CUA can get the data from the CS. Go back to >SQL-MIN plus add the 'IN' function. Then only allow ONE >logical operator where they MUST BE from the same component. > >It will eliminate complex queries - but that seems to be >the large part of the debate. > >Then we can tackle complex queries extensions as an add on draft. > > > From owner-ietf-calendar@mail.imc.org Tue Mar 26 11:24:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09505 for ; Tue, 26 Mar 2002 11:24:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QGEW303317 for ietf-calendar-bks; Tue, 26 Mar 2002 08:14:32 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QGEQ403313 for ; Tue, 26 Mar 2002 08:14:26 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2QGEQdl024607; Tue, 26 Mar 2002 11:14:26 -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 g2QGEKQ15432; Tue, 26 Mar 2002 11:14:21 -0500 (EST) Message-Id: <5.1.0.14.0.20020326110624.0b90d5a8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Mar 2002 11:17:13 -0500 To: Robert Lusardi , John Stracke From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 Cc: CalSched IETF In-Reply-To: <3C9FBBC4.6040207@sendmail.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 07:07 PM 25/03/2002 -0500, Robert Lusardi wrote: >Well, I can certainly tell you how SQL would do it, but I don't want to >drag the conversation down to that (did I just hear someone say "Too >Late!" :-). It's never too late to correct something if it really is broken. >My point was that I keep hearing in the emails how the query language is >"based" on SQL, so the question becomes how much is it based on SQL, and >at what point does it deviate? Is (are) the point(s) of deviation the >place(s) that make(s) the most sense? And do the resolutions make the most >sense? CAP-QL really just "uses an SQL-like syntax". In the CAP draft, some analogies are drawn between the way components/properties and SQL tables/columns are queried to aid in the reader's understanding, but it's misleading to take that analogy too far - it's _not_ SQL. The reason it deviates, is due to the extra complexity of the iCalendar data model, as has been stated before. Perhaps this difference makes SQL a bad choice- a decision was made by someone to make it look like SQL a long time in the past, perhaps before these issues were fully understood. Perhaps we really do need to accept that an SQL-like syntax isn't really viable without introducing some extra relational-db style 'columns', to work around the child-component/multi-property/parameter complexities. >My homework is to read up, and then shut up if I don't have an alternative. Please don't shut up, as what you say is making sense. --Alan From owner-ietf-calendar@mail.imc.org Tue Mar 26 11:30: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 LAA09858 for ; Tue, 26 Mar 2002 11:30:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QGKLI03521 for ietf-calendar-bks; Tue, 26 Mar 2002 08:20:21 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QGKI403503 for ; Tue, 26 Mar 2002 08:20:18 -0800 (PST) To: "John Stracke" Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 11:20:28 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 11:20:21 AM, Serialize complete at 03/26/2002 11:20:21 AM Content-Type: multipart/alternative; boundary="=_alternative 0059C46C85256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059C46C85256B88_= Content-Type: text/plain; charset="us-ascii" I agree. We need to accomplish our goals, but not at the expense of CAP. "John Stracke" Sent by: owner-ietf-calendar@mail.imc.org 03/26/02 11:04 To: CalSched IETF cc: Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal >If the other tasks are still on >the list, it could be a problem if all we do is focus on CAP??? The dates are just goals. Getting CAP right is more important than getting other stuff done fast. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |No matter how subtle the wizard, a knife in the shoulderblades| |will cramp his style. | \==============================================================/ --=_alternative 0059C46C85256B88_= Content-Type: text/html; charset="us-ascii"
I agree.  We need to accomplish our goals, but not at the expense of CAP.


"John Stracke" <jstracke@incentivesystems.com>
Sent by: owner-ietf-calendar@mail.imc.org

03/26/02 11:04

       
        To:        CalSched IETF <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: CAP / BEEP / XML / iCalendar  -  updated proposal




>If the other tasks are still on
>the list, it could be a problem if all we do is focus on CAP???

The dates are just goals.  Getting CAP right is more important than
getting other stuff done fast.

/==============================================================\
|John Stracke                    |Principal Engineer           |
|jstracke@incentivesystems.com   |Incentive Systems, Inc.      |
|http://www.incentivesystems.com |My opinions are my own.      |
|==============================================================|
|No matter how subtle the wizard, a knife in the shoulderblades|
|will cramp his style.                                         |
\==============================================================/

--=_alternative 0059C46C85256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 11:33:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10052 for ; Tue, 26 Mar 2002 11:33:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QGJvo03482 for ietf-calendar-bks; Tue, 26 Mar 2002 08:19:57 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QGJu403478 for ; Tue, 26 Mar 2002 08:19:56 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2QGJsdl024669 for ; Tue, 26 Mar 2002 11:19:54 -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 g2QGJiQ15919 for ; Tue, 26 Mar 2002 11:19:44 -0500 (EST) Message-Id: <5.1.0.14.0.20020326110048.0ab23fe0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Mar 2002 11:23:12 -0500 To: CalSched IETF From: Alan Davies Subject: Re: CAP draft 07 issues - sections 3 and 4 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: To anyone who still hasn't quite grasped the complications that arise when you assume that SQL can be used to query the iCalendar data model, please reread John's earlier post that I quote below, as he explains the issues at hand extremely clearly; dropping CAP-QL and using the 'simpler' SQL-MIN doesn't begin to address these issues: At 03:26 PM 25/03/2002 -0500, John Stracke wrote: >If we dropped USING_PROPERTY, we'd be left with three choices for how to >deal with "property relop1 value1 AND property relop2 value2" (where relop >is a relational operator such as = or <=): > >(a) Both references to "property" always refer to the same instance. In >this case, "ATTENDEE='foo@example.com' AND ATTENDEE='bar@example.com'" >will always be false--not very useful. > >(b) "property relop value" always means "there exists some instance of >property such that property relop value". In this case, >"VALARM.DTSTART>=20020325T000000Z AND VALARM.DTSTART<=20020325T235959Z" >means "there exists a VALARM A that starts after 20020325T000000Z and >another VALARM B, possibly the same as A, that starts >before 20020325T235959Z". Again, not very useful. > >(c) Define, on a property-by-property basis, which of (a) or (b) applies >for each property in 2445. Lots of work, lots of potential for error, >difficult to maintain as 2445 evolves. > >I don't think any of these is viable; I think we need to keep >USING_PROPERTY (and USING_PARAMETER, too, by the same reasoning). From owner-ietf-calendar@mail.imc.org Tue Mar 26 11:45:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10986 for ; Tue, 26 Mar 2002 11:45:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QGRhQ03731 for ietf-calendar-bks; Tue, 26 Mar 2002 08:27:43 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QGRg403726 for ; Tue, 26 Mar 2002 08:27:42 -0800 (PST) To: ietf-calendar@imc.org Subject: Friendly Reminder MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 11:27:52 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 11:27:44 AM, Serialize complete at 03/26/2002 11:27:44 AM Content-Type: multipart/alternative; boundary="=_alternative 005A71A085256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A71A085256B88_= Content-Type: text/plain; charset="us-ascii" Hi, this is your co-Chair thanking you for all your participation on this list. This is also a general touchy-feely and friendly reminder to keep our responses "nice" - by that I mean relevant without being angry or hostile in nature. We all get very enthusiastic in our responses - sometimes too much so. If we keep the tone on a higher level, maybe we can coax some of the over 350 people who monitor this list to reply more often. Let's give everyone a chance to reply and post their comments. Cool? Also, I heard comments from several people that the replies get very technical in nature - for that reason they can not reply even if they wanted to. I don't want the list to become an educational tool - however, maybe we can start trying to put some of what we are talking about into "English". By that I mean putting in some text that says - "ok, what this means to you is you won't be able to store your calendar if this is not done." That sort of thing. I don't think it will add much to the text and it may bring out more responses. Now, don't hit me for asking! This is just a simple attempt to draw out more participants and to help foster a community that gets our drafts to market and the public. And finally, to echo what Steve has said, let's try to keep focused on a point, resolve it, get concensus and move on to the next item. Ok, that's it for now. --=_alternative 005A71A085256B88_= Content-Type: text/html; charset="us-ascii"
Hi, this is your co-Chair thanking you for all your participation on this list.  This is also a general touchy-feely and  friendly reminder to keep our responses "nice" - by that I mean relevant without being angry or hostile in nature.  We all get very enthusiastic in our responses - sometimes too much so.  If we keep the tone on a higher level, maybe we can coax some of the over 350 people who monitor this list to reply more often.  Let's give everyone a chance to reply and post their comments.  Cool?

Also, I heard comments from several people that the replies get very technical in nature - for that reason they can not reply even if they wanted to.  I don't want the list to become an educational tool - however, maybe we can start trying to put some of what we are talking about into "English".  By that I mean putting in some text that says - "ok, what this means to you is you won't be able to store your calendar if this is not done."  That sort of thing.  I don't think it will add much to the text and it may bring out more responses.  Now, don't hit me for asking!  This is just a simple attempt to draw out more participants and to help foster a community that gets our drafts to market and the public.

And finally, to echo what Steve has said, let's try to keep focused on a point, resolve it, get concensus and move on to the next item.

Ok, that's it for now. --=_alternative 005A71A085256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 11:52: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 LAA11611 for ; Tue, 26 Mar 2002 11:52:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QGdpQ04123 for ietf-calendar-bks; Tue, 26 Mar 2002 08:39:51 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QGdn404113 for ; Tue, 26 Mar 2002 08:39:49 -0800 (PST) To: Gary Frederick Cc: CalSched IETF , John Stracke , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 11:40:00 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 11:39:51 AM, Serialize complete at 03/26/2002 11:39:51 AM Content-Type: multipart/alternative; boundary="=_alternative 005B8DFB85256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B8DFB85256B88_= Content-Type: text/plain; charset="us-ascii" Hi Gary. An updated charter is in the works. We, like many groups, are behind in getting it updated. The dates do need to be renewed/adjusted. And yes, we have all those other things to work on, including updating iCalendar, iTIP and iMIP with things we find from interoperability testing - something we are working on as well. I think what we mean by focus on CAP is just that. We need to get the draft to last call - if we could get other volunteers we can do all the things that are on the milestones. It's hard to do when you only have about 7 people who are actively working on items. I know Shannon is helping with the iCalendar stuff, but CAP is really big and it needs all the help we can get. We've solicited on the list often. The Steltor people have been great in stepping in to help out - as have all our volunteers. If we can keep the notes to the list focused, it makes it easier for those who have agreed to help to keep on top of what is happening. 100 or more notes a day does not make it easy - unless the notes are relevant and concise. Actually, we need to figure out what to do with vCard and vCalendar. Someone asked me where the home was for vCard. I'm not sure, but our group is a likely candidate unless some other group thinks it belongs with them. Not sure. Hope that helps. Gary Frederick Sent by: owner-ietf-calendar@mail.imc.org 03/26/02 10:12 To: pregen@egenconsulting.com cc: CalSched IETF , John Stracke , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal Thanks! As I read the charter, the next things are: Jul 01 Request last call on Guide to Internet Calendaring Jul 01 Submit Internet-Draft on Guide to Internet Calendaring for consideration as a Proposed Standard Jul 01 Submit revisions for Internet-Draft for iCalendar, iMIP and iTIP Jul 01 Submit revisions for Internet-Draft for Calendar Access Protocol I understand that you adjusted the milestones and that CAP may be the only thing on the adjusted milestones. If the other tasks are still on the list, it could be a problem if all we do is focus on CAP??? Gary pregen@egenconsulting.com wrote: > > The charter can be found at > http://www.ietf.org/html.charters/calsch-charter.html. An updated > charter with adjusted milestones has been sent to the secretariet for > update. --=_alternative 005B8DFB85256B88_= Content-Type: text/html; charset="us-ascii"
Hi Gary.  An updated charter is in the works.  We, like many groups, are behind in getting it updated. The dates do need to be renewed/adjusted.  

And yes, we have all those other things to work on, including updating iCalendar, iTIP and iMIP with things we find from interoperability testing - something we are working on as well.  

I think what we mean by focus on CAP is just that.  We need to get the draft to last call - if we could get other volunteers we can do all the things that are on the milestones.  It's hard to do when you only have about 7 people who are actively working on items.  I know Shannon is helping with the iCalendar stuff, but CAP is really big and it needs all the help we can get.  We've solicited on the list often.  The Steltor people have been great in stepping in to help out - as have all our volunteers.  If we can keep the notes to the list focused, it makes it easier for those who have agreed to help to keep on top of what is happening.  100 or more notes a day does not make it easy - unless the notes are relevant and concise.  
Actually, we need to figure out what to do with vCard and vCalendar.  Someone asked me where the home was for vCard.  I'm not sure, but our group is a likely candidate unless some other group thinks it belongs with them.  Not sure.

Hope that helps.


Gary Frederick <gary.frederick@jsoft.com>
Sent by: owner-ietf-calendar@mail.imc.org

03/26/02 10:12

       
        To:        pregen@egenconsulting.com
        cc:        CalSched IETF <ietf-calendar@imc.org>, John Stracke <jstracke@incentivesystems.com>, owner-ietf-calendar@mail.imc.org
        Subject:        Re: CAP / BEEP / XML / iCalendar  -  updated proposal




Thanks!

As I read the charter, the next things are:
  Jul 01   Request last call on Guide to Internet Calendaring
  Jul 01   Submit Internet-Draft on Guide to Internet Calendaring for
             consideration as a Proposed Standard
  Jul 01   Submit revisions for Internet-Draft for iCalendar, iMIP and
iTIP
  Jul 01   Submit revisions for Internet-Draft for Calendar Access Protocol

I understand that you adjusted the milestones and that CAP may be the
only thing on the adjusted milestones. If the other tasks are still on
the list, it could be a problem if all we do is focus on CAP???

Gary

pregen@egenconsulting.com wrote:
>
> The charter can be found at
> http://www.ietf.org/html.charters/calsch-charter.html.  An updated
> charter with adjusted milestones has been sent to the secretariet for
> update.

--=_alternative 005B8DFB85256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 12:12: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 MAA13098 for ; Tue, 26 Mar 2002 12:12:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QH0S204788 for ietf-calendar-bks; Tue, 26 Mar 2002 09:00:28 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QH0Q404784 for ; Tue, 26 Mar 2002 09:00:26 -0800 (PST) To: CalSched IETF Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 12:10:45 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 12:10:54 PM, Serialize complete at 03/26/2002 12:10:54 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Actually, we need to figure out what to do with vCard and vCalendar. >Someone asked me where the home was for vCard. It doesn't really have one at this point; it looks like RFC-2425 and 2426 were developed by a WG called ASID, but ASID doesn't exist any more. (Or they might have been developed by individuals who got help from the ASID group; it's not clear to me.) It doesn't particularly need a WG as long as it's stable, after all; and it's got a registration process defined for small-scale evolution. >I'm not sure, but our >group is a likely candidate unless some other group thinks it belongs >with them. Not sure. I would think vCard would fall more closely to one of the LDAP working groups; it's closer to their expertise. The affinity between vCard and [vi]Calendar is more a historical artifact than a technical relationship. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |"How can one conceive of a one party system in a country that has| |over 200 varieties of cheese?" --Charles de Gaulle | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 12:23: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 MAA13665 for ; Tue, 26 Mar 2002 12:23:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QHCWx05882 for ietf-calendar-bks; Tue, 26 Mar 2002 09:12:32 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QHCV405875 for ; Tue, 26 Mar 2002 09:12:31 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QHCRdx012904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 09:12:32 -0800 (PST) Message-ID: <3CA0ABF8.6050305@Royer.com> Date: Tue, 26 Mar 2002 10:12:24 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: I MOVE we simplify the query language. References: <3C9E69C6.685D0550@netscape.com> <5.1.0.14.0.20020325123530.0ab068a8@imap1.in.steltor.com> <5.1.0.14.0.20020325151644.0b8ee660@imap1.in.steltor.com> <5.1.0.14.0.20020325164315.0ab57508@imap1.in.steltor.com> <3C9FA02C.3050208@sendmail.com> <5.1.0.14.0.20020325192337.0ab3d310@imap1.in.steltor.com> <5.1.0.14.0.20020326105606.0b917d20@imap1.in.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 Alan Davies wrote: > > > If we're going to simplify something, simplify CAP-QL, which > at least has a chance of being understood by a machine, not > just a human who glances at it and thinks that it sort of > looks correct. I am happy with that. My issues are for PDA, Cell, and limited memory support: (1) Currently we allow unlimited logical operators. I mean I could create a query that was 90 pages long used 100 USING statements an 40 levels of parentheses and still add to it. (2) We need some way to for a CS to say that it can not handle more than (example) 2 logical operators where both are from the same instance of the same component. (3) I think we are turning the CS into a database server. And that is going to make writing a CS near impossible. Like XML-Schema - it is complete - but who can write a complete one? (4) Is a vendor really going to make a CUA GUI that allows the CU to ask for all appointments where 'fred' is an attendee and no one else has accepted? And any other variation of that? Does this need to be a query to the CS, or can we limit the queries to something simple like: SELECT * FROM VEVENT WHERE ATTENDEE = 'fred' then let the CUA sort it out what it wants? I think we have pushed the CUA code into the CS by forcing the CS to get 'what ever I want'. And I think the correct mode should be 'get what I need so I can do what I want'. Perhaps the best break point would be that a MIN version could not support any USING operators. This would limit the queries and force the CUA to do more data processing. But at the same time allows small CS's to be implemented. Also - MIN would not allow any parentheses at all. And a limited number of logical operators. Then the FULL QL could be what CAP-QL is now for and allow a mega-CS. Maybe define some pre-defined queries that take an argument as John has pointed out. Get 'today', get everything that changed since last sync, all non-booked entries, ... I have already mapped most of CAP-QL into SQL (somewhat tested). My concern is that we are forcing all CS's to be rather huge implementations that might take a LONG time to be interoperable. From owner-ietf-calendar@mail.imc.org Tue Mar 26 12:53: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 MAA15944 for ; Tue, 26 Mar 2002 12:53:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QHi7L08157 for ietf-calendar-bks; Tue, 26 Mar 2002 09:44:07 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QHi6408153 for ; Tue, 26 Mar 2002 09:44:06 -0800 (PST) To: ietf-calendar@imc.org Subject: Concensus - no XML in CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 12:44:17 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 12:44:08 PM, Serialize complete at 03/26/2002 12:44:08 PM Content-Type: multipart/alternative; boundary="=_alternative 0061708C85256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0061708C85256B88_= Content-Type: text/plain; charset="us-ascii" Ok, I think I have seen more replies saying it's ok to remove XML from CAP - and that we don't need it in order to support BEEP. I have actually seen more than two people state this - a record! That being said, I would like to propose that we have reached Concensus (saints preserve us!) on the XML in CAP issue. Anyone disagree????? Going, going, ..... --=_alternative 0061708C85256B88_= Content-Type: text/html; charset="us-ascii"
Ok, I think I have seen more replies saying it's ok to remove XML from CAP - and that we don't need it in order to support BEEP.  I have actually seen more than two people state this - a record!  That being said, I would like to propose that we have reached Concensus (saints preserve us!) on the XML in CAP issue.

Anyone disagree?????  Going, going, .....
--=_alternative 0061708C85256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 13:07:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16823 for ; Tue, 26 Mar 2002 13:07:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QHqtW08637 for ietf-calendar-bks; Tue, 26 Mar 2002 09:52:55 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QHqs408630 for ; Tue, 26 Mar 2002 09:52:54 -0800 (PST) To: CalSched IETF Subject: Re: I MOVE we simplify the query language. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 13:03:11 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 01:03:22 PM, Serialize complete at 03/26/2002 01:03:22 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >I am happy with that. My issues are for PDA, Cell, and limited >memory support: [...] > (2) We need some way to for a CS to say that it can not > handle more than (example) 2 logical operators where I think I'm missing something. Why would you run a CS on a handheld? > (4) Is a vendor really going to make a CUA GUI that allows the > CU to ask for all appointments where 'fred' is an attendee > and no one else has accepted? And any other variation > of that? You probably wouldn't be able to compose such queries by hand; but a CUA might have hard-coded queries that are that complicated. For example, the above query would be useful for Fred's admin. > Does this need to be a query to the CS, or can > we limit the queries to something simple like: > > SELECT * FROM VEVENT WHERE ATTENDEE = 'fred' > > then let the CUA sort it out what it wants? That doesn't scale on the CS, though. Pushing the query back towards the store makes for less bandwidth and less CAP processing. For database-based CSes (the only ones that will scale), you want to run the query in the DB itself, to get as little data as possible coming back over the wire from the DB. It also hurts CUA performance, especially for limited-bandwidth cases like PDAs and cellphones, where users get charged by the byte. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Know your limits, then destroy 'em. | \========================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 13:44: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 NAA18519 for ; Tue, 26 Mar 2002 13:44:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QIWqX11150 for ietf-calendar-bks; Tue, 26 Mar 2002 10:32:52 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QIWo411136 for ; Tue, 26 Mar 2002 10:32:50 -0800 (PST) To: "John Stracke" Cc: CalSched IETF , owner-ietf-calendar@mail.imc.org Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 26 Mar 2002 13:33:01 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 03/26/2002 01:32:52 PM, Serialize complete at 03/26/2002 01:32:52 PM Content-Type: multipart/alternative; boundary="=_alternative 0065E6D985256B88_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065E6D985256B88_= Content-Type: text/plain; charset="us-ascii" Excellent. I think I agree with you John. We did not really need another thing on our plate - I just did not want the issue to go unaddressed. So, case closed. "John Stracke" Sent by: owner-ietf-calendar@mail.imc.org 03/26/02 12:10 To: CalSched IETF cc: Subject: Re: CAP / BEEP / XML / iCalendar - updated proposal >Actually, we need to figure out what to do with vCard and vCalendar. >Someone asked me where the home was for vCard. It doesn't really have one at this point; it looks like RFC-2425 and 2426 were developed by a WG called ASID, but ASID doesn't exist any more. (Or they might have been developed by individuals who got help from the ASID group; it's not clear to me.) It doesn't particularly need a WG as long as it's stable, after all; and it's got a registration process defined for small-scale evolution. >I'm not sure, but our >group is a likely candidate unless some other group thinks it belongs >with them. Not sure. I would think vCard would fall more closely to one of the LDAP working groups; it's closer to their expertise. The affinity between vCard and [vi]Calendar is more a historical artifact than a technical relationship. /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |"How can one conceive of a one party system in a country that has| |over 200 varieties of cheese?" --Charles de Gaulle | \=================================================================/ --=_alternative 0065E6D985256B88_= Content-Type: text/html; charset="us-ascii"
Excellent.  I think I agree with you John.  We did not really need another thing on our plate - I just did not want the issue to go unaddressed.  So, case closed.


"John Stracke" <jstracke@incentivesystems.com>
Sent by: owner-ietf-calendar@mail.imc.org

03/26/02 12:10

       
        To:        CalSched IETF <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: CAP / BEEP / XML / iCalendar  -  updated proposal




>Actually, we need to figure out what to do with vCard and vCalendar.
>Someone asked me where the home was for vCard.

It doesn't really have one at this point; it looks like RFC-2425 and 2426
were developed by a WG called ASID, but ASID doesn't exist any more.  (Or
they might have been developed by individuals who got help from the ASID
group; it's not clear to me.) It doesn't particularly need a WG as long as
it's stable, after all; and it's got a registration process defined for
small-scale evolution.

>I'm not sure, but our
>group is a likely candidate unless some other group thinks it belongs
>with them.  Not sure.

I would think vCard would fall more closely to one of the LDAP working
groups; it's closer to their expertise.  The affinity between vCard and
[vi]Calendar is more a historical artifact than a technical relationship.

/=================================================================\
|John Stracke                    |Principal Engineer              |
|jstracke@incentivesystems.com   |Incentive Systems, Inc.         |
|http://www.incentivesystems.com |My opinions are my own.         |
|=================================================================|
|"How can one conceive of a one party system in a country that has|
|over 200 varieties of cheese?" --Charles de Gaulle               |
\=================================================================/

--=_alternative 0065E6D985256B88_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 26 14:45: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 OAA20511 for ; Tue, 26 Mar 2002 14:45:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QJYSO14182 for ietf-calendar-bks; Tue, 26 Mar 2002 11:34: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 g2QJYR414176 for ; Tue, 26 Mar 2002 11:34:27 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QJYPdx014871 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 11:34:29 -0800 (PST) Message-ID: <3CA0CD3C.5090709@Royer.com> Date: Tue, 26 Mar 2002 12:34:20 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: vCard home 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 > >Actually, we need to figure out what to do with vCard and vCalendar. > >Someone asked me where the home was for vCard. See: http://www.imc.org/pdi From owner-ietf-calendar@mail.imc.org Tue Mar 26 15:07: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 PAA21493 for ; Tue, 26 Mar 2002 15:07:19 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QJpeJ15177 for ietf-calendar-bks; Tue, 26 Mar 2002 11:51: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 g2QJpd415173 for ; Tue, 26 Mar 2002 11:51:39 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QJpadx015095 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 11:51:41 -0800 (PST) Message-ID: <3CA0D144.9070808@Royer.com> Date: Tue, 26 Mar 2002 12:51:32 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: I MOVE we simplify the query language. 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 > You probably wouldn't be able to compose such queries by hand; but a CUA > might have hard-coded queries that are that complicated. For example, the > above query would be useful for Fred's admin. Sounds like a great example for a stored query :-) > >> Does this need to be a query to the CS, or can >> we limit the queries to something simple like: >> >> SELECT * FROM VEVENT WHERE ATTENDEE = >> > 'fred' > >> then let the CUA sort it out what it wants? >> > > That doesn't scale on the CS, though. I am NOT saying that we don't need a QL-FULL, I am saying we need a QL-MIN that is an exact and limited subset of QL-FULL so that small device CSs can be implemented without having to have a full blown database server behind them. > Pushing the query back towards the > store makes for less bandwidth and less CAP processing. I would suspect that a CUA won't ask for what it can't handle. And why would expecting a CS that serves N number of CUA, scale better than 1 CUA doing the same work? > For > database-based CSes (the only ones that will scale), you want to run the > query in the DB itself, to get as little data as possible coming back over > the wire from the DB. Does your database server support 'USING_PROPERTIES()', if not - no it can't be at that level. If it can't be mapped 1:1 to your database query language, then the CS is going to have to do exactly what you say won't scale. There are forces on this list that do not want an SQL language. So we invented things that break every database server language. > It also hurts CUA performance, especially for limited-bandwidth cases like > PDAs and cellphones, where users get charged by the byte. I would suspect that those vendors will be using stored queries and not 90 page requests with complicated queries. I am not trying to limit a CS from doing a QL-FULL. I am trying to enable small devices and small implementations to not have to buy a full database server in order to do CAP-QL. From owner-ietf-calendar@mail.imc.org Tue Mar 26 16:11:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24087 for ; Tue, 26 Mar 2002 16:11:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QKxva17421 for ietf-calendar-bks; Tue, 26 Mar 2002 12:59:57 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QKxt417413 for ; Tue, 26 Mar 2002 12:59:55 -0800 (PST) To: CalSched IETF Subject: Re: I MOVE we simplify the query language. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 16:10:12 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 04:10:24 PM, Serialize complete at 03/26/2002 04:10:24 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> You probably wouldn't be able to compose such queries by hand; but a CUA >> might have hard-coded queries that are that complicated. For example, the >> above query would be useful for Fred's admin. > >Sounds like a great example for a stored query :-) No, because, in the standard, a stored query cannot do anything that a non-stored query cannot do. >>> then let the CUA sort it out what it wants? >> >> That doesn't scale on the CS, though. > >I am NOT saying that we don't need a QL-FULL, I am saying we need >a QL-MIN that is an exact and limited subset of QL-FULL And I am saying that we already have a minimal subset; we can't trim it down any further and still have something useful. >so that >small device CSs can be implemented You ignored my question of why a small device would run a CS. >> Pushing the query back towards the >> store makes for less bandwidth and less CAP processing. > >I would suspect that a CUA won't ask for what it can't handle. That's not feasible. The CUA, almost by definition, has no idea how much stuff is going to come down. Anyway, without the USING constructs, it is impossible for the CUA to make some of the most important queries (e.g., "today's alarms"), which guarantees that the CUA will frequently have to pull down too much stuff. >And why would expecting a CS that serves N number of CUA, scale >better than 1 CUA doing the same work? Because it does. If I'm a CS, stepping through VEVENTs to send down, then examining each one to decide whether it matches a query takes much less time than transmitting it. That means that pushing the query back towards the store saves work all along the way. This is why database stored procedures exist: because they're faster than bringing all the data down to the database client to be processed. At eCal, I initially opposed using stored procedures, on the grounds that they would increase the database's load. I was wrong; when we went to stored procedures, our performance went up enormously. >> For >> database-based CSes (the only ones that will scale), you want to run the >> query in the DB itself, to get as little data as possible coming back over >> the wire from the DB. > >Does your database server support 'USING_PROPERTIES()', if not - no it >can't be at that level. If it can't be mapped 1:1 to your database >query language, then the CS is going to have to do Red herring. Obviously the database can't run the CAP query language directly--if nothing else, queries on multivalued properties are going to have to be rewritten into joins. So you compile the CAP query into SQL. No big deal; your only alternative is to interpret the CAP query, which is almost as hard as compiling it. >exactly what you >say won't scale. No, I said that CSes that don't use a DB backend at all won't scale. It's possible to have the CS do filtering on what comes back from the DB, if you really can't compile the CAP query into a SQL query (or don't want to take the time to implement that compilation); and it wastes less processing & bandwidth than having the CUA do the filtering, since the round-trip time to the database is usually less than to the CS. >There are forces on this list that do not want an SQL language. >So we invented things that break every database server language. There are forces on this list that do not want a non-SQL language. So we invented things to keep SQL from being broken by the iCalendar data model. These extensions are painful, but they're the only way to keep SQL and get a query language that actually works. >> It also hurts CUA performance, especially for limited-bandwidth cases like >> PDAs and cellphones, where users get charged by the byte. > >I would suspect that those vendors will be using stored queries Again, if they're standard CAP queries, then being stored is irrelevant. On the other hand, if standard CAP queries don't meet the CUAs' needs, then we've failed. >I am not trying to limit a CS from doing a QL-FULL. I am trying >to enable small devices and small implementations to not have to >buy a full database server in order to do CAP-QL. You don't need a SQL-based server to implement the CAP query language; you can interpret the queries yourself. /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===========================================================| |I am destined to build a bridge to China out of live sheep.| \===========================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 16:18: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 QAA24498 for ; Tue, 26 Mar 2002 16:18:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QL6IR17835 for ietf-calendar-bks; Tue, 26 Mar 2002 13:06:18 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QL6H417831 for ; Tue, 26 Mar 2002 13:06:17 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2QL6Idl030051 for ; Tue, 26 Mar 2002 16:06:18 -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 g2QL6DQ20328 for ; Tue, 26 Mar 2002 16:06:13 -0500 (EST) Message-Id: <5.1.0.14.0.20020326154721.0aa813a0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Mar 2002 16:09:40 -0500 To: CalSched IETF From: Alan Davies Subject: Re: I MOVE we simplify the query language. In-Reply-To: <3CA0D144.9070808@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 12:51 PM 26/03/2002 -0700, Doug Royer wrote: >I am NOT saying that we don't need a QL-FULL, I am saying we need >a QL-MIN that is an exact and limited subset of QL-FULL so that >small device CSs can be implemented without having to have a full >blown database server behind them. You seem to be making the assertation that CAP must be simple enough to implement a Calendar Server (CS) on a "small device" quite regularly, but I can't find any mention to this in the CAP Requirements Draft; could you point me to the relevant section, if it exists? What are these mythical small device CS's; and will they proliferate at the same rate that Mail Servers and Web Servers have not proliferated on small devices? While simplifying the query language has some advantages, it will make the implementation of small device _CUA_ more difficult, as John pointed out, due to increased bandwidth (and we're not just talking about the odd byte here or there, possibly orders of magnitude more bandwidth), and complexity pushed into the CUA. >There are forces on this list that do not want an SQL language. >So we invented things that break every database server language. What forces on this list do not want an SQL language? I haven't seen them; I've seen reasoned discussion that have pointed out flaws in the overly-optimistic that plain SQL to query a non-SQL schema. --Alan From owner-ietf-calendar@mail.imc.org Tue Mar 26 16:42: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 QAA26238 for ; Tue, 26 Mar 2002 16:42:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QLX7Z19148 for ietf-calendar-bks; Tue, 26 Mar 2002 13:33:07 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QLX5419141 for ; Tue, 26 Mar 2002 13:33:05 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2QLX6dl030481 for ; Tue, 26 Mar 2002 16:33:06 -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 g2QLX0Q23334 for ; Tue, 26 Mar 2002 16:33:00 -0500 (EST) Message-ID: <0ce201c1d50e$06212b20$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3CA0D144.9070808@Royer.com> Subject: Re: I MOVE we simplify the query language. Date: Tue, 26 Mar 2002 16:34:35 -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: "CalSched IETF" Sent: Tuesday, March 26, 2002 2:51 PM Subject: Re: I MOVE we simplify the query language. > I am NOT saying that we don't need a QL-FULL, I am saying we need > a QL-MIN that is an exact and limited subset of QL-FULL so that > small device CSs can be implemented without having to have a full > blown database server behind them. I can see your point about needing a simple QL for implementing a small CS, Doug, but we can't afford to ignore the "large" implementation while allowing for the small. (I seem to recall reading something about the IETF goals and large-scale deployments....) Right now, CAP-QL provides enough functionality to deliver a reasonably feature-rich CS in a traditional client-server environment. IF we cut down CAP-QL to be suitable for implementing a CS on a small device, then we MUST have a richer query language defined BEFORE last call, not as some magical "add-on draft" to be done "later"; without it, CAP will only be a toy, not a useful IETF [draft | proposed] standard. I don't agree with the thought that it will take a long time to come up with a good query language (unless we're forced to use an SQL-like syntax that doesn't fit with the iCalendar data model); John Stracke has already proposed one reasonable alternative query language, (, thanks for posting the link earlier John), and certainly others are possible. Maybe we should have 2 versions of CAP-QL: the CAP-QL that the list (more or less) agreed on in January, and a CAP-QL "Lite" for simple CS implementations. As CAP-QL was sort of a "one language fits all" compomise, this would raise 2 questions: 1) Is CAP-QL as it stands sufficient for those wanting to implement a "full" CS, or are there more features that would be *needed* (rather than "this would be cool")? 2) What would be the strict minimum needed for a CAP-QL "Lite", for a "simple" CS? (Doug?) Graham From owner-ietf-calendar@mail.imc.org Tue Mar 26 16:48: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 QAA26556 for ; Tue, 26 Mar 2002 16:48:30 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QLchu19798 for ietf-calendar-bks; Tue, 26 Mar 2002 13:38:43 -0800 (PST) Received: from office2.jigzaw.com ([216.248.40.78]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QLcf419792 for ; Tue, 26 Mar 2002 13:38:41 -0800 (PST) Received: from colatz ([10.0.0.10]) by office2.jigzaw.com (8.9.3/8.9.3) with ESMTP id PAA20205; Tue, 26 Mar 2002 15:29:59 -0600 From: "Shannon J. Clark" To: "Alan Davies" , "CalSched IETF" Subject: RE: I MOVE we simplify the query language. - small device CSs Date: Tue, 26 Mar 2002 15:38:49 -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 In-Reply-To: <5.1.0.14.0.20020326154721.0aa813a0@imap1.in.steltor.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just a quick thought about Small Devices. In our various documents we describe a "typical" Calendar User Agent as probably also have a Calendar Server engine "inside of it" - in order to hold and consume iCalendar objects a calendar user agent will have to have some storage capability and native understanding of the iCalendar object structure - so in many cases a basic calendar server is a part of a calendar user agent design. (if not then the user agent design is perhaps nothing more than a screen display with no actual "application" - rather it relies entirely on data from a server application for what to show and where - i.e. something very different than currently envisioned by CAP. CAP delivers FROM a Calendar Server iCalendar objects - which must then be used (and almost certainly stored) by the Calender User Agent. So I think that the answer to the "mythical small device calendar servers" is that they will have such a server as a part of Calendar User Agents written for them. Or at least this is a very likely and probable scenario. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Alan Davies Sent: Tuesday, March 26, 2002 3:10 PM To: CalSched IETF Subject: Re: I MOVE we simplify the query language. At 12:51 PM 26/03/2002 -0700, Doug Royer wrote: >I am NOT saying that we don't need a QL-FULL, I am saying we need >a QL-MIN that is an exact and limited subset of QL-FULL so that >small device CSs can be implemented without having to have a full >blown database server behind them. You seem to be making the assertation that CAP must be simple enough to implement a Calendar Server (CS) on a "small device" quite regularly, but I can't find any mention to this in the CAP Requirements Draft; could you point me to the relevant section, if it exists? What are these mythical small device CS's; and will they proliferate at the same rate that Mail Servers and Web Servers have not proliferated on small devices? While simplifying the query language has some advantages, it will make the implementation of small device _CUA_ more difficult, as John pointed out, due to increased bandwidth (and we're not just talking about the odd byte here or there, possibly orders of magnitude more bandwidth), and complexity pushed into the CUA. >There are forces on this list that do not want an SQL language. >So we invented things that break every database server language. What forces on this list do not want an SQL language? I haven't seen them; I've seen reasoned discussion that have pointed out flaws in the overly-optimistic that plain SQL to query a non-SQL schema. --Alan From owner-ietf-calendar@mail.imc.org Tue Mar 26 17:06: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 RAA27064 for ; Tue, 26 Mar 2002 17:06:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QLosN20057 for ietf-calendar-bks; Tue, 26 Mar 2002 13:50: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 g2QLorm20052 for ; Tue, 26 Mar 2002 13:50:53 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QLoZdx017084 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 13:50:40 -0800 (PST) Message-ID: <3CA0ED25.9040103@Royer.com> Date: Tue, 26 Mar 2002 14:50:29 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: I MOVE we simplify the query language. 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 > No, because, in the standard, a stored query cannot do anything that a > non-stored query cannot do. Okay? So it still sounds like a good canidate for a stored query. > > > You ignored my question of why a small device would run a CS. Because I can sell it. Because it was a CAP requirement to support thin devices. Because I want to. > >>>Pushing the query back towards the >>>store makes for less bandwidth and less CAP processing. >>> >>I would suspect that a CUA won't ask for what it can't handle. >> > > That's not feasible. The CUA, almost by definition, has no idea how much > stuff is going to come down. It is a TCP connection. Read what you can process when you can process it. We don't have to invent flow control. If you don't like what you are getting, close the BEEP channel or abort the command. Or the CUA will have set the MAX size when it connected in its capabilities and the CS will have never sent large replies. > Anyway, without the USING constructs, it is impossible for the CUA to make > some of the most important queries (e.g., "today's alarms"), which > guarantees that the CUA will frequently have to pull down too much stuff. OR - my PDA can call a stored query that my mega-windows-GUI created that gets what the PDA wants. Even when the PDA could never understand the contents of the query, and even if the PDA could have never generated the complicated query that it is using by QUERYID only. From owner-ietf-calendar@mail.imc.org Tue Mar 26 17:19: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 RAA27545 for ; Tue, 26 Mar 2002 17:19:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QM9xo20517 for ietf-calendar-bks; Tue, 26 Mar 2002 14:09:59 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QM9vm20513 for ; Tue, 26 Mar 2002 14:09:57 -0800 (PST) To: "CalSched IETF" Subject: RE: I MOVE we simplify the query language. - small device CSs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 17:20:07 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 05:20:27 PM, Serialize complete at 03/26/2002 05:20:27 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >(if not then the user agent design is perhaps nothing more than a screen >display with no actual "application" - rather it relies entirely on data >from a server application for what to show and where - i.e. something very >different than currently envisioned by CAP. On the contrary, that is *exactly* how I've always envisioned a CAP client. Just like an IMAP client. If you want to do offline work, you need to do sync over CAP; but the local store that you sync with the CS is out of scope for CAP. You can access it however you please; it's entirely yours, so there's no question of interoperability. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Illiterate? Write today for free help! | \========================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 17:22: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 RAA27653 for ; Tue, 26 Mar 2002 17:22:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QMCxm20729 for ietf-calendar-bks; Tue, 26 Mar 2002 14:12: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 g2QMCvm20725 for ; Tue, 26 Mar 2002 14:12:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QMCtBM017712 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 14:12:59 -0800 (PST) Message-ID: <3CA0F261.6040104@Royer.com> Date: Tue, 26 Mar 2002 15:12:49 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: I MOVE we simplify the query language. References: <3CA0D144.9070808@Royer.com> <0ce201c1d50e$06212b20$092e0165@in.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 Graham Gilmore wrote: > > I can see your point about needing a simple QL for implementing a small > CS, Doug, but we can't afford to ignore the "large" implementation while > allowing for the small. I never said scrap the full QL. I would argue against scraping FULL-QL. > > Maybe we should have 2 versions of CAP-QL: the CAP-QL that the list > (more or less) agreed on in January, and a CAP-QL "Lite" for simple CS > implementations. As CAP-QL was sort of a "one language fits all" compomise, > this would raise 2 questions: Yes - that was my thoughts. > 1) Is CAP-QL as it stands sufficient for those wanting to implement a > "full" CS, or are there more features that would be *needed* (rather than > "this would be cool")? I think it would allow CAP-QL to extend if needed and not compromise small devices. > 2) What would be the strict minimum needed for a CAP-QL "Lite", for a > "simple" CS? (Doug?) Bare bones query including allowing for a LITE-CUA to call stored queries that perhaps were setup by a FULL-QL CUA, even when the LITE-CUA can not generate those queries. I know that John disagrees with stored queries, but I don't see why a LITE-CUA could not be built that ONLY supported pre-defined queries. Perhaps the best break point would be that a MIN version could not support any USING operators. This would limit the queries and force the CUA to do more data processing. But at the same time allows small CS's to be implemented. Also - MIN would not allow any parentheses at all. And a limited number of logical operators (1?). Then the FULL QL could be what CAP-QL is now for and allow a mega-CS. Maybe define some pre-defined queries that take an argument as John has pointed out. Get 'today', get everything that changed since last sync, all non-booked entries, get all alarms for today, ... I have already mapped most of CAP-QL into SQL (somewhat tested). My concern is that we are forcing all CS's to be rather huge implementations that might take a LONG time to be interoperable. The reason that SQL-MIN existed was because we gave up trying to do a mega-query language. However in that debate that resulted in CAP-QL, we forgot that small devices just can do all of that. I don't see any reason that I can not have a From owner-ietf-calendar@mail.imc.org Tue Mar 26 17: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 RAA28637 for ; Tue, 26 Mar 2002 17:47:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QMZd721191 for ietf-calendar-bks; Tue, 26 Mar 2002 14:35:39 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QMZcm21187 for ; Tue, 26 Mar 2002 14:35:38 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2QMZedl031353 for ; Tue, 26 Mar 2002 17:35:40 -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 g2QMZZQ00901 for ; Tue, 26 Mar 2002 17:35:35 -0500 (EST) Message-Id: <5.1.0.14.0.20020326172309.0aa5ed70@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Mar 2002 17:39:02 -0500 To: CalSched IETF From: Alan Davies Subject: Re: I MOVE we simplify the query language. In-Reply-To: <3CA0F261.6040104@Royer.com> References: <3CA0D144.9070808@Royer.com> <0ce201c1d50e$06212b20$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 03:12 PM 26/03/2002 -0700, Doug Royer wrote: >Perhaps the best break point would be that a MIN version could >not support any USING operators. This would limit the queries >and force the CUA to do more data processing. But at the same time >allows small CS's to be implemented. Also - MIN would not allow >any parentheses at all. And a limited number of logical operators (1?). >Then the FULL QL could be what CAP-QL is now for and allow a mega-CS. You seem to think that the USING operators can be left out to provide a simplified QL, but you haven't yet provided an answer as to which of the three unsatisfactory options (a), (b), or (c) would be chosen in their absence: http://www.imc.org/ietf-calendar/mail-archive/msg05613.html --Alan From owner-ietf-calendar@mail.imc.org Tue Mar 26 17:52: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 RAA28767 for ; Tue, 26 Mar 2002 17:52:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QMfaE21295 for ietf-calendar-bks; Tue, 26 Mar 2002 14:41:36 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QMfZm21291 for ; Tue, 26 Mar 2002 14:41:35 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2QMfVdl031440 for ; Tue, 26 Mar 2002 17:41: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 g2QMfLQ01564 for ; Tue, 26 Mar 2002 17:41:21 -0500 (EST) Message-ID: <3CA0F9B5.506C69DF@steltor.com> Date: Tue, 26 Mar 2002 17:44:05 -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: moving to closure on transport / application layers References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@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: > > Does anyone have issues with this? Can we close this issue and move > on? I have no problem about removing XML from CAP. On the other hand, we need to look at the issues that need to be addressed as a result of this change. Don't worry, none of the following issues need XML to be resolved! 1- The version of iCalendar supported by the CS will end up being specified in an iCalendar object (chicken'n'egg problem). Shall we specify that the capabilities MUST always be returned in an iCalendar 2.0 object? For instance, a CS supporting iCalendar 2.1 would returned : BEGIN:VCALENDAR VERSION:2.0 <-- Always 2.0 BEGIN:VCAPABILITY VERSION:2.1 <-- Version of iCalendar ... supported by the CS END:VCAPABILITY END:VCALENDAR 2- The MODIFY command requires ordering of components (i.e., OLD-VALUES component needs to appear before the NEW-VALUES component in the iCalendar object). The iCalendar syntax usually doesn't impose ordering of components. Are there iCalendar parsers known not to preserve the ordering of components in iCalendar objects? Should the old and new values be identified explicitly by some other mean than their ordering? Is that an issue? 3- According to RFC 2445, besides CALSCALE, METHOD, PRODID and VERSION, only "x-prop" properties can appear in the body of iCalendar components. Do we want to break this syntax and allow TARGET, CMDID, LATENCY, etc. in iCalendar components? We used to have a VCOMMAND components for these types of properties. Do we need to add it back? What about iTIP? iTIP doesn't allow TARGET, etc. in the iCalendar object either. 4- We need to agree on the mapping of the existent DTD into the iCalendar syntax. That is, we will need to define new components (e.g., VCAPABILITY, VGENERATE-UID) as well as new properties and parameters (e.g., UPN property or parameter for the IDENTIFY command, NUMBER-OF-UID property or parameter for the GENERATE-UID command). We will also have to define the format of the response returned for the commands, perhaps we will need a VRESULT component? 5- Further to this change, I think it will become even more important to separate the method/command specified in the iCalendar objects from their actual state. Perhaps, we will want/need the ability to create objects in a specific initial state eventually (e.g., a PDA willing to sync its meeting trash can on the CS (i.e., create meeting in the state DELETED)). We might also want to consider Doug's proposition of using a "CMD" property to hold the name of the command instead of using METHOD. It might be worthwhile to use METHOD only in iTIP messages. Doug's proposal can be found at http://www.imc.org/ietf-calendar/mail-archive/msg04741.html Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Mar 26 18:05:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29241 for ; Tue, 26 Mar 2002 18:05:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QMl8H21451 for ietf-calendar-bks; Tue, 26 Mar 2002 14:47:08 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QMl7m21447 for ; Tue, 26 Mar 2002 14:47:07 -0800 (PST) To: CalSched IETF Subject: Re: I MOVE we simplify the query language. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 17:57:22 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 05:57:36 PM, Serialize complete at 03/26/2002 05:57:36 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> You ignored my question of why a small device would run a CS. > >Because I can sell it. This pushes the question back: why would someone buy a CS running on a handheld? >Because it was a CAP requirement to support thin devices. Where is the CAP requirements doc? It's not available as a Draft or an RFC. However, I suspect that the requirement was to support thin clients, not thin servers. (We've definitely talked about thin clients before, but I don't remember talking about thin servers. And, in any case, the two are mutually exclusive; *somebody's* got to do the work.) >>>>Pushing the query back towards the >>>>store makes for less bandwidth and less CAP processing. >>>> >>>I would suspect that a CUA won't ask for what it can't handle. >> >> That's not feasible. The CUA, almost by definition, has no idea how much >> stuff is going to come down. > >It is a TCP connection. Read what you can process when you >can process it. We don't have to invent flow control. We're not talking about keeping up with the connection; we're talking about paying for the bandwidth. >Or the CUA will have set the MAX size when it connected in >its capabilities and the CS will have never sent large replies. Without USING*, it is likely that the only way a CUA can get what it needs is to accept large replies. >> Anyway, without the USING constructs, it is impossible for the CUA to make >> some of the most important queries (e.g., "today's alarms"), which >> guarantees that the CUA will frequently have to pull down too much stuff. > >OR - my PDA can call a stored query that my mega-windows-GUI created >that gets what the PDA wants. So what? You still need a query language with USING, whether the query was composed on a thin client or a thick one. And for basic functionality like "today's alarms", the PDA can include a hard-wired query; you don't need a GUI to compose it. Besides, as things stand, a stored query would be useless for "today's alarms", or "today's events", because the query language has no term for "today". /==========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==========================================================| |"Collect call from reality, will you accept the--" *click*| \==========================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 18:05: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 SAA29281 for ; Tue, 26 Mar 2002 18:05:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QMrXO21625 for ietf-calendar-bks; Tue, 26 Mar 2002 14:53:33 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2QMrVm21621 for ; Tue, 26 Mar 2002 14:53:32 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: I MOVE we simplify the query language. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Tue, 26 Mar 2002 18:03:47 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/26/2002 06:04:02 PM, Serialize complete at 03/26/2002 06:04:02 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Bare bones query including allowing for a LITE-CUA to call stored queries >that perhaps were setup by a FULL-QL CUA, even when the LITE-CUA >can not generate those queries. But having a thin CUA use queries composed by a fat CUA does not solve anybody's problem. If the thin CUA doesn't understand the full language, then it doesn't know what query to run for each piece of its GUI. >I know that John disagrees with >stored queries, but I don't see why a LITE-CUA could not be built >that ONLY supported pre-defined queries. They should be pre-defined at compile time, not at run time. The thin CUA doesn't *need* a fat CUA to compose the queries, because it only needs a handful of queries, composed by the developer, not by the user. >Perhaps the best break point would be that a MIN version could >not support any USING operators. Without USING, you're really stuck. As we've already demonstrated, without USING, you can't even query for alarms in a given time range--and alarms are the most important reason to carry a PDA with a CUA. /============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |============================================================| |"God does not play games with His loyal servants." "Whoo-ee,| |where have you *been*?" --_Good Omens_ | \============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 26 18:36: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 SAA29942 for ; Tue, 26 Mar 2002 18:36:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QNOvA22517 for ietf-calendar-bks; Tue, 26 Mar 2002 15:24: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 g2QNOum22512 for ; Tue, 26 Mar 2002 15:24:56 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QNOsBM019034 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 15:24:58 -0800 (PST) Message-ID: <3CA1033F.5040408@Royer.com> Date: Tue, 26 Mar 2002 16:24:47 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: iCalenar format version (2.0 or 2.1) References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@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 Bernard Desruisseaux wrote: > 1- The version of iCalendar supported by the CS will end up > being specified in an iCalendar object (chicken'n'egg > problem). Shall we specify that the capabilities MUST > always be returned in an iCalendar 2.0 object? For > instance, a CS supporting iCalendar 2.1 would returned : > > BEGIN:VCALENDAR > VERSION:2.0 <-- Always 2.0 > BEGIN:VCAPABILITY > VERSION:2.1 <-- Version of iCalendar > ... supported by the CS > END:VCAPABILITY > END:VCALENDAR The capabilities VERSION was changed to CAP-VERSION - no longer a conflict. And the CAP-VERSION is "1.0". (I think this was a George suggestion and is currently in -07). From owner-ietf-calendar@mail.imc.org Tue Mar 26 18:40: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 SAA00025 for ; Tue, 26 Mar 2002 18:40:22 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QNRlh22571 for ietf-calendar-bks; Tue, 26 Mar 2002 15:27: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 g2QNRlm22567 for ; Tue, 26 Mar 2002 15:27:47 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QNRjBM019076 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 15:27:49 -0800 (PST) Message-ID: <3CA103EA.5020402@Royer.com> Date: Tue, 26 Mar 2002 16:27:38 -0700 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: MOVE - ordering. References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@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 Bernard Desruisseaux wrote: > > 2- The MODIFY command requires ordering of components (i.e., > OLD-VALUES component needs to appear before the NEW-VALUES > component in the iCalendar object). The iCalendar syntax > usually doesn't impose ordering of components. Are there > iCalendar parsers known not to preserve the ordering of > components in iCalendar objects? Should the old and new > values be identified explicitly by some other mean than > their ordering? Is that an issue? Good idea. It first I thought I could live with it being an exception. But exceptions are killing us with query. So it might be a good idea to specifically tag them. Andy ideas for property names? From owner-ietf-calendar@mail.imc.org Tue Mar 26 18:43: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 SAA00082 for ; Tue, 26 Mar 2002 18:43:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QNWxb22728 for ietf-calendar-bks; Tue, 26 Mar 2002 15:32: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 g2QNWwm22724 for ; Tue, 26 Mar 2002 15:32:58 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QNWtBM019155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 15:33:00 -0800 (PST) Message-ID: <3CA10520.6060504@Royer.com> Date: Tue, 26 Mar 2002 16:32:48 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: X-PROP vs CAP property names. References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@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 > 3- According to RFC 2445, besides CALSCALE, METHOD, PRODID and > VERSION, only "x-prop" properties can appear in the body of > iCalendar components. Do we want to break this syntax and > allow TARGET, CMDID, LATENCY, etc. in iCalendar components? > We used to have a VCOMMAND components for these types of > properties. Do we need to add it back? What about iTIP? > iTIP doesn't allow TARGET, etc. in the iCalendar object > either. 2445 allows us to make new properties, parameters, and value types as long as we register them with iana, or in an RFC. iTIP allows iana registered properties, parameters, and value types. So the sections in CAP that explicitly define those properties simply have to also register them as new in CAP. When CAP is an RFC, they are iana registered and valid in 2445, iTIP, iMIP, and CRISP objects. From owner-ietf-calendar@mail.imc.org Tue Mar 26 18: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 SAA00250 for ; Tue, 26 Mar 2002 18:50:10 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2QNfAC22840 for ietf-calendar-bks; Tue, 26 Mar 2002 15:41: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 g2QNf9m22835 for ; Tue, 26 Mar 2002 15:41:09 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QNf7BM019324 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 15:41:11 -0800 (PST) Message-ID: <3CA1070C.7050601@Royer.com> Date: Tue, 26 Mar 2002 16:41:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: DTD References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@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 assume you mean the BEEP DTD? If no, yes xCal will describe how to generically map iCal into and from XML. If yes ... Bernard Desruisseaux wrote: > 4- We need to agree on the mapping of the existent DTD into > the iCalendar syntax. That is, we will need to define new > components (e.g., VCAPABILITY, VGENERATE-UID) as well as new > properties and parameters (e.g., UPN property or parameter > for the IDENTIFY command, NUMBER-OF-UID property or parameter > for the GENERATE-UID command). We will also have to define > the format of the response returned for the commands, perhaps > we will need a VRESULT component? GET-CAPABILITY simply is a METHOD, not a component. Same with IDENTIFY and the others. Is all we have to do is define how we return the results. Pre-BEEP we had a way to do a iCalendar REPLY, I assume the quickest way is to update that. Perhaps a VCALENDAR object with METHOD:REPLY and CMDID and TARGET matching the original command, then include any reply objects. It will require new properties. And for 'capability' - we had pre-beep defined them as CS or calendar properties. We can just go back to that and update it for the additions and changes. Or if that no longer fits, then we could make up new components. From owner-ietf-calendar@mail.imc.org Tue Mar 26 18:52: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 SAA00347 for ; Tue, 26 Mar 2002 18:52:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2QNgkI22888 for ietf-calendar-bks; Tue, 26 Mar 2002 15:42: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 g2QNgjm22878 for ; Tue, 26 Mar 2002 15:42:45 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2QNghBM019353 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 15:42:47 -0800 (PST) Message-ID: <3CA1076C.4080900@Royer.com> Date: Tue, 26 Mar 2002 16:42:36 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CMD vs METHOD References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@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 with my proposal :-) Bernard Desruisseaux wrote: > 5- Further to this change, I think it will become even more > important to separate the method/command specified in the > iCalendar objects from their actual state. Perhaps, we > will want/need the ability to create objects in a specific > initial state eventually (e.g., a PDA willing to sync its > meeting trash can on the CS (i.e., create meeting in the > state DELETED)). > > We might also want to consider Doug's proposition of using > a "CMD" property to hold the name of the command instead > of using METHOD. It might be worthwhile to use METHOD > only in iTIP messages. Doug's proposal can be found at > http://www.imc.org/ietf-calendar/mail-archive/msg04741.html From owner-ietf-calendar@mail.imc.org Tue Mar 26 19:55:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01628 for ; Tue, 26 Mar 2002 19:55:20 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2R0iUM24326 for ietf-calendar-bks; Tue, 26 Mar 2002 16:44:30 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2R0iTm24322 for ; Tue, 26 Mar 2002 16:44:29 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2R0iWdl032230 for ; Tue, 26 Mar 2002 19:44:32 -0500 Received: from steltor.com ([101.0.0.3]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2R0iQQ12373 for ; Tue, 26 Mar 2002 19:44:26 -0500 (EST) Message-ID: <3CA1166E.73510D5@steltor.com> Date: Tue, 26 Mar 2002 19:46:38 -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: iCalenar format version (2.0 or 2.1) References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@steltor.com> <3CA1033F.5040408@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 capabilities VERSION was changed to CAP-VERSION - no longer a conflict. > And the CAP-VERSION is "1.0". Draft-07 has both capabilities. cap-version 1+ Version of CAP. MUST include at least "1.0" for this version of CAP. version 1+ Version of iCalendar support. MUST BE at least "2.0". supported. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Mar 26 20:05: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 UAA01842 for ; Tue, 26 Mar 2002 20:05:35 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2R0uCc24502 for ietf-calendar-bks; Tue, 26 Mar 2002 16:56:12 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2R0uBm24498 for ; Tue, 26 Mar 2002 16:56:12 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2R0u9dl032266 for ; Tue, 26 Mar 2002 19:56:14 -0500 Received: from steltor.com ([101.0.0.3]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2R0txQ13446 for ; Tue, 26 Mar 2002 19:55:59 -0500 (EST) Message-ID: <3CA11923.B84E153E@steltor.com> Date: Tue, 26 Mar 2002 19:58:11 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: X-PROP vs CAP property names. References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@steltor.com> <3CA10520.6060504@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: > > 2445 allows us to make new properties, parameters, and value types > as long as we register them with iana, or in an RFC. Unfortunately, that's not the case. From section 4.6 (Calendar Components) of RFC 2445: calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once prodid /version / ; 'calscale' and 'method' are optional, ; but MUST NOT occur more than once calscale / method / x-prop ) > > iTIP allows iana registered properties, parameters, and value types. Unfortunately, RFC 2446 [iTIP] does not. There is no such thing as "iana-prop" in this RFC. > So the sections in CAP that explicitly define those properties simply > have to also register them as new in CAP. When CAP is an RFC, they > are iana registered and valid in 2445, iTIP, iMIP, and CRISP objects. Perhaps both 2445 and 2446 should have allowed "iana-prop", but they did not. If we decide to break the syntax we should state it clearly in the CAP draft. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Mar 26 20:21: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 UAA02236 for ; Tue, 26 Mar 2002 20:21:11 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2R18ou24751 for ietf-calendar-bks; Tue, 26 Mar 2002 17:08:50 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2R18mm24747 for ; Tue, 26 Mar 2002 17:08:49 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2R18pdl032305 for ; Tue, 26 Mar 2002 20:08:51 -0500 Received: from steltor.com ([101.0.0.3]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2R18jQ14312 for ; Tue, 26 Mar 2002 20:08:45 -0500 (EST) Message-ID: <3CA11C21.CD14177B@steltor.com> Date: Tue, 26 Mar 2002 20:10:57 -0500 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: DTD References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@steltor.com> <3CA1070C.7050601@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 assume you mean the BEEP DTD? > > If no, yes xCal will describe how to generically > map iCal into and from XML. > > If yes ... I meant the CAP DTD. Section 8 of draft-07 (was section 9 in draft-06). > > Bernard Desruisseaux wrote: > > > 4- We need to agree on the mapping of the existent DTD into > > the iCalendar syntax. That is, we will need to define new > > components (e.g., VCAPABILITY, VGENERATE-UID) as well as new > > properties and parameters (e.g., UPN property or parameter > > for the IDENTIFY command, NUMBER-OF-UID property or parameter > > for the GENERATE-UID command). We will also have to define > > the format of the response returned for the commands, perhaps > > we will need a VRESULT component? > > GET-CAPABILITY simply is a METHOD, not a component. > Same with IDENTIFY and the others. I know, but in which component are you planning to return the capabilities? I figured METHOD:GET-CAPABILITY could return a VCAPABILITY component. Anyway, my point is that removing XML is not straightforward. We need to discuss these issues (which is what we are doing now :-) ). > > Is all we have to do is define how we return the results. > Pre-BEEP we had a way to do a iCalendar REPLY, I assume the > quickest way is to update that. Perhaps a VCALENDAR object > with METHOD:REPLY and CMDID and TARGET matching the original > command, then include any reply objects. It will require new > properties. Can you provide an example of what you mean here? I hope you don't mean adding numerous properties directly in the VCALENDAR components. > And for 'capability' - we had pre-beep defined them > as CS or calendar properties. Sorry. Capabilities have never been defined as properties. From section 7.1.5 of draft-05: C: CAPABILTIY S: 2.0 S: . S: CAPVERSION=1.0 S: ITIPVERSION=1.0 S: AUTH=KERBEROS_V4 S: AUTH=DIGEST_MD5 S: . > We can just go back to that and > update it for the additions and changes. Or if that no longer > fits, then we could make up new components. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Mar 26 21:02: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 VAA03163 for ; Tue, 26 Mar 2002 21:02:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2R1l4225681 for ietf-calendar-bks; Tue, 26 Mar 2002 17:47: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 g2R1l3m25676 for ; Tue, 26 Mar 2002 17:47:03 -0800 (PST) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g2R1l1BM020975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Mar 2002 17:47:06 -0800 (PST) Message-ID: <3CA1248E.9000305@Royer.com> Date: Tue, 26 Mar 2002 18:46:54 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: X-PROP vs CAP property names. References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@steltor.com> <3CA10520.6060504@Royer.com> <3CA11923.B84E153E@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 Bernard Desruisseaux wrote: > Doug Royer wrote: > >>2445 allows us to make new properties, parameters, and value types >>as long as we register them with iana, or in an RFC. Okay, So we extent 2445. That is what the registration process is all about. From owner-ietf-calendar@mail.imc.org Wed Mar 27 09:57: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 JAA01051 for ; Wed, 27 Mar 2002 09:57:14 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2REfcq18464 for ietf-calendar-bks; Wed, 27 Mar 2002 06:41:38 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2REfam18460 for ; Wed, 27 Mar 2002 06:41:36 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2REfadl003136 for ; Wed, 27 Mar 2002 09:41: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 g2REfUQ19954 for ; Wed, 27 Mar 2002 09:41:30 -0500 (EST) Message-ID: <3CA1DABF.EEC3E5CF@steltor.com> Date: Wed, 27 Mar 2002 09:44: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: MOVE - ordering. References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@steltor.com> <3CA103EA.5020402@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: > > > > > 2- The MODIFY command requires ordering of components (i.e., > > OLD-VALUES component needs to appear before the NEW-VALUES > > component in the iCalendar object). The iCalendar syntax > > usually doesn't impose ordering of components. Are there > > iCalendar parsers known not to preserve the ordering of > > components in iCalendar objects? Should the old and new > > values be identified explicitly by some other mean than > > their ordering? Is that an issue? > > Good idea. It first I thought I could live with it being > an exception. But exceptions are killing us with query. So > it might be a good idea to specifically tag them. > > Andy ideas for property names? Actually, it might be better to use components to avoid creating yet another exception (i.e., property FOO is not a property of the component being modified, it is only a property used to identify which component is the OLD one and which is the NEW one). BEGIN:VCALENDAR VERSION:2.0 TARGET:my-cal CMD:MODIFY LATENCY;ACTION="ask":3 BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58' END:VQUERY + BEGIN:VOLDVALUE BEGIN:VEVENT LOCATION:building 3 END:VEVENT + END:VOLDVALUE + BEGIN:VNEWVALUE BEGIN:VEVENT LOCATION:building 4 END:VEVENT + END:VNEWVALUE END:VCALENDAR Any ideas for better component names? :-) Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Mar 27 10:00: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 KAA01208 for ; Wed, 27 Mar 2002 10:00:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2REp3R19812 for ietf-calendar-bks; Wed, 27 Mar 2002 06:51:03 -0800 (PST) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2REp2m19804 for ; Wed, 27 Mar 2002 06:51:02 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: X-PROP vs CAP property names. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 27 Mar 2002 10:01:26 -0500 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 03/27/2002 10:01:32 AM, Serialize complete at 03/27/2002 10:01:32 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> iTIP allows iana registered properties, parameters, and value types. > >Unfortunately, RFC 2446 [iTIP] does not. There is no such >thing as "iana-prop" in this RFC. Not a problem; just means the CAP RFC has to be marked as updating 2446. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |*BOOM* "Thank you, Beaker. Now we know that is definitely too| |much gunpowder." -- Dr. Bunsen Honeydew | \=============================================================/ From owner-ietf-calendar@mail.imc.org Wed Mar 27 10:14: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 KAA01798 for ; Wed, 27 Mar 2002 10:14:15 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2RExm820365 for ietf-calendar-bks; Wed, 27 Mar 2002 06:59:48 -0800 (PST) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2RExkm20360 for ; Wed, 27 Mar 2002 06:59:47 -0800 (PST) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g2RExldl003409 for ; Wed, 27 Mar 2002 09:59: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 g2RExaQ21731 for ; Wed, 27 Mar 2002 09:59:36 -0500 (EST) Message-ID: <3CA1DEFE.CA177D57@steltor.com> Date: Wed, 27 Mar 2002 10:02: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: X-PROP vs CAP property names. References: <3C9AA7B6.2D4459DF@netscape.com> <200203220428.g2M4Sn4F031914@lin2.andrew.cmu.edu> <3CA008B0.BD57E53@netscape.com> <3CA0F9B5.506C69DF@steltor.com> <3CA10520.6060504@Royer.com> <3CA11923.B84E153E@steltor.com> <3CA1248E.9000305@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: > > > >>2445 allows us to make new properties, parameters, and value types > >>as long as we register them with iana, or in an RFC. > > Okay, So we extent 2445. That is what the registration process > is all about. The registration process doesn't allow us to break existent rule parts. If this WG agrees on breaking existent rule parts it needs to make that clear to everybody. Perhaps by changing the iCalendar version being used. Don't get me wrong. I'm not against breaking the syntax. Perhaps that the right thing to do, and perhaps it's the right time to do it. On the other hand, we need to be clear on that. I do understand that changing the iCalendar version being used will be painful. There are ways to achieve our goals without breaking the existent iCalendar syntax. Using VCOMMAND components as was done in draft-05 is one of them. Prior to using XML, CAP was using VCOMMAND components. It just seems logical that we need to add them back while removing XML. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878