From owner-ietf-calendar@mail.imc.org Wed Aug 1 18:00:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06697 for ; Wed, 1 Aug 2001 18:00:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71LQws19195 for ietf-calendar-bks; Wed, 1 Aug 2001 14:26:58 -0700 (PDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71LQus19189 for ; Wed, 1 Aug 2001 14:26:57 -0700 (PDT) Received: from metaacer ([212.151.247.201]) by fep04-svc.swip.net with ESMTP id <20010801212650.ERQP7534.fep04-svc.swip.net@metaacer> for ; Wed, 1 Aug 2001 23:26:50 +0200 From: "Greg FitzPatrick" To: Subject: FW: IETF date/time draft in last call Date: Wed, 1 Aug 2001 23:27:02 +0200 Message-ID: <000b01c11ad0$bcd6d480$c9f797d4@metaacer> 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, Build 10.0.2511 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit For some reason or other, I have not seen this notice on our list. Greg Folks, For interest: the following Internet draft has just completed IETF working group last call, and has been requested to go forward for IETF last call for standard track. http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-04.txt It profiles ISO 8601 date/time format for use in Internet protocol timestamps, and is similar in content to the W3C NOTE: http://www.w3.org/TR/NOTE-datetime #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-calendar@mail.imc.org Thu Aug 2 01:54:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28619 for ; Thu, 2 Aug 2001 01:54:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f725YVF29364 for ietf-calendar-bks; Wed, 1 Aug 2001 22:34:31 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f725YTs29360 for ; Wed, 1 Aug 2001 22:34:30 -0700 (PDT) Received: (qmail 90969 invoked from network); 2 Aug 2001 05:30:18 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 2 Aug 2001 05:30:18 -0000 Message-ID: <3B68E44D.69BBECA7@kasey.umkc.edu> Date: Thu, 02 Aug 2001 00:25:33 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: CalSched IETF Subject: Re: CAP issue: Fallback/fanout to iTIP References: <3B5711E9.7AA8A254@netscape.com> <20010719225043.A12481@khazad-dum.copa.nl> <3B5773DB.720F619@netscape.com> <20010720020858.A13480@khazad-dum.copa.nl> <3B62F726.32DA3264@netscape.com> <3B656648.5080808@ecal.com> <3B657672.7010202@netscape.com> <3B65C3F9.6020603@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > Either the servers trust each > other, or the server doing fanout has to be able to exercise the user's > credentials on the remote server. Does the event definition language include a way to say, "This event belongs to joe@blarg.zzz" even though the session belongs to mary@blarg.zzz? If it does, implementing fanout in terms of putative users who have been given access rights to post events that are owned by others would be relatively easy. From owner-ietf-calendar@mail.imc.org Thu Aug 2 22:26:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12456 for ; Thu, 2 Aug 2001 22:26:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732BBQ04517 for ietf-calendar-bks; Thu, 2 Aug 2001 19:11:11 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732B7s04509 for ; Thu, 2 Aug 2001 19:11:07 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYWJ00.4EN for ; Thu, 2 Aug 2001 22:00:19 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PIY00.0C8; Fri, 27 Jul 2001 20:04:10 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id HAA25429; Wed, 25 Jul 2001 07:45:55 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26043 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25391 for ; Wed, 25 Jul 2001 06:31:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07271; Wed, 25 Jul 2001 06:31:33 -0400 (EDT) Message-Id: <200107251031.GAA07271@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-05.txt Date: Wed, 25 Jul 2001 06:31:33 -0400 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-05.txt Pages : 124 Date : 24-Jul-01 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-05.txt 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-05.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-05.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: <20010724132027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132027.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Fri Aug 3 05:08:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10195 for ; Fri, 3 Aug 2001 05:08:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738suO05092 for ietf-calendar-bks; Fri, 3 Aug 2001 01:54:56 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738sts05083 for ; Fri, 3 Aug 2001 01:54:55 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFCQ00.5P8 for ; Fri, 3 Aug 2001 03:55:38 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PIY00.0C8; Fri, 27 Jul 2001 20:04:10 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id HAA25429; Wed, 25 Jul 2001 07:45:55 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26043 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25391 for ; Wed, 25 Jul 2001 06:31:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07271; Wed, 25 Jul 2001 06:31:33 -0400 (EDT) Message-Id: <200107251031.GAA07271@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-05.txt Date: Wed, 25 Jul 2001 06:31:33 -0400 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-05.txt Pages : 124 Date : 24-Jul-01 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-05.txt 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-05.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-05.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: <20010724132027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132027.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Sat Aug 4 17:55:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01464 for ; Sat, 4 Aug 2001 17:55:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74LW8c26786 for ietf-calendar-bks; Sat, 4 Aug 2001 14:32:08 -0700 (PDT) Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74LW4s26782 for ; Sat, 4 Aug 2001 14:32:05 -0700 (PDT) Received: from metaacer ([212.151.232.50]) by fep01-svc.swip.net with ESMTP id <20010804213147.DOWD18391.fep01-svc.swip.net@metaacer>; Sat, 4 Aug 2001 23:31:47 +0200 From: "Greg FitzPatrick" To: , Cc: Subject: RE: 51st IETF - Calendaring and Scheduling WG (CALSCH) Date: Sat, 4 Aug 2001 23:32:47 +0200 Message-ID: <000401c11d2d$059d1900$32e897d4@metaacer> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C11D3D.C92F10C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C11D3D.C92F10C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am afraid that this date is broken =96 and I unfortunately went for = the 9th rather than the Wednesday when booking my flight =96 I assume now = that Wednesday is the correct variable =96 I hope nobody else has been fooled by this. I still have not gotten a new ticket Wednesday, August 09 at 0900-1130 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Pat Egen Bob Mahoney AGENDA: Agenda Bashing Guide to Internet Calendaring CalConnect Interoperability results - next plans iCalendar Updates Other drafts - SKICAL, CRISP CAP draft Update charter ------=_NextPart_000_0005_01C11D3D.C92F10C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am afraid that this date is broken – = and I unfortunately went for the 9th rather than the Wednesday when booking my flight – I assume now that Wednesday is the correct = variable – I hope nobody else has been fooled by this. I still have not gotten a = new ticket

Wednesday, August 09 at 0900-1130
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIRS: Pat Egen <pregen@egenconsulting.com>
       Bob Mahoney <bobmah@mit.edu>

AGENDA:

Agenda Bashing
Guide to Internet Calendaring
CalConnect Interoperability results - next plans
iCalendar Updates
Other drafts - SKICAL, CRISP
CAP draft
Update charter

------=_NextPart_000_0005_01C11D3D.C92F10C0-- From owner-ietf-calendar@mail.imc.org Mon Aug 6 04:02:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18754 for ; Mon, 6 Aug 2001 04:02:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f767hrv11842 for ietf-calendar-bks; Mon, 6 Aug 2001 00:43:53 -0700 (PDT) Received: from server1.egenconsulting.com (nbppp5-254.gtnetworks.net [216.143.5.254]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f767hos11829 for ; Mon, 6 Aug 2001 00:43:50 -0700 (PDT) To: "Greg FitzPatrick" Cc: ietf-calendar@imc.org, paf@cisco.se Subject: RE: 51st IETF - Calendaring and Scheduling WG (CALSCH) X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: pregen@egenconsulting.com Date: Mon, 6 Aug 2001 03:43:42 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 08/06/2001 03:44:01 AM, Serialize complete at 08/06/2001 03:44:01 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 002A745185256AA0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 002A745185256AA0_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greg, I believe the agenda people posted another copy of this agenda with=20 the correct date. You must not have seen that revised one. Hope you can=20 make it. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Greg FitzPatrick" 08/04/01 05:32 PM =20 To: , cc: Subject: RE: 51st IETF - Calendaring and Scheduling WG (CALS= CH) I am afraid that this date is broken ? and I unfortunately went for the 9th= rather than the Wednesday when booking my flight ? I assume now that=20 Wednesday is the correct variable ? I hope nobody else has been fooled by=20 this. I still have not gotten a new ticket Wednesday, August 09 at 0900-1130 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Pat Egen Bob Mahoney AGENDA: Agenda Bashing Guide to Internet Calendaring CalConnect Interoperability results - next plans iCalendar Updates Other drafts - SKICAL, CRISP CAP draft Update charter --=_alternative 002A745185256AA0_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greg, I believe the agenda people po= sted another copy of this agenda with the correct date.  You must not = have seen that revised one. Hope you can make it.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


"Greg FitzPatrick" <= greg.fitzpatrick@metamatrix.se>

08/04/01 05:32 PM

       
        To: &nbs= p;      <pregen@egenconsulting.com>, <ietf-calendar= @imc.org>
        cc: &nbs= p;      <paf@cisco.se>
        Subject:=        RE: 51st IETF - Calendaring and Scheduling WG (= CALSCH)



I am afraid that this date is broke= n – and I unfortunately went for the 9th rather than the W= ednesday when booking my flight – I assume now that Wednesday is the = correct variable – I hope nobody else has been fooled by this. I stil= l have not gotten a new ticket

Wednesday, August 09 at 0900-1130
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIRS: Pat Egen <pregen@egenconsulting.com>
      Bob Mahoney <bobmah@mit.edu>

AGENDA:

Agenda Bashing
Guide to Internet Calendaring
CalConnect Interoperability results - next plans
iCalendar Updates
Other drafts - SKICAL, CRISP
CAP draft
Update charter

--=_alternative 002A745185256AA0_=-- From owner-ietf-calendar@mail.imc.org Mon Aug 6 05:35:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20379 for ; Mon, 6 Aug 2001 05:35:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f769Mx320688 for ietf-calendar-bks; Mon, 6 Aug 2001 02:22:59 -0700 (PDT) Received: from localhost.localdomain (host217-33-139-196.ietf.ignite.net [217.33.139.196]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f769MvN20684 for ; Mon, 6 Aug 2001 02:22:57 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) (authenticated) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f769Lvi30249 for ; Mon, 6 Aug 2001 05:21:58 -0400 Message-ID: <3B6E61A5.B8702D6B@ecal.com> Date: Mon, 06 Aug 2001 10:21:42 +0100 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: FW: IETF date/time draft in last call References: <000b01c11ad0$bcd6d480$c9f797d4@metaacer> 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 Greg FitzPatrick wrote: > For some reason or other, I have not seen this notice on our list. It's not a problem for us. It uses a different subset of 8601, because they needed to include a GMT offset (not a full timezone spec). -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |The Net was designed to survive nukes, but not| |francis@ecal.com|lawsuits. Wait a minute. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 6 06:44:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21093 for ; Mon, 6 Aug 2001 06:44:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76ASM026625 for ietf-calendar-bks; Mon, 6 Aug 2001 03:28:22 -0700 (PDT) Received: from server1.egenconsulting.com (nbppp5-254.gtnetworks.net [216.143.5.254]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76ASKN26620 for ; Mon, 6 Aug 2001 03:28:20 -0700 (PDT) To: ietf-calendar@imc.org Subject: Monday Night dinner X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: pregen@egenconsulting.com Date: Mon, 6 Aug 2001 06:28:25 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 08/06/2001 06:28:32 AM, Serialize complete at 08/06/2001 06:28:32 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0039886F85256AA0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0039886F85256AA0_= Content-Type: text/plain; charset="us-ascii" For those of the list participants who are with us in London, we will be meeting in the lobby of the Hilton (near the front desk) at 7:00 tonight, Monday, for dinner. See you there. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0039886F85256AA0_= Content-Type: text/html; charset="us-ascii"
For those of the list participants who are with us in London, we will be meeting in the lobby of the Hilton (near the front desk) at 7:00 tonight, Monday, for dinner.  See you there.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0039886F85256AA0_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 7 05:45:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28840 for ; Tue, 7 Aug 2001 05:45:35 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f779BQe22187 for ietf-calendar-bks; Tue, 7 Aug 2001 02:11:26 -0700 (PDT) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f779BLN22183 for ; Tue, 7 Aug 2001 02:11:21 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id FAA13777; Tue, 7 Aug 2001 05:11:17 -0400 (EDT) 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 FAA19715; Tue, 7 Aug 2001 05:11:14 -0400 (EDT) Received: from monalisa (host217-33-137-213.ietf.ignite.net [217.33.137.213]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id FAA15625; Tue, 7 Aug 2001 05:11:11 -0400 (EDT) From: "Paul B. Hill" To: "Steve Mansour" , "John Stracke" Cc: "CalSched IETF" Subject: RE: CAP issue: Fallback/fanout to iTIP Date: Tue, 7 Aug 2001 05:11:11 -0400 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: <3B6642BB.EF563126@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > So... any opinions on whether or not to try to keep fanout in CAP ? > > John? Anybody? > I thought this was proposed in San Diego during hallway conversations and that we had an action item to make the change to the draft and bring the result to the list. My impression is that any of the working groups that are dealing with authorization issues across traditional security boundaries are having a really tough job of approaching consensus, or even nailing down their requirements. Paul From owner-ietf-calendar@mail.imc.org Tue Aug 7 06:22:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29393 for ; Tue, 7 Aug 2001 06:22:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77A8iw24671 for ietf-calendar-bks; Tue, 7 Aug 2001 03:08:44 -0700 (PDT) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77A8hN24667 for ; Tue, 7 Aug 2001 03:08:43 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id GAA18491; Tue, 7 Aug 2001 06:08:40 -0400 (EDT) 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 GAA20139; Tue, 7 Aug 2001 06:08:39 -0400 (EDT) Received: from monalisa (host217-33-137-213.ietf.ignite.net [217.33.137.213]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id GAA17037; Tue, 7 Aug 2001 06:08:38 -0400 (EDT) From: "Paul B. Hill" To: "Steve Mansour" , "George Babics" Cc: "CalSched IETF" Subject: RE: CAP Issue: Decreed VCARs Date: Tue, 7 Aug 2001 06:08:38 -0400 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: <3B6636D7.16EDE1B9@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, There is open discussion about decreed VCARs and in the past there has been discussion about inhereitence rules. E.g. ...How do you know, given a particular VCAR, whether or not it is decreed? Since decreed vcars cannot be overridden, we have to know. For example Today we have VCARs that look something like: BEGIN:VCAR CARID:Users Default Access GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; VALUE="Users Default Access" ;OBJECT=METHOD,VALUE=DELETE,MODIFY END:VCAR Suppose that we add some semantics to a VCAR that specifically address some of the inheritence rules. 1) Allow / Prohibit inheritable permissions to be modified at a lower level. Allow-Override | No-Override 2) Allow / Prohibit inheritable permissions from parent to propagate to this object. Inheritance-On | Inheritance-Off 3) Reset permissions on all child objects and enable propagation of inheritable permissions. Reset-On | Reset-Off So a VCAR that an administrator wants to set on all child objects could be defined as: BEGIN:VCAR CARID:Users Default Access CAR-INHERIT: No-Override GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; VALUE="Users Default Access" ;OBJECT=METHOD,VALUE=DELETE,MODIFY END:VCAR If a user / admin needs to apply a change to all of the child objects then the example would become: BEGIN:VCAR CARID:Users Default Access CAR-INHERIT: No-Override; Reset GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; VALUE="Users Default Access" ;OBJECT=METHOD,VALUE=DELETE,MODIFY END:VCAR If an admin or user wants to set a default but wants to enable others with sufficient rights to modify child objects then a VACR could be defined as: BEGIN:VCAR CARID:Users Default Access CAR-INHERIT: Allow-Override GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; VALUE="Users Default Access" ;OBJECT=METHOD,VALUE=DELETE,MODIFY END:VCAR If the CAR-INHERIT property is not specified the default behavior would be Allow-Override and Inheritance-On. From owner-ietf-calendar@mail.imc.org Tue Aug 7 12:52:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08211 for ; Tue, 7 Aug 2001 12:52:25 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f77GPvn04254 for ietf-calendar-bks; Tue, 7 Aug 2001 09:25:57 -0700 (PDT) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77GPuN04250 for ; Tue, 7 Aug 2001 09:25:56 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA07909; Tue, 7 Aug 2001 12:25:57 -0400 (EDT) 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 MAA27137; Tue, 7 Aug 2001 12:25:56 -0400 (EDT) Received: from [217.33.137.30] (host217-33-137-30.ietf.ignite.net [217.33.137.30]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA04128; Tue, 7 Aug 2001 12:25:51 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4FB1B360.201909CA.10749803@netscape.net (Roger D References: <4FB1B360.201909CA.10749803@netscape.net (Roger D Date: Tue, 7 Aug 2001 12:25:38 -0400 To: rogerdox14@netscape.net (Roger D) From: Bob Mahoney Subject: Re: Proposed change to iCal (was RE: Adding more unique identifiers) Cc: ietf-calendar@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think we can safely assert that on this list at least, silence does not equal consensus. I would encourage anyone with an opinion on this question to make themselves heard... -Bob At 9:40 PM -0400 7/25/01, Roger D wrote: >Did anyone have any opinion on the changes I proposed to iCalendar >to add unique identifiers to those components that don't have them, >and to those properties that can occur more than once in a >component? I haven't seen any feedback on them; the 2 week >discussion period is drawing to an end, and I'm not sure whether to >interpret silence as concensus or as no-one wanting to take the time >to shoot them down? > >As currently written, though using them is optional, they do have >implementation consequences for all implementors, since even if a >calendar system does not choose to add UIDs or PUIDs to things that >don't have them in RFC 2445, it MUST store and return them if >replying to a request which contained them. Are people happy with >this extra requirement? > >--Roger > > >__________________________________________________________________ >Your favorite stores, helpful shopping tools and great gift ideas. >Experience the convenience of buying online with Shop@Netscape! >http://shopnow.netscape.com/ > >Get your own FREE, personal Netscape Mail account today at >http://webmail.netscape.com/ From owner-ietf-calendar@mail.imc.org Tue Aug 7 12:52:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08241 for ; Tue, 7 Aug 2001 12:52:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77GFmu03942 for ietf-calendar-bks; Tue, 7 Aug 2001 09:15:48 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77GFlN03938 for ; Tue, 7 Aug 2001 09:15:47 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f77GFgZ20435 for ; Tue, 7 Aug 2001 09:15:42 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GHPH6600.3Z1; Tue, 7 Aug 2001 09:15:42 -0700 Message-ID: <3B7013BD.D82B747A@netscape.com> Date: Tue, 07 Aug 2001 09:13:49 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Paul B. Hill" CC: George Babics , CalSched IETF Subject: Re: CAP Issue: Decreed VCARs References: Content-Type: multipart/mixed; boundary="------------45096EC4A752225EA14BC817" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------45096EC4A752225EA14BC817 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul, This looks much more palatable. Can you explain Reset on/off a little more. I don't quite follow it. -Steve "Paul B. Hill" wrote: > Hi, > > There is open discussion about decreed VCARs and in the past there has been > discussion about inhereitence rules. > > E.g. ...How do you know, given a particular VCAR, whether or not it is > decreed? Since > decreed vcars cannot be overridden, we have to know. For example > > Today we have VCARs that look something like: > > BEGIN:VCAR > CARID:Users Default Access > GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* > DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; > VALUE="Users Default Access" > ;OBJECT=METHOD,VALUE=DELETE,MODIFY > END:VCAR > > Suppose that we add some semantics to a VCAR that specifically address some > of the inheritence rules. > > 1) Allow / Prohibit inheritable permissions to be modified at a lower level. > > Allow-Override | No-Override > > 2) Allow / Prohibit inheritable permissions from parent to propagate to this > object. > > Inheritance-On | Inheritance-Off > > 3) Reset permissions on all child objects and enable propagation of > inheritable permissions. > > Reset-On | Reset-Off > > So a VCAR that an administrator wants to set on all child objects could be > defined as: > > BEGIN:VCAR > CARID:Users Default Access > CAR-INHERIT: No-Override > GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* > DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; > VALUE="Users Default Access" > ;OBJECT=METHOD,VALUE=DELETE,MODIFY > END:VCAR > > If a user / admin needs to apply a change to all of the child objects then > the example would become: > > BEGIN:VCAR > CARID:Users Default Access > CAR-INHERIT: No-Override; Reset > GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* > DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; > VALUE="Users Default Access" > ;OBJECT=METHOD,VALUE=DELETE,MODIFY > END:VCAR > > If an admin or user wants to set a default but wants to enable others with > sufficient rights to modify child objects then a VACR could be defined as: > > BEGIN:VCAR > CARID:Users Default Access > CAR-INHERIT: Allow-Override > GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* > DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; > VALUE="Users Default Access" > ;OBJECT=METHOD,VALUE=DELETE,MODIFY > END:VCAR > > If the CAR-INHERIT property is not specified the default behavior would be > Allow-Override and Inheritance-On. --------------45096EC4A752225EA14BC817 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------45096EC4A752225EA14BC817-- From owner-ietf-calendar@mail.imc.org Tue Aug 7 17:52:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13034 for ; Tue, 7 Aug 2001 17:52:52 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77LWC811485 for ietf-calendar-bks; Tue, 7 Aug 2001 14:32:12 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f77LWBN11481 for ; Tue, 7 Aug 2001 14:32:11 -0700 (PDT) Received: (qmail 181052 invoked from network); 7 Aug 2001 21:27:49 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 7 Aug 2001 21:27:49 -0000 Message-ID: <3B705C1D.2411C460@kasey.umkc.edu> Date: Tue, 07 Aug 2001 16:22:37 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Paul B. Hill" CC: Steve Mansour , George Babics , CalSched IETF Subject: Re: CAP Issue: Decreed VCARs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > > Hi, > > There is open discussion about decreed VCARs and in the past there has been > discussion about inhereitence rules. > > E.g. ...How do you know, given a particular VCAR, whether or not it is > decreed? Since > decreed vcars cannot be overridden, we have to know. Isn't it an implementation detail? If it can't be overridden, that could be reflected in the error message you get when you try to override one? But CAP doesn't have a good way to request additional VCARs anyway. -- David Nicol 816.235.1187 free Dmitry Skylarov From owner-ietf-calendar@mail.imc.org Wed Aug 8 04:11:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07872 for ; Wed, 8 Aug 2001 04:11:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f787mNA17686 for ietf-calendar-bks; Wed, 8 Aug 2001 00:48:23 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f787mLN17679 for ; Wed, 8 Aug 2001 00:48:21 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id DAA17099; Wed, 8 Aug 2001 03:48:19 -0400 (EDT) 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 DAA00855; Wed, 8 Aug 2001 03:48:18 -0400 (EDT) Received: from monalisa (host217-33-137-213.ietf.ignite.net [217.33.137.213]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id DAA21504; Wed, 8 Aug 2001 03:48:17 -0400 (EDT) From: "Paul B. Hill" To: "Steve Mansour" Cc: "George Babics" , "CalSched IETF" Subject: RE: CAP Issue: Decreed VCARs Date: Wed, 8 Aug 2001 03:48:17 -0400 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: <3B7013BD.D82B747A@netscape.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This looks much more palatable. Can you explain Reset on/off a little more. I don't quite follow it. OK, "reset" might not be the best term, but the intent is that if the inherited VCAR allows it, reset indicates that inheritence from above should be blocked, and the new permissions are then inherited by subsequent child objects. If the object and child objects already exists and the "reset" is part of a change, then the new permissions will be explicitly applied to the already existing child objects, possibly changing their previously inherited VCARs. Paul From owner-ietf-calendar@mail.imc.org Wed Aug 8 08:11:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10826 for ; Wed, 8 Aug 2001 08:11:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78BvII07239 for ietf-calendar-bks; Wed, 8 Aug 2001 04:57:18 -0700 (PDT) Received: from barrayar.appoint.lan ([216.52.68.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78BvHN07235 for ; Wed, 8 Aug 2001 04:57:17 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by barrayar.appoint.lan (8.9.3/8.9.3) with ESMTP id HAA02351 for ; Wed, 8 Aug 2001 07:56:52 -0400 Message-ID: <3B7128D3.CE783677@ecal.com> Date: Wed, 08 Aug 2001 12:56:03 +0100 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Proposed change to iCal (was RE: Adding more unique identifiers) References: <4FB1B360.201909CA.10749803@netscape.net (Roger D 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 Roger D wrote: > As currently written, though using them is optional, they do have implementation consequences for all implementors, since even if a calendar system does not choose to add UIDs or PUIDs to things that don't have them in RFC 2445, it MUST store and return them if replying to a request which contained them. Are people happy with this extra requirement? No. I have to be conservative about adding new field to my database; and the purpose of these new IDs was not clear to me. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |But this one goes to 11x. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 8 11:42:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15330 for ; Wed, 8 Aug 2001 11:42:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78FNxo17414 for ietf-calendar-bks; Wed, 8 Aug 2001 08:23:59 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FNvN17410 for ; Wed, 8 Aug 2001 08:23:57 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f78FNqZ27359 for ; Wed, 8 Aug 2001 08:23:52 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GHR9FS00.A06; Wed, 8 Aug 2001 08:23:52 -0700 Message-ID: <3B715915.7376B967@netscape.com> Date: Wed, 08 Aug 2001 08:21:57 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Paul B. Hill" CC: George Babics , CalSched IETF Subject: Re: CAP Issue: Decreed VCARs References: Content-Type: multipart/mixed; boundary="------------86822F711C8A4F3C223098B0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------86822F711C8A4F3C223098B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit sman wrote: > This looks much more palatable. Can you explain Reset on/off a little more. > I don't quite follow it. "Paul B. Hill" wrote: > OK, "reset" might not be the best term, but the intent is that if the > inherited VCAR allows it, reset indicates that inheritence from above should > be blocked, OK, that makes sense in terms of the functionality you're trying to achieve. It provides a mechanism to keep you from being "surprised" when you move an object from one area of the hierarchy to another. > and the new permissions are then inherited by subsequent child > objects. Do you mean that subsequent child objects have all permissions denied except those granted by the current vcar? What happens if we encounter multiple vcars, all of which have the same OBJECT in their GRANT property and all of which indicate "reset" ? > If the object and child objects already exists and the "reset" is > part of a change, then the new permissions will be explicitly applied to the > already existing child objects, possibly changing their previously inherited > VCARs. So, it would be a process of recursing downward and resetting all vcars for objects "beneath" the OBJECT targeted ? -Steve --------------86822F711C8A4F3C223098B0 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------86822F711C8A4F3C223098B0-- From owner-ietf-calendar@mail.imc.org Wed Aug 8 11:42:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15341 for ; Wed, 8 Aug 2001 11:42:39 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f78FTZC17555 for ietf-calendar-bks; Wed, 8 Aug 2001 08:29:35 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FTXN17543 for ; Wed, 8 Aug 2001 08:29:33 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA11897; Wed, 8 Aug 2001 11:29:26 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA09284; Wed, 8 Aug 2001 11:29:26 -0400 (EDT) Received: from monalisa (host217-33-137-213.ietf.ignite.net [217.33.137.213]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id LAA27968; Wed, 8 Aug 2001 11:29:25 -0400 (EDT) From: "Paul B. Hill" To: "Steve Mansour" Cc: "George Babics" , "CalSched IETF" Subject: RE: CAP Issue: Decreed VCARs Date: Wed, 8 Aug 2001 11:29:24 -0400 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: <3B715915.7376B967@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >...Do you mean that subsequent child objects have all permissions denied except those granted by the current vcar? What happens if we encounter multiple vcars, all of which have the same OBJECT in their GRANT property and all of which indicate "reset" ? Good catch. I was modeling this after a system that assumes everything is granted unless specifically denied. The opposite of the current CAP model. Needs some further thought. >> If the object and child objects already exists and the "reset" is > part of a change, then the new permissions will be explicitly applied to the > already existing child objects, possibly changing their previously inherited > VCARs. >So, it would be a process of recursing downward and resetting all vcars for objects "beneath" the OBJECT targeted ? Yes. From owner-ietf-calendar@mail.imc.org Wed Aug 8 12:51:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17006 for ; Wed, 8 Aug 2001 12:51:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78GawW23153 for ietf-calendar-bks; Wed, 8 Aug 2001 09:36:58 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78GavN23149 for ; Wed, 8 Aug 2001 09:36:57 -0700 (PDT) To: ietf-calendar@imc.org Subject: Applogies... MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_08062001 August 06, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Wed, 8 Aug 2001 12:40:04 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 08/08/2001 12:49:23 PM, Serialize complete at 08/08/2001 12:49:23 PM Content-Type: multipart/alternative; boundary="=_alternative 005B190E85256AA2_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B190E85256AA2_= Content-Type: text/plain; charset="US-ASCII" It seems that there is a mail gateway / directory problem at my site thats caused nearly all of the recent WG traffic to reject back to IMC. I thought it odd I was not seeing anything and I checked w/Paul who reported lots of "User not found in directory" kinds of errors. The folks here are "working on it" still and I hope to get traffic flowing again. Ill be trying to use the WG archives to catch up on the issues Ive missed last week and this... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005B190E85256AA2_= Content-Type: text/html; charset="US-ASCII"
It seems that there is a mail gateway / directory problem at my site thats caused nearly all of the recent WG traffic to reject back to IMC.  I thought it odd I was not seeing anything and I checked w/Paul who reported lots of "User not found in directory" kinds of errors.  The folks here are "working on it" still and I hope to get traffic flowing again.

Ill be trying to use the WG archives to catch up on the issues Ive missed last week and this...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005B190E85256AA2_=-- From owner-ietf-calendar@mail.imc.org Wed Aug 8 14:10:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18542 for ; Wed, 8 Aug 2001 14:10:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78HrQM24695 for ietf-calendar-bks; Wed, 8 Aug 2001 10:53:26 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HrON24691 for ; Wed, 8 Aug 2001 10:53:24 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA07117; Wed, 8 Aug 2001 13:53:24 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id NAA06664; Wed, 8 Aug 2001 13:53:24 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> Date: Wed, 8 Aug 2001 13:53:23 -0400 (EDT) To: ietf-calendar@imc.org Cc: jdrosen@dynamicsoft.com, hgs@cs.columbia.edu Subject: CPL: Summary of what it is X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm not in London at the IETF, but I've heard reports from those who are. Apparently there was some discussion of the CPL issue there, and I've been asked to do several things. The first of these was to give a brief summary of what CPL is, and why iCalendar should care about it, for newcomers or those who've lost track of the discussion. CPL is the Call Processing Language. It is a simple language for representing telephone call handling. It allows a user to specify how their calls should be handled, in an intelligent, extensible way. This includes things like controlling who's allowed to call you, what time they're allowed to call you, which of your several locations should be alerted for any given call, and so forth. The language is designed to be run in large IP telephony servers. Customers are trusted to specify the handling of their own calls, but aren't necessarily trusted not to try to perform hostile or stupid actions which could potentially disable the server. Thus, one of the design goals of the language is that script processing should not force a server to use arbitrary amounts of CPU time, memory, or related issues. One of the conditions which can affect call treatment is by the current time-of-day, day-of-week, and so forth. This is the area where iCalendar becomes relevant to CPL. The consensus was that since the IETF already has a standard for representing repeating events and periods of time (RFC 2445), CPL should re-use that existing work rather than inventing something new. This allows, among other things, call processing scripts to be derived from calendar book entries. However, there is a conflict between this desire to re-use existing technology, and the requirement that script processing not impose unlimited processing requirements on a server. In some pathological cases, iCalendar recurring events can describe items that can take very large amounts of processing in order to resolve correctly. I summarized these issues before, about two weeks ago, in a message to this list. It's archived at the address . This message lists the specific details of the problems, and my proposed solutions. I hope this clears up the current situation. I'd really like to reach closure on this issue very soon. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Aug 8 14:23:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18749 for ; Wed, 8 Aug 2001 14:23:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78I9rl24957 for ietf-calendar-bks; Wed, 8 Aug 2001 11:09:53 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78I9pN24952 for ; Wed, 8 Aug 2001 11:09:51 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA08271; Wed, 8 Aug 2001 14:09:53 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id OAA06716; Wed, 8 Aug 2001 14:09:53 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15217.32880.573586.997300@grandcentral.cs.columbia.edu> Date: Wed, 8 Aug 2001 14:09:52 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, hgs@cs.columbia.edu Subject: Re: BYSETPOS: Fresh start In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, July 27 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, ietf-calendar@imc.org" saying: > Ok, Im totally overwhelmed by the backlog of WG traffic that I filed away > so Im going to take a fresh start at this BYSETPOS concept again to see if > I can summarize the latest thoughts on it. Here are my takes on how > things stand with BYSETPOS based on emails and phone calls. I'm sorry I haven't responded to this earlier. I had been waiting to see if you had any respone to my other "RECAP and status" message , but this might have been after your mail started bouncing. I'll try to comment on the issues you mention from CPL's point of view. > 1: BYSETPOS is only of real use when the data set from the recurrence rule > has a variable amount of data (ie: "All the Thursdays in the Month") For > ALL other cases the recurrence rule can easily be rewritten to just select > those desired data points. So I would agree that some prose in the > updated draft could reflect this and possibly even mandate that BYSETPOS > is only used for rules that generate variable sets of data. That is to > say, in a FREQ=WEEKLY;BYDAY=MO,WE,FR rule that a BYSETPOS=2 on that should > just cause the rule to be simplified down to FREQ=WEEKLY;BYDAY=WE. > > As far as we've seen so far, the only rule that will generate a variable > length data set is the FREQ=MONTHLY;BYDAY=[MO,TU,WE,TH,FR,SA,SU] so this > should not be that great an impact going forwards. Anyone know of other > cases? A number of the FREQ=YEARLY cases can do this. Any case can do it in the presence of DST transitions, but those are corner cases. There's also the "The 30th of the month, if it exists, otherwise the last day of the month" case someone mentioned here -- FREQ=MONTHLY;BYMONTHDAY=28,29,30;BYSETPOS=-1. There are other ways to do this, but they're less concise. As a general philosophical issue, though, I don't know if it's a good idea to be imposing arbitrary constraints upon the RECUR language without good reasons. FREQ=WEEKLY;BYDAY=MO,WE,FR;BYSETPOS=2 doesn't actually *hurt* anything, after all. It's not hard to process; it's just mildly ugly. Imposing aesthetic constraints on a data representation language feels like a slippery slope to me. (I also note that it isn't necessarily the same thing as FREQ=WEEKLY;BYDAY=WE; this depends on what day of the week DTSTART falls on.) > 2: The concern about ~31M data points is orthogonal to the BYSETPOS issue > since all the BYxxx subcomponents on a FREQ=DAILY rule w/o a BYSETPOS can > generate that large data set size. As such it is unclear to me (at this > late hour at least) why they are considered llinked. In the CPL case -- and for other cases, such as "show me all the occurences of this rule that happen this week" -- you don't normally have to expand out the whole data set. You can be much more efficient by just expanding those occurences you actually need to expand. However, once BYSETPOS enters the picture, you really *do* have to expand the whole set, in order to count out the set positions. > 3: iTIP / iCalendar define the use of REQUEST-STATUS properties to back > application level statuses like "Grammar too complex", "Unsupported RRULE > subcomponent", etc. Why cant this same kind of mechanism be reused in CPL > when a rule uses a BYSETPOS or generates a data set too large for O(1) > evaluation? It can. CPL already assumes a mechanism that allows servers to complain about errors in a submitted CPL script. However, I think that, for interoperability, the definition of "too complex" ought to be formally defined, so clients can know what they can reasonably expect to be allowed to generate. I don't think such a formal definition would be terribly hard to write. I already have an outline of such a definition in my "Recap and status" message. > 4: Much of the bitter back and forth seems to focus on very extreme cases > (ie: "bombing" CS/CPL servers) rather than on the 'normal' usages that the > vast majority of installations will deal with on a regular basis. Sure we > have to deal with some DOS or other maliscious kinds of activity at > various levels of design bug I suspect that these fringe cases have > distracted us from the real technical work. This could be, certainly. As long as we have *some* way to deal with it (such as "go away"), and as long as legitimate cases don't get mis-identified as malicious, I'm inclined to let this slide to a "watch out for this, and do something reasonable" statement in a Security Considerations section. > So how about we refocus on the items above or if I left any off that we > put them on the plate anew and try to get on the same page. I talked w/Tom > (Robert) today before dinner and he seemed to think that we were all in > basic agreement about how recurrence grammars get expanded. If this is > not quite accurate then Im willing to try and restart that again too. It sounds fine to me. If you could take a look at my other message as well, that'd be great... -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Aug 8 18:07:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22444 for ; Wed, 8 Aug 2001 18:07:35 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f78LkHd17729 for ietf-calendar-bks; Wed, 8 Aug 2001 14:46:17 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f78LkGN17680 for ; Wed, 8 Aug 2001 14:46:16 -0700 (PDT) Received: (qmail 197877 invoked from network); 8 Aug 2001 21:41:53 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 8 Aug 2001 21:41:53 -0000 Message-ID: <3B71B0E3.AE124F36@kasey.umkc.edu> Date: Wed, 08 Aug 2001 16:36:35 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" CC: ietf-calendar@imc.org Subject: Re: Additional RECAP and status of CPL RECUR Issues. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > The concept of a "simple" list of the other occurrences of an event - > while seemingly simple - gets really really ugly fast if you have to deal > with any of the following - events that recur "forever" (the Monday morning > conference call); In the paper and ink, squeaky-file-cabinet world, you rarely have more than 12 months of paper calendar. Even in extended situations, events are maintained by users or user agents, who might, for instance, take an hour in September to pencil all the monday morning conference calls into next year's paper calendar. That's where the division traditionally has been between CS and CUA -- the CS only looks so far ahead, and the calendar user notes the recurring events as far into the future as the CS supports. The situation immediately deuglifies if you allow the user software to be responsible for the events that recur forever. specifying 52 events takes less bandwidth than this letter. Bandwidth has traditionally kept up with processing power: unless we're dealing with an expensive link, conserving it is questionable. > events that are LOCAL and REOCCURRING - thus the "time" of > each reoccurrence might be dependant on a user's timezone settings (and > further complicated by Daylight savings shifts that result in the possible > case of events "reoccurring" on a non-existent time; Events with a large > reoccurrence set - for a simple example an entry on a calendar intended to > define my "work days" for the year - could be entered easily as an event > that reoccurs from 9-5pm Mon-Fri having a set of exceptions mapped to my > client's holidays - even bound to one year - this event could have a simple > RRULE w/10 Exceptions - or if enumerated will over 200+ dates in a list - > probably increasing the size considerably. A complex compliant CS could take the 200 dates in either compact or expanded form, a simple one would insist that they be pre-expanded. I hope my suggestion did not sound like I was suggesting that recurrence rules should be eschewed -- merely switched from MUST to SHOULD status (not sure where they are now) -- so a CS that did not implement them could still be compliant. > Two - on the related concept of removing RRULES to a degree from RFC2445 - I > think this is a GOOD idea - my suggestion would be to define the RRULES in a > SEPARATE standards track - one that is very much tied to RFC2445 (but no > solely defined therein) - this allows the RRULES to be applied in a clean > fashion to other programs requiring Temporal Reoccurrences (such as > Caches) - without adding the scheduling/meeting infrastructure and overhead > of iCalendar. Another obvious but necessary example might be a rewrite of Vixie cron. -- David Nicol 816.235.1187 free Dmitry Skylarov From owner-ietf-calendar@mail.imc.org Wed Aug 8 18:38:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23116 for ; Wed, 8 Aug 2001 18:38:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78MMUQ21604 for ietf-calendar-bks; Wed, 8 Aug 2001 15:22:30 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78MMSN21600 for ; Wed, 8 Aug 2001 15:22:28 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id RAA03880; Wed, 8 Aug 2001 17:07:59 -0500 From: "Shannon J. Clark" To: "David L. Nicol" Cc: Subject: RE: Additional RECAP and status of CPL RECUR Issues. Date: Wed, 8 Aug 2001 17:08:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B71B0E3.AE124F36@kasey.umkc.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree that CUA could do this - HOWEVER it "feels" highly non-conducive to interoperability and very much prone to information drop-offs. For example - if a CUA is designed to keep things accurate for the next 12 months - or ANY arbitrary period - then requests just OUTSIDE of this window will be dealt with in an INACCURATE manner. That is - if the CS is working just by storing an expanded list - without reference to an RRULE set as well, then it has no means of knowing that an event is "going to" be set for a given time in the future - in a paper world this is perhaps less critical since you rarely are dealing with events into the future - but consider how networked calendaring systems could reshape how things are planned and organized: Simple example - wouldn't it be quite powerful if when planning a conference for example - (a year or two out perhaps) - the planner could "publish" the event and receive back feedback from the many potential speaker's calendar servers - perhaps indicating commitments a year or two out. Now extend this to include the schedules of all of the following: media, members of the organization (and their corporation's schedules), and sponsors - such a system could potentially allow for better attendance and more productive events. To accomplish this (which could easily involve the exchange of many messages across many different implementations of iCalendar/CAP based calendar servers it is probably vital that all involved have the ability to present as accurate as possible a view of the ARBITRARY future - that is that when queried for FREE/BUSY information or when processing a published event the CS can reliably deal with a non-bound point in the future. Any system that is dependant on the CUA for "keeping it up to date" is one that CAN NOT meet these requirements - a list of 52 events and a "promise" to add additional events on some fixed interval is NOT the same as the CS store having the information required to "know" that the event reoccurs forever - this requires that the CS has some means of "knowing" that at any point in the future - should that point intersect with the repetition pattern of a particular event that event will occur on that date. This does require some computation on the part of the CS - at some point - one option that is not ideal but probably acceptable even in the complex model I described above is to extend repetitions out past the boundaries that a CS will function on (for example many Unix based systems might choose not to deal with ANYTHING after 2037 due to Unix time stamp y2037 issues... in this case there is a cutoff - but the whole system does not function - which is probably cleaner than returning invalid information (i.e. a NO INFORMATION POSSIBLE/OUT of BOUNDS message is more meaningful than a message saying "NO CONFLICTS" but returning "CONFLICTS" when queried a bit later. Also, there is a further issue of precedence and order of operations - in this type of scenario say that reasonably enough you want to have certain behavior should you be scheduled for two events at the same time - this could be as simple as the order to display the events or as drastic as an automated rule to send a "not attending" message on events that arrive in conflict. Should a system with reoccurrences maintained by a CUA give precedence to the event vs. a new conflicting event? How would this work? When the second conflicting event arrives the time in question might be empty of conflict - since the CUA could have not yet caught up to that point in time - then when the CUA does attempt to "catch up" should the conflict trigger conflict related behaviors? Should it trigger a message back to the second conflicting event's organizer saying "sorry - can't come?" This is one of the types of problems I thought electronic calendaring and scheduling systems were designed to solve - to get us all out of the problem of "forgetting" that something that is always reoccurring would be reoccurring at a particular point of time in the future - whether it is the Monday morning conference call that always happens, or the options expiration day etc - the point is that calendaring and scheduling systems are intended to get users away from conflicting messages about a given future event - by allowing for the future to be partially mapped out! Shannon -----Original Message----- From: RFC850 host name inserted by qmail-smtpd [mailto:david@nicol6.umkc.edu]On Behalf Of David L. Nicol Sent: Wednesday, August 08, 2001 4:37 PM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: Re: Additional RECAP and status of CPL RECUR Issues. "Shannon J. Clark" wrote: > The concept of a "simple" list of the other occurrences of an event - > while seemingly simple - gets really really ugly fast if you have to deal > with any of the following - events that recur "forever" (the Monday morning > conference call); In the paper and ink, squeaky-file-cabinet world, you rarely have more than 12 months of paper calendar. Even in extended situations, events are maintained by users or user agents, who might, for instance, take an hour in September to pencil all the monday morning conference calls into next year's paper calendar. That's where the division traditionally has been between CS and CUA -- the CS only looks so far ahead, and the calendar user notes the recurring events as far into the future as the CS supports. The situation immediately deuglifies if you allow the user software to be responsible for the events that recur forever. specifying 52 events takes less bandwidth than this letter. Bandwidth has traditionally kept up with processing power: unless we're dealing with an expensive link, conserving it is questionable. > events that are LOCAL and REOCCURRING - thus the "time" of > each reoccurrence might be dependant on a user's timezone settings (and > further complicated by Daylight savings shifts that result in the possible > case of events "reoccurring" on a non-existent time; Events with a large > reoccurrence set - for a simple example an entry on a calendar intended to > define my "work days" for the year - could be entered easily as an event > that reoccurs from 9-5pm Mon-Fri having a set of exceptions mapped to my > client's holidays - even bound to one year - this event could have a simple > RRULE w/10 Exceptions - or if enumerated will over 200+ dates in a list - > probably increasing the size considerably. A complex compliant CS could take the 200 dates in either compact or expanded form, a simple one would insist that they be pre-expanded. I hope my suggestion did not sound like I was suggesting that recurrence rules should be eschewed -- merely switched from MUST to SHOULD status (not sure where they are now) -- so a CS that did not implement them could still be compliant. > Two - on the related concept of removing RRULES to a degree from RFC2445 - I > think this is a GOOD idea - my suggestion would be to define the RRULES in a > SEPARATE standards track - one that is very much tied to RFC2445 (but no > solely defined therein) - this allows the RRULES to be applied in a clean > fashion to other programs requiring Temporal Reoccurrences (such as > Caches) - without adding the scheduling/meeting infrastructure and overhead > of iCalendar. Another obvious but necessary example might be a rewrite of Vixie cron. -- David Nicol 816.235.1187 free Dmitry Skylarov From owner-ietf-calendar@mail.imc.org Wed Aug 8 18:54:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23254 for ; Wed, 8 Aug 2001 18:54:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78MkNl24100 for ietf-calendar-bks; Wed, 8 Aug 2001 15:46:23 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f78MkMN24096 for ; Wed, 8 Aug 2001 15:46:22 -0700 (PDT) Received: (qmail 198644 invoked from network); 8 Aug 2001 22:42:00 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 8 Aug 2001 22:42:00 -0000 Message-ID: <3B71BEF9.C1A7BBF@kasey.umkc.edu> Date: Wed, 08 Aug 2001 17:36:41 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" CC: ietf-calendar@imc.org Subject: Re: Additional RECAP and status of CPL RECUR Issues. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > Simple example - wouldn't it be quite powerful if when planning a > conference for example - (a year or two out perhaps) - the planner could > "publish" the event and receive back feedback from the many potential > speaker's calendar servers - perhaps indicating commitments a year or two > out. How about, the CUA tracks the end point that a CS is promising to maintain information until, perhaps this is even part of the CS's greeting: Hello, I'm calendar.umkc.edu, maintaining dates until Mon 2011-Aug-08 and the CUA expands the RRULES it is tracking, as the date recedes? > . Any system that > is dependant on the CUA for "keeping it up to date" is one that CAN NOT meet > these requirements - a list of 52 events and a "promise" to add additional > events on some fixed interval is NOT the same as the CS store having the > information required to "know" that the event reoccurs forever Standards should be inclusive. I think there's a standard that says that. > This does require some computation on the part of the CS - at some point - > one option that is not ideal but probably acceptable even in the complex > model I described above is to extend repetitions out past the boundaries > that a CS will function on (for example many Unix based systems might choose > not to deal with ANYTHING after 2037 due to Unix time stamp y2037 issues... > in this case there is a cutoff - but the whole system does not function - > which is probably cleaner than returning invalid information (i.e. a NO > INFORMATION POSSIBLE/OUT of BOUNDS message is more meaningful than a message > saying "NO CONFLICTS" but returning "CONFLICTS" when queried a bit later. Agreed. Does the current draft contain an error code for this situation? > Also, there is a further issue of precedence and order of operations - in > this type of scenario say that reasonably enough you want to have certain > behavior should you be scheduled for two events at the same time - this > could be as simple as the order to display the events or as drastic as an > automated rule to send a "not attending" message on events that arrive in > conflict. This sounds like an implementation detail, dealt with by a good calendar interoperability standard at best by providing a channel for implementation-specific settings. Currently the draft says that extensions may not ship. That sounds to me like a rule that is set up to be broken. > Should a system with reoccurrences maintained by a CUA give precedence to > the event vs. a new conflicting event? How would this work? When the second > conflicting event arrives the time in question might be empty of conflict - > since the CUA could have not yet caught up to that point in time - then when > the CUA does attempt to "catch up" should the conflict trigger conflict > related behaviors? Should it trigger a message back to the second > conflicting event's organizer saying "sorry - can't come?" These make sense as implementation and user preference issues, not part of a standard. > This is one of the types of problems I thought electronic calendaring and > scheduling systems were designed to solve - to get us all out of the problem > of "forgetting" that something that is always reoccurring would be > reoccurring at a particular point of time in the future - whether it is the > Monday morning conference call that always happens, or the options > expiration day etc - the point is that calendaring and scheduling systems > are intended to get users away from conflicting messages about a given > future event - by allowing for the future to be partially mapped out! > Shannon The desire to have your servants plan your day is certainly understandable, but I'd rather have mine present me with a menu of options and play my priorities by my mood of the moment. Prioritization of events feels like it belongs in the UA not the S; and if so programmed, having the UA preprocess all the events and set your availability makes more sense to me than insisting that only one style of personal organization is supported by a standard. Standards are supposed to be inclusive. -- David Nicol 816.235.1187 "Tomato!" From owner-ietf-calendar@mail.imc.org Thu Aug 9 04:35:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17460 for ; Thu, 9 Aug 2001 04:35:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f798JS224515 for ietf-calendar-bks; Thu, 9 Aug 2001 01:19:28 -0700 (PDT) Received: from barrayar.appoint.lan ([216.52.68.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f798JQN24510 for ; Thu, 9 Aug 2001 01:19:26 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by barrayar.appoint.lan (8.9.3/8.9.3) with ESMTP id EAA06185; Thu, 9 Aug 2001 04:18:25 -0400 Message-ID: <3B72471F.6E76AE92@ecal.com> Date: Thu, 09 Aug 2001 09:17:36 +0100 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: Jonathan Lennox CC: ietf-calendar@imc.org, jdrosen@dynamicsoft.com, hgs@cs.columbia.edu Subject: Re: CPL: Summary of what it is References: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> 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 Jonathan Lennox wrote: > Thus, one of the design goals of the > language is that script processing should not force a server to use > arbitrary amounts of CPU time, memory, or related issues. Something that came up in the meeting: what about disk space? This arises from the idea of expanding the first, say, 90 days' worth of instances, and then rerunning the expansion every 90 days. In theory, someone could have a recurrence rule that would expand to up to, er, 7,776,000 instances; but that can be detected easily when the rule is submitted. Basically, this changes the expensive resource consumed from CPU time (which is hard to measure in advance) to disk space (which is easy--just give the users a disk quota). -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"If there's anything The Flintstones have taught| |francis@ecal.com|us, it's that pelicans can be used to mix | | |cement." -- Homer Simpson | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 9 04:59:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17956 for ; Thu, 9 Aug 2001 04:59:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f798jos26772 for ietf-calendar-bks; Thu, 9 Aug 2001 01:45:50 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f798jnN26766 for ; Thu, 9 Aug 2001 01:45:49 -0700 (PDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id EAA11851; Thu, 9 Aug 2001 04:45:48 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id EAA10283; Thu, 9 Aug 2001 04:45:46 -0400 (EDT) Message-ID: <3B7278DE.3DF35481@cs.columbia.edu> Date: Thu, 09 Aug 2001 04:49:50 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: CPL: Summary of what it is References: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> <3B72471F.6E76AE92@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm not sure if you're saying that complexity in CPU doesn't matter with pre-expansion or if disk space is another, additional concern. In any event, pre-expansion is done by the same CPU as the checking, so I don't see the advantage of pre-expansion. (In all likelihood, big servers will keep all scripts/calsch in main memory, given that we're talking about acceptable processing delays on the order of 1-10 ms.) In either case, you have the problem that submitting a CPL script or calsch becomes a crapshoot. Depending on the server, it will sometimes work and sometimes not, possibly depending on how many rules you have. Note that unlike regular calendaring, it is quite likely that the CPL script changes frequently, so that precomputation may not necessarily be most efficient, since there may not be any uses of the information until the next update. John Stracke wrote: > > Jonathan Lennox wrote: > > > Thus, one of the design goals of the > > language is that script processing should not force a server to use > > arbitrary amounts of CPU time, memory, or related issues. > > Something that came up in the meeting: what about disk space? This arises from > the idea of expanding the first, say, 90 days' worth of instances, and then > rerunning the expansion every 90 days. In theory, someone could have a > recurrence rule that would expand to up to, er, 7,776,000 instances; but that > can be detected easily when the rule is submitted. > > Basically, this changes the expensive resource consumed from CPU time (which is > hard to measure in advance) to disk space (which is easy--just give the users a > disk quota). > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |"If there's anything The Flintstones have taught| > |francis@ecal.com|us, it's that pelicans can be used to mix | > | |cement." -- Homer Simpson | > \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 9 05:48:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19314 for ; Thu, 9 Aug 2001 05:48:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f799VCG01001 for ietf-calendar-bks; Thu, 9 Aug 2001 02:31:12 -0700 (PDT) Received: from barrayar.appoint.lan ([216.52.68.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f799VBN00993 for ; Thu, 9 Aug 2001 02:31:11 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by barrayar.appoint.lan (8.9.3/8.9.3) with ESMTP id FAA06319; Thu, 9 Aug 2001 05:30:35 -0400 Message-ID: <3B72580A.30938F98@ecal.com> Date: Thu, 09 Aug 2001 10:29:46 +0100 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: CPL: Summary of what it is References: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> <3B72471F.6E76AE92@ecal.com> <3B7278DE.3DF35481@cs.columbia.edu> 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 Henning Schulzrinne wrote: > I'm not sure if you're saying that complexity in CPU doesn't matter with > pre-expansion or if disk space is another, additional concern. In any > event, pre-expansion is done by the same CPU as the checking, See, I was assuming that that wouldn't be the case; that the expansion would be done by a separate CPU, outside the fast path, like with IP routers that do BGP in a CPU and then have ASICs to use the resulting data. Even if it's on the same CPU, it can be done at a lower priority. > so I don't > see the advantage of pre-expansion. (In all likelihood, big servers will > keep all scripts/calsch in main memory, given that we're talking about > acceptable processing delays on the order of 1-10 ms.) Um. How big are we talking about? A thousand users? A million users? > In either case, > you have the problem that submitting a CPL script or calsch becomes a > crapshoot. Depending on the server, it will sometimes work and sometimes > not, possibly depending on how many rules you have. Yes, but, with the pre-expansion route, you can tell people what their budget is, and how much they've used up; people understand budgeting. > Note that unlike > regular calendaring, it is quite likely that the CPL script changes > frequently, Really? Why? Do you expect users to be changing their rules hourly? > so that precomputation may not necessarily be most > efficient, since there may not be any uses of the information until the > next update. I'm not talking about precomputing the whole thing, just expanding the recurrence rules. The result would be that you'd have a database of on-recurring events; searching that database would be faster than applying the recurrence rules on the fly. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Speak softly and carry an Illudium Q-32 | |francis@ecal.com|Explosive Space Disintegrator. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 9 06:02:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19651 for ; Thu, 9 Aug 2001 06:02:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f799mb402293 for ietf-calendar-bks; Thu, 9 Aug 2001 02:48:37 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f799mVN02287 for ; Thu, 9 Aug 2001 02:48:31 -0700 (PDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id FAA15746; Thu, 9 Aug 2001 05:48:30 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id FAA10518; Thu, 9 Aug 2001 05:48:29 -0400 (EDT) Message-ID: <3B728790.4775E0DC@cs.columbia.edu> Date: Thu, 09 Aug 2001 05:52:32 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: Henning Schulzrinne , Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: CPL: Summary of what it is References: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> <3B72471F.6E76AE92@ecal.com> <3B7278DE.3DF35481@cs.columbia.edu> <3B72580A.30938F98@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > Henning Schulzrinne wrote: > > > I'm not sure if you're saying that complexity in CPU doesn't matter with > > pre-expansion or if disk space is another, additional concern. In any > > event, pre-expansion is done by the same CPU as the checking, > > See, I was assuming that that wouldn't be the case; that the expansion would be done > by a separate CPU, outside the fast path, like with IP routers that do BGP in a CPU > and then have ASICs to use the resulting data. There is no ASIC that can process calsch data; this is not lookup (like packet processing), but rather real processing. > > Even if it's on the same CPU, it can be done at a lower priority. Doesn't help, as load bursts are sufficiently long to not leave additional capacity. It is not helpful if my update of logic doesn't show up for five minutes - yields very strange failure scenarios. > > > so I don't > > see the advantage of pre-expansion. (In all likelihood, big servers will > > keep all scripts/calsch in main memory, given that we're talking about > > > acceptable processing delays on the order of 1-10 ms.) > > Um. How big are we talking about? A thousand users? A million users? Thousands to millions. A typical mobile switching center can easily support a million users. > > > In either case, > > you have the problem that submitting a CPL script or calsch becomes a > > crapshoot. Depending on the server, it will sometimes work and sometimes > > not, possibly depending on how many rules you have. > > Yes, but, with the pre-expansion route, you can tell people what their budget is, > and how much they've used up; people understand budgeting. Each new script is a complete one, so all you get is failure or success, except that I have no way to predict in advance whether a script will fail or not. > > > Note that unlike > > regular calendaring, it is quite likely that the CPL script changes > > frequently, > > Really? Why? Do you expect users to be changing their rules hourly? Yes, not all or even most of them, but since these are generated automatically, this is not implausible. > > > so that precomputation may not necessarily be most > > efficient, since there may not be any uses of the information until the > > next update. > > I'm not talking about precomputing the whole thing, just expanding the recurrence > rules. The result would be that you'd have a database of on-recurring events; > searching that database would be faster than applying the recurrence rules on the > fly. What matters is the total computation of expansion + lookup. If you do a small number of lookups for each expansion (as is probably typical), you don't save much, even ignoring the storage space issue. Thus, this may help in some circumstances, but not others. I do agree that, if we can't agree on reasonable restrictions of rule expansion, precomputation is about the only viable route, so that errors can be generated when the calendaring information is submitted. I suspect what will happen is that instead of expanding and then discovering that the rule expands to 37 million entries, of which the 36,995,457th is needed, servers will apply the same rules we've been talking about to reject "suspicious" BYSETPOS. From owner-ietf-calendar@mail.imc.org Thu Aug 9 06:24:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20134 for ; Thu, 9 Aug 2001 06:24:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79ABPG02717 for ietf-calendar-bks; Thu, 9 Aug 2001 03:11:25 -0700 (PDT) Received: from barrayar.appoint.lan ([216.52.68.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79ABNN02713 for ; Thu, 9 Aug 2001 03:11:23 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by barrayar.appoint.lan (8.9.3/8.9.3) with ESMTP id GAA06390; Thu, 9 Aug 2001 06:10:48 -0400 Message-ID: <3B726177.DC608B0A@ecal.com> Date: Thu, 09 Aug 2001 11:09:59 +0100 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: CPL: Summary of what it is References: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> <3B72471F.6E76AE92@ecal.com> <3B7278DE.3DF35481@cs.columbia.edu> <3B72580A.30938F98@ecal.com> <3B728790.4775E0DC@cs.columbia.edu> 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 Henning Schulzrinne wrote: > John Stracke wrote: > > > > Henning Schulzrinne wrote: > > See, I was assuming that that wouldn't be the case; that the expansion would be done > > by a separate CPU, outside the fast path, like with IP routers that do BGP in a CPU > > and then have ASICs to use the resulting data. > > There is no ASIC that can process calsch data; this is not lookup (like > packet processing), but rather real processing. I didn't say it had to be an ASIC; it could be a separate full-power CPU. > > Even if it's on the same CPU, it can be done at a lower priority. > > Doesn't help, as load bursts are sufficiently long to not leave > additional capacity. It is not helpful if my update of logic doesn't > show up for five minutes - yields very strange failure scenarios. OK, good point. > > Um. How big are we talking about? A thousand users? A million users? > > Thousands to millions. A typical mobile switching center can easily > support a million users. Hmm. A million users, 10 ms response time...how many calls per second? How many rules per user? I'm thinking that, if you precompute 90 days (or whatever) at a time, putting the rules onto disk, and then load today's rules off the disk at midnight, you need only enough RAM to hold today's rules. But I need some numbers to know what that'll cost. > > Yes, but, with the pre-expansion route, you can tell people what their budget is, > > and how much they've used up; people understand budgeting. > > Each new script is a complete one, So I can't update individual rules separately? OK, that makes precomputation harder. (Mind you, it seems to me that it'll also make a lot of other things harder; I can't add someone to my ruleset without downloading the whole thing, modifying it, and sending it back up again--in which case you need locking to prevent lost-write problems.) > > Really? Why? Do you expect users to be changing their rules hourly? > > Yes, not all or even most of them, but since these are generated > automatically, this is not implausible. See, I was assuming that the rules could be updated independently, in which case you wouldn't have to precompute the ones that didn't change. As a side note, if you're expecting agents to generate the rules automatically, then independent updates become more important, since someone may have multiple agents. > > I'm not talking about precomputing the whole thing, just expanding the recurrence > > rules. The result would be that you'd have a database of on-recurring events; > > searching that database would be faster than applying the recurrence rules on the > > fly. > > What matters is the total computation of expansion + lookup. If you do a > small number of lookups for each expansion (as is probably typical), you > don't save much, even ignoring the storage space issue. If you can do incremental precomputation, then each precomputation gets amortized over a much larger set of lookups. In addition, using the database approach means that you can spread the computation work across different systems: the CPUs in set A expand the rules and write to the database; those in set B read from the database (N hours of data at a time) and apply the rules. Of course, when a rule comes in that changes the contents of the next N hours, the rules need to be propagated into set B's RAM. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This sentance has threee errors. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 9 07:57:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21423 for ; Thu, 9 Aug 2001 07:57:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79BgH606721 for ietf-calendar-bks; Thu, 9 Aug 2001 04:42:17 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79BgGN06716 for ; Thu, 9 Aug 2001 04:42:16 -0700 (PDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id HAA21861; Thu, 9 Aug 2001 07:42:15 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id HAA10788; Thu, 9 Aug 2001 07:42:14 -0400 (EDT) Message-ID: <3B72A23A.154D68A2@cs.columbia.edu> Date: Thu, 09 Aug 2001 07:46:18 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: Henning Schulzrinne , Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: CPL: Summary of what it is References: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> <3B72471F.6E76AE92@ecal.com> <3B7278DE.3DF35481@cs.columbia.edu> <3B72580A.30938F98@ecal.com> <3B728790.4775E0DC@cs.columbia.edu> <3B726177.DC608B0A@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I didn't say it had to be an ASIC; it could be a separate full-power CPU. Sure; with sufficient thrust, anything will fly... > Hmm. A million users, 10 ms response time...how many calls per second? How many rules > per user? > > I'm thinking that, if you precompute 90 days (or whatever) at a time, putting the rules > onto disk, and then load today's rules off the disk at midnight, you need only enough RAM > to hold today's rules. But I need some numbers to know what that'll cost. About 100 calls/second seems a typical number for a single host (Netra-class), take or leave a factor of two or three. I don't have a good idea as to the number of rules, as that depends on the model: for example, the client could upload only the rules that match the day plus recurrences or dump the whole calendar, past, present and future. If you figure five events a day for a typical user (I suspect that others have much better guesses here) and two years, you get about 3000 events/person. Multiply by user count as appropriate. > > > > Yes, but, with the pre-expansion route, you can tell people what their budget is, > > > and how much they've used up; people understand budgeting. > > > > Each new script is a complete one, > > So I can't update individual rules separately? OK, that makes precomputation > harder. (Mind you, it seems to me that it'll also make a lot of other things harder; I > can't add someone to my ruleset without downloading the whole thing, modifying it, and > sending it back up again--in which case you need locking to prevent lost-write problems.) There actually is a versioning mechanism that deals with some of this, but that's probably out of scope of this discussion. > > As a side note, if you're expecting agents to generate the rules automatically, then > independent updates become more important, since someone may have multiple agents. Definitely. From owner-ietf-calendar@mail.imc.org Thu Aug 9 09:19:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22835 for ; Thu, 9 Aug 2001 09:19:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79D1Zi15594 for ietf-calendar-bks; Thu, 9 Aug 2001 06:01:35 -0700 (PDT) Received: from barrayar.appoint.lan ([216.52.68.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79D1UN15589 for ; Thu, 9 Aug 2001 06:01:30 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by barrayar.appoint.lan (8.9.3/8.9.3) with ESMTP id JAA06801; Thu, 9 Aug 2001 09:00:55 -0400 Message-ID: <3B728954.123C7290@ecal.com> Date: Thu, 09 Aug 2001 14:00:05 +0100 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: CPL: Summary of what it is References: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> <3B72471F.6E76AE92@ecal.com> <3B7278DE.3DF35481@cs.columbia.edu> <3B72580A.30938F98@ecal.com> <3B728790.4775E0DC@cs.columbia.edu> <3B726177.DC608B0A@ecal.com> <3B72A23A.154D68A2@cs.columbia.edu> 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 Henning Schulzrinne wrote: > If you > figure five events a day for a typical user (I suspect that others have > much better guesses here) 5/day is probably a little high, but not much; let's take it as accurate. > and two years, you get about 3000 > events/person. OK, now assume each event takes about 50 bytes (that's probably a little high--it's assuming each date-time is stored as an iCalendar string, so that start&end take 30 bytes). So storing all those in RAM will take 150K/person, or about 150G for a million users. Obviously too high. However, I did not suggest storing two years' worth of events at a time; I suggested 90 days on disk and one day in memory. One day's worth of data for one million users would then be 5 million events; at 50 bytes apiece, that's 250M. 250M of RAM costs about $50. Meanwhile, 90 days on disk would take about 22.5G--something like $100. Obviously, RAM and storage costs are not a serious limitation here. (I realize that the costs will be higher for the kind of reliable hardware that telcos need; but even a factor of 5 only comes to $750.) > > As a side note, if you're expecting agents to generate the rules automatically, then > > independent updates become more important, since someone may have multiple agents. > > Definitely. Actually, I've just realized that having a monolithic ruleset doesn't imply that precalculation has to be done from scratch, *provided* the individual rules carry sequence numbers (as in iCalendar). Then the server can compare the old and new rules and preserve the events whose sequence numbers haven't changed. How about it? Does CPL have sequence numbers? If not, would you be willing to add them? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |But this one goes to 11x. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 9 10:36:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25414 for ; Thu, 9 Aug 2001 10:36:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79EI6J17350 for ietf-calendar-bks; Thu, 9 Aug 2001 07:18:06 -0700 (PDT) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79EI4N17346 for ; Thu, 9 Aug 2001 07:18:04 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA20191 for ; Thu, 9 Aug 2001 10:18:05 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA09114 for ; Thu, 9 Aug 2001 10:18:04 -0400 (EDT) Received: from monalisa (host217-33-137-213.ietf.ignite.net [217.33.137.213]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id KAA08141 for ; Thu, 9 Aug 2001 10:18:03 -0400 (EDT) From: "Paul B. Hill" To: Subject: UTF-8 considerations Date: Thu, 9 Aug 2001 10:18:03 -0400 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 V5.50.4522.1200 In-Reply-To: <3B728954.123C7290@ecal.com> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, We are urged to read draft-ietf-idn-idna, Internationalizing Host Names In Applications (IDNA), which is coming out the idn (Internationalized Domain Name) working group in the Internet Area. If we allow UTF-8 for the UPN or other identifiers that we might want to query on we will have some real problems. UTF-8 introduces problems when trying to perform matching, or sorting. Paul From owner-ietf-calendar@mail.imc.org Thu Aug 9 11:56:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28332 for ; Thu, 9 Aug 2001 11:56:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79Fcjt22590 for ietf-calendar-bks; Thu, 9 Aug 2001 08:38:45 -0700 (PDT) Received: from barrayar.appoint.lan ([216.52.68.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FciN22583 for ; Thu, 9 Aug 2001 08:38:44 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by barrayar.appoint.lan (8.9.3/8.9.3) with ESMTP id LAA07761 for ; Thu, 9 Aug 2001 11:38:40 -0400 Message-ID: <3B72AE4F.A7320893@ecal.com> Date: Thu, 09 Aug 2001 16:37:51 +0100 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: UTF-8 considerations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > If we allow UTF-8 for the UPN or other identifiers that we might want to > query on we will have some real problems. UTF-8 introduces problems when > trying to perform matching, or sorting. I think it's not so much that it introduces problems; it's that it, on its own, does nothing to solve the problems that exist. A quick overview of the problems (based on what I remember from sitting in on IDN in Pittsburgh): when you search for a string, users usually don't want to do an exact bitwise match. Some things they may want to ignore: * In a language using the Roman alphabet: case, accents. * In Hebrew: vowels. Vowels, in Hebrew, are not considered letters; they are small decorations added to consonants. They are often omitted when writing quickly--for example, when entering a search string. (Come to think of it, this may be closely analogous to accents in Roman-alphabet languages.) * In Chinese: distinction between different encoding systems. Chinese computer users have the Traditional system and the Simplified system; in Unicode, the Simplified characters are a proper subset of the Traditional characters; a Simplified character may represent different Traditional characters in different contexts. So, if someone enters an event with Traditional text, and then someone else enters a Simplified search string (or vice versa), then the server needs to map the Traditional string into Simplified before looking for a match. I'm sure there are other subtleties, too. Now, UPNs probably don't have quite the same problems (they're not human text; they're computer identifiers, and need to match exactly); but it does pose a problem for queries against the CS. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"We can't duplicate the bug." "Have you tried| |francis@ecal.com|the Xerox machine?" | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 9 12:02:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28623 for ; Thu, 9 Aug 2001 12:02:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79FqRt24675 for ietf-calendar-bks; Thu, 9 Aug 2001 08:52:27 -0700 (PDT) Received: from smtp7.andrew.cmu.edu (SMTP7.ANDREW.CMU.EDU [128.2.10.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FqPN24668 for ; Thu, 9 Aug 2001 08:52:25 -0700 (PDT) Received: from mail3.andrew.cmu.edu (MAIL3.ANDREW.CMU.EDU [128.2.10.133]) (user=leg mech=KERBEROS_V4 (56 bits)) by smtp7.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f79FqFtn019004; Thu, 9 Aug 2001 11:52:15 -0400 Date: Thu, 9 Aug 2001 11:52:15 -0400 Message-Id: <200108091552.f79FqFtn019004@smtp7.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-calendar@imc.org In-reply-to: <3B72AE4F.A7320893@ecal.com> Subject: Re: UTF-8 considerations References: <3B72AE4F.A7320893@ecal.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: Thu, 09 Aug 2001 16:37:51 +0100 From: John Stracke "Paul B. Hill" wrote: > If we allow UTF-8 for the UPN or other identifiers that we might want to > query on we will have some real problems. UTF-8 introduces problems when > trying to perform matching, or sorting. I think it's not so much that it introduces problems; it's that it, on its own, does nothing to solve the problems that exist. One thing to strongly consider is use of the ACAP (now also used in Sieve) comparator registry, which was created to help solve these problems. We don't want to tackle these problems protocol by protocol. It would be nice if people who feel strongly about these issues would create new comparators for use. Larry From owner-ietf-calendar@mail.imc.org Thu Aug 9 12:24:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29383 for ; Thu, 9 Aug 2001 12:24:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79G6Pl26099 for ietf-calendar-bks; Thu, 9 Aug 2001 09:06:25 -0700 (PDT) Received: from barrayar.appoint.lan ([216.52.68.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79G6ON26095 for ; Thu, 9 Aug 2001 09:06:24 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by barrayar.appoint.lan (8.9.3/8.9.3) with ESMTP id MAA07840 for ; Thu, 9 Aug 2001 12:06:20 -0400 Message-ID: <3B72B4CB.FC5FA7EE@ecal.com> Date: Thu, 09 Aug 2001 17:05:31 +0100 From: John Stracke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: UTF-8 considerations References: <3B72AE4F.A7320893@ecal.com> <200108091552.f79FqFtn019004@smtp7.andrew.cmu.edu> 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 Lawrence Greenfield wrote: > One thing to strongly consider is use of the ACAP (now also used in > Sieve) comparator registry, which was created to help solve these > problems. We don't want to tackle these problems protocol by > protocol. No argument there. Do you have a URL, or an RFC number? I think we may have it easier than IDN, which had to consider these problems in an existing protocol with no room for, say, specifying which comparator to use. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"A dog will eat pretty much anything; one major | |francis@ecal.com|reason why there are no restaurants for dogs is | | |that the customers would eat the menus." -- Dave| | |Barry | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 9 18:26:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06653 for ; Thu, 9 Aug 2001 18:26:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79MDLS04045 for ietf-calendar-bks; Thu, 9 Aug 2001 15:13:21 -0700 (PDT) Received: from smtp5.andrew.cmu.edu (SMTP5.ANDREW.CMU.EDU [128.2.10.85]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79MDJN04040 for ; Thu, 9 Aug 2001 15:13:20 -0700 (PDT) Received: from mail3.andrew.cmu.edu (MAIL3.ANDREW.CMU.EDU [128.2.10.133]) (user=leg mech=KERBEROS_V4 (56 bits)) by smtp5.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f79MDKgZ017525; Thu, 9 Aug 2001 18:13:20 -0400 Date: Thu, 9 Aug 2001 18:13:20 -0400 Message-Id: <200108092213.f79MDKgZ017525@smtp5.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-calendar@imc.org In-reply-to: <3B72B4CB.FC5FA7EE@ecal.com> Subject: Re: UTF-8 considerations References: <3B72AE4F.A7320893@ecal.com> <200108091552.f79FqFtn019004@smtp7.andrew.cmu.edu> <3B72B4CB.FC5FA7EE@ecal.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: Thu, 09 Aug 2001 17:05:31 +0100 From: John Stracke Lawrence Greenfield wrote: > One thing to strongly consider is use of the ACAP (now also used in > Sieve) comparator registry, which was created to help solve these > problems. We don't want to tackle these problems protocol by > protocol. No argument there. Do you have a URL, or an RFC number? The ACAP RFC is 2244. Comparators are discussed in section 3.4. A future specification should probably specify a comparator based on Unicode Technical Recommendation #10 as another baseline comparator that will work for UTF-8 and probably include it as a must implement. Larry From owner-ietf-calendar@mail.imc.org Fri Aug 10 18:30:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12594 for ; Fri, 10 Aug 2001 18:30:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7AM4Df25438 for ietf-calendar-bks; Fri, 10 Aug 2001 15:04:13 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7AM4BN25434 for ; Fri, 10 Aug 2001 15:04:11 -0700 (PDT) Received: (qmail 219084 invoked from network); 10 Aug 2001 21:59:46 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 10 Aug 2001 21:59:46 -0000 Message-ID: <3B74580E.FC581E88@kasey.umkc.edu> Date: Fri, 10 Aug 2001 16:54:22 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: Henning Schulzrinne , Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: CPL: Summary of what it is References: <15217.31891.466421.595763@grandcentral.cs.columbia.edu> <3B72471F.6E76AE92@ecal.com> <3B7278DE.3DF35481@cs.columbia.edu> <3B72580A.30938F98@ecal.com> <3B728790.4775E0DC@cs.columbia.edu> <3B726177.DC608B0A@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > In addition, using the database approach means that you can > spread the computation work Please delete now if you don't want to get yelled at. How or what ever, these discussions are off topic! A standard is an inclusive minimum! The preferability of different implementation options is off topic! Provide support for multiple methods (such as error messages on recurrance expression complexity) and let the CS implementors decide how they want to do it! -- David Nicol 816.235.1187 From owner-ietf-calendar@mail.imc.org Mon Aug 13 01:32:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28635 for ; Mon, 13 Aug 2001 01:32:39 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7D5DEX07298 for ietf-calendar-bks; Sun, 12 Aug 2001 22:13:14 -0700 (PDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7D5DCN07294 for ; Sun, 12 Aug 2001 22:13:12 -0700 (PDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7D54sxX005204; Mon, 13 Aug 2001 01:04:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 01:05:33 -0400 Message-ID: From: Jonathan Rosenberg To: "'David L. Nicol'" , John Stracke Cc: Henning Schulzrinne , Jonathan Lennox , ietf-calendar@imc.org, Jonathan Rosenberg Subject: RE: CPL: Summary of what it is Date: Mon, 13 Aug 2001 01:05:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: David L. Nicol [mailto:david@kasey.umkc.edu] > Sent: Friday, August 10, 2001 5:54 PM > To: John Stracke > Cc: Henning Schulzrinne; Jonathan Lennox; ietf-calendar@imc.org; > jdrosen@dynamicsoft.com > Subject: Re: CPL: Summary of what it is > > > John Stracke wrote: > > > > In addition, using the database approach means that you can > > spread the computation work > > Please delete now if you don't want to get yelled at. > > > How or what ever, these discussions are off topic! A standard > is an inclusive minimum! The preferability of different > implementation options is off topic! Provide support for multiple > methods (such as error messages on recurrance expression complexity) > and let the CS implementors decide how they want to do it! I agree. This thread was really starting to get me nervous. Requiring an implementation to be built in a certain way in order to deal with a problem within a specification itself seems to be a mistake. If computation about whether the current time fits within a recurrence cannot be done in a reasonable time bound, then that is the problem that needs to be fixed. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From owner-ietf-calendar@mail.imc.org Mon Aug 13 08:44:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17735 for ; Mon, 13 Aug 2001 08:44:35 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7DCTvW18135 for ietf-calendar-bks; Mon, 13 Aug 2001 05:29:57 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DCTuN18131 for ; Mon, 13 Aug 2001 05:29:56 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA29111; Mon, 13 Aug 2001 08:29:56 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA15685; Mon, 13 Aug 2001 08:29:53 -0400 (EDT) Received: from [66.92.67.186] (airport.bobmah.com [66.92.67.186]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA03559; Mon, 13 Aug 2001 08:29:52 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 13 Aug 2001 08:29:48 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: RE: CPL: Summary of what it is Cc: "'David L. Nicol'" , John Stracke , Henning Schulzrinne , Jonathan Lennox , Jonathan Rosenberg Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: CALSCH Folks- I think the questions about the assumptions underlying CPL were useful in allowing us to better understand the background of the problem. But it would be best if we return to the question of whether we can accommodate the changes that have been requested in our work. -Bob From owner-ietf-calendar@mail.imc.org Mon Aug 13 14:15:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26476 for ; Mon, 13 Aug 2001 14:15:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DI3BZ03285 for ietf-calendar-bks; Mon, 13 Aug 2001 11:03:11 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DI3AN03281 for ; Mon, 13 Aug 2001 11:03:10 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7DI5G616840 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Mon, 13 Aug 2001 14:05:17 -0400 Message-ID: <3B7816DC.3020309@ecal.com> Date: Mon, 13 Aug 2001 14:05:16 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: Henning Schulzrinne , Jonathan Lennox , ietf-calendar@imc.org Subject: Re: CPL: Summary of what it is 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 Jonathan Rosenberg wrote: >Requiring an >implementation to be built in a certain way in order to deal with a problem >within a specification itself seems to be a mistake. If computation about >whether the current time fits within a recurrence cannot be done in a >reasonable time bound, then that is the problem that needs to be fixed. > But that statement already makes assumptions about implementation and about the spec: you are assuming a priori that the spec is broken and the implementation is correct. I have pointed out that you can solve the problem by changing the implementation instead, trading storage (which is cheap) for CPU (which is expensive). If I'm wrong, and such an implementation is not feasible, then say so. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Diplomacy: The art of letting someone else have| |francis@ecal.com|your way | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 13 16:45:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28413 for ; Mon, 13 Aug 2001 16:45:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DKTk106568 for ietf-calendar-bks; Mon, 13 Aug 2001 13:29:46 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DKTjN06564 for ; Mon, 13 Aug 2001 13:29:45 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA25444; Mon, 13 Aug 2001 16:29:45 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id QAA04699; Mon, 13 Aug 2001 16:29:45 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15224.14519.873017.655947@grandcentral.cs.columbia.edu> Date: Mon, 13 Aug 2001 16:29:43 -0400 (EDT) To: John Stracke Cc: Jonathan Rosenberg , Henning Schulzrinne , ietf-calendar@imc.org Subject: Re: CPL: Summary of what it is In-Reply-To: <3B7816DC.3020309@ecal.com> References: <3B7816DC.3020309@ecal.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, August 13 2001, "John Stracke" wrote to "Jonathan Rosenberg, Henning Schulzrinne, Jonathan Lennox, ietf-calendar@imc.org" saying: > > Jonathan Rosenberg wrote: > > >Requiring an > >implementation to be built in a certain way in order to deal with a problem > >within a specification itself seems to be a mistake. If computation about > >whether the current time fits within a recurrence cannot be done in a > >reasonable time bound, then that is the problem that needs to be fixed. > > > But that statement already makes assumptions about implementation and > about the spec: you are assuming a priori that the spec is broken and > the implementation is correct. I have pointed out that you can solve > the problem by changing the implementation instead, trading storage > (which is cheap) for CPU (which is expensive). This transformation -- turning the computationally-complex representation into the computationally-cheap one -- is *itself* computationally expensive, of course. If the assumption is that access to recurrence information happens often, and modifications to it happen only rarely, this is a valid optimization. But this isn't true for all usage scenarios. (It's also not true for the "prevent hostile or stupid users launching DoS attacks" case. What if some software bug causes someone's script to be uploaded every five seconds?) Now, admittedly, I've already gone a little ways down this path, for the COUNT -> UNTIL transformation. This is why, in my "defined SHOULD-strength limits" proposal, COUNT values are one of the things that would be bounded. Do you strongly object to the "SHOULD-strength limits" proposal, where we define minimal implementation limits for RECUR interoperability? It seems to me like it'd solve everyone's concerns quite easily, but for some reason there's been a lot of silence about it, and a moderate amount of complaint, for reasons I don't really understand. (This isn't to say that the storage-for-CPU implementation choice isn't a reasonable one. But I don't think it solves the problem I'm trying to address.) -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Aug 13 16:52:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28524 for ; Mon, 13 Aug 2001 16:52:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DKhgO06842 for ietf-calendar-bks; Mon, 13 Aug 2001 13:43:42 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DKhfN06838 for ; Mon, 13 Aug 2001 13:43:41 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7DKjm617274 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Mon, 13 Aug 2001 16:45:49 -0400 Message-ID: <3B783C7C.5080006@ecal.com> Date: Mon, 13 Aug 2001 16:45:48 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Lennox CC: Jonathan Rosenberg , Henning Schulzrinne , ietf-calendar@imc.org Subject: Re: CPL: Summary of what it is References: <3B7816DC.3020309@ecal.com> <15224.14519.873017.655947@grandcentral.cs.columbia.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 Jonathan Lennox wrote: >On Monday, August 13 2001, "John Stracke" wrote to "Jonathan Rosenberg, Henning Schulzrinne, Jonathan Lennox, ietf-calendar@imc.org" saying: > >>Jonathan Rosenberg wrote: >> >>>Requiring an >>>implementation to be built in a certain way in order to deal with a problem >>>within a specification itself seems to be a mistake. If computation about >>>whether the current time fits within a recurrence cannot be done in a >>>reasonable time bound, then that is the problem that needs to be fixed. >>> >>But that statement already makes assumptions about implementation and >>about the spec: you are assuming a priori that the spec is broken and >>the implementation is correct. I have pointed out that you can solve >>the problem by changing the implementation instead, trading storage >>(which is cheap) for CPU (which is expensive). >> > >This transformation -- turning the computationally-complex representation >into the computationally-cheap one -- is *itself* computationally expensive, >of course. > Yeah, but it's not done on the critical path in call processing. >Do you strongly object to the "SHOULD-strength limits" proposal, where we >define minimal implementation limits for RECUR interoperability? > I think I do. The problem I have with it is that I believe it'll actually hurt interop. Most of the time, when you create an iCalendar object, you have no idea what the recipient's CUA will be able to handle. This means that a properly cautious CUA will stick to the minimal subset. A CUA that uses anything outside the minimal subset will be taking the chance that the recipient's CUA will misinterpret the object. For example, if BYSETPOS were outside the minimal subset, and I sent an event to occur on the last Friday of the month, some recipients might see it as every Friday. If we want to define a subset, we should throw out all the features outside the subset. That's my ideal outcome; but I've been getting a lot of pushback from people who want those features. My second choice is to come up with a way you guys can use RECUR as is. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"I said no camels! That's 5 camels! Can't you| |francis@ecal.com|count?" -- Indiana Jones & TLC | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 13 20:10:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00531 for ; Mon, 13 Aug 2001 20:10:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DNxoW12949 for ietf-calendar-bks; Mon, 13 Aug 2001 16:59:50 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7DNxnN12945 for ; Mon, 13 Aug 2001 16:59:49 -0700 (PDT) Received: (qmail 265205 invoked from network); 13 Aug 2001 23:55:20 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 13 Aug 2001 23:55:20 -0000 Message-ID: <3B786791.BE410C6A@kasey.umkc.edu> Date: Mon, 13 Aug 2001 18:49:37 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: Jonathan Lennox , Jonathan Rosenberg , Henning Schulzrinne , ietf-calendar@imc.org Subject: Re: CPL: Summary of what it is References: <3B7816DC.3020309@ecal.com> <15224.14519.873017.655947@grandcentral.cs.columbia.edu> <3B783C7C.5080006@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > >Do you strongly object to the "SHOULD-strength limits" proposal, where we > >define minimal implementation limits for RECUR interoperability? > > > I think I do. The problem I have with it is that I believe it'll > actually hurt interop. Most of the time, when you create an iCalendar > object, you have no idea what the recipient's CUA will be able to > handle. This means that a properly cautious CUA will stick to the > minimal subset. A CUA that uses anything outside the minimal subset > will be taking the chance that the recipient's CUA will misinterpret the > object. For example, if BYSETPOS were outside the minimal subset, and I > sent an event to occur on the last Friday of the month, some recipients > might see it as every Friday. This objection is nonsense. Consider SMTP as a model: SMTP has a robust method of declaring which optional add-ons any given SMTP server can do, and a default minimal behaviour to fall back to when the extension doesn't work quite right. I compose an e-mail and hand it off to my MUA. My MUA contacts the local MTA and negotiates the transfer method and follows through on the negotiated method. CAP follows SMTP in having central servers and user agents. In a world where CSes have different capabilities, I could tell my CUA that I am going to be in my office from nine AM to six PM except 12:30 to 1:30 every weekday except holidays on a list with a well-known name (HOLIDAYS-US-FEDERAL for instance) and the CUA would negotiate with the local CS as to what the best way to upload that to the CS would be: as several thousand indivudual availabity/nonavailability events or as one big expandable expression, and furthermore does the CS know about the list of holidays or does it need to have it listed explicitly. > If we want to define a subset, we should throw out all the features > outside the subset. That's my ideal outcome; but I've been getting a > lot of pushback from people who want those features. My second choice > is to come up with a way you guys can use RECUR as is. A standard is NOT the specifications document for a product. -- David Nicol 816.235.1187 "Tomato!" From owner-ietf-calendar@mail.imc.org Tue Aug 14 14:29:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12395 for ; Tue, 14 Aug 2001 14:29:52 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7EIJ7x23228 for ietf-calendar-bks; Tue, 14 Aug 2001 11:19:07 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EIJ6N23224 for ; Tue, 14 Aug 2001 11:19:06 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA14871 for ; Tue, 14 Aug 2001 14:19:08 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA25100 for ; Tue, 14 Aug 2001 14:19:08 -0400 (EDT) Received: from [66.92.67.186] (WEST-ELEVEN-THREE.MIT.EDU [18.11.0.152]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA23640 for ; Tue, 14 Aug 2001 14:19:07 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 14 Aug 2001 14:19:05 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Re: BEEP Protocol and Internationalization: Interim meeting? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Small typo: >So, would people be open to an interim meeting on the east coast >someplace, in an early October November time frame? I can probably >get space at MIT without difficulty, if that is acceptable. Sorry, the intended date was "early October" -Bob From owner-ietf-calendar@mail.imc.org Tue Aug 14 14:35:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12569 for ; Tue, 14 Aug 2001 14:35:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7EID9j23106 for ietf-calendar-bks; Tue, 14 Aug 2001 11:13:09 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EID8N23102 for ; Tue, 14 Aug 2001 11:13:08 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12744 for ; Tue, 14 Aug 2001 14:13:10 -0400 (EDT) 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 OAA29092 for ; Tue, 14 Aug 2001 14:13:07 -0400 (EDT) Received: from [66.92.67.186] (WEST-ELEVEN-THREE.MIT.EDU [18.11.0.152]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA21498 for ; Tue, 14 Aug 2001 14:13:07 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Tue, 14 Aug 2001 14:13:05 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: BEEP Protocol and Internationalization: Interim meeting? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks- We've been asked to look at two issues by our Area Directors. 1) Internationalization is becoming increasingly high-profile, and it is *not* an optional concern for us. In depth conversations between Patrik and the Kerberos WG indicates there are issues we have yet to deal with. The guess is that we have some work to do for this. 2) Ned attended our meeting in London, and after a detailed reading of the CAP draft, suggested (with reluctance given the late date) that we look closer at the BEEP work. He suggested we consider using BEEP, or perhaps just move some of our overhead down into the "payload", to simplify a future conversion to BEEP. Casual conversations in London indicate that we may be able to deal with this quickly, given the right folks focusing on it for a short time. We asked Patrik and Ned if they would object to an interim meeting to focus on these two points, and they were fine with that. So, would people be open to an interim meeting on the east coast someplace, in an early October November time frame? I can probably get space at MIT without difficulty, if that is acceptable. Please let us know. -Bob Some drafts to read: BEEP Mapping the BEEP Core onto TCP (RFC 3081) http://www.ietf.org/rfc/rfc3081.txt The Blocks Extensible Exchange Protocol Core (RFC 3080) http://www.ietf.org/rfc/rfc3080.txt IDN Internationalizing Host Names In Applications (IDNA) http://search.ietf.org/internet-drafts/draft-ietf-idn-idna-03.txt From owner-ietf-calendar@mail.imc.org Tue Aug 14 15:00:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13056 for ; Tue, 14 Aug 2001 15:00:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7EImfF23829 for ietf-calendar-bks; Tue, 14 Aug 2001 11:48:41 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EImdN23824 for ; Tue, 14 Aug 2001 11:48:39 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7EIou620696 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 14 Aug 2001 14:50:58 -0400 Message-ID: <3B797310.3070107@ecal.com> Date: Tue, 14 Aug 2001 14:50:56 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org CC: Jonathan Lennox , Jonathan Rosenberg , Henning Schulzrinne Subject: Re: CPL: Summary of what it is References: <3B7816DC.3020309@ecal.com> <15224.14519.873017.655947@grandcentral.cs.columbia.edu> <3B783C7C.5080006@ecal.com> <3B786791.BE410C6A@kasey.umkc.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 David L. Nicol wrote: (I've mostly taken to ignoring this guy, because he has no clue, but I'll make an exception in this case.) >John Stracke wrote: > >>The problem I have with it is that I believe it'll >>actually hurt interop. Most of the time, when you create an iCalendar >>object, you have no idea what the recipient's CUA will be able to >>handle. This means that a properly cautious CUA will stick to the >>minimal subset. A CUA that uses anything outside the minimal subset >>will be taking the chance that the recipient's CUA will misinterpret the >>object. For example, if BYSETPOS were outside the minimal subset, and I >>sent an event to occur on the last Friday of the month, some recipients >>might see it as every Friday. >> > > >This objection is nonsense. Consider SMTP as a model: SMTP has a >robust method of declaring which optional add-ons > [...] >CAP follows SMTP > We are *not* talking about CAP. We are talking about iCalendar. In general, there is no backchannel from recipient to sender. If you had actually read what I wrote, you would understand this. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |He wondered if Elli was going to buy that | |francis@ecal.com|explanation. His taste for heavily-armed | | |girlfriends did have its drawbacks. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 14 15:29:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13513 for ; Tue, 14 Aug 2001 15:29:40 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7EJ9gx24338 for ietf-calendar-bks; Tue, 14 Aug 2001 12:09:42 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EJ9fN24334 for ; Tue, 14 Aug 2001 12:09:41 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7EJBx620764 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Tue, 14 Aug 2001 15:12:00 -0400 Message-ID: <3B7977FF.6090400@ecal.com> Date: Tue, 14 Aug 2001 15:11:59 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org CC: Jonathan Lennox , Jonathan Rosenberg , Henning Schulzrinne Subject: Re: CPL: Summary of what it is References: <3B7816DC.3020309@ecal.com> <15224.14519.873017.655947@grandcentral.cs.columbia.edu> <3B783C7C.5080006@ecal.com> <3B786791.BE410C6A@kasey.umkc.edu> <3B797310.3070107@ecal.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 John Stracke wrote: > David L. Nicol wrote: > > (I've mostly taken to ignoring this guy, because he has no clue, but > I'll make an exception in this case.) Oh my god, I meant to delete that. Please excuse me. That was much too insulting; I wrote it while irritated by something else. This is extremely embarassing, especially given that part of the reason I've been skipping David L. Nicol's posts is that he said something I found insulting--to have dropped down to a similar level is mortifying. It is not the case that he has no clue; it's just that I have grown tired of his take on credentials, and felt that he was ignoring the obvious in the one particular post I was replying to. Time to cut back on caffeine again. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |All your problems can be solved by not caring!| |francis@ecal.com| | \===============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 14 15:48:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13813 for ; Tue, 14 Aug 2001 15:48:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7EJbVB25097 for ietf-calendar-bks; Tue, 14 Aug 2001 12:37:31 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7EJbUN25093 for ; Tue, 14 Aug 2001 12:37:30 -0700 (PDT) Received: (qmail 275939 invoked from network); 14 Aug 2001 19:32:59 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 14 Aug 2001 19:32:59 -0000 Message-ID: <3B797B8F.E223EA01@kasey.umkc.edu> Date: Tue, 14 Aug 2001 14:27:11 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org, Jonathan Lennox , Jonathan Rosenberg , Henning Schulzrinne Subject: Re: CPL: Summary of what it is References: <3B7816DC.3020309@ecal.com> <15224.14519.873017.655947@grandcentral.cs.columbia.edu> <3B783C7C.5080006@ecal.com> <3B786791.BE410C6A@kasey.umkc.edu> <3B797310.3070107@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > David L. Nicol wrote: > > (I've mostly taken to ignoring this guy, because he has no clue, but > I'll make an exception in this case.) A masterful paraphrase! -- David Nicol 816.235.1187 "Tomato!" From owner-ietf-calendar@mail.imc.org Tue Aug 14 15:56:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13927 for ; Tue, 14 Aug 2001 15:56:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7EJhts25261 for ietf-calendar-bks; Tue, 14 Aug 2001 12:43:55 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EJhrN25254 for ; Tue, 14 Aug 2001 12:43:53 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA11224 for ; Tue, 14 Aug 2001 14:40:22 -0500 From: "Shannon J. Clark" To: Subject: Question and/or suggestion Date: Tue, 14 Aug 2001 14:43:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B797310.3070107@ecal.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A client recently suggested a "feature" that as far as I know (haven't exhaustively searched the old archives) been addressed. They would like to be able to define an event - which will then be made "open" to a number of people - but with a preset limit. i.e. the event could be published and/or people "invited" - but after some set limit further attendees would not be allowed. Obviously a particular calendar server could implement such a feature by way of an X-param and careful handling of input flow - so my question is as follows: One - is such a feature already part of CAP or iCalendar (but I have overlooked it?) Two - is such a feature a part of any pending proposal - such as SkiCal? - especially with PUBLISHED events ala SkiCal I could see a need for the ability to set an upper limit on attendees for a given event (with implementations being able to control what happens on reaching the limit - perhaps just a message back to the user - or perhaps some other more dynamic action such as generating a new instance of the event in question - though this would then have other concerns... In light of the recent discussions about the differences between iCalendar and CAP etc. I think this type of functionality is yet another example of something that would (could) work one way in a connected mode (CAP, iTip) in a similiar but slightly different manner in a messaging mode (iMIP) but may be highly problematic in a "pure" iCalendar mode (where iCalendar files or other forms may be exchanged but no messaging service exists between clients - for example an iCalendar file available on a website - obviously in that case it would be highly unlikely to be able to handle this type of feature. Also - this raises a question about why PUBLISH events MUST not have attendees - obviously for many PUBLISHED events that makes perfect sense (i.e. a TV Schedule) - but for something like a PUBLISHED class it might not make as much sense. One option might be to force a generation of an invitation - so not a PUBLISHED event but an invited one - but that seems potentially very clunky - especially is you need to "invite" far more people than will in fact ATTEND. (and raises workflow questions about what additional messages need to be exchanged between attendees - a published event is nice in that it may not require that people who plan on attending the event also receive modifications and changes that are changes to the list of who is attending (especially in the current mode where published events can not have attendee lists) I look forward to comments and suggestions, thanks all, Shannon Shannon Clark President, JigZaw Inc www.jigzaw.com shannon@jigzaw.com From owner-ietf-calendar@mail.imc.org Tue Aug 14 21:38:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20163 for ; Tue, 14 Aug 2001 21:38:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7F1RlG03827 for ietf-calendar-bks; Tue, 14 Aug 2001 18:27:47 -0700 (PDT) Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1RjN03823 for ; Tue, 14 Aug 2001 18:27:45 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-d04.mx.aol.com (mail_out_v31_r1.3.) id 3.f1.1d114ae (16234); Tue, 14 Aug 2001 21:27:41 -0400 (EDT) Received: from netscape.net (host-192-125-18-192.iplanet.com [192.18.125.192]) by air-in02.mail.aol.com (v79.27) with ESMTP id MAILININ210-0814212741; Tue, 14 Aug 2001 21:27:41 -0400 Message-ID: <3B79D00E.2000105@netscape.net> Date: Tue, 14 Aug 2001 18:27:42 -0700 From: Roger D User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-GB,en,en-US MIME-Version: 1.0 To: francis@ecal.com, ietf-calendar@imc.org Subject: Re: Proposed change to iCal (was RE: Adding more unique identifiers) References: <4FB1B360.201909CA.10749803@netscape.net (Roger D <3B7128D3.CE783677@ecal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit francis@ecal.com wrote: > Roger D wrote: >>As currently written, though using them is optional, they do have >>implementation consequences for all implementors, since even if a >>calendar system does not choose to add UIDs or PUIDs to things that >>don't have them in RFC 2445, it MUST store and return them if >>replying to a request which contained them. Are people happy with >>this extra requirement? > > No. I have to be conservative about adding new field to my database; How do you store and return unchanged X-PARAMs and X-PROPs? If you don't, I believe you are in breach of the standard; if you do, why can't you just use the same mechanism for storing these? > and the purpose of these new IDs was not clear to me. OK. Here is the basic problem: Suppose a user is organizing a meeting. They have several different CUAs that they are using to make modifications to the meeting (say a desktop machine, a laptop, a PDA, a website or voice interface attached to the calendar server), and possibly one or more other individuals are entitled to make changes on their behalf and are doing so using yet other CUAs. Particularly given that some of these may allow the user to work in offline mode on a cached copy of the data, there is no guarantee that the various changes they make in these CUAs will reach the server in the correct order. We don't just want to bump the sequence number every time anything is changed and discard changes that arrive out of order with a stale sequence number, since that would a) force invitees to re-RSVP to a meeting even if nothing major has changed about it, and b) enforce throwing away what may be perfectly good changes that we could have successfully figured out how to merge. So it is a reasonable aim for a server to attempt to merge changes from coming in from different sources: if e.g. if one change changes the SUMMARY and another changes one of the VALARMs, they can reasonably be merged. (But if both change the description, we are going to have decide which one of them we have overwrite the other, or else involve the user to help use resolve the merge.) However, there is a problem to doing this: currently there are a number of different entities attached to a meeting (e.g. ATTACHments, RESOURCES, VALARMs, CATEGORIES) for which there can be multiple entities of a certain type attached to a meeting (so an individual one is not uniquely identified by the UID of the meeting) and that (unlike an ATTENDEE) do not have an inherent unique identifier. This makes trying to merge changes to these items extremely difficult for the server: if you started with list {a, b} and sent back {c, d}, did you intend to delete a and b and add c and d, or to change a into c and b into d, or to change a into d and b into c, or to delete a, add b, and change c into d, etc.? How should this be merged with another change that started with {a, b} and returned {b} (presumably they just deleted a, but even this is not completely clear). If the objects had a unique identifier this would be resolved, since changing a into b would keep the same unique identifier, while deleting a and adding b would create a new one. Then the merge rule is simple: identify objects by their unique ID, and only if to changes change the same object do you need to worry about resolving the order in which the changes should be applied. A more direct inspiration for us to want to do this is that we are using a format derived from iCal on our internal data bus inside our CUA, and different pieces of the application (the GUI, the connection to the server) could me making unsynchronized changes to details of the same event: we need some way of automatically merging these changes in our data bus, and we can't afford to unnecessarily bump the sequence number, discard changes, or involve the user. Thus, at least internally, we need to add more unique identifiers than the iCal standard has. Since our server and client share codebase, it is thus very tempting to add them in the server too, and to transmit them between the client and server and use them as outlined in the previous paragraph. A general rule of good data structure design is that any item of data should have a unique identifier. Currently iCal breaks that: a) at the component level: a VALARM has no unique identifier, a VTIMEZONE is identified only by its TZID which is not guaranteeably unique, and the STANDARDC and DAYLIGHTC components in a VTIMEZONE are best identified by their DTSTART but again this is not guaranteed to be unique. My proposal was that a UID be allowed as a property of each of these, and that at least for VALARM the standard recommend that one be generated when the VALARM is generated. b) at the property level: ATTACH, CATEGORIES, COMMENT, CONTACT, DAYLIGHTC, EXRULE, FREEBUSY, RSTATUS, RELATED, RESOURCES, RRULE, STANDARDC, TZNAME and X-PROP, and possibly also DESCRIPTION for VJOURNALs (the standard disagrees with itself) can occur multiple times but have no inherent unique identifier (unlike ATTENDEE, and arguably EXDATE and RDATE). My proposal was to add a PUID unique identifier property parameter to these properties to allow them to be uniquely identified. From the lack of response on the list to my previous suggestion, I get the impression that many other people have found some other way of resolving this data merging issue, and I would be interested in know what approach(es) they took. If no one wants these added to the standard, we will just make them X-PROPerties and X-PARAMeters and use them internally in our CUA and server and between our CUA and our server. But that means we can't be smart about merging changes if they come from some other CUA (say one on a PDA). To get full interoperability, they need to be in the standard. Obviously we can have interoperability without everyone adding UIDs and PUIDs that they don't use in their CUA: they can be optional, and if the CUA that the event was first created on didn't add them the server can add them later if it wishes (the reverse, a server not using them but a CUA adding them is more problematic: what if two different CUAs both issue different unique identifiers to the same item?). However, if a CUA that doesn't use them is communicating with a server that does put UIDs on VALARMs, and/or PUIDs on certain properties, it does need to retain them and return them on a changed version of the event, not strip them off and return a changed VEVENT with pieces in it that are no longer uniquely identified, otherwise we are back at square one. --Roger From owner-ietf-calendar@mail.imc.org Wed Aug 15 10:10:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21515 for ; Wed, 15 Aug 2001 10:10:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FDqsE20699 for ietf-calendar-bks; Wed, 15 Aug 2001 06:52:54 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FDqrN20695 for ; Wed, 15 Aug 2001 06:52:53 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7FDtA623521 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 15 Aug 2001 09:55:12 -0400 Message-ID: <3B7A7F3E.4010307@ecal.com> Date: Wed, 15 Aug 2001 09:55:10 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Proposed change to iCal (was RE: Adding more unique identifiers) References: <4FB1B360.201909CA.10749803@netscape.net (Roger D <3B7128D3.CE783677@ecal.com> <3B79D00E.2000105@netscape.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Roger D wrote: > francis@ecal.com wrote: > >> I have to be conservative about adding new field to my database; > > How do you store and return unchanged X-PARAMs and X-PROPs? If you > don't, I believe you are in breach of the standard; What standard? iCalendar is a data format; it is silent about what you do with the data. CAP could attempt to specify that x-params have to come back unchanged; but, at present, it doesn't, because it barely specifies behavior at all. If such behavior is added to a future version of the I-D, I will oppose it, because it would require me to have an open-ended database schema, which would be difficult or impossible to tune for performance. > > and the purpose of these new IDs was not clear to me. > > OK. Here is the basic problem: [...] I dunno; it sounds to me like an edge case. It is a problem, but a solved one (I think): that's what sync engines are for. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"No, no, that's *not* a boat, that's Queen | |francis@ecal.com|Victoria." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 15 10:35:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22431 for ; Wed, 15 Aug 2001 10:35:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FEIf721595 for ietf-calendar-bks; Wed, 15 Aug 2001 07:18:41 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FEIeN21591 for ; Wed, 15 Aug 2001 07:18:40 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA08198; Wed, 15 Aug 2001 10:18:36 -0400 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 f7FEIaf07871; Wed, 15 Aug 2001 10:18:36 -0400 (EDT) Message-Id: <5.1.0.14.0.20010815092552.01f61008@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Aug 2001 10:19:58 -0400 To: Roger D , francis@ecal.com, ietf-calendar@imc.org From: Alan Davies Subject: Re: Proposed change to iCal (was RE: Adding more unique identifiers) In-Reply-To: <3B79D00E.2000105@netscape.net> References: <4FB1B360.201909CA.10749803@netscape.net (Roger D <3B7128D3.CE783677@ecal.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:27 PM 14/08/2001 -0700, Roger D wrote: > [...] e.g. if one change changes the SUMMARY and another changes one of > the VALARMs, they can reasonably be merged. (But if both change the > description, we are going to have decide which one of them we have > overwrite the other, or else involve the user to help use resolve the merge.) > [...] This makes trying to merge changes to these items extremely difficult > for the server: if you started with list {a, b} and sent back {c, d}, did > you intend to delete a and b and add c and d, or to change a into c and b > into d, or to change a into d and b into c, or to delete a, add b, and change > c into d, etc.? How should this be merged with another change that started with > {a, b} and returned {b} (presumably they just deleted a, but even this is not > completely clear). I agree. > If the objects had a unique identifier [...] Then the merge rule is simple: > identify objects by their unique ID, and only if to changes change the same > object do you need to worry about resolving the order in which the changes > should be applied. How would the PUIDs help a CS to solve the problem that you stated and I quoted above, where two CUAs modify the same list? It still doesn't know which combination of b, c and d to keep without user interaction. Can you give an example of a CS correctly performing a merge with a conflict that couldn't have been resolved without PUIDs? A CS also has to rely on both CUAs interpreting this sentence in the same way: "changing a into b would keep the same unique identifier". What exactly does "changing a into b" mean? --Alan From owner-ietf-calendar@mail.imc.org Wed Aug 15 11:43:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24078 for ; Wed, 15 Aug 2001 11:43:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FFM6q24099 for ietf-calendar-bks; Wed, 15 Aug 2001 08:22:06 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FFM5N24094 for ; Wed, 15 Aug 2001 08:22:05 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7FFOM624088 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 15 Aug 2001 11:24:23 -0400 Message-ID: <3B7A9426.9070208@ecal.com> Date: Wed, 15 Aug 2001 11:24:22 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Updated CRISP document Content-Type: multipart/mixed; boundary="------------030403050200060204020005" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------030403050200060204020005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've just submitted an updated CRISP draft (as Pat requested in London); I expect it'll come through in a few days, but here it is anyway. It goes into a little more detail than the -00 version, but, of course, the real purpose is to refresh the draft, since the -00 version has expired. I still don't have a real Security Considerations section; it mentions that it inherits CAP's security analysis, but that it probably needs some examination of its own, especially since the whole point of CRISP is to address security concerns. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Diplomacy: The art of letting someone else have| |francis@ecal.com|your way | \================================================================/ --------------030403050200060204020005 Content-Type: text/plain; name="draft-ietf-calsch-crisp-01.txt" Content-Disposition: inline; filename="draft-ietf-calsch-crisp-01.txt" Content-Transfer-Encoding: 8bit Internet Engineering Task Force J. Stracke INTERNET DRAFT eCal draft-ietf-calsch-crisp-01.txt August 2001 Expires: February 2002 CAP Realtime iTIP-based Scheduling Profile (CRISP) 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu­ ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to francis@ecal.com or to the ietf-calendar@imc.org discussion list (subscription address ietf-calendar-request@imc.org; "SUBSCRIBE" or "UNSUBSCRIBE" in the body). 2. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 3. Abstract This document sets forth a restricted profile of [CAP], one which supports no operations beyond the scheduling functionality of [iTIP]. The motivation is to permit use of CAP's real-time iTIP functionality without exposing the calendar access functionality (which may require stricter security controls than iTIP). Stracke [Page 1] CRISP August 2001 4. Introduction [iTIP] defines a scheduling protocol based on exchanging specially formatted [iCalendar] messages. iTIP is defined to be independent of transport protocol. At present, there is one standard binding of iTIP to a transport protocol, [iMIP], which carries iTIP messages in email. This is a useful base level capability (email can reach vir­ tually any user on the Net), but can involve considerable latencies. A real-time binding for iTIP would be useful; it would permit appli­ cation developers to give users better feedback on the progress of the iTIP operations. Since CAP includes full iTIP functionality, one option would be to permit full access to CAP; to schedule an event with a remote user, one would then make a CAP connection to their CS. The problem is that such a connection may be considered a security risk in some organizations; even though the CS has ACLs to prevent the client from performing non-iTIP operations, it would be better if the client sim­ ply could not attempt such operations. (It's as if mail administra­ tors were told that an SMTP server outside the firewall had to include IMAP functionality as well.) Thus, this document defines CRISP, a profile of CAP, a subset which does not support non-iTIP operations. This document does not specify the relationship between a CRISP server and a (full-powered) CAP server. They may be implemented together, with the CRISP server being nothing more than the CAP server responding in CRISP mode (e.g., based on source IP address); the CRISP server may act as a proxy for the CAP server (see Firewall Application, below); the two servers may feed into the same database, but not know about each other; or there may be no CAP server, only the CRISP server, used for interdomain scheduling, but not for calen­ dar access. Or, of course, there may be other modes of operation. These are implementation details, which do not need to be included in a protocol spec. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that CRISP is a replacement for the former proposal known as iRIP (no reference is available, because the Internet-Draft has long since expired), which was abandoned when it was realized that the functionality of CAP was a superset of the functionality of iRIP. Stracke [Page 2] CRISP August 2001 5. Profile Definition A CRISP server is a CAP server with the following capabilities: * ITIPVERSION=1.0 * CAPVERSION=1.0 * CAR=NONE * QUERYLEVEL=NONE In addition, various AUTH capabilities are expected. Anonymous authentication SHOULD be supported, since the point of CRISP is to permit iTIP communication across security domains. However, other authentication mechanisms may make sense in some cases; for example, if CRISP is being used for scheduling between cooperating companies (that is, in an extranet), then one company's CRISP server might be able to authenticate users from the other company. Other capabilities which apply to iTIP operations MAY be specified; e.g., MAXDATE and MAXICALOBJECTSIZE. Note that NONE is not a legal value for CAR or QUERYLEVEL in the cur­ rent draft of CAP. This will have to be resolved. A CRISP server MUST NOT accept any iCalendar component which is not a valid iTIP component. In effect, the statement that a server is CRISP is a statement about the server's current advertised capabilities. It is conceivable that a CAP server might be CRISP under some conditions and not others. For example, the server might offer a CRISP capability set on initial connection, but upgrade to full CAP if the client uses STARTTLS and provides an appropriate certificate. It's not clear, though, whether there's any good way to advertise this fact. For the rest of this document, we will assume that a CRISP server is always CRISP. 6. Possible Firewall Application This section is non-normative. Clearly, it would be undesirable for an organization with a CAP server to have a CRISP server implemented completely separately, but having access to the same database. Such duplication would increase development costs, maintenance costs, and security exposure. On the other hand, it would be possible to build a CRISP server which han­ dles all operations by proxying them to the CAP server. Such a proxy could be placed within the "no-man's-land" common in firewalls; the firewall would permit CAP connections from the outside to the proxy, Stracke [Page 3] CRISP August 2001 and from the proxy to the internal CAP server. The proxy would review all incoming iCalendar components and validate that they were legitimate iTIP operations; no non-iTIP components would be forwarded to the CAP server. Similarly, if necessary, the proxy might censor the iTIP replies coming from the CAP server. Naturally, this is not the only approach possible; this section is merely illustrative. The CRISP client does not know or care how the CRISP server gets at the underlying calendar store. 7. Security Considerations CRISP is a subset of [CAP], and accordingly inherits all of CAP's security analysis. However, new analysis does need to be done for the subset, especially since the whole point of the subset is to address security concerns. 8. Author's Address: John Stracke Chief Scientist eCal Corp. Email: francis@ecal.com 9. References [iTIP] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- Independent Interoperability Protocol (iTIP)", RFC 2446, November 1998 [iMIP] Dawson, Mansour, Silverberg, "iCalendar Message-Based Interop­ erability Protocol (iMIP)", RFC 2445, November 1998 [CAP] Mansour, Dawson, Royer, Taler, Hill, "Calendar Access Protocol (CAP)", draft-ietf-calsch-cap-05.txt, July 2001. Work in progress. [iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998 Stracke [Page 4] --------------030403050200060204020005-- From owner-ietf-calendar@mail.imc.org Wed Aug 15 12:57:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26069 for ; Wed, 15 Aug 2001 12:57:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FGhmV01190 for ietf-calendar-bks; Wed, 15 Aug 2001 09:43:48 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FGhkN01186 for ; Wed, 15 Aug 2001 09:43:46 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA10996; Wed, 15 Aug 2001 12:43:42 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7FGhgf21234; Wed, 15 Aug 2001 12:43:42 -0400 (EDT) Message-ID: <3B7AA6AA.148C2152@steltor.com> Date: Wed, 15 Aug 2001 12:43:22 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Upaded Links On calsch.org 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 You can now find xml, html, and standard text versions of CAP and the Guide at: http://www.calsch.org/ietf/ietfdocs.html There you can also find the list of CAP issues and outstanding tasks. George From owner-ietf-calendar@mail.imc.org Wed Aug 15 14:37:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28786 for ; Wed, 15 Aug 2001 14:37:14 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7FIKgO05579 for ietf-calendar-bks; Wed, 15 Aug 2001 11:20:42 -0700 (PDT) Received: from agony.busboom.org (dt010n57.san.rr.com [204.210.12.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FIKfN05573 for ; Wed, 15 Aug 2001 11:20:41 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f7FIKcw20947 for ; Wed, 15 Aug 2001 11:20:39 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Wed, 15 Aug 2001 11:20:38 -0700 (PDT) From: Eric Busboom X-X-Sender: To: Subject: Minor Updates to iCalednar Issues and Draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I incorporated a few more minor issues from the iCalendar issues list into the iCalendar draft, online at: http://softwarestudio.org/iCal/ eric. From owner-ietf-calendar@mail.imc.org Wed Aug 15 16:07:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00296 for ; Wed, 15 Aug 2001 16:07:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FJrnJ09524 for ietf-calendar-bks; Wed, 15 Aug 2001 12:53:49 -0700 (PDT) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7FJrlN09517 for ; Wed, 15 Aug 2001 12:53:48 -0700 (PDT) Received: (qmail 289085 invoked from network); 15 Aug 2001 19:49:15 -0000 Received: from nicol6.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.67) by hilbert.umkc.edu with SMTP; 15 Aug 2001 19:49:15 -0000 Message-ID: <3B7AD0E0.ECB22F16@kasey.umkc.edu> Date: Wed, 15 Aug 2001 14:43:28 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" , CalSched IETF Subject: 2445:4.1 (x-name) is misleading. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 2445:4.1 (x-name) is misleading. At least it mislead me. But I am noti=oriously clueless. "Shannon J. Clark" wrote: > > [...] look at RFC2445 starting at page 133 for a general discussion of X- > properties. > > Shannon thanks. Section 4.8.8.1 is comforting. The passage in 4.1 x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") ; Reservered for experimental use. Not intended for use in ; released products. misled me. I think I have a wider conception of what a "released product" is and a narrower conception of what "experimental use" means than the authors of the document. I understood the passage to mean that x-names were only to be used within clean-room kinds of situations to test features which might get added into later versions of 2445. A clearer rephrasing might more closely resemble the definition of SMTP EXTENSION-FIELD in rfc822: 4.7.4. EXTENSION-FIELD A limited number of common fields have been defined in this document. As network mail requirements dictate, addi- tional fields may be standardized. To provide user-defined fields with a measure of safety, in name selection, such extension-fields will never have names that begin with the string "X-". Maybe the lines in 4.1 describing x-name might be rewritten, less ominously, like so: x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") ; The "X-" parameter name space is reserved for user extensions. -- David Nicol 816.235.1187 "Tomato!" From owner-ietf-calendar@mail.imc.org Thu Aug 16 07:14:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28548 for ; Thu, 16 Aug 2001 07:14:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GB1ts05197 for ietf-calendar-bks; Thu, 16 Aug 2001 04:01:55 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GB1rN05193 for ; Thu, 16 Aug 2001 04:01:54 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27864; Thu, 16 Aug 2001 07:00:41 -0400 (EDT) Message-Id: <200108161100.HAA27864@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-crisp-01.txt Date: Thu, 16 Aug 2001 07:00:40 -0400 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 : CAP Realtime iTIP-based Scheduling Profile (CRISP) Author(s) : J. Stracke Filename : draft-ietf-calsch-crisp-01.txt Pages : 4 Date : 15-Aug-01 This document sets forth a restricted profile of [CAP], one which supports no operations beyond the scheduling functionality of [iTIP]. The motivation is to permit use of CAP's real-time iTIP functionality without exposing the calendar access functionality (which may require stricter security controls than iTIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-crisp-01.txt 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-crisp-01.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-crisp-01.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: <20010815144819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-crisp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-crisp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010815144819.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Thu Aug 16 08:33:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02285 for ; Thu, 16 Aug 2001 08:33:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GCMx210582 for ietf-calendar-bks; Thu, 16 Aug 2001 05:22:59 -0700 (PDT) Received: from ns.thibault.org (65-85-145-218.client.dsl.net [65.85.145.218]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GCMwN10578 for ; Thu, 16 Aug 2001 05:22:58 -0700 (PDT) Received: from ecal.com (IDENT:francis@sergyar.local.thibault.org [192.168.10.20]) by ns.thibault.org (8.11.2/8.11.2) with ESMTP id f7GCQAV15657 for ; Thu, 16 Aug 2001 08:26:10 -0400 Message-ID: <3B7BBCF1.3020900@ecal.com> Date: Thu, 16 Aug 2001 08:30:41 -0400 From: John Stracke Organization: eCal Corp. User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: 2445:4.1 (x-name) is misleading. References: <3B7AD0E0.ECB22F16@kasey.umkc.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 David L. Nicol wrote: >2445:4.1 (x-name) is misleading. At least it mislead me. > Actually, I think you're right in your reading of it; it's just that, since 2445 was written, everybody's understanding of X- has drifted. I, for one, had forgotten that it was forbidden in released software, and had come to think of it as meaning the same thing it does in RFC-[2]822 headers: "use at your own risk". However, on reflection, I suspect the approach taken in 2445 may be better for our purposes. iCalendar properties interact so much that adding new ones may be somewhat risky. By contrast, mail headers generally stand alone; about the only interaction I can think of is that Reply-To: overrides From:. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Reality is what refuses to go away when I stop| |francis@ecal.com|believing in it. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 10:04:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07644 for ; Thu, 16 Aug 2001 10:04:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GDnvf12834 for ietf-calendar-bks; Thu, 16 Aug 2001 06:49:57 -0700 (PDT) Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GDntN12830 for ; Thu, 16 Aug 2001 06:49:55 -0700 (PDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id f7GDnnD27377 for ; Thu, 16 Aug 2001 09:49:50 -0400 (EDT) Received: from mailsrv1.mitre.org (mailsrv1.mitre.org [129.83.20.6]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id f7GDnmX19959 for ; Thu, 16 Aug 2001 09:49:48 -0400 (EDT) Received: from mitre.org ([129.83.210.198]) by mailsrv1.mitre.org (Netscape Messaging Server 4.15) with ESMTP id GI5YEZ00.39I for ; Thu, 16 Aug 2001 09:49:47 -0400 Message-ID: <3B7BF9BD.EA1A8E51@mitre.org> Date: Thu, 16 Aug 2001 09:50:05 -0700 From: "Leveille,Peter S." Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: The iCalendar XML DTD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have found the IETF internet draft dated December 4, 1998 for the iCalendar XML DTD. Is there a more recent copy of this material? Thanks, -Pete From owner-ietf-calendar@mail.imc.org Thu Aug 16 10:33:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09555 for ; Thu, 16 Aug 2001 10:33:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GEKNF13664 for ietf-calendar-bks; Thu, 16 Aug 2001 07:20:23 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GEKLN13660 for ; Thu, 16 Aug 2001 07:20:22 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GEMb627008 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 10:22:39 -0400 Message-ID: <3B7BD72D.4040109@ecal.com> Date: Thu, 16 Aug 2001 10:22:37 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: The iCalendar XML DTD References: <3B7BF9BD.EA1A8E51@mitre.org> 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 Leveille,Peter S. wrote: >I have found the IETF internet draft dated December 4, 1998 for the >iCalendar XML DTD. Is there a more recent copy of this material? > No, it was abandoned, on the grounds that it'd be counterproductive to have two different formats. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"Simply vanished--like an old oak table." --Lord| |francis@ecal.com|Percy, _Black Adder II_ | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 10:56:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10843 for ; Thu, 16 Aug 2001 10:56:00 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GEbQx14467 for ietf-calendar-bks; Thu, 16 Aug 2001 07:37:26 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GEbPN14463 for ; Thu, 16 Aug 2001 07:37:25 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA24562; Thu, 16 Aug 2001 10:37:17 -0400 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 f7GEbGf23573; Thu, 16 Aug 2001 10:37:16 -0400 (EDT) Message-Id: <5.1.0.14.0.20010816103238.01f6aab0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 16 Aug 2001 10:38:38 -0400 To: "Leveille,Peter S." From: Alan Davies Subject: Re: The iCalendar XML DTD Cc: ietf-calendar@imc.org In-Reply-To: <3B7BF9BD.EA1A8E51@mitre.org> 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: A (slightly) more recent version was written by Dawson, Reddy, and Royer. iPlanet appears to use it in their server, and has a copy of the (expired) draft here on their website (unfortunately it suffers from formatting problems, I can mail a cleaned up version on request to anyone who's interested): http://developer.iplanet.com/docs/wpapers/calendar/ietf.txt Several different vendors use xml representations of iCalendar, and this draft will be resurrected and completed/corrected in the future to standardise them. --Alan At 09:50 AM 16/08/2001 -0700, you wrote: >I have found the IETF internet draft dated December 4, 1998 for the >iCalendar XML DTD. Is there a more recent copy of this material? > >Thanks, >-Pete From owner-ietf-calendar@mail.imc.org Thu Aug 16 11:23:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12561 for ; Thu, 16 Aug 2001 11:23:06 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GFAhC17436 for ietf-calendar-bks; Thu, 16 Aug 2001 08:10:43 -0700 (PDT) Received: from liffey.metamatrix.se (liffey.metamatrix.se [213.88.195.123]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GFAeN17429 for ; Thu, 16 Aug 2001 08:10:40 -0700 (PDT) Received: from metamatrix.se (dublin.metamatrix.se [213.88.195.121]) by liffey.metamatrix.se (Postfix) with ESMTP id EBB0320089 for ; Thu, 16 Aug 2001 17:10:32 +0200 (CEST) Message-ID: <3B7BE2A0.9864EE2C@metamatrix.se> Date: Thu, 16 Aug 2001 17:11:28 +0200 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 2445:4.1 (x-name) is misleading. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit John Stracke wrote: > > 2445:4.1 (x-name) is misleading. At least it mislead me. > Actually, I think you're right in your reading of it; it's just that, > since 2445 was written, everybody's understanding of X- has drifted. > I, for one, had forgotten that it was forbidden in released software, > and had come to think of it as meaning the same thing it does in > RFC-[2]822 headers: "use at your own risk". > However, on reflection, I suspect the approach taken in 2445 may be > better for our purposes. iCalendar properties interact so much that > adding new ones may be somewhat risky. Preferrably, released software should have an option: to pass on X-prefixed properties, or to erase such information (for extremely vulnerable systems). If all released software erases X-prefixed data, then how can iCalendar mature and adapt to needs not known when RFC2445 was formulated? If, for example, SKiCal data is to be delivered from a SKiCal aware Calendar User Agent through a Calendar Store to another SKiCal aware CUA, then the CS must pass on the X-fields or all information concerning, for example, handicap accessibility will be lost. Suppose X-SKI-HANDICAP-FACILITIES proves to be a very popular extension. Then it should go into the next version of iCalendar, shouldn't it? But no one would ever know unless X-data is being forwarded through the systems. /Pär From owner-ietf-calendar@mail.imc.org Thu Aug 16 11:30:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13057 for ; Thu, 16 Aug 2001 11:30:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GFFOZ17710 for ietf-calendar-bks; Thu, 16 Aug 2001 08:15:24 -0700 (PDT) Received: from ae.poss.com (adam-m.poss.com [198.70.184.161]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GFFNN17706 for ; Thu, 16 Aug 2001 08:15:23 -0700 (PDT) Received: from homer ([198.70.184.96]) by ae.poss.com (Netscape Messaging Server 4.1) with ESMTP id GI62E600.OCR for ; Thu, 16 Aug 2001 11:15:42 -0400 From: "David King" To: Subject: RE: The iCalendar XML DTD Date: Thu, 16 Aug 2001 11:20:08 -0400 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.2910.0) In-Reply-To: <3B7BF9BD.EA1A8E51@mitre.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I also brought up a similar question when I first started looking at iCalendar. My research led me to the RDF Calendar taskforce. Have a look: http://ilrt.org/discovery/2001/04/calendar/ -David > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Leveille,Peter S. > Sent: Thursday, August 16, 2001 12:50 PM > To: ietf-calendar@imc.org > Subject: The iCalendar XML DTD > > > > I have found the IETF internet draft dated December 4, 1998 for the > iCalendar XML DTD. Is there a more recent copy of this material? > > Thanks, > -Pete > From owner-ietf-calendar@mail.imc.org Thu Aug 16 12:35:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15373 for ; Thu, 16 Aug 2001 12:35:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GGHsh23411 for ietf-calendar-bks; Thu, 16 Aug 2001 09:17:54 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GGHrN23406 for ; Thu, 16 Aug 2001 09:17:53 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GGKD627423 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 12:20:14 -0400 Message-ID: <3B7BF2BD.8000605@ecal.com> Date: Thu, 16 Aug 2001 12:20:13 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: UG expansion? 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 CAP section 2.4.3 says "The CS MUST accept a CUA request for UG expansion". Why? This sounds like a security risk to me. SMTP doesn't force a server to honor the EXPN command. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"What we have here is a failure to assimilate."| |francis@ecal.com|--Cool Hand Locutius | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 13:03:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16144 for ; Thu, 16 Aug 2001 13:03:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GGmfO24313 for ietf-calendar-bks; Thu, 16 Aug 2001 09:48:41 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GGmdN24309 for ; Thu, 16 Aug 2001 09:48:39 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA13437; Thu, 16 Aug 2001 11:44:13 -0500 From: "Shannon J. Clark" To: =?iso-8859-1?B?UORyIExhbm5lcvY=?= , Subject: RE: 2445:4.1 (x-name) is misleading. Date: Thu, 16 Aug 2001 11:48:26 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3B7BE2A0.9864EE2C@metamatrix.se> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I was under the impression that the intention of X- prefixed elements was that they were to be preserved by all compliant systems - but could be ignored by any system without risk. That is, they are intended for additional features that a particular vendor decides to explore (such as SkiCAL) - they should not contain information that is crucial to the iCalendar context of the given object - i.e. the iCalendar object should still be well formed and use the mandatory elements of that object to store the required information. This means for example, that a CS that receives an object with X- prefixed elements should still be able to handle it in a manner expected by the originator of the object. So, a good example of an X- prefixed element would be the SkiCAL Handicap-facilities field - it is a new type of segregated data (that would probably have previously be stored, if at all, in the description of the event) but does not "break" the standard elements of the given iCalendar object - CS or CUA that do not "understand" the X-SKI-HANDICAP-FACILITIES extension can ignore it and the use of the object is not impacted - it is also not hard to imagine that many systems would be able to display unknown extensions to the end user (in whatever section they have available for unformatted/unlimited text - my company's tools for example will very likely display any unknown extensions as an extension/value pair - though probably only in an "advanced" mode of our application. This is (and I think was in fact modeled after) similar to how X- extensions are handled by mail programs - it is very common for mail headers to have many X- parameters, most of which any given mail reader simply ignores - if the user is interested they can see them in the full header, but to all but the programs that use them they are ignored at no risk. An example of an X- extension that would be a problem would be one that was substituted for a required field and/or contradicted/modified a standard field - say someone wanted to make iCalendar function on Astronomical time - this is probably not possible under the standard since all the time related elements assume UTC or other standard bases - the non-Gregorian time structures seem unavailable at the moment. One option might appear to be to use X-params but this would creating objects with perhaps missing DSTART fields for example. Anyway, just another few cents of commentary on this topic, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Pär Lannerö Sent: Thursday, August 16, 2001 10:11 AM To: ietf-calendar@imc.org Subject: Re: 2445:4.1 (x-name) is misleading. John Stracke wrote: > > 2445:4.1 (x-name) is misleading. At least it mislead me. > Actually, I think you're right in your reading of it; it's just that, > since 2445 was written, everybody's understanding of X- has drifted. > I, for one, had forgotten that it was forbidden in released software, > and had come to think of it as meaning the same thing it does in > RFC-[2]822 headers: "use at your own risk". > However, on reflection, I suspect the approach taken in 2445 may be > better for our purposes. iCalendar properties interact so much that > adding new ones may be somewhat risky. Preferrably, released software should have an option: to pass on X-prefixed properties, or to erase such information (for extremely vulnerable systems). If all released software erases X-prefixed data, then how can iCalendar mature and adapt to needs not known when RFC2445 was formulated? If, for example, SKiCal data is to be delivered from a SKiCal aware Calendar User Agent through a Calendar Store to another SKiCal aware CUA, then the CS must pass on the X-fields or all information concerning, for example, handicap accessibility will be lost. Suppose X-SKI-HANDICAP-FACILITIES proves to be a very popular extension. Then it should go into the next version of iCalendar, shouldn't it? But no one would ever know unless X-data is being forwarded through the systems. /Pär From owner-ietf-calendar@mail.imc.org Thu Aug 16 13:43:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17185 for ; Thu, 16 Aug 2001 13:43:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GHTPv25523 for ietf-calendar-bks; Thu, 16 Aug 2001 10:29:25 -0700 (PDT) Received: from eeyore.jsoft.com (mail.jsoft.com [24.240.234.245] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GHTON25519 for ; Thu, 16 Aug 2001 10:29:24 -0700 (PDT) Received: from jsoft.com (IDENT:ggf@eeyore.jsoft.com [192.168.1.46]) by eeyore.jsoft.com (8.11.0/8.11.0) with ESMTP id f7GHYS612554; Thu, 16 Aug 2001 12:34:29 -0500 Message-ID: <3B7C0424.2010000@jsoft.com> Date: Thu, 16 Aug 2001 12:34:28 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Alan Davies CC: ietf-calendar@imc.org Subject: Re: The iCalendar XML DTD References: <5.1.0.14.0.20010816103238.01f6aab0@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 I would like a cleaned up copy of the iPlanet DTD. Thanks... I recently modified the libical library to output XML. No DTD, the XML looks like the iCalendar 'objects'. It should be easy to translate my output to whatever standard if one is picked. I don't think it's necessary to have an iCalendar XML DTD. The iCalendar standard exists and is used by lots of software. If XML were used instead of the current iCalendar format, the world would be a better place... but it was not. :-) If people use XML and publish their formats, others can interface. I love getting 'iCalendar' in XML. We have XSL stylesheets that are easy for non-developers to modify. I am marginal about suffering thru the process of coming up with a standard DTD. Sounds like more trouble than it's worth. --- and I plan on looking at the RDF Calendar taskforce info David King pointed out (thanks!) and I would be interested in talking with others that are using XML with iCalendar (off list???) Gary Alan Davies wrote: > > A (slightly) more recent version was written by Dawson, Reddy, and > Royer. iPlanet appears to use it in their server, and has a > copy of the (expired) draft here on their website (unfortunately > it suffers from formatting problems, I can mail a cleaned up > version on request to anyone who's interested): > > http://developer.iplanet.com/docs/wpapers/calendar/ietf.txt > > Several different vendors use xml representations of iCalendar, > and this draft will be resurrected and completed/corrected in the > future to standardise them. > > --Alan > > At 09:50 AM 16/08/2001 -0700, you wrote: > >> I have found the IETF internet draft dated December 4, 1998 for the >> iCalendar XML DTD. Is there a more recent copy of this material? >> >> Thanks, >> -Pete > From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:42:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18983 for ; Thu, 16 Aug 2001 14:42:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIV2w26986 for ietf-calendar-bks; Thu, 16 Aug 2001 11:31:02 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIV0N26973 for ; Thu, 16 Aug 2001 11:31:00 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIXI627857 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:33:19 -0400 Message-ID: <3B7C11EE.4000806@ecal.com> Date: Thu, 16 Aug 2001 14:33:18 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: error code 6.9 leaks data Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit CAP section 7.1.3 defines an error code, 6.9, which reports that the user exists, but cannot use the given mechanism. I believe it's generally considered a bad idea to tell an unauthenticated client a user exists, because it aids with dictionary attacks. (For example, when you log in to a Unix system, it doesn't distinguish between a bad username and a bad password; either way, it just says "Login incorrect".) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Organ transplants are best left to the | |francis@ecal.com |professionals. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:42:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18994 for ; Thu, 16 Aug 2001 14:42:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GITsI26875 for ietf-calendar-bks; Thu, 16 Aug 2001 11:29:54 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GITqN26868 for ; Thu, 16 Aug 2001 11:29:52 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIWD627829 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:32:14 -0400 Message-ID: <3B7C11AD.20201@ecal.com> Date: Thu, 16 Aug 2001 14:32:13 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: things that are out of scope 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 The CAP draft imposes some requirements that I believe are out of scope: * In section 2.4.2, there's a requirement that a CS integrated with a directory system must support the ability to configure which schema attribute stores the UPN. This is (a) irrelevant to CAP, because it's hidden from a CAP client, and (b) a bad requirement, because there is some value in implementations that couple the different servers more tightly than this. If you want to be able to mix-and-match LDAP and CAP servers, then this configurability is a useful feature; but maybe you want to build a CAP server with its own user directory, which exposes that directory via LDAP. That's integration with a directory server (itself), but there is no value in that case in being able to do this configuration. * In 2.4.2.1, there's a requirement that a CAP implementation must be able to configure what attribute in a certificate contains the UPN. Again, this is out of scope, because it's irrelevant to CAP, and it's not always a useful feature anyway (maybe your CS is also your CA). -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |Vlad was not a vampire, but that's the only nice| |francis@ecal.com |thing that could be said about him. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:42:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19006 for ; Thu, 16 Aug 2001 14:42:27 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GITR826852 for ietf-calendar-bks; Thu, 16 Aug 2001 11:29:27 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GITQN26848 for ; Thu, 16 Aug 2001 11:29:26 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIVl627818 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 16 Aug 2001 14:31:48 -0400 Message-ID: <3B7C1193.3060802@ecal.com> Date: Thu, 16 Aug 2001 14:31:47 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: why define Resource Calendar? 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 In section 1.3, the definition of Resource Calendar says that there is no syntactic difference between an RC and a Calendar. So why do we define it at all? Is there any difference? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Collect call from reality, will you accept | |francis@ecal.com |the--" *click* | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:42:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19017 for ; Thu, 16 Aug 2001 14:42:29 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIXGx27134 for ietf-calendar-bks; Thu, 16 Aug 2001 11:33:16 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIXEN27128 for ; Thu, 16 Aug 2001 11:33:14 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIZY627905 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:35:36 -0400 Message-ID: <3B7C1276.2070207@ecal.com> Date: Thu, 16 Aug 2001 14:35:34 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: let's not copy text 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 The Editors Note in CAP section 7.2.2 discusses adding the restriction tables for each iTIP method, based on the tables in the iTIP spec. (Similarly, the existing restriction tables for, e.g., CREATE include restriction tables copied from iCalendar, to restrict what can be created.) Copying specification text is almost always a Bad Thing; better to refer to the existing spec, perhaps with deltas where necessary. Along the same lines, I agree with Doug's (?) editor's note in section 9, that the minimum component properties for VEVENT, etc., must be the same as for iTIP. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"If there's anything The Flintstones have taught| |francis@ecal.com |us, it's that pelicans can be used to mix | | |cement." -- Homer Simpson | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:42:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19028 for ; Thu, 16 Aug 2001 14:42:30 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIVmg27033 for ietf-calendar-bks; Thu, 16 Aug 2001 11:31:48 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIVlN27028 for ; Thu, 16 Aug 2001 11:31:47 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIY8627877 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:34:09 -0400 Message-ID: <3B7C1220.2030905@ecal.com> Date: Thu, 16 Aug 2001 14:34:08 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: these are not legal iCalendar objects 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 In all (I think) of the CAP examples, we have a Content-type: of text/calendar, but the outermost BEGIN of the iCalendar is "VCAP". By 2445, this is not legal; an iCalendar object always begins with "BEGIN:VCALENDAR". We have similar problems scattered around; for example, in the first example in 7.2.1.2.1, creating a VCALENDAR component is used to represent a calendar to create. A VCALENDAR component *is* an iCalendar object; it cannot (I think) appear inside another component. In the responses to a query, if you request only some fields, you can get back VEVENT components which are not legal VEVENTs (they don't have all the required properties). We need to either change the syntax so these data structures do not claim to be iCalendar objects, or add text to CAP clarifying that these objects are not what they claim to be, and may not parse properly in a parser based on RFC-2445. The latter is probably more reasonable; having them look like iCalendars is probably more helpful than misleading. Still, I would rather see some minor changes for better harmony with 2445: have the VCAP contained inside a VCALENDAR, and define a new component representing calendars. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"How quietly do you think we can nail these back| |francis@ecal.com |in?" --Calvin | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:42:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19039 for ; Thu, 16 Aug 2001 14:42:36 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GITDO26840 for ietf-calendar-bks; Thu, 16 Aug 2001 11:29:13 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GITCN26836 for ; Thu, 16 Aug 2001 11:29:12 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIVW627810 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 16 Aug 2001 14:31:33 -0400 Message-ID: <3B7C1184.2070801@ecal.com> Date: Thu, 16 Aug 2001 14:31:32 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: inconsistency in Overlapped Booking definition 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 In section 1.3, the definition of Overlapped Booking says it's a policy that can be applied to a calendar or an individual entry. However, the definition of Calendar Policy seems to indicate that policies apply only to calendars; this is inconsistent. In any case, it seems like an Overlapped Booking policy for individual entries would be redundant, since the same effect can be obtained by the TRANSP property on VEVENTs. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |Dave Barry for President! He'll Keep Dan Quayle.| |francis@ecal.com |(OK, it's old) | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:42:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19050 for ; Thu, 16 Aug 2001 14:42:38 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIV8G26993 for ietf-calendar-bks; Thu, 16 Aug 2001 11:31:08 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIV6N26989 for ; Thu, 16 Aug 2001 11:31:06 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIXR627861 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:33:28 -0400 Message-ID: <3B7C11F7.7070503@ecal.com> Date: Thu, 16 Aug 2001 14:33:27 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: SASL mechanisms and MITM attacks 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 CAP section 7.1.3 discusses the risk of an attacker forcing the client to pick a weak SASL mechanism. It says that the CUA should fetch the list of supported mechanisms after authenticating, to make sure it hasn't changed. First: it's not clear to me how this fetch would be done; can we spell it out? Second: does this actually do any good? Can't the man-in-the-middle change the list of supported mechanisms after authenticating, as well as before? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This space intentionally left blank. | |francis@ecal.com | | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:43:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19074 for ; Thu, 16 Aug 2001 14:43:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIU3726893 for ietf-calendar-bks; Thu, 16 Aug 2001 11:30:03 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIU2N26888 for ; Thu, 16 Aug 2001 11:30:02 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIWN627833 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:32:24 -0400 Message-ID: <3B7C11B7.9010508@ecal.com> Date: Thu, 16 Aug 2001 14:32:23 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: matching common names 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 The last paragraph of CAP section 2.4.2.1 specifies that a CS or CUA processing data received by iMIP should compare the personal-name part of the From: email address with the CN part of the ORGANIZER or ATTENDEE property, and refuse the message if they don't match. This is very risky; people's names do not stay unchanged forever. Consider Lisa Dusseault; in the time I've known her, she's also gone by Lisa Lippert and Lisa Lippert-Dusseault. Looking at my old calsch mail, I see some messages from her saying "Lisa Lippert (Dusseault) (Exchange)", which brings up another, shorter time-scale problem: sometimes different UAs for the same email address will be configured with slightly different names. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"The struggle is always worthwhile, if the end | |francis@ecal.com |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 Thu Aug 16 14:43:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19085 for ; Thu, 16 Aug 2001 14:43:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIWDF27060 for ietf-calendar-bks; Thu, 16 Aug 2001 11:32:13 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIWBN27056 for ; Thu, 16 Aug 2001 11:32:11 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIYW627885 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:34:33 -0400 Message-ID: <3B7C1238.7060101@ecal.com> Date: Thu, 16 Aug 2001 14:34:32 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: commands need definitions, not just examples 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 For most of the commands CAP defines, we don't actually get a formal definition; we just get some informal descriptive text and some examples. This is a problem, because, with a firm definition, it'll be impossible to determine whether any given implementation is compliant. For example, in the first example in 7.2.1.2.1, it is unclear whether the two calendars created need to be created in the order specified. In the second example, the text does not match the example: it says "The response contains the calendar (CALID) and UID of the component"--but it doesn't; there are no CALID or UID properties in the response. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Among animals, it's eat or be eaten. Among | |francis@ecal.com |people, it's define or be defined. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:43:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19112 for ; Thu, 16 Aug 2001 14:43:27 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GITba26860 for ietf-calendar-bks; Thu, 16 Aug 2001 11:29:37 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GITZN26856 for ; Thu, 16 Aug 2001 11:29:36 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIVr627822 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 16 Aug 2001 14:31:54 -0400 Message-ID: <3B7C1199.3050306@ecal.com> Date: Thu, 16 Aug 2001 14:31:53 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: man-in-the-middle attacks 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 In section 2.4, it says that spoofing of a CS is due to a hostile client, then lists the threats that can come from hostile agents between client and server. I believe that spoofing of a CS is not due to a hostile client at all (it's an attack *on* the client); it comes solely from hostile intermediate agents (e.g., man-in-the-middle attackers). -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Sometimes we in the media have to give the | |francis@ecal.com |copycat criminals a little kick-start." -- Tina| | |the Tech Writer, in _Dilbert_ | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:44:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19186 for ; Thu, 16 Aug 2001 14:44:15 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIWfY27085 for ietf-calendar-bks; Thu, 16 Aug 2001 11:32:41 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIWeN27081 for ; Thu, 16 Aug 2001 11:32:40 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIZ0627893 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:35:01 -0400 Message-ID: <3B7C1254.1020001@ecal.com> Date: Thu, 16 Aug 2001 14:35:00 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: moving components 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 The editors note for 7.2.1.6 (MOVE) says: > 1) Should one be able to move a calendar owned by person X into a > calendar owned by person Y. (Can these such rights be specified in VCARs?) I think such a move is probably risky; if it's possible, though, then it must be possible to write VCARs to control it. > 2) Should we also be able to move components from one calendar to another? Definitely--otherwise there's no way for a user to correct their mistake if they create a component in the wrong calendar. > What if the calendars are owned by different users? As with moving calendars, I think this is problematic. Does ownership change? (Permitting an arbitrary user to change ownership is potentially risky; if nothing else, it permits someone to create incriminating data and make it look like it was created by someone else.) If not, does the new user have the ability to remove the component from their calendar? They'd better be able to; but, if they can, where does it go? Can they delete it? -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Stupid, adj.: Losing $25 on the game and $50 on| |francis@ecal.com |the instant replay. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:44:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19197 for ; Thu, 16 Aug 2001 14:44:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIWOT27071 for ietf-calendar-bks; Thu, 16 Aug 2001 11:32:24 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIWMN27067 for ; Thu, 16 Aug 2001 11:32:22 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIYh627889 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:34:44 -0400 Message-ID: <3B7C1243.5010601@ecal.com> Date: Thu, 16 Aug 2001 14:34:43 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: why do we need GENERATEUID? 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 GENERATEUID asks the CS to generate one or more unique UIDs. What is this for? Why can't the client create its own UIDs, like any other CUA? Why should we introduce extra round-trips, and extra work on the CS? If there's some strong reason the UID has to be generated by the CS, then it should still not be done in a separate command; CREATE should accept components without UIDs, and report back the UIDs they were assigned. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Baldric, how did you manage to find a turnip| |francis@ecal.com |that cost 400,000 pounds?" "Well, I had to | | |haggle." --Blackadder III | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:44:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19210 for ; Thu, 16 Aug 2001 14:44:24 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIVIP27007 for ietf-calendar-bks; Thu, 16 Aug 2001 11:31:18 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIVGN27002 for ; Thu, 16 Aug 2001 11:31:16 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIXb627865 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:33:39 -0400 Message-ID: <3B7C1201.8090107@ecal.com> Date: Thu, 16 Aug 2001 14:33:37 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: cancelling authentication 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 CAP section 7.1.3 mentions that what happens if the authentication process is cancelled during its negotiation is implementation-specific; I'm afraid this might lead to a lack of interop. A little further down, it mentions that the CUA may not (I believe it should be MUST NOT) reissue AUTHENTICATE, even if the first attempt was aborted; if the CUA attempts to do so, the CS must (MUST?) terminate the session. I believe this can be simplified simply by requiring the CS to drop the connection immediately if the AUTHENTICATE is cancelled. Since no further AUTHENTICATE can be issued, that connection cannot be used again; keeping it open has no value. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Anyone who has a conditioned response | |francis@ecal.com |immediately thinks of Pavlov. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:44:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19222 for ; Thu, 16 Aug 2001 14:44:29 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIW4527050 for ietf-calendar-bks; Thu, 16 Aug 2001 11:32:04 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIW2N27046 for ; Thu, 16 Aug 2001 11:32:02 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIYM627881 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:34:24 -0400 Message-ID: <3B7C122E.9000107@ecal.com> Date: Thu, 16 Aug 2001 14:34:22 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: stored queries 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 CAP's stored queries look problematic to me. Are they really necessary? I would prefer to be able to build a CAP server as a frontend to my existing server, which means I don't want to introduce too much new items to be stored. In addition, I'm unhappy about the storage costs. It seems likely that VQUERYs can't be shared between different users, which means that, if I have 100K users, each using the same CUA, and that CUA creates 5 VQUERYs, then I have to store 500K VQUERYs, even though there are only 5 different ones. This seems wasteful. Can stored queries be made optional? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"And bring the search warrant." "You mean the| |francis@ecal.com |sledgehammer, sir?" "Yes." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:44:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19233 for ; Thu, 16 Aug 2001 14:44:38 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GITMX26846 for ietf-calendar-bks; Thu, 16 Aug 2001 11:29:22 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GITLN26842 for ; Thu, 16 Aug 2001 11:29:21 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIVe627814 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 16 Aug 2001 14:31:41 -0400 Message-ID: <3B7C118C.2090500@ecal.com> Date: Thu, 16 Aug 2001 14:31:40 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: OWNER of a CS? 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 In section 1.3., the definition of OWNER says "The owner is specified in the OWNER calendar property and in the OWNER calendar store property". What does OWNER mean when applied to a CS? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Collect call from reality, will you accept | |francis@ecal.com |the--" *click* | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:44:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19245 for ; Thu, 16 Aug 2001 14:44:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIYWU27198 for ietf-calendar-bks; Thu, 16 Aug 2001 11:34:32 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIYUN27194 for ; Thu, 16 Aug 2001 11:34:31 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIap627925 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:36:52 -0400 Message-ID: <3B7C12C3.2090308@ecal.com> Date: Thu, 16 Aug 2001 14:36:51 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: nits 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 Some nits from the CAP draft (typos, English problems, etc.): * Section 1.3 (the definitions): * "Calendar Properties" is defined as "An attribute of a calendar". Singular/plural mismatch. * "Calendar User Agent" is defined as "the client application that a CU or UG utilizes...". Should we strike "or UG"? A user group does not use a CUA; only a user does. This looks like a global-replace mistake. * "Calendaring and Scheduling System": "...services for accessing manipulating calendars...". Should there be an "and" after "accessing"? * "Heirarchical Calendars": * "A CS feature where a calendar have"--should be "has". * There's a definition of sibling relationships; I think that should be omitted, since it's implicit in the parent/child relationship. * "User Principal Name": the sentence "A CU's UPN to email address mapping..." is utterly unclear to me. What does it mean? * Section 2.1.1: * "One example of a site site policy"--strike one "site". * "calendar.site.com"--all example domain names in any RFC should be in "example.{com,net,org}", which are reserved for such purpose, so that, e.g., site.com doesn't get hit over and over by people reading the RFC. * Section 2.4.3: * "The Three Stooges. There is"--should be "are". * "The National Football League"--maybe find an example which will be better recognized outside the US? * 2.4.4: * "individual VCARs MUST be specifically granted to an authenticated CU". I think this is poorly phrased; as written, it sounds as if a CS MUST NOT forbid a CU from doing whatever they please. I think this phrase can just be struck, actually; its intent is redundant with with first part of the sentence ("All rights MUST be denied unless specifically granted"). * 2.4.6: the examples are the same as in 2.4.3. Do they need to be repeated here? * 2.6: the port number, 5229, is in an awkward range. Something under 1024 would probably be better. (This came up in the London meeting.) * 2.7: the paragraph saying "The iCalendar METHOD property format has been updated with new values" should probably be moved up, so that it comes before the paragraph that lists some of these new values. * 2.8: The second-to-last sentence ("Followed by a DELETE...") is not a complete sentence. * 5.1.1: the ABNF for "search" does not include CRLF separators between "expand", "maxresults", etc. * 6.: as in 2.4.4, the first clause of the second paragraph seems to imply that a CU MUST be granted all rights. Again, I think this first clause can be struck. * 6.1: the "By implication" is not implied at all. "Subcalendars inherit from root" does not imply "subcalendars inherit from parents", although the other way around is true. * 6.2: "This setting overrides access While access control..."--this doesn't make sense; I think there's a cut-and-paste error here. * 7.1.4 and 7.1.5: MAXEXPANDLIST, MAXCALIDEXPAND, and MAXCALIDEXPANDLIST all seem to be used interchangeably; should they all be MAXCALIDEXPANDLIST? * 7.1.4: example #2 lists the same calid twice in the response. * 7.1.5: * AUTH: "Implementations MUST implement at least"--and then cuts off. * MAXICALOBJECTSIZE: "specifies The largest ICAL object"--I believe it should be "specifies the size of the largest..."; an integer does not specify an iCalendar object. * 7.1.7 refers to "stuck in TCP-WAIT state". I believe that should be "stuck in TCP's TIME_WAIT state". * 7.1.11: * does not specify the syntax in which the members of the UPN are returned (examples don't count). * The group expansions seem to show that groups include themselves. Is this true? If so, why? * 7.2.1.2's restriction table: * Under "VCAP": "can send up PIPELINE"--should be "up to PIPELINE". * Under "VCAP", then "VCOMMAND": says "MUST at least one container"--a verb, Senator, we need a verb! * 7.2.1.7: the first example has a blank line after the "BEGIN:VEVENT". (There's no S:, so it's not a blank line from the server; it looks like it's just a typo.) * 7.2.2.1 is just riddled with spelling mistakes: * "automaticly" should be "automatically" (appears at least twice, and once in 7.2.2.7). * Apostrophes have been left out all over the place. * "...is not booked in your calendar, It is..."--change to "...calendar; it is...". * "The the CUA and CU could delete"--strike the second "the". * "...METHOD:DELETE the component an inform..."--"and". * 7.2.2.2: "If the CU wishes to keep the published entry."--sentence fragment. * 7.2.2.3: "This as described in [iTIP] and would be modified just like PUBLISH above". Don't say "just like"; that's too imprecise for a spec. Define what's going on; don't leave it up to the reader to intuit. Also, there should be an "is" after "This". * 7.2.2.7: * "may effect"--should be "affect". * 8: * 2.0.1: ">CRLF>.>CRLF>"--should that be "."? * Several descriptions of response codes say "If can"--I think that should be "It can". * 8.3: "DATETIME value was too large"--all DATETIMEs are about the same size (15 or 16 bytes). Should that be "too far in future"? * 10.1: * Many of these property descriptions have spurious uppercase letters at the start of the second line. * CALMASTER: why does it have to be a mailto: URI? Why not im: (when IMPP is standardized), or http: (to get a page to read before sending a message)? If it does have to be email, why not a bare email address rather than a URI? * CSID: "hostname or virtual host name"--I haven't been able to find anything in the spec about virtual hosts. Did I miss it? * DEFAULT_VCARS: add a period after "CARID". * CURRENT_DATETIME: * What is this for? So the CUA can synchronize its clock with the CS? If so, then doing it over TCP is probably a bad idea. NTP already provides this functionality; CAP shouldn't attempt to duplicate it. * It says it's a DATE-TIME value, but it's returned as a local time and TZID. How? The DATE-TIME syntax doesn't have room for a TZID. * 10.2: * DEFAULT_VCAR: refers to DEFAULT_VCAR in the calendar store; but there is no such property. There is a DEFAULT_VCARS property, though. Which should it be? * PARENT: "this calendars Parent" should be "this calendar's parent". * RELCALID: "A unique name for the calendar"--should that be "unique ID"? -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"Where's your sense of adventure?" "Hiding under| |francis@ecal.com |the bed." | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:44:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19256 for ; Thu, 16 Aug 2001 14:44:44 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIUaU26952 for ietf-calendar-bks; Thu, 16 Aug 2001 11:30:36 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIUYN26948 for ; Thu, 16 Aug 2001 11:30:34 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIWt627845 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:32:56 -0400 Message-ID: <3B7C11D7.7080705@ecal.com> Date: Thu, 16 Aug 2001 14:32:55 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: autologout 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 A couple of questions about autologout on idle: * 4.4: "When a timeout occurs, the server drops the connection to the CUA". Should there be some sort of notification first? We've got a notification for server shutdown (difficult as that may be to implement); one for idle timeout seems reasonable. * 7.1.12: the NOOP command seems like a way of evading the server's idle timeout policy. Many servers I've known with such timeouts don't want them evaded (for example, I had an ISP which had an idle timeout on their PPP connections, and warned that ping packets didn't count, because people were using ping to keep the connection alive). Maybe there should be an error code reporting that the NOOP has been ignored? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Please do not adjust your mind--reality is | |francis@ecal.com |malfunctioning. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:44:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19257 for ; Thu, 16 Aug 2001 14:44:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIUOW26920 for ietf-calendar-bks; Thu, 16 Aug 2001 11:30:24 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIULN26904 for ; Thu, 16 Aug 2001 11:30:22 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIWg627841 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:32:43 -0400 Message-ID: <3B7C11CA.4080703@ecal.com> Date: Thu, 16 Aug 2001 14:32:42 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: IDENTIFY seems dangerous 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 The CAP IDENTIFY command seems like it has some dangerous security implications. AUTHENTICATE presents credentials, then IDENTIFY can reuse those credentials to become a different user. The problem is that this requires the CS to keep the credentials stored in memory for the lifetime of the connection, which carries a risk of leakage (a bug which lets an attacker read the contents of the server's memory can expose the credentials for all active connections). Now, with some types of credentials, this may be safe; but, for others, it's not. I believe that, at a minimum, the server needs to be able to refuse to store credentials which are not safe. More generally, it's not clear why IDENTIFY is needed at all, as a separate comand. Clearly, there is some need to be able to authenticate as a user other than the default implied by one's credentials (proxy access); but that doesn't have to mean switching identities at arbitrary times during the connection; it can be handled with an extra parameter to AUTHENTICATE. I believe this would be the better approach (better than refusing to store unsafe credentials), because it would mean that proxy access can be done with any sort of credentials, not just ones which are safe for the server to store. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"Why did you become a spokesmodel?" "Oh, well,| |francis@ecal.com |I've always liked pointing." -- _LA Story_ | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:49:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19455 for ; Thu, 16 Aug 2001 14:49:14 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIVeN27022 for ietf-calendar-bks; Thu, 16 Aug 2001 11:31:40 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIVcN27018 for ; Thu, 16 Aug 2001 11:31:38 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIXw627873 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:33:59 -0400 Message-ID: <3B7C1216.8090703@ecal.com> Date: Thu, 16 Aug 2001 14:33:58 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: changes needed for CRISP 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 If we want to support CRISP, then some changes are needed in CAP. In section 7.1.5, CAPVERSION, CAR, and QUERYLEVEL all need to be able to have values of NONE. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"How quietly do you think we can nail these back| |francis@ecal.com |in?" --Calvin | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:49:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19466 for ; Thu, 16 Aug 2001 14:49:21 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIXmi27157 for ietf-calendar-bks; Thu, 16 Aug 2001 11:33:48 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIXkN27153 for ; Thu, 16 Aug 2001 11:33:46 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIa7627917 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:36:08 -0400 Message-ID: <3B7C1297.7000903@ecal.com> Date: Thu, 16 Aug 2001 14:36:07 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: Item Registration Considered Harmful 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 The CAP draft defines a process for registering new "items" for CAP. I believe this is a bad idea. CAP seems to have picked up the "item registration" meme from iCalendar, which got it from MIME. In MIME, it makes sense (all Content-types, for example, are independent); in iCalendar, it's risky (different properties can interact); in CAP, it's an out-and-out mistake. CAP is a protocol, not a data format; it cannot be defined piecemeal. For that reason, protocols need to be updated by the normal RFC process. If someone wants to define, say, a new method for CAP, they need to write an I-D and get it approved as a standards-track RFC, updating the CAP RFC. (This does not mean that they have to reissue an updated CAP RFC; they can have a smaller RFC that just defines the new method.) This is the normal mechanism for extending protocols. We should not be coming up with our own mechanism just for CAP. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"We can't duplicate the bug." "Have you tried| |francis@ecal.com |the Xerox machine?" | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:49:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19479 for ; Thu, 16 Aug 2001 14:49:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIT5c26830 for ietf-calendar-bks; Thu, 16 Aug 2001 11:29:05 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIT3N26825 for ; Thu, 16 Aug 2001 11:29:03 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIVO627806 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 16 Aug 2001 14:31:25 -0400 Message-ID: <3B7C117C.70105@ecal.com> Date: Thu, 16 Aug 2001 14:31:24 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: why 2 ways to organize calendars? 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 Section 1.3 of the CAP draft defines Calendar Collections. But we've already got calendars organized heirarchically; why do we need two separate ways to organize them? -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"If there's anything The Flintstones have taught| |francis@ecal.com |us, it's that pelicans can be used to mix | | |cement." -- Homer Simpson | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:51:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19577 for ; Thu, 16 Aug 2001 14:51:00 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIUnG26967 for ietf-calendar-bks; Thu, 16 Aug 2001 11:30:49 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIUlN26963 for ; Thu, 16 Aug 2001 11:30:48 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIX8627853 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:33:09 -0400 Message-ID: <3B7C11E4.5010802@ecal.com> Date: Thu, 16 Aug 2001 14:33:08 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: Bounded latency 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 CAP has features to let the client specify that the server should not spend more than X amount of time on a request. I believe that these features should be removed, or made optional, because they are essentially impossible to implement in a single-threaded server. If my server is working on the client's request, the only way I could possibly apply the latency limit would be by setting an alarm to interrupt me. But such alarms are not safe; generally speaking, they can interrupt any operation, whether or not it leaves the system in an unsafe state. If the bounded latency stuff is cut, that means ABORT and CONTINUE must be cut. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"HTTP is what happens in the absence of good | |francis@ecal.com |design." -- Keith Moore | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:51:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19592 for ; Thu, 16 Aug 2001 14:51:04 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIXTc27144 for ietf-calendar-bks; Thu, 16 Aug 2001 11:33:29 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIXRN27136 for ; Thu, 16 Aug 2001 11:33:27 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIZm627909 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 16 Aug 2001 14:35:49 -0400 Message-ID: <3B7C1284.8070201@ecal.com> Date: Thu, 16 Aug 2001 14:35:48 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: why does a calendar have a TZID? 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 CAP section 10.2 lists a TZID property for a calendar. What does this mean? Every DSTART, etc., in every VEVENT, etc., in the calendar has to specify its own TZID. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |If God had meant us to be in the Army, we | |francis@ecal.com |would've been born with green, baggy skin. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:51:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19606 for ; Thu, 16 Aug 2001 14:51:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIVVA27014 for ietf-calendar-bks; Thu, 16 Aug 2001 11:31:31 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIVSN27010 for ; Thu, 16 Aug 2001 11:31:29 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIXn627869 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:33:50 -0400 Message-ID: <3B7C120D.9070007@ecal.com> Date: Thu, 16 Aug 2001 14:33:49 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: MUST anonymous auth? 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 CAP section 2.4.2.2 says that an implementation MUST support anonymous authentication. Why? Why should a CS whose owners don't have any content they're going to expose to anonymous users have code for anonymous auth? Also, in section 7.1.3.1, which discusses anon auth, it says "The user's normal UPN MUST not be used for the subsequent CAP operations". (a) Why not? (b) What happens if it is used? (c) Should that be "MUST NOT"? -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |It's not an optical illusion, it just looks like| |francis@ecal.com |one. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:51:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19624 for ; Thu, 16 Aug 2001 14:51:09 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIX5N27120 for ietf-calendar-bks; Thu, 16 Aug 2001 11:33:05 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIX4N27116 for ; Thu, 16 Aug 2001 11:33:04 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIZO627901 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:35:26 -0400 Message-ID: <3B7C126C.8020803@ecal.com> Date: Thu, 16 Aug 2001 14:35:24 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: "iTIP message queued too long" 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 does CAP response code 10.5 (see section 8) mean? "The ITIP message has been queued too too long. Delivery has been aborted." Aside from the extra "too", it's unclear when this would be used. I suppose I could see bouncing back a message that's taken too long to deliver; but it wouldn't be as a response code (you wouldn't expect the CAP connection to stay open that long), it'd be as a separate CAP session or something. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"I only wish I had time to get married myself,| |francis@ecal.com |as I've told m'wife many's the time." | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:51:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19641 for ; Thu, 16 Aug 2001 14:51:10 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIYlP27212 for ietf-calendar-bks; Thu, 16 Aug 2001 11:34:47 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIYiN27204 for ; Thu, 16 Aug 2001 11:34:44 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIb4627929 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:37:06 -0400 Message-ID: <3B7C12D0.1030006@ecal.com> Date: Thu, 16 Aug 2001 14:37:04 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: implications of fanout 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 Section 2.4 ("Security Model") points out that CAP's wide variety of connectivity scenarios complicates the security model; personally, I'd consider that another argument against fanout. If we remove fanout, there is a lot of text in the draft to be removed. A probably-incomplete list: * 2.6: "A qualified calendar address is required when the of the target calendar address differs from that of the CAP server receiving the command". * 7.2.1.7, 7.2.2.{2,3,4}: response 2.2 makes sense only in case of fanout. * 8: response 2.0.6 makes sense only in case of fanout. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"HTTP is what happens in the absence of good | |francis@ecal.com |design." -- Keith Moore | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:51:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19676 for ; Thu, 16 Aug 2001 14:51:37 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIUDE26901 for ietf-calendar-bks; Thu, 16 Aug 2001 11:30:13 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIUCN26897 for ; Thu, 16 Aug 2001 11:30:12 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIWW627837 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:32:33 -0400 Message-ID: <3B7C11C0.8080200@ecal.com> Date: Thu, 16 Aug 2001 14:32:32 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: no ordering on GRANT/DENY? 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 CAP section 2.4.4.1 says that there is no ordering on the GRANT and DENY properties in a VCAR, and has an editor's note saying that this may be incorrect. I think it's definitely incorrect--if GRANT and DENY don't have ordering, then you run into big trouble trying to specify something like "grant access to the British royal family, but deny access to Prince Charles", since you don't know which rule will take precedence. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"HTTP is what happens in the absence of good | |francis@ecal.com |design." -- Keith Moore | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 14:52:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19706 for ; Thu, 16 Aug 2001 14:52:44 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIY0127171 for ietf-calendar-bks; Thu, 16 Aug 2001 11:34:00 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIXwN27165 for ; Thu, 16 Aug 2001 11:33:58 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIaI627921 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:36:20 -0400 Message-ID: <3B7C12A2.4040600@ecal.com> Date: Thu, 16 Aug 2001 14:36:18 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: deferring response to REFRESH? 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 CAP section 7.2.2.7 says that the CS should not automatically respond to a REFRESH if there are pending iTIP messages that may affect the response to the REFRESH. I believe this is a mistake. When each pending message is processed, after all, it will trigger a new message to each ATTENDEE, so it's not as if responding immediately to REFRESH will deprive the sender of some information. An immediate response, in fact, is probably for the best. Somebody sent that REFRESH because they didn't have up-to-date information; better to update them at once than to wait. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |No matter how subtle the wizard, a knife in the| |francis@ecal.com |shoulderblades will cramp his style. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 15:07:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20127 for ; Thu, 16 Aug 2001 15:07:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIxt528240 for ietf-calendar-bks; Thu, 16 Aug 2001 11:59:55 -0700 (PDT) Received: from lin2.nas.cmu.edu (LIN2.NAS.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIxrN28235 for ; Thu, 16 Aug 2001 11:59:54 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) (user=leg mech=KERBEROS_V4 (56 bits)) by lin2.nas.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7GIxrgm002457; Thu, 16 Aug 2001 14:59:53 -0400 Date: Thu, 16 Aug 2001 14:59:53 -0400 Message-Id: <200108161859.f7GIxrgm002457@lin2.nas.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: calsch WG , John Stracke In-reply-to: <3B7C11F7.7070503@ecal.com> Subject: Re: CAP: SASL mechanisms and MITM attacks References: <3B7C11F7.7070503@ecal.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: This is only useful if integrity or privacy protection were negotiated. Clients MUST have minimal acceptable security parameters to avoid the active attacker problem. Larry Date: Thu, 16 Aug 2001 14:33:27 -0400 From: John Stracke Organization: eCal Corporation CAP section 7.1.3 discusses the risk of an attacker forcing the client to pick a weak SASL mechanism. It says that the CUA should fetch the list of supported mechanisms after authenticating, to make sure it hasn't changed. First: it's not clear to me how this fetch would be done; can we spell it out? Second: does this actually do any good? Can't the man-in-the-middle change the list of supported mechanisms after authenticating, as well as before? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This space intentionally left blank. | |francis@ecal.com | | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 15:07:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20140 for ; Thu, 16 Aug 2001 15:07:36 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GIw5j28086 for ietf-calendar-bks; Thu, 16 Aug 2001 11:58:05 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIw4N28082 for ; Thu, 16 Aug 2001 11:58:04 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA31460; Thu, 16 Aug 2001 14:58:01 -0400 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 f7GIw0f23186; Thu, 16 Aug 2001 14:58:00 -0400 (EDT) Message-Id: <5.1.0.14.0.20010816144745.01f7e9b8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 16 Aug 2001 14:58:17 -0400 To: Gary Frederick From: Alan Davies Subject: Re: The iCalendar XML DTD Cc: ietf-calendar@imc.org In-Reply-To: <3B7C0424.2010000@jsoft.com> References: <5.1.0.14.0.20010816103238.01f6aab0@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 found what appears to be another (also expired, but seemingly slightly newer- the version number is 01) version of this draft here: http://www.watersprings.org/pub/id/draft-many-ical-xmldoc-01.txt I also found a few places that make reference to draft-many-ical-xmldoc-02, which has also expired, if it was ever submitted. Does a copy of this still exist anywhere? --Alan At 12:34 PM 16/08/2001 -0500, Gary Frederick wrote: >I would like a cleaned up copy of the iPlanet DTD. Thanks... > >I recently modified the libical library to output XML. No DTD, the XML >looks like the iCalendar 'objects'. It should be easy to translate my >output to whatever standard if one is picked. > >I don't think it's necessary to have an iCalendar XML DTD. The iCalendar >standard exists and is used by lots of software. If XML were used instead >of the current iCalendar format, the world would be a better place... but >it was not. :-) > >If people use XML and publish their formats, others can interface. > >I love getting 'iCalendar' in XML. We have XSL stylesheets that are easy >for non-developers to modify. > >I am marginal about suffering thru the process of coming up with a >standard DTD. Sounds like more trouble than it's worth. > > --- > >and I plan on looking at the RDF Calendar taskforce info David King >pointed out (thanks!) > >and I would be interested in talking with others that are using XML with >iCalendar (off list???) > >Gary From owner-ietf-calendar@mail.imc.org Thu Aug 16 15:12:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20226 for ; Thu, 16 Aug 2001 15:11:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GJ2V628452 for ietf-calendar-bks; Thu, 16 Aug 2001 12:02:31 -0700 (PDT) Received: from lin2.nas.cmu.edu (LIN2.NAS.CMU.EDU [128.2.6.35]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GJ2UN28448 for ; Thu, 16 Aug 2001 12:02:30 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) (user=leg mech=KERBEROS_V4 (56 bits)) by lin2.nas.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7GJ2Ugm002464; Thu, 16 Aug 2001 15:02:30 -0400 Date: Thu, 16 Aug 2001 15:02:30 -0400 Message-Id: <200108161902.f7GJ2Ugm002464@lin2.nas.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: calsch WG , John Stracke In-reply-to: <3B7C1201.8090107@ecal.com> Subject: Re: CAP: cancelling authentication References: <3B7C1201.8090107@ecal.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: Note that most other SASL protocols support cancelling authentication and retrying in the same session. I don't think it makes a big deal either way. I agree it makes sense for the connection to be closed immediately if authentication can't be reattempted. Larry Date: Thu, 16 Aug 2001 14:33:37 -0400 From: John Stracke Organization: eCal Corporation CAP section 7.1.3 mentions that what happens if the authentication process is cancelled during its negotiation is implementation-specific; I'm afraid this might lead to a lack of interop. A little further down, it mentions that the CUA may not (I believe it should be MUST NOT) reissue AUTHENTICATE, even if the first attempt was aborted; if the CUA attempts to do so, the CS must (MUST?) terminate the session. I believe this can be simplified simply by requiring the CS to drop the connection immediately if the AUTHENTICATE is cancelled. Since no further AUTHENTICATE can be issued, that connection cannot be used again; keeping it open has no value. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Anyone who has a conditioned response | |francis@ecal.com |immediately thinks of Pavlov. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 15:39:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19269 for ; Thu, 16 Aug 2001 14:44:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GIWto27103 for ietf-calendar-bks; Thu, 16 Aug 2001 11:32:55 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GIWqN27098 for ; Thu, 16 Aug 2001 11:32:53 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GIZD627897 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 14:35:14 -0400 Message-ID: <3B7C1261.1090102@ecal.com> Date: Thu, 16 Aug 2001 14:35:13 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: CAP: order of processing iTIP messages 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 CAP section 7.2.2.1 says, "The CUA MUST process the scheduled components in the order sent." This sounds like it means "in the order sent over the CAP connection by the CS", which implies that the CS needs to preserve the order in which it received the components (tricky, and not a good thing anyway, if they arrived out of order). I believe that what the authors probably meant was that the iTIP components have to be processed in the order in which they were originally sent from the iTIP sender. But I'm pretty sure this does not need to be specified in CAP; it's part of iTIP, isn't it? -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |A computer without Windows is like a chocolate| |francis@ecal.com |cake without mustard. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 15:45:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21175 for ; Thu, 16 Aug 2001 15:45:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GJVoR29636 for ietf-calendar-bks; Thu, 16 Aug 2001 12:31:50 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GJVmN29632 for ; Thu, 16 Aug 2001 12:31:48 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GJY9628103 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 15:34:10 -0400 Message-ID: <3B7C2030.5060706@ecal.com> Date: Thu, 16 Aug 2001 15:34:08 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 2445:4.1 (x-name) is misleading. 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 Shannon J. Clark wrote: >I was under the impression that the intention of X- prefixed elements was >that they were to be preserved by all compliant systems - but could be >ignored by any system without risk. > For properties and parameters, this would be a possible approach (though not what's specified); but, for some of the places where x-name appears (e.g., values of PARTSTAT), it wouldn't work; ignoring it would mean no value at all. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |All I ask is a chance to prove that money can't| |francis@ecal.com|make me happy. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 15:53:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21421 for ; Thu, 16 Aug 2001 15:53:00 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7GJYoH29743 for ietf-calendar-bks; Thu, 16 Aug 2001 12:34:50 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GJYmN29738 for ; Thu, 16 Aug 2001 12:34:48 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7GJb9628113 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 16 Aug 2001 15:37:10 -0400 Message-ID: <3B7C20E5.7040206@ecal.com> Date: Thu, 16 Aug 2001 15:37:09 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: cancelling authentication References: <3B7C1201.8090107@ecal.com> <200108161902.f7GJ2Ugm002464@lin2.nas.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: >Note that most other SASL protocols support cancelling authentication >and retrying in the same session. > If it can be done, then, yes, I agree that's probably a bit better. It just needs to be defined how. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"You gotta learn to dance before you learn to| |francis@ecal.com|crawl!" -- Meatloaf, "Everything Louder than | | |Everything Else" | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 16 21:50:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29901 for ; Thu, 16 Aug 2001 21:50:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7H1L3v05538 for ietf-calendar-bks; Thu, 16 Aug 2001 18:21:03 -0700 (PDT) Received: from imo-m08.mx.aol.com (imo-m08.mx.aol.com [64.12.136.163]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7H1L2N05534 for ; Thu, 16 Aug 2001 18:21:02 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-m08.mx.aol.com (mail_out_v31_r1.3.) id 3.52.9d46bc (16229); Thu, 16 Aug 2001 21:20:54 -0400 (EDT) Received: from netscape.net (host-192-125-18-192.iplanet.com [192.18.125.192]) by air-in02.mx.aol.com (v80.17) with ESMTP id MAILININ25-0816212054; Thu, 16 Aug 2001 21:20:54 -0400 Message-ID: <3B7C7176.2070601@netscape.net> Date: Thu, 16 Aug 2001 18:20:54 -0700 From: Roger D User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-GB,en,en-US MIME-Version: 1.0 To: francis@ecal.com, ietf-calendar@imc.org Subject: Re: Proposed change to iCal (was RE: Adding more unique identifiers) References: <4FB1B360.201909CA.10749803@netscape.net (Roger D <3B7128D3.CE783677@ecal.com> <3B79D00E.2000105@netscape.net> <3B7A7F3E.4010307@ecal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit francis@ecal.com wrote: > I dunno; it sounds to me like an edge case. Data integrity if the user uses more than one CUA is an edge case? I don't regard it as such: plenty of people have at least two out of: work desktop, home desktop, laptop, PDA, direct website connection to server, voice access to server. > It is a problem, but a > solved one (I think): that's what sync engines are for. That's exactly what I'm tring to do: write a synch engine. The iCal standard is inadequate to the task, since it contains lists on anonymous elements. --Roger From owner-ietf-calendar@mail.imc.org Thu Aug 16 22:19:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00103 for ; Thu, 16 Aug 2001 22:19:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7H2Abm06561 for ietf-calendar-bks; Thu, 16 Aug 2001 19:10:37 -0700 (PDT) Received: from imo-m04.mx.aol.com (imo-m04.mx.aol.com [64.12.136.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7H2AZN06555 for ; Thu, 16 Aug 2001 19:10:35 -0700 (PDT) Received: from rogerdox14@netscape.net by imo-m04.mx.aol.com (mail_out_v31_r1.3.) id e.1d.1df48c2 (16233); Thu, 16 Aug 2001 22:10:05 -0400 (EDT) Received: from netscape.net (host-192-125-18-192.iplanet.com [192.18.125.192]) by air-in02.mx.aol.com (v80.17) with ESMTP id MAILININ29-0816221005; Thu, 16 Aug 2001 22:10:05 -0400 Message-ID: <3B7C7CFE.5030209@netscape.net> Date: Thu, 16 Aug 2001 19:10:06 -0700 From: Roger D User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-GB,en,en-US MIME-Version: 1.0 To: aland@steltor.com CC: francis@ecal.com, ietf-calendar@imc.org Subject: Re: Proposed change to iCal (was RE: Adding more unique identifiers) References: <4FB1B360.201909CA.10749803@netscape.net (Roger D <3B7128D3.CE783677@ecal.com> <5.1.0.14.0.20010815092552.01f61008@imap1.in.steltor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit aland@steltor.com wrote: > At 06:27 PM 14/08/2001 -0700, Roger D wrote: >> [...] This makes trying to merge changes to these items extremely difficult >> for the server: if you started with list {a, b} and sent back {c, d}, did >> you intend to delete a and b and add c and d, or to change a into c and b >> into d, or to change a into d and b into c, or to delete a, add b, and change >> c into d, etc.? How should this be merged with another change that started with >> {a, b} and returned {b} (presumably they just deleted a, but even this is not >> completely clear). ... > How would the PUIDs help a CS to solve the problem that you stated and I quoted > above, where two CUAs modify the same list? It still doesn't know which combination > of b, c and d to keep without user interaction. Can you give an example of > a CS correctly performing a merge with a conflict that couldn't have been > resolved without PUIDs? 1) A VEVENT is somehow created on the server with two RESOURCES: "flipchat" and "projector". Each has been issued a PUID. 2) A copy of the VEVENT is downloaded to a CUA on the user's laptop, where it is cached. 3) A copy of the VEVENT is downloaded to another CUA on the PDA of the user's secretary (who has "act on behalf" of privileges for the user), where it is cached. 4) Working offline (his radio modem has temporarily dropped the connection due to poor reception on the train he's on), the user deletes "projecter" since he recalls that the location they will be using has one built in and so it doesn't need to be arranged specially. Later he adds "microphone and PA system" (this gets issued a new PUID), since he recalls that the ones installed in the location are unreliable. 5) Also working offline (waiting at a bus terminal), the user's secretary corrects the misspelling of "flipchat" to "flipchart" and "projecter" to "projector". Since these are modification of the existing items, her CUA retains the same PUIDs for them. 6) At some point and in some order, the user's laptop and the secretary's PDA get resynched with the server. a) Suppose the secretary's PDA synchs first. The server sees an incoming item with the same sequence number as it's version (since none of these changes were large enough to require a new sequence number). Where it has: {"flipchat"[PUID=1], "projecter"[PUID=2]} the incoming version has: {"flipchart"[PUID=1], "projector"[PUID=2]} The server knows that this is a change of the name of both items, and updates itself to: {"flipchart"[PUID=1], "projector"[PUID=2]} Then the laptop synchronizes. The server knows that the version that the laptop downloaded was: {"flipchat"[PUID=1], "projecter"[PUID=2]} What is returned is: {"flipchat"[PUID=1], "microphone and PA system"[PUID=3]} The server notes that they did not modify the item with PUID=1, so it retains latest version, i.e. the secretary's correction of this to "flipchart". However, they did delete the item with PUID=2, so the secretaries corrected version "projector" is deleted, and they added a new item with a new PUID, "microphone and PA system". The system thus sets itself to: {"flipchart"[PUID=1], "microphone and PA system"[PUID=3]} b) Suppose the user's laptop synchs first. The server sees an incoming item with the same sequence number as it's version (since none of these changes were large enough to require a new sequence number). Where it has: {"flipchat"[PUID=1], "projecter"[PUID=2]} the incoming version has: {"flipchat"[PUID=1], "microphone and PA system"[PUID=3]} The server updates itself to this. Then the secretary's PDA synchronizes. The server knows that the version that the PDA downloaded was: {"flipchat"[PUID=1], "projecter"[PUID=2]} What is returned is: {"flipchart"[PUID=1], "projector"[PUID=2]} The server accepts the update of item with PUID=1, but discards that of the item with PUID=2 since that item has been deleted. The system thus sets itself to: {"flipchart"[PUID=1], "microphone and PA system"[PUID=3]} Thus, regardless of the order the changes arrive in, the server merges them and ends up with the same result, which is different from (and superior to) either of the versions that were returned to it. I have been unable to think of any way of producing this result without using a unique identifier. iCal recognizes the importance of unique identifiers and puts UIDs on many items in the standard: it just doesn't go far enough. > A CS also has to rely on both CUAs interpreting this sentence in the > same way: "changing a into b would keep the same unique identifier". > What exactly does "changing a into b" mean? For this to be useful the user interfaces of both CUAs need to distinguish between "delete 'projecter', then as a later operation add 'microphone and PA system' [which gets a new PUID]" and "transform 'flipchat' into 'flipchart' [keeping the same PUID]". This is a common distinction to make in graphical user interfaces (e.g. deleting one file and later creating another is a different operation from simply renaming the file). Obviously there may be CUAs that don't make this distinction, or that don't retain and return the PUID. If so, merging their changes into the others will work just as badly as things do currently. But to the extent that the server and all CUAs involved maintain and correctly use PUIDs, the result will be more accurate merging of changes coming from different sources. --Roger From owner-ietf-calendar@mail.imc.org Fri Aug 17 11:25:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05083 for ; Fri, 17 Aug 2001 11:25:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HEvYw25870 for ietf-calendar-bks; Fri, 17 Aug 2001 07:57:34 -0700 (PDT) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HEvXN25866 for ; Fri, 17 Aug 2001 07:57:33 -0700 (PDT) Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.140.169.29]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 7B12262; Fri, 17 Aug 2001 16:57:25 +0200 (METDST) Received: from isar.bbn.hp.com (isar.bbn.hp.com [15.140.168.13]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id QAA29250; Fri, 17 Aug 2001 16:57:33 +0200 (METDST) Received: from 15.140.168.13 by isar.bbn.hp.com (InterScan E-Mail VirusWall NT); Fri, 17 Aug 2001 16:57:32 +0200 (W. Europe Daylight Time) Received: by isar.bbn.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 16:57:32 +0200 Message-ID: From: "NITSCH,FRANK (HP-Germany,ex1)" To: "'Alan Davies'" Cc: "IETF-Calendar Mailing List (E-mail)" Subject: RE: The iCalendar XML DTD Date: Fri, 17 Aug 2001 16:57:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alan, I'm also interested in this cleaned up version of iPlanet's DTD. I have asked for XML on this list a while ago. David gave me the pointer to RDF which was completely new to me (Thanx David!). After reading an introduction to RDF I think I have an idea what RDF is used for. But when I'm looking at the RDF Calendaring progress I have the feeling that there's not yet a package one could call "ready". David: have you worked with the RDF Calendar stuff already? Could you make a statement what state it has? I find it difficult to draw a picture of the information offered on their home page... What I had hoped was that this RDF Calendar effort would provide tools (maybe a library as libical) for converting RDF Calendar data to iCalendar data and vice versa. I think it would be best if libical would contain an RDF Calendar parser. But this will probably not happen before the RDF efforts are somehow established. Gary: I'm going to start with iCalendar in XML pretty soon. So if you want we can exchange findings and experiences "off list". ;-) Best Regards Frank -- ==================================================================== Frank Nitsch mailto:frank_nitsch@hp.com -------------------------------------------------------------------- Hewlett-Packard GmbH | http://www.hewlett-packard.de Mailstop ASM-NGP, Building B32/3M17 | HP-Telnet 777-2135 Herrenberger Strasse 110-140 | Phone (+49) 07031/14-2135 D-71034 Boeblingen | Fax (+49) 07031/14-8253 ==================================================================== Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus, Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081 ==================================================================== > -----Original Message----- > From: Alan Davies [mailto:aland@steltor.com] > Sent: Thursday, 16 August, 2001 16:39 > To: Leveille,Peter S. > Cc: ietf-calendar@imc.org > Subject: Re: The iCalendar XML DTD > > > > A (slightly) more recent version was written by Dawson, Reddy, and > Royer. iPlanet appears to use it in their server, and has a > copy of the (expired) draft here on their website (unfortunately > it suffers from formatting problems, I can mail a cleaned up > version on request to anyone who's interested): > > http://developer.iplanet.com/docs/wpapers/calendar/ietf.txt > > Several different vendors use xml representations of iCalendar, > and this draft will be resurrected and completed/corrected in the > future to standardise them. > > --Alan > > At 09:50 AM 16/08/2001 -0700, you wrote: > > >I have found the IETF internet draft dated December 4, 1998 for the > >iCalendar XML DTD. Is there a more recent copy of this material? > > > >Thanks, > >-Pete > From owner-ietf-calendar@mail.imc.org Fri Aug 17 12:10:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06824 for ; Fri, 17 Aug 2001 12:10:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HFvIY00696 for ietf-calendar-bks; Fri, 17 Aug 2001 08:57:18 -0700 (PDT) Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HFvHN00688 for ; Fri, 17 Aug 2001 08:57:17 -0700 (PDT) Received: from provence (prgy-npn1.prodigy.com [207.115.54.37]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with SMTP id f7HFv61115812; Fri, 17 Aug 2001 11:57:10 -0400 Message-ID: <099401c12735$9a1f0a40$a1c1a8c0@prodigy.com> From: "bpapkin" To: "NITSCH,FRANK \(HP-Germany,ex1\)" , "'Alan Davies'" Cc: "IETF-Calendar Mailing List \(E-mail\)" References: Subject: Re: The iCalendar XML DTD Date: Fri, 17 Aug 2001 11:59:27 -0400 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.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit If you guys do decide to extend this thread "off list", please copy to me. I may have to deal with this soon. ================================================================== Code is not a crime: help to absolve Dmitry Sklyarov. Sign the petition: http://www.dibona.com/dmca/ Updates: http://www.freesklyarov.org/ Write: http://www.boycottadobe.org/ Attend: http://www.freesklyarov.org/calendar/index.html =================================================================== ----- Original Message ----- From: "NITSCH,FRANK (HP-Germany,ex1)" To: "'Alan Davies'" Cc: "IETF-Calendar Mailing List (E-mail)" Sent: Friday, August 17, 2001 10:57 AM Subject: RE: The iCalendar XML DTD > > Hi Alan, > > I'm also interested in this cleaned up version of iPlanet's DTD. > I have asked for XML on this list a while ago. David gave me the > pointer to RDF which was completely new to me (Thanx David!). > After reading an introduction to RDF I think I have an idea what > RDF is used for. But when I'm looking at the RDF Calendaring > progress I have the feeling that there's not yet a package one > could call "ready". > David: have you worked with the RDF Calendar stuff already? Could > you make a statement what state it has? I find it difficult to > draw a picture of the information offered on their home page... > > What I had hoped was that this RDF Calendar effort would provide > tools (maybe a library as libical) for converting RDF Calendar > data to iCalendar data and vice versa. I think it would be best > if libical would contain an RDF Calendar parser. But this will > probably not happen before the RDF efforts are somehow established. > > Gary: I'm going to start with iCalendar in XML pretty soon. So if > you want we can exchange findings and experiences "off list". ;-) > > Best Regards > > Frank > -- > ==================================================================== > Frank Nitsch mailto:frank_nitsch@hp.com > -------------------------------------------------------------------- > Hewlett-Packard GmbH | http://www.hewlett-packard.de > Mailstop ASM-NGP, Building B32/3M17 | HP-Telnet 777-2135 > Herrenberger Strasse 110-140 | Phone (+49) 07031/14-2135 > D-71034 Boeblingen | Fax (+49) 07031/14-8253 > ==================================================================== > Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen > Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus, > Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms > Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081 > ==================================================================== > > > -----Original Message----- > > From: Alan Davies [mailto:aland@steltor.com] > > Sent: Thursday, 16 August, 2001 16:39 > > To: Leveille,Peter S. > > Cc: ietf-calendar@imc.org > > Subject: Re: The iCalendar XML DTD > > > > > > > > A (slightly) more recent version was written by Dawson, Reddy, and > > Royer. iPlanet appears to use it in their server, and has a > > copy of the (expired) draft here on their website (unfortunately > > it suffers from formatting problems, I can mail a cleaned up > > version on request to anyone who's interested): > > > > http://developer.iplanet.com/docs/wpapers/calendar/ietf.txt > > > > Several different vendors use xml representations of iCalendar, > > and this draft will be resurrected and completed/corrected in the > > future to standardise them. > > > > --Alan > > > > At 09:50 AM 16/08/2001 -0700, you wrote: > > > > >I have found the IETF internet draft dated December 4, 1998 for the > > >iCalendar XML DTD. Is there a more recent copy of this material? > > > > > >Thanks, > > >-Pete > > From owner-ietf-calendar@mail.imc.org Fri Aug 17 15:04:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12905 for ; Fri, 17 Aug 2001 15:04:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HITQj03804 for ietf-calendar-bks; Fri, 17 Aug 2001 11:29:26 -0700 (PDT) Received: from eeyore.jsoft.com (mail.jsoft.com [24.240.234.245] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HITPN03799 for ; Fri, 17 Aug 2001 11:29:25 -0700 (PDT) Received: from jsoft.com (IDENT:ggf@eeyore.jsoft.com [192.168.1.46]) by eeyore.jsoft.com (8.11.0/8.11.0) with ESMTP id f7HIYiC07688; Fri, 17 Aug 2001 13:34:44 -0500 Message-ID: <3B7D63C4.2010706@jsoft.com> Date: Fri, 17 Aug 2001 13:34:44 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: bpapkin CC: "NITSCH,FRANK (HP-Germany,ex1)" , "'Alan Davies'" , "IETF-Calendar Mailing List (E-mail)" Subject: Re: The iCalendar XML DTD References: <099401c12735$9a1f0a40$a1c1a8c0@prodigy.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 Off list we go. I'll report back when (if) there is something to report. Gary bpapkin wrote: > If you guys do decide to extend this thread "off list", > please copy to me. I may have to deal with this soon. > > ================================================================== > Code is not a crime: help to absolve Dmitry Sklyarov. > Sign the petition: http://www.dibona.com/dmca/ > Updates: http://www.freesklyarov.org/ > Write: http://www.boycottadobe.org/ > Attend: http://www.freesklyarov.org/calendar/index.html > =================================================================== > > ----- Original Message ----- > From: "NITSCH,FRANK (HP-Germany,ex1)" > To: "'Alan Davies'" > Cc: "IETF-Calendar Mailing List (E-mail)" > Sent: Friday, August 17, 2001 10:57 AM > Subject: RE: The iCalendar XML DTD > > > >>Hi Alan, >> >>I'm also interested in this cleaned up version of iPlanet's DTD. >>I have asked for XML on this list a while ago. David gave me the >>pointer to RDF which was completely new to me (Thanx David!). >>After reading an introduction to RDF I think I have an idea what >>RDF is used for. But when I'm looking at the RDF Calendaring >>progress I have the feeling that there's not yet a package one >>could call "ready". >>David: have you worked with the RDF Calendar stuff already? Could >>you make a statement what state it has? I find it difficult to >>draw a picture of the information offered on their home page... >> >>What I had hoped was that this RDF Calendar effort would provide >>tools (maybe a library as libical) for converting RDF Calendar >>data to iCalendar data and vice versa. I think it would be best >>if libical would contain an RDF Calendar parser. But this will >>probably not happen before the RDF efforts are somehow established. >> >>Gary: I'm going to start with iCalendar in XML pretty soon. So if >>you want we can exchange findings and experiences "off list". ;-) >> >>Best Regards >> >>Frank >>-- >>==================================================================== >>Frank Nitsch mailto:frank_nitsch@hp.com >>-------------------------------------------------------------------- >>Hewlett-Packard GmbH | http://www.hewlett-packard.de >>Mailstop ASM-NGP, Building B32/3M17 | HP-Telnet 777-2135 >>Herrenberger Strasse 110-140 | Phone (+49) 07031/14-2135 >>D-71034 Boeblingen | Fax (+49) 07031/14-8253 >>==================================================================== >>Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen >>Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus, >>Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms >>Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081 >>==================================================================== >> >> >>>-----Original Message----- >>>From: Alan Davies [mailto:aland@steltor.com] >>>Sent: Thursday, 16 August, 2001 16:39 >>>To: Leveille,Peter S. >>>Cc: ietf-calendar@imc.org >>>Subject: Re: The iCalendar XML DTD >>> >>> >>> >>>A (slightly) more recent version was written by Dawson, Reddy, and >>>Royer. iPlanet appears to use it in their server, and has a >>>copy of the (expired) draft here on their website (unfortunately >>>it suffers from formatting problems, I can mail a cleaned up >>>version on request to anyone who's interested): >>> >>>http://developer.iplanet.com/docs/wpapers/calendar/ietf.txt >>> >>>Several different vendors use xml representations of iCalendar, >>>and this draft will be resurrected and completed/corrected in the >>>future to standardise them. >>> >>>--Alan >>> >>>At 09:50 AM 16/08/2001 -0700, you wrote: >>> >>> >>>>I have found the IETF internet draft dated December 4, 1998 for the >>>>iCalendar XML DTD. Is there a more recent copy of this material? >>>> >>>>Thanks, >>>>-Pete >>>> From owner-ietf-calendar@mail.imc.org Sat Aug 18 15:21:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14971 for ; Sat, 18 Aug 2001 15:21:47 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7IIxNZ01141 for ietf-calendar-bks; Sat, 18 Aug 2001 11:59:23 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IIxMN01137 for ; Sat, 18 Aug 2001 11:59:22 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA24960; Sat, 18 Aug 2001 14:59:19 -0400 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7IIxIf29991; Sat, 18 Aug 2001 14:59:18 -0400 (EDT) Message-ID: <3B7EBB55.D160133F@steltor.com> Date: Sat, 18 Aug 2001 15:00:37 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: inconsistency in Overlapped Booking definition References: <3B7C1184.2070801@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes it seems wrong. Anyone know of why we need or wanted Overlapped Booking policies for individual entries? If there are no objections, I'll fix the definition of Overlapped Booking. George John Stracke wrote: > > In section 1.3, the definition of Overlapped Booking says it's a > policy that can be applied to a calendar or an individual entry. > However, the definition of Calendar Policy seems to indicate that > policies apply only to calendars; this is inconsistent. > > In any case, it seems like an Overlapped Booking policy for individual > entries would be redundant, since the same effect can be obtained by the > TRANSP property on VEVENTs. > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |Dave Barry for President! He'll Keep Dan Quayle.| > |francis@ecal.com |(OK, it's old) | > \=================================================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 18 15:22:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14982 for ; Sat, 18 Aug 2001 15:22:00 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7IJ5q001301 for ietf-calendar-bks; Sat, 18 Aug 2001 12:05:52 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IJ5oN01297 for ; Sat, 18 Aug 2001 12:05:50 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA24998; Sat, 18 Aug 2001 15:05:47 -0400 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7IJ5kf00412; Sat, 18 Aug 2001 15:05:46 -0400 (EDT) Message-ID: <3B7EBCD6.394323CF@steltor.com> Date: Sat, 18 Aug 2001 15:07:02 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: why define Resource Calendar? References: <3B7C1193.3060802@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think it is another unused definition. I see no difference. You can look at the mailing list archive to see if at one point there was a difference or if someone wanted resource calendars with different properties. George John Stracke wrote: > > In section 1.3, the definition of Resource Calendar says that there is > no syntactic difference between an RC and a Calendar. So why do we > define it at all? Is there any difference? > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |"Collect call from reality, will you accept | > |francis@ecal.com |the--" *click* | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 18 15:22:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14993 for ; Sat, 18 Aug 2001 15:22:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7IIt0c01074 for ietf-calendar-bks; Sat, 18 Aug 2001 11:55:00 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IIswN01070 for ; Sat, 18 Aug 2001 11:54:58 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA24956; Sat, 18 Aug 2001 14:54:50 -0400 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7IIsnf29744; Sat, 18 Aug 2001 14:54:50 -0400 (EDT) Message-ID: <3B7EBA48.60B2A349@steltor.com> Date: Sat, 18 Aug 2001 14:56:08 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: why 2 ways to organize calendars? References: <3B7C117C.70105@ecal.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 "Calendar Collections" is not used anywhere outside the definition section. We should remove it. One of the things on the CAP To Do list (http://calsch.org/ietf/cap-ToDo.txt) is to remove all unused definitions. If anyone finds any more unused definitions please let us know. George John Stracke wrote: > > Section 1.3 of the CAP draft defines Calendar Collections. But we've > already got calendars organized heirarchically; why do we need two > separate ways to organize them? > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |"If there's anything The Flintstones have taught| > |francis@ecal.com |us, it's that pelicans can be used to mix | > | |cement." -- Homer Simpson | > \=================================================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 18 15:23:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15022 for ; Sat, 18 Aug 2001 15:23:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7IJ3Jc01263 for ietf-calendar-bks; Sat, 18 Aug 2001 12:03:19 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IJ3IN01259 for ; Sat, 18 Aug 2001 12:03:18 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA24982; Sat, 18 Aug 2001 15:03:14 -0400 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7IJ3Df00320; Sat, 18 Aug 2001 15:03:14 -0400 (EDT) Message-ID: <3B7EBC41.A472E3AC@steltor.com> Date: Sat, 18 Aug 2001 15:04:33 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: OWNER of a CS? References: <3B7C118C.2090500@ecal.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 It is probably a mistake, or the OWNER of a CS was confused with the CALMASTER property of the CS. Will fix definition if there are no objections. George John Stracke wrote: > > In section 1.3., the definition of OWNER says "The owner is specified > in the OWNER calendar property and in the OWNER calendar store > property". What does OWNER mean when applied to a CS? > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |"Collect call from reality, will you accept | > |francis@ecal.com |the--" *click* | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 18 15:29:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15058 for ; Sat, 18 Aug 2001 15:29:24 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7IJCEN01494 for ietf-calendar-bks; Sat, 18 Aug 2001 12:12:14 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IJCCN01490 for ; Sat, 18 Aug 2001 12:12:12 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA25022; Sat, 18 Aug 2001 15:12:09 -0400 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7IJC8f00912; Sat, 18 Aug 2001 15:12:08 -0400 (EDT) Message-ID: <3B7EBE56.A8CFD5B9@steltor.com> Date: Sat, 18 Aug 2001 15:13:26 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: man-in-the-middle attacks References: <3B7C1199.3050306@ecal.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 Noted. Added this and plus previous items to the cap to do list. George John Stracke wrote: > > In section 2.4, it says that spoofing of a CS is due to a hostile > client, then lists the threats that can come from hostile agents between > client and server. I believe that spoofing of a CS is not due to a > hostile client at all (it's an attack *on* the client); it comes solely > from hostile intermediate agents (e.g., man-in-the-middle attackers). > > -- > /================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |===============================================| > |eCal Corp. |"Sometimes we in the media have to give the | > |francis@ecal.com |copycat criminals a little kick-start." -- Tina| > | |the Tech Writer, in _Dilbert_ | > \================================================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 18 15:33:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15096 for ; Sat, 18 Aug 2001 15:33:49 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7IJFNg01561 for ietf-calendar-bks; Sat, 18 Aug 2001 12:15:23 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IJFMN01557 for ; Sat, 18 Aug 2001 12:15:22 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA25030; Sat, 18 Aug 2001 15:15:19 -0400 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7IJFFf01000; Sat, 18 Aug 2001 15:15:15 -0400 (EDT) Message-ID: <3B7EBF13.2AE70968@steltor.com> Date: Sat, 18 Aug 2001 15:16:35 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: things that are out of scope References: <3B7C11AD.20201@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I am not sure why it was originally added to CAP. You can check the archive or the CAP requirements document. Paul? Steve? Do you know why these requirements are part of CAP. George John Stracke wrote: > > The CAP draft imposes some requirements that I believe are out of scope: > > * In section 2.4.2, there's a requirement that a CS integrated with > a directory system must support the ability to configure which > schema attribute stores the UPN. This is (a) irrelevant to CAP, > because it's hidden from a CAP client, and (b) a bad requirement, > because there is some value in implementations that couple the > different servers more tightly than this. If you want to be able > to mix-and-match LDAP and CAP servers, then this configurability > is a useful feature; but maybe you want to build a CAP server with > its own user directory, which exposes that directory via LDAP. > That's integration with a directory server (itself), but there is > no value in that case in being able to do this configuration. > * In 2.4.2.1, there's a requirement that a CAP implementation must > be able to configure what attribute in a certificate contains the > UPN. Again, this is out of scope, because it's irrelevant to CAP, > and it's not always a useful feature anyway (maybe your CS is also > your CA). > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |Vlad was not a vampire, but that's the only nice| > |francis@ecal.com |thing that could be said about him. | > \=================================================================/ From owner-ietf-calendar@mail.imc.org Sat Aug 18 15:35:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15113 for ; Sat, 18 Aug 2001 15:35:47 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7IJKc701614 for ietf-calendar-bks; Sat, 18 Aug 2001 12:20:38 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IJKbN01610 for ; Sat, 18 Aug 2001 12:20:37 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA25055; Sat, 18 Aug 2001 15:20:30 -0400 Received: from steltor.com (host5.vpn.cst.ca [192.168.6.5]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7IJKTf01289; Sat, 18 Aug 2001 15:20:30 -0400 (EDT) Message-ID: <3B7EC04D.DF1BC80@steltor.com> Date: Sat, 18 Aug 2001 15:21:49 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: matching common names References: <3B7C11B7.9010508@ecal.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 Noted on the to do list as an issue. Perhaps all we should compare is the UPN with the e-mail address? Suggestions? George John Stracke wrote: > > The last paragraph of CAP section 2.4.2.1 specifies that a CS or CUA > processing data received by iMIP should compare the personal-name part > of the From: email address with the CN part of the ORGANIZER or ATTENDEE > property, and refuse the message if they don't match. This is very > risky; people's names do not stay unchanged forever. Consider Lisa > Dusseault; in the time I've known her, she's also gone by Lisa Lippert > and Lisa Lippert-Dusseault. Looking at my old calsch mail, I see some > messages from her saying "Lisa Lippert (Dusseault) (Exchange)", which > brings up another, shorter time-scale problem: sometimes different UAs > for the same email address will be configured with slightly different names. > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |"The struggle is always worthwhile, if the end | > |francis@ecal.com |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 Sun Aug 19 13:52:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15067 for ; Sun, 19 Aug 2001 13:52:22 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7JHYsr25888 for ietf-calendar-bks; Sun, 19 Aug 2001 10:34:54 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7JHYqN25883 for ; Sun, 19 Aug 2001 10:34:53 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA28154; Sun, 19 Aug 2001 13:34:48 -0400 Received: from steltor.com (host4.vpn.cst.ca [192.168.6.4]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7JHYmf07995; Sun, 19 Aug 2001 13:34:48 -0400 (EDT) Message-ID: <3B7FF900.AC1E9196@steltor.com> Date: Sun, 19 Aug 2001 13:36:00 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: autologout References: <3B7C11D7.7080705@ecal.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 The issue of having a NOOP command, and allowing the server to ignore it did come up in January 2000 (see the archive). Looking at the archive, it was agreed to allow the server to ignore NOOP and still drop the connection. What you are suggesting is to return an error rather than simply ignore NOOP. Should we return an error, or simply allow the server to drop the connection despite the NOOPs? The reasons NOOP was kept was: - allow the client to attempt to keep the connection up - a simple way to check if the server is still alive, Like PING. (In fact, another issue that came up in the NOOP thread was if NOOP should be renamed to "PING.") However, we should have a way of discouraging avoid the situation where a CUA calls NOOP often. In section 4.4 we have: "A CUA may be discouraged from attempts to do useless things only to keep the connection alive." Yet, we also give them NOOP that may encourage CUAs to do such useless things. That part of section 4.4 can be interpreted that the CS can terminate the connection or return some error code if the CUA calls NOOP too many times? George John Stracke wrote: > > A couple of questions about autologout on idle: > > * 4.4: "When a timeout occurs, the server drops the connection to > the CUA". Should there be some sort of notification first? We've > got a notification for server shutdown (difficult as that may be > to implement); one for idle timeout seems reasonable. > * 7.1.12: the NOOP command seems like a way of evading the server's > idle timeout policy. Many servers I've known with such timeouts > don't want them evaded (for example, I had an ISP which had an > idle timeout on their PPP connections, and warned that ping > packets didn't count, because people were using ping to keep the > connection alive). Maybe there should be an error code reporting > that the NOOP has been ignored? > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |Please do not adjust your mind--reality is | > |francis@ecal.com |malfunctioning. | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Sun Aug 19 14:22:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15392 for ; Sun, 19 Aug 2001 14:22:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7JI6MY26235 for ietf-calendar-bks; Sun, 19 Aug 2001 11:06:22 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7JI6LN26229 for ; Sun, 19 Aug 2001 11:06:21 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA28251; Sun, 19 Aug 2001 14:06:18 -0400 Received: from steltor.com (host4.vpn.cst.ca [192.168.6.4]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7JI6Hf09721; Sun, 19 Aug 2001 14:06:17 -0400 (EDT) Message-ID: <3B800061.A6961C2E@steltor.com> Date: Sun, 19 Aug 2001 14:07:29 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: Bounded latency References: <3B7C11E4.5010802@ecal.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 Another way to implement it would be for the thread to check every X seconds or milliseconds if the latency time has run out or not. This may slow the thread down a little, it will not be completely accurate, and will not be the nicest thing to code. The latency time will only be an approximation. Are there potentially other problems for a single-threaded server? Are bounded latency, and the ABORT and CONTINUE commands the only ones? Should we make these features optional? Remove them? Are there some reasons why they are a must? Opinions? BTW, the CAP requirements draft does mention these features: "Support functionality such that the client is not forced to remain connected and waiting while a command is in progress. One possible way for the protocol to meet this requirement would be to allow the CU to abort a command that is taking too long." (The CAP requirements draft has expired. We should repost it.) George John Stracke wrote: > > CAP has features to let the client specify that the server should not > spend more than X amount of time on a request. I believe that these > features should be removed, or made optional, because they are > essentially impossible to implement in a single-threaded server. If my > server is working on the client's request, the only way I could possibly > apply the latency limit would be by setting an alarm to interrupt me. > But such alarms are not safe; generally speaking, they can interrupt any > operation, whether or not it leaves the system in an unsafe state. > > If the bounded latency stuff is cut, that means ABORT and CONTINUE must > be cut. > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |"HTTP is what happens in the absence of good | > |francis@ecal.com |design." -- Keith Moore | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Sun Aug 19 14:22:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15404 for ; Sun, 19 Aug 2001 14:22:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7JIC7V26318 for ietf-calendar-bks; Sun, 19 Aug 2001 11:12:07 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7JIC6N26314 for ; Sun, 19 Aug 2001 11:12:06 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA28260; Sun, 19 Aug 2001 14:12:03 -0400 Received: from steltor.com (host4.vpn.cst.ca [192.168.6.4]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7JIC2f10058; Sun, 19 Aug 2001 14:12:02 -0400 (EDT) Message-ID: <3B8001BB.8C27631A@steltor.com> Date: Sun, 19 Aug 2001 14:13:15 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: error code 6.9 leaks data References: <3B7C11EE.4000806@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I Agree. It should return code 6.0. George John Stracke wrote: > > CAP section 7.1.3 defines an error code, 6.9, which reports that the > user exists, but cannot use the given mechanism. I believe it's > generally considered a bad idea to tell an unauthenticated client a user > exists, because it aids with dictionary attacks. (For example, when you > log in to a Unix system, it doesn't distinguish between a bad username > and a bad password; either way, it just says "Login incorrect".) > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |Organ transplants are best left to the | > |francis@ecal.com |professionals. | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 20 10:46:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22536 for ; Mon, 20 Aug 2001 10:46:06 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7KEU5X18006 for ietf-calendar-bks; Mon, 20 Aug 2001 07:30:05 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KEU3N18001 for ; Mon, 20 Aug 2001 07:30:03 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7KEWV612684 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Mon, 20 Aug 2001 10:32:32 -0400 Message-ID: <3B811F7F.5030807@ecal.com> Date: Mon, 20 Aug 2001 10:32:31 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: matching common names References: <3B7C11B7.9010508@ecal.com> <3B7EC04D.DF1BC80@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 George Babics wrote: >Noted on the to do list as an issue. >Perhaps all we should compare is the UPN >with the e-mail address? > Yeah, that's what I was thinking. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Never underestimate the power of human | |francis@ecal.com|stupidity. --I forget who | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 20 10:48:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22643 for ; Mon, 20 Aug 2001 10:48:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KESKv17959 for ietf-calendar-bks; Mon, 20 Aug 2001 07:28:20 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KESIN17955 for ; Mon, 20 Aug 2001 07:28:18 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7KEUg612680 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Mon, 20 Aug 2001 10:30:45 -0400 Message-ID: <3B811F12.1000207@ecal.com> Date: Mon, 20 Aug 2001 10:30:42 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: why define Resource Calendar? References: <3B7C1193.3060802@ecal.com> <3B7EBCD6.394323CF@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 George Babics wrote: >I think it is another unused definition. I see no difference. > OK, does anybody object to dropping it? A quick skim through the draft shows that the term "Resource Calendar" does get used, but it doesn't get used differently from the term "Calendar". -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Round up the usual disclaimers. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 20 10:49:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22659 for ; Mon, 20 Aug 2001 10:49:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KEXNl18138 for ietf-calendar-bks; Mon, 20 Aug 2001 07:33:23 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KEXGN18123 for ; Mon, 20 Aug 2001 07:33:17 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7KEZc612695 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Mon, 20 Aug 2001 10:35:39 -0400 Message-ID: <3B81203A.6000908@ecal.com> Date: Mon, 20 Aug 2001 10:35:38 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: autologout References: <3B7C11D7.7080705@ecal.com> <3B7FF900.AC1E9196@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 George Babics wrote: >Looking at the archive, it was agreed to allow the server to ignore >NOOP and still drop the connection. > And I have no problem with that. >What you are suggesting is to return an error rather than simply >ignore >NOOP. > Sure. I mean, if the server isn't honoring the request, it should say so; it shouldn't just send a success code--that would be lying. On the other hand, a CUA that gets an error code in response to NOOP might then start doing useless things to keep the connection alive, and those will cost more server resources. So maybe it's best if the server can keep the CUA in the dark. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |For the life of me, I've never understood why | |francis@ecal.com|people dismiss the importance of "semantics" in | | |communication. After all, if semantics had no | | |purpleness, you'd slitheringly go bold at by-sit| | |it I'm climbing. -- Tangwystyl | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 20 10:50:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22677 for ; Mon, 20 Aug 2001 10:50:06 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7KEdSU18327 for ietf-calendar-bks; Mon, 20 Aug 2001 07:39:28 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KEdQN18323 for ; Mon, 20 Aug 2001 07:39:27 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7KEfr612712 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Mon, 20 Aug 2001 10:41:54 -0400 Message-ID: <3B8121B1.3030603@ecal.com> Date: Mon, 20 Aug 2001 10:41:53 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: Bounded latency References: <3B7C11E4.5010802@ecal.com> <3B800061.A6961C2E@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 George Babics wrote: >Another way to implement it would be for the thread to >check every X seconds or milliseconds if the latency >time has run out or not. > That won't work, though. If I have a single-threaded system, relying on blocking function calls (e.g., for database access), then I can't check the clock during those calls. >Are there potentially other problems for a single-threaded server? > Not that I've noticed. >BTW, the CAP requirements draft does mention these >features: > > "Support functionality such that the client is not forced to remain > connected and waiting while a command is in progress. One possible >way > for the protocol to meet this requirement would be to allow the CU >to > abort a command that is taking too long." > I'm not sure, but I believe making the bounded-latency features optional would meet this requirement. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Never mind the GUIs--Unix won't be for the | |francis@ecal.com|masses until we fix backspace & delete. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 20 17:58:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05263 for ; Mon, 20 Aug 2001 17:58:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KLkEx02155 for ietf-calendar-bks; Mon, 20 Aug 2001 14:46:14 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KLkCN02151 for ; Mon, 20 Aug 2001 14:46:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15Ywn9-0005Tu-00; Mon, 20 Aug 2001 16:41:03 -0500 Message-ID: <3B8183EF.D2E2D6F7@kasey.umkc.edu> Date: Mon, 20 Aug 2001 16:41:03 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: IDENTIFY seems dangerous References: <3B7C11CA.4080703@ecal.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 If we drop IDENTIFY and define a syntax for presenting authorization certificates, we could leave what the certificates mean completely up to the implementations. Wrapping credentials into a certificate which will work as a UPN-changing command would be trivial, for instance, and secure over TLS. single-use bearer certificates might help with issues of security in the over-email protocol too. John Stracke wrote: > > The CAP IDENTIFY command seems like it has some dangerous security > implications. AUTHENTICATE presents credentials, then IDENTIFY can reuse > those credentials to become a different user. The problem is that this > requires the CS to keep the credentials stored in memory for the > lifetime of the connection, which carries a risk of leakage (a bug which > lets an attacker read the contents of the server's memory can expose the > credentials for all active connections). Now, with some types of > credentials, this may be safe; but, for others, it's not. I believe > that, at a minimum, the server needs to be able to refuse to store > credentials which are not safe. > > More generally, it's not clear why IDENTIFY is needed at all, as a > separate comand. Clearly, there is some need to be able to authenticate > as a user other than the default implied by one's credentials (proxy > access); but that doesn't have to mean switching identities at arbitrary > times during the connection; it can be handled with an extra parameter > to AUTHENTICATE. I believe this would be the better approach (better > than refusing to store unsafe credentials), because it would mean that > proxy access can be done with any sort of credentials, not just ones > which are safe for the server to store. > > -- > /===============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |==============================================| > |eCal Corp. |"Why did you become a spokesmodel?" "Oh, well,| > |francis@ecal.com |I've always liked pointing." -- _LA Story_ | > \===============================================================/ -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Mon Aug 20 18:11:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05621 for ; Mon, 20 Aug 2001 18:11:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KLs5J02331 for ietf-calendar-bks; Mon, 20 Aug 2001 14:54:05 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KLs3N02326 for ; Mon, 20 Aug 2001 14:54:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15Ywuu-0005U5-00; Mon, 20 Aug 2001 16:49:04 -0500 Message-ID: <3B8185D0.95499F7F@kasey.umkc.edu> Date: Mon, 20 Aug 2001 16:49:04 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > GENERATEUID asks the CS to generate one or more unique UIDs. What is > this for? Why can't the client create its own UIDs, like any other CUA? > Why should we introduce extra round-trips, and extra work on the CS? My interpretation of this was as a precursor to implementing bearer certificates, which intention somehow got lost. One reason to have a server generate unique IDs is to avoid collisions. > If there's some strong reason the UID has to be generated by the CS, > then it should still not be done in a separate command; CREATE should > accept components without UIDs, and report back the UIDs they were assigned. A scenario where you don't know any details at all about the event you are planning but you know you are having an event would not be too hard to construct: for instance, the Downtown Community Center gives each member organization three events per month and lets them schedule them on a first-come-first-serve basis. They do this by having the CS generate three event-IDs, restrict the event-IDs in an implementation-dependent way, generate authorization certificates for each of them, and e-mail the authorization certificates to the facilitator of the organization for distribution to the event planners. Just a for-instance, off the op of my head. > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |"Baldric, how did you manage to find a turnip| > |francis@ecal.com |that cost 400,000 pounds?" "Well, I had to | > | |haggle." --Blackadder III | > \==============================================================/ -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Mon Aug 20 21:05:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08644 for ; Mon, 20 Aug 2001 21:05:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7L0pDa05720 for ietf-calendar-bks; Mon, 20 Aug 2001 17:51:13 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7L0pCN05716 for ; Mon, 20 Aug 2001 17:51:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15YzgM-0005XI-00; Mon, 20 Aug 2001 19:46:14 -0500 Message-ID: <3B81AF56.1E8301DE@kasey.umkc.edu> Date: Mon, 20 Aug 2001 19:46:14 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: why does a calendar have a TZID? References: <3B7C1284.8070201@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > CAP section 10.2 lists a TZID property for a calendar. What does this > mean? Every DSTART, etc., in every VEVENT, etc., in the calendar has to > specify its own TZID. The time zone that the calendar lists times in. It would also make sense to relax the time zone requirement for everything else and allow the TZID for the calendar to be the default when not specified. -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Mon Aug 20 21:19:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08776 for ; Mon, 20 Aug 2001 21:19:40 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7L0sT905792 for ietf-calendar-bks; Mon, 20 Aug 2001 17:54:29 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7L0sSN05788 for ; Mon, 20 Aug 2001 17:54:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15YzjX-0005XT-00; Mon, 20 Aug 2001 19:49:31 -0500 Message-ID: <3B81B01A.9141E60B@kasey.umkc.edu> Date: Mon, 20 Aug 2001 19:49:30 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: cancelling authentication References: <3B7C1201.8090107@ecal.com> <200108161902.f7GJ2Ugm002464@lin2.nas.cmu.edu> <3B7C20E5.7040206@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > Lawrence Greenfield wrote: > > >Note that most other SASL protocols support cancelling authentication > >and retrying in the same session. > > > If it can be done, then, yes, I agree that's probably a bit better. It > just needs to be defined how. One _successful_ authentication event. From owner-ietf-calendar@mail.imc.org Tue Aug 21 05:40:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03323 for ; Tue, 21 Aug 2001 05:40:19 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7L9MIN10372 for ietf-calendar-bks; Tue, 21 Aug 2001 02:22:18 -0700 (PDT) Received: from pretzel.foresight.co.uk (overload.foresight.co.uk [212.125.93.19]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7L9MGN10359 for ; Tue, 21 Aug 2001 02:22:16 -0700 (PDT) Received: (from natashas@localhost) by pretzel.foresight.co.uk (8.11.2/8.11.2) id f7L9E5h04869 for ietf-calendar@imc.org; Tue, 21 Aug 2001 10:14:05 +0100 Date: Tue, 21 Aug 2001 10:14:05 +0100 From: Natasha Sainty To: ietf-calendar@imc.org Subject: RFC2445 - VALARM with DURATION or REPEAT? Message-ID: <20010821101405.C4820@foresight.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hiya, I have a query regarding valarms - rfc 2445 clearly states that if one of DURATION or REPEAT is present, then the other must also be. I presumed that this meant it was an error to have only one present, until I read (on page 71): "Both of these properties MUST be present in order to specify a repeating alarm. If one of these two properties is absent, then the alarm will not repeat beyond the initial trigger." Does this mean we should accept alarms with only one of duration or repeat? Could someone please clarify? Thanks, Natasha -- Natasha Sainty natasha.sainty@foresight.co.uk Foresight (Europe) Ltd http://www.foresight.co.uk T: +44 (0)20 7348 1000 D: +44 (0)20 7348 1223 From owner-ietf-calendar@mail.imc.org Tue Aug 21 11:16:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19691 for ; Tue, 21 Aug 2001 11:16:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LF2cd00849 for ietf-calendar-bks; Tue, 21 Aug 2001 08:02:38 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LF2aN00845 for ; Tue, 21 Aug 2001 08:02:37 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7LF52617818 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Tue, 21 Aug 2001 11:05:03 -0400 Message-ID: <3B82789E.2090900@ecal.com> Date: Tue, 21 Aug 2001 11:05:02 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B8185D0.95499F7F@kasey.umkc.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 David L. Nicol wrote: >One reason to have a >server generate unique IDs is to avoid collisions. > Yes, but we know how to generate unique IDs on the client side; MUAs have been doing it for nearly 20 years. Involving the server just adds an extra round trip. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Earth: love it or leave it. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 21 11:20:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19918 for ; Tue, 21 Aug 2001 11:20:56 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7LFA9N01074 for ietf-calendar-bks; Tue, 21 Aug 2001 08:10:09 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LFA7N01068 for ; Tue, 21 Aug 2001 08:10:07 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7LFCZ617839 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Tue, 21 Aug 2001 11:12:36 -0400 Message-ID: <3B827A63.7090204@ecal.com> Date: Tue, 21 Aug 2001 11:12:35 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: why does a calendar have a TZID? References: <3B7C1284.8070201@ecal.com> <3B81AF56.1E8301DE@kasey.umkc.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 David L. Nicol wrote: >John Stracke wrote: > >> CAP section 10.2 lists a TZID property for a calendar. What does this >>mean? >> >The time zone that the calendar lists times in. > But the calendar doesn't list times; it lists events (etc.), each of which has its own timezone(s). > It would also make sense >to >relax the time zone requirement for everything else and allow the TZID for >the calendar to be the default when not specified. > This would have the problem that the CUA would have to be very careful to add correct TZIDs and VTIMEZONEs when exposing data from the CS to any other entity. We have a good self-contained data model; we shouldn't play games with it. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Campbell's has it wrong--it's "Never | |francis@ecal.com|underestimate the power of *chocolate*". | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 21 14:11:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26160 for ; Tue, 21 Aug 2001 14:11:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LHrAo09500 for ietf-calendar-bks; Tue, 21 Aug 2001 10:53:10 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LHr8N09494 for ; Tue, 21 Aug 2001 10:53:08 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA24242; Tue, 21 Aug 2001 13:53:04 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LHr4X26939; Tue, 21 Aug 2001 13:53:04 -0400 (EDT) Message-ID: <3B829FEC.1CD91F3D@steltor.com> Date: Tue, 21 Aug 2001 13:52:44 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: SASL mechanisms and MITM attacks References: <3B7C11F7.7070503@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > CAP section 7.1.3 discusses the risk of an attacker forcing the client > to pick a weak SASL mechanism. Where does it say it in 7.1.3? Perhaps it is in another section? Or is it simply implied? > It says that the CUA should fetch the > list of supported mechanisms after authenticating, to make sure it > hasn't changed. First: it's not clear to me how this fetch would be > done; can we spell it out? Use the CAPABILITIES command. > Second: does this actually do any good? Can't > the man-in-the-middle change the list of supported mechanisms after > authenticating, as well as before? It probably does not help. Perhaps the solution it say use a weak SASL mechanisms at your own risk? People concerned with security will make sure their clients use strong methods. Is this acceptable? Paul? George > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |This space intentionally left blank. | > |francis@ecal.com | | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 21 14:20:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26561 for ; Tue, 21 Aug 2001 14:20:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LI5JE09756 for ietf-calendar-bks; Tue, 21 Aug 2001 11:05:19 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LI5IN09752 for ; Tue, 21 Aug 2001 11:05:18 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7LI7h620966 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Tue, 21 Aug 2001 14:07:47 -0400 Message-ID: <3B82A36F.5010906@ecal.com> Date: Tue, 21 Aug 2001 14:07:43 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: SASL mechanisms and MITM attacks References: <3B7C11F7.7070503@ecal.com> <3B829FEC.1CD91F3D@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 George Babics wrote: > >John Stracke wrote: > >> CAP section 7.1.3 discusses the risk of an attacker forcing the client >>to pick a weak SASL mechanism. >> > > Where does it say it in 7.1.3? > It's the paragraph starting "If a SASL security layer is negotiated...". >>It says that the CUA should fetch the >>list of supported mechanisms after authenticating, to make sure it >>hasn't changed. First: it's not clear to me how this fetch would be >>done; can we spell it out? >> > > Use the CAPABILITIES command. > OK, now I see; but it wasn't clear when I read it before. >>Second: does this actually do any good? Can't >>the man-in-the-middle change the list of supported mechanisms after >>authenticating, as well as before? >> > > It probably does not help. Perhaps the solution it say use >a weak SASL mechanisms at your own risk? People concerned with >security will make sure their clients use strong methods. > Probably best, yes. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Help stamp out vi in our lifetime! | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 21 17:51:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02261 for ; Tue, 21 Aug 2001 17:51:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LLdWH16801 for ietf-calendar-bks; Tue, 21 Aug 2001 14:39:32 -0700 (PDT) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LLdUN16797 for ; Tue, 21 Aug 2001 14:39:30 -0700 (PDT) To: ietf-calendar@imc.org Subject: CalConnect III MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.07a May 14, 2001 From: pregen@egenconsulting.com Message-ID: Date: Tue, 21 Aug 2001 17:39:02 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 08/21/2001 05:39:11 PM, Serialize complete at 08/21/2001 05:39:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0076FBBA85256AAF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076FBBA85256AAF_= Content-Type: text/plain; charset="us-ascii" Calconnect III interop testing has been confirmed and scheduled for November 29 and 30th at McGill University in Montreal. The cost is $1000 (for two people). Please let Pat Egen know if you are interested in attending and participating on the interop testing. More information (hotel locations, directions, etc) will be on the calsch.org website in the next two weeks. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0076FBBA85256AAF_= Content-Type: text/html; charset="us-ascii"
Calconnect III interop testing has been confirmed and scheduled for November 29 and 30th at McGill University in Montreal.  The cost is $1000 (for two people).  Please let Pat Egen know if you are interested in attending and participating on the interop testing.  More information (hotel locations, directions, etc) will be on the calsch.org website in the next two weeks.  
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0076FBBA85256AAF_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 21 17:54:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02307 for ; Tue, 21 Aug 2001 17:54:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LLXSV16737 for ietf-calendar-bks; Tue, 21 Aug 2001 14:33:28 -0700 (PDT) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LLXQN16733 for ; Tue, 21 Aug 2001 14:33:26 -0700 (PDT) To: minutes@ietf.org Cc: ietf-calendar@imc.org Subject: CALSCH meeting minutes - London MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.07a May 14, 2001 From: pregen@egenconsulting.com Message-ID: Date: Tue, 21 Aug 2001 17:32:35 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 08/21/2001 05:33:07 PM, Serialize complete at 08/21/2001 05:33:07 PM Content-Type: multipart/alternative; boundary="=_alternative 0076391F85256AAF_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076391F85256AAF_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat, co chair, went over the following agenda: Agenda Bashing Guide to Internet Calendaring CalConnect Interoperability results - next plans iCalendar Updates Other drafts - SKICAL, CRISP IPCPL - iCalendar CAP draft Update charter =20 Bob Mahoney gave a brief update on the Guide to Internet Calendaring. We=20 asked people to review the list so it could go to IETF last call. George mentioned that the Guide is now available in HTML format, and it=20 will soon be available on the calsch.org website. =20 At this point, we moved up the IPTEL discussion so that the rep from that=20 group) could leave early. He asked the group to please help us make a=20 decision on how this issue (particularly with their request for changes to = BYSETPOS). Pat explained that we had spoken with the Area Director and he = gave us some suggestions on what we could do. We will try once again to=20 see if we can resolve this over the list. Otherwise, Bob and Pat will work = with Jonathan Lennox to come up with a one page summary on the issue and=20 give it to Patrik for next steps. =20 Pat next covered the interop testing held in Standford in the first half=20 of the year. A final report will be on the list by the end of the month.=20 We will hold the next interop in November at McGill University in=20 Montreal. Pat asked for some more vendors to participate. =20 Pat went over the CRISP document and SKICAL at which point she turned over = the meeting to Greg Fitzpatrick to talk about SKICAL. =20 Greg talked about a document that shows the SKICAL reference in HTML=20 format. We are going to put it on calsch.org. He also talked about an=20 effort going on at the W3C in relation to iCalendar and RDF. He said=20 Libby Miller was the head of this effort and she will join us after the=20 meeting so Greg can introduce her to the working group members. =20 Greg then went into discussion of where SKICAL is and how they have=20 struggled with their effort in trying to define an Event type of draft. He = talked about how they would like to see standardization on names such as=20 what a vendor calls a meeting or event. He correlated this to having an=20 XML namespace where things were defined. This may be hard to do as many=20 vendors choose to call objects differently. =20 Greg pointed out that the ABNF and the examples are different when it=20 comes to requiring a DTStart. He said for his effort, not requiring a=20 Replace DTStart with DTSTART would help. We need to first fix the=20 iCalendar spec and then determine which is correct for our draft -=20 required or not required. Greg feels there are other issues or changes to = iCalendar that need to be addressed. We aske him to put these on the=20 list. Greg talked about some work resurrecting the Chris Newman document on=20 dates and times. He wanted to know why we don't follow the ISO 8601=20 standards and constructs. John Stracke addressed this briefly. John said that we do follow a subset of ISO 8601. There was a general discussion about working with the W3C and how this=20 becomes difficult. There was a general discussion about the challenges of = working with time. Greg said it would be helpful to have a language=20 property (like lang) added to iCalendar. He said it could be called lang=20 - John objected to this idea. John objected because it was a French word. This was inconsistent with all = the other names which are all in English. =20 Next George Babics did an update on CAP. He went through the slides=20 (copies included with this draft). We announced we want to go to last=20 call in December. We also asked for more participation on the list so we=20 can make sure we have consensus. During the discussion about VCARs and=20 their challenges, Ned Freed asked about how, in the document, do we=20 explain how to determine the identity of a calendar. In other words, how=20 do we define what that should look like. Our naming model may be too=20 flexible. Paul Hill said he just came from a SASL discussion and he said=20 they were having the same challenges. They are looking at application=20 profiles that define these. Some do it in the DN for LDAP and some do it=20 for Kerberos. George stated that we need more participation and participants since CAP=20 is big and complex. The more people looking at it, the better. George=20 mentioned that an HTML version of the CAP document will also soon be=20 available on the calsch.org website. John Stracke said we need to do a better job of defining our CAP methods. Ned then said he had just read the draft and had some comments. He wanted = to know if we had looked at the BEEP RFC. We explained it was a timing=20 issue. BEEP was not around when we started working on our draft. Ned=20 suggested we move some of the overhead down into the "payload" portion and = let something like BEEP manage the transport. Pat asked if this should be = a part of iTIP? =20 General questions from the audience. =20 Have we looked at a calendar other than Gregorian. Answer is no for now.=20 General discussion about this. Talked about time in general. =20 Nick Shelness said our group had done a good job defining time and the=20 issues associated with this effort. =20 Pat talked about the fact she had contacted Olson regarding interfacing=20 with the IETF to establish a common timezone table. Then, a member of the = audience wondered if there needed to be some sort of Internet Time Space - = this is beyond the scope of the IETF. =20 Someone wanted to know if we had looked into any of the presence=20 documents. He said we may want to think about somehow incorporating this=20 into the drafts to manage where a person is at any point. =20 Pat talked about charter updates and whether or not we needed to resubmit=20 our requirements document. Ned suggested we look at the document and if=20 there was nothing controversial, submit it as an information document. If = we have veered too much from the original document, then leaving expired=20 may be best. Guide to Internet Calendaring ? In Working group last call ? Most recent comments ? Minor typos/grammer ? Designate=20 CalConnect II - Interop Testing ? Standford University ? Three Vendors ? Lotus, Steltor, iPlanet ? Significantly improved results ? Report on list by end of week 8/13 ? Next Calconnect ? Montreal ? McGill University ? November 2001 iCalendar, iTIP, iMIP ? Need to make changes found during interop testing ? Do we want to resubmit draft that shows XML extensions for=20 iCalendar? ? Eric Busboom now main editor Other Drafts ? SKICAL ? last call ? Crisp ? need to resubmit CPL and iCalendar Issues ? RECUR ? BYSETPOS ? What do we do? CAP What Is New In Version 5? ? Use RFC 2629 (Writing I-Ds and RFCs using XML) ? Added some new examples ? Clarifications ? Fixed some errors Our Plans (1) ? Resolve all open issues: ? We have started posting them to the list ? Finish all other outstanding tasks ? Goal: last call in December Our Plans (2) ? Need more participation and participants! ? CAP is large and complex ? Many details Open Issues: Fanout (1) ? Fanout: ability for a CUA to communicate to a single server to be=20 able to perform scheduling=20 operations with calendars on many CSs ? MUST be able to do it with iMIP Open Issues: Fanout (2) ? Problems: ? Can we map all the CAP commands into iMIP methods? ? E.g. CREATE -> REQUEST ? Security: how can the remote server trust the server doing fanout? = Open Issues: Fanout (3) ? Problems without fanout: ? CUA has to manage scheduling using different types of addresses:=20 CAP and email (iMIP) Open Issues: Decreed VCARs ? The ability to have administrator controlled immutable VCARs that=20 apply to all calendars on the server. ? E.g. disallow anyone from permitting anonymous users do gain=20 access to their calendars ? Problem: there is no way to identify decreed VCARs ? Need new properties ? Do we need them? Open Issues: Restriction Tables ? There are a number of issues with the Methods in the restriction=20 tables ? Check the draft for these issues ? We should be addressing them soon Open Issue: Delegation ? CAP does not easily allow delegation ? Some suggestions recently on how we can fix this Outstanding Tasks ? Register port number (5229) with IANA ? Get new properties and components into iCalendar ? E.g. VQUERY, GRANT ? Add new examples, such as an entire "typical" session from start=20 to finish ? Review security ? Review restriction tables Charter Update ? Current Charter ? Note last call on CAP ? Move Guide up food chain ? Re-post requirements Doc? ? Re-post CRISP? --=_alternative 0076391F85256AAF_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Pat, co chair, went over the follow= ing agenda:
Agenda Bashing
Guide to Internet Calendaring
CalConnect Interoperability results= - next plans
iCalendar Updates
Other drafts - SKICAL, CRISP
IPCPL - iCalendar
CAP draft
Update charter

Bob Mahoney gave a brief update on the Guide to Internet Calendaring. We as= ked people to review the list so it could go to IETF last call.

George mentioned that the Guide is now available in HTML format, and it wil= l soon be available on the calsch.org website.


At this point, we moved up the IPTEL discussion so that the rep from that g= roup) could leave early.  He asked the group to please help us  m= ake a decision on how this issue (particularly with their request for chang= es to BYSETPOS).  Pat explained that we had spoken with the Area Direc= tor and he gave us some suggestions on what we could do.  We will try = once again to see if we can resolve this over the list. Otherwise, Bob and = Pat will work with Jonathan Lennox to come up with a one page summary on th= e issue and give it to Patrik for next steps.

Pat next covered the interop testing held in Standford in the first half of= the year.  A final report will be on the list by the end of the month= .  We will hold the next interop in November at McGill University in M= ontreal.  Pat asked for some more vendors to participate.

Pat went over the CRISP document and SKICAL at which point she turned over = the meeting to Greg Fitzpatrick to talk about SKICAL.

Greg talked about a document that shows the SKICAL reference in HTML format= .  We are going to put it on calsch.org.  He also talked about an= effort going on at the W3C in relation to iCalendar and RDF.  He said= Libby Miller was the head of this effort and she will join us after the me= eting so Greg can introduce her to the working group members.

Greg then went into discussion of where SKICAL is and how they have struggl= ed with their effort in trying to define an Event type of draft.  He t= alked about how they would like to see standardization on names such as wha= t a vendor calls a meeting or event.  He correlated this to having an = XML namespace where things were defined.  This may be hard to do as ma= ny vendors choose to call objects differently.

Greg pointed out that the ABNF and the examples are different when it comes= to requiring a DTStart.  He said for his effort, not requiring a Repl= ace DTStart with DTSTART would help.  We need to first fix the iCalend= ar spec and then determine which is correct for our draft - required or not= required.  Greg feels there are other issues or changes to iCalendar = that need to be addressed.  We aske him to put these on the list.

Greg talked about some work resurrecting the Chris Newman document on dates= and times.  He wanted to know why we don't follow the ISO 8601 standa= rds and constructs.  John Stracke addressed this briefly.

John said that we do follow a subset of ISO 8601.

There was a general discussion about working with the W3C and how this beco= mes difficult.  There was a general discussion about the challenges of= working with time.  Greg said it would be helpful to have a language = property (like lang) added to iCalendar.  He said it could be called l= ang - John objected to this idea.

John objected because it was a French word. This was inconsistent with all = the other names which are all in English.

Next George Babics did an update on CAP.  He went through the slides (= copies included with this draft).  We announced we want to go to last = call in December.  We also asked for more participation on the list so= we can make sure we have consensus.  During the discussion about VCAR= s and their challenges, Ned Freed asked about how, in the document, do we e= xplain how to determine the identity of a calendar.  In other words, h= ow do we define what that should look like.  Our naming model may be t= oo flexible.  Paul Hill said he just came from a SASL discussion and h= e said they were having the same challenges.  They are looking at appl= ication profiles that define these.  Some do it in the DN for LDAP and= some do it for Kerberos.

George stated that we need more participation and participants since CAP is= big and complex. The more people looking at it, the better. George mention= ed that an HTML version of the CAP document will also soon be available on = the calsch.org website.

John Stracke said we need to do a better job of defining our CAP
methods.

Ned then said he had just read the draft and had some comments.  He wa= nted to know if we had looked at the BEEP RFC.  We explained it was a = timing issue.  BEEP was not around when we started working on our draf= t.  Ned suggested we move some of the overhead down into the "pay= load" portion and let something like BEEP manage the transport.  = Pat asked if this should be a part of iTIP?

General questions from the audience.

Have we looked at a calendar other than Gregorian.  Answer is no for n= ow.  General discussion about this.  Talked about time in general= .
Nick Shelness said our group had do= ne a good job defining time and the issues associated with this effort.

Pat talked about the fact she had contacted Olson regarding interfacing wit= h the IETF to establish a common timezone table.  Then, a member of th= e audience wondered if there needed to be some sort of Internet Time Space = - this is beyond the scope of the IETF.

Someone wanted to know if we had looked into any of the presence documents.=  He said we may want to think about somehow incorporating this into t= he drafts to manage where a person is at any point.

Pat talked about charter updates and whether or not we needed to resubmit o= ur requirements document.  Ned suggested we look at the document and i= f there was nothing controversial, submit it as an information document. &n= bsp;If we have veered too much from the original document, then leaving exp= ired may be best.

Guide to Internet Calendaring

•        = In Working group last call
•        = Most recent comments
–        = Minor typos/grammer
–        = Designate

CalConnect II - Interop Testing

•        = Standford University
•        = Three Vendors
–        = Lotus, Steltor, iPlanet
•        = Significantly improved results
–        = Report on list by end of week 8/13
•        = Next Calconnect
–        = Montreal – McGill University
–        = November 2001

iCalendar, iTIP, iMIP

•        = Need to make changes found during interop testing
•        = Do we want to resubmit draft that shows XML extensions for iCalendar?
•        = Eric Busboom now main editor


Other Drafts

•        = SKICAL – last call
•        = Crisp – need to resubmit


CPL and iCalendar Issues
•        = RECUR
•        = BYSETPOS
•        = What do we do?


CAP
What Is New In Version 5?
•        = Use RFC 2629 (Writing I-Ds and RFCs using XML)
•        = Added some new examples
•        = Clarifications
•        = Fixed some errors


Our Plans (1)

•        = Resolve all open issues:
–        = We have started posting them to the list
•        = Finish all other outstanding tasks
•        = Goal: last call in December

Our Plans (2)

•        = Need more participation and participants!
–        = CAP is large and complex
–        = Many details


Open Issues: Fanout (1)

•        = Fanout: ability for a CUA to communicate to a single server to be able to p= erform scheduling
      operations wit= h calendars on many CSs
•        = MUST be able to do it with iMIP


Open Issues: Fanout (2)

•        = Problems:
–        = Can we map all the CAP commands into iMIP methods?
•        = E.g. CREATE -> REQUEST
–        = Security: how can the remote server trust the server doing fanout?


Open Issues: Fanout (3)

•        = Problems without fanout:
–        = CUA has to manage scheduling using different types of addresses: CAP and em= ail (iMIP)


Open Issues: Decreed VCARs
•        = The ability to have administrator controlled immutable VCARs that apply to = all calendars on the server.
–        = E.g. disallow anyone from permitting anonymous users do gain access to thei= r calendars
•        = Problem: there is no way to identify decreed VCARs
–        = Need new properties
•        = Do we need them?


Open Issues: Restriction Tables

•        = There are a number of issues with the Methods in the restriction tables
•        = Check the draft for these issues
•        = We should be addressing them soon


Open Issue: Delegation

•        = CAP does not easily allow delegation
•        = Some suggestions recently on how we can fix this


Outstanding Tasks

•        = Register port number (5229) with IANA
•        = Get new properties and components into iCalendar
–        = E.g. VQUERY, GRANT
•        = Add new examples, such as an entire "typical" session from start to finish<= /font>
•        = Review security
•        = Review restriction tables


Charter Update

•        = Current Charter
•        = Note last call on CAP
•        = Move Guide up food chain
•        = Re-post requirements Doc?
•        = Re-post CRISP? --=_alternative 0076391F85256AAF_=-- From owner-ietf-calendar@mail.imc.org Tue Aug 21 19:58:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03470 for ; Tue, 21 Aug 2001 19:58:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LNi3018893 for ietf-calendar-bks; Tue, 21 Aug 2001 16:44:03 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LNi2N18889 for ; Tue, 21 Aug 2001 16:44:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15ZL6i-0006DP-00; Tue, 21 Aug 2001 18:38:52 -0500 Message-ID: <3B82F10C.DE178E12@kasey.umkc.edu> Date: Tue, 21 Aug 2001 18:38:52 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF , cap-talk@mail.eros-os.org Subject: Authorization Certificates Are All Around Us 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 It was surprising to me the chilly reception that suggesting that the first realease of the calendar server standard might support authorization certificates got, since there is a nicely written RFC describing them thoroughly and giving some vocabulary for them. People responded, "This Authorization Certificate stuff is new, it is experimental! Wait until people have better grasp of how to work with them." This confused me until I realized that there is a misperception that Authorization Certificates are something new, instead of a proposed Offical and Unambiguous name which has been proposed, and, in my opinion, works well, for referring to the concept which will eventually be widely recognized as the Authorization Certificate. To demonstrate the wide acceptance of the concept in normal daily life, I have been keeping a diary of Authorization Certificates I have seen or used in the last twenty four hours. I will use the calendar/scheduling term "designate" to mean a person who the SPKI theory RFC call would call a "delegate." Much list serving software that does recipent verification uses a one-time bearer certificate to authorize the mailing list to add the recipient to the list. The EZMLM mailing list software uses a bearer certificate to authorize removal from the list, a technique called "variable envelope return path." Any system which multiplexes many virtual connections over a single connection can be considered a use of the "handle ID" as a authorization certificate. This includes: The NFS file system which uses a call ID to provide simultaneity, the Linux NBD protocol, which uses a call ID to provide simultaneity the TCP/IP protocol itself, in which the combination of source address, source port, destination address, destination port, sequence number taken together constitute a certificate that authorizes the payload of the TCP packet to be added to a particular buffer (thus the possibility of "TCP spoofing" attacks) Any http-based service that issues "session cookies" is issuing a certificate that authorizes the presenter to, for instance, add merchandise to a virtual shopping cart. There are ways to achiece the same effect with "hidden fields" and "directory path info" that do not involve "cookies" and work just as well. What they all share is, there is a certificate that is presented to authorize the current packet to be associated with a previously existing object. An argument could be made for "Credit Card Number" falling under the definition of "SPKI Authorization certificate" -- by presenting the number, a designate is authorized to purchase things, as verified by the card authorization machine. Credit card number is not an authentication system. When I give Ellen my credit card to buy things, Ellen does not misrepresent herself as me when she does that: she honestly represents herself as my designate. I draw the line at automated teller machine PIN codes. These are an authentication system, and are supposed to be kept secret. This is a personal preference however, and, as was demonstrated in last night's Seinfeld rerun, PIN codes can be effectively shared with a designate. Another broad set of applications that routinely use the techinque are bug and abuse reports, where issues are often given authorization certificates called "trouble tickets" which authorize a customer to follow up on a previously reported issue. Lunch, at Burger King. After paying for my food, I was given a number, which I presented to the other end of the counter to authorize myself to accept a "Whopper Value Meal." This is an authorization certificate: the counter help does not care who I am, only that I demonstrate that I am authorized to pick up a particular lunch order. Dry cleaners all work this way too: they don't care who you are as long as you present the laundry ticket with the number on it, you are authorized to pick up that laundry. Waiting rooms often have numbers, and it was, as I understand it, not unheard of for otherwise unemployed people to take advantage of time arbitrage by taking a low number and selling it to a more recent arrivals in certain places in formerly communist eastern europe. It would certainly work on a busy day at the Grandview, Missouri department of motor vehicles, at least it would have before they posted the sign expressly forbidding the practice. The holder of the low number is authorized to be helped by the bureaucrat. Television channels. There are eighty-odd possible broadcast TV channels defined. Presenting the desired channel number to my television authorizes me to receive the content on that channel. Television is not very secure. -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Tue Aug 21 20:51:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03995 for ; Tue, 21 Aug 2001 20:51:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7M0ehu19838 for ietf-calendar-bks; Tue, 21 Aug 2001 17:40:43 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M0egN19834 for ; Tue, 21 Aug 2001 17:40:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15ZLzc-0006Eo-00; Tue, 21 Aug 2001 19:35:36 -0500 Message-ID: <3B82FE58.33BE5EC@kasey.umkc.edu> Date: Tue, 21 Aug 2001 19:35:36 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B8185D0.95499F7F@kasey.umkc.edu> <3B82789E.2090900@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > David L. Nicol wrote: > > >One reason to have a > >server generate unique IDs is to avoid collisions. > > > Yes, but we know how to generate unique IDs on the client side; MUAs > have been doing it for nearly 20 years. Involving the server just adds > an extra round trip. At the risk of degenerating into name-calling again, if IDs become authenticaion certificates, you want them being generated by whoever is going to keep track of them. Such a GENERATE command would take as an argument a representation of a access right the current user has, in a well defined syntax (the existence of which is implied by the existence of the VCAR specification) and some other optional arguments such as expiration time and possibly access list and possibly a limit on the number of times the certificate can be presented before it burns out, or other implementation-based accounting or other restrictions; and the response to the GENERATE command would be an SPKI authentication certificate. From owner-ietf-calendar@mail.imc.org Tue Aug 21 21:21:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04270 for ; Tue, 21 Aug 2001 21:21:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7M18UC20265 for ietf-calendar-bks; Tue, 21 Aug 2001 18:08:30 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M18TN20261 for ; Tue, 21 Aug 2001 18:08:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15ZMQT-0006Fa-00; Tue, 21 Aug 2001 20:03:21 -0500 Message-ID: <3B8304D9.122A0ED1@kasey.umkc.edu> Date: Tue, 21 Aug 2001 20:03:21 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: George Babics CC: John Stracke , calsch WG Subject: Re: CAP: matching common names References: <3B7C11B7.9010508@ecal.com> <3B7EC04D.DF1BC80@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit For maximum flexibility we would leave UPN as vague as possible except there is a one-one rltn btwn it and specific individuals or constructs that act like individuals. Most implementations will use e-mail address but some implementations might have multiple e-mail addresses mapping to one UPN. This kind of situation is generally dealt with by allowing administrative aliasing of one to another. But regardless of if the standard insists that UPNs have to be well-formed e-mail addresses rather than random 64-bit integers, demanding that the Personal Name portion of an e-mail address match something is just going to be frustrating for people who get it wrong and not do anything to stop abuse. George Babics wrote: > > Noted on the to do list as an issue. > Perhaps all we should compare is the UPN > with the e-mail address? > > Suggestions? > > George > > John Stracke wrote: > > > > The last paragraph of CAP section 2.4.2.1 specifies that a CS or CUA > > processing data received by iMIP should compare the personal-name part > > of the From: email address with the CN part of the ORGANIZER or ATTENDEE > > property, and refuse the message if they don't match. This is very > > risky; people's names do not stay unchanged forever. Consider Lisa > > Dusseault; in the time I've known her, she's also gone by Lisa Lippert > > and Lisa Lippert-Dusseault. Looking at my old calsch mail, I see some > > messages from her saying "Lisa Lippert (Dusseault) (Exchange)", which > > brings up another, shorter time-scale problem: sometimes different UAs > > for the same email address will be configured with slightly different names. -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Tue Aug 21 21:24:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04284 for ; Tue, 21 Aug 2001 21:24:01 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7M1DDh20504 for ietf-calendar-bks; Tue, 21 Aug 2001 18:13:13 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M1DCN20500 for ; Tue, 21 Aug 2001 18:13:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15ZMV4-0006Fq-00; Tue, 21 Aug 2001 20:08:06 -0500 Message-ID: <3B8305F6.EB597BA7@kasey.umkc.edu> Date: Tue, 21 Aug 2001 20:08:06 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: George Babics CC: John Stracke , calsch WG Subject: Re: CAP: autologout References: <3B7C11D7.7080705@ecal.com> <3B7FF900.AC1E9196@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit George Babics wrote: > In section 4.4 we have: > > "A CUA may be discouraged from attempts to do useless things only to > keep the > connection alive." > > Yet, we also give them NOOP that may encourage CUAs to do such useless > things. So the standard supports a CS that drops you after 20m even if you have been issuing pings, and a CS that lets you stay on all the time so you can have a responsive calendar. Is there an event-notification channel written into the standard, so that when something happens, the event description is sent to the client? I think we just have polling for that. From owner-ietf-calendar@mail.imc.org Tue Aug 21 21:31:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04391 for ; Tue, 21 Aug 2001 21:31:27 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7M1KFX20753 for ietf-calendar-bks; Tue, 21 Aug 2001 18:20:15 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M1KEN20749 for ; Tue, 21 Aug 2001 18:20:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15ZMbt-0006GC-00; Tue, 21 Aug 2001 20:15:09 -0500 Message-ID: <3B83079D.EC24916A@kasey.umkc.edu> Date: Tue, 21 Aug 2001 20:15:09 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: Bounded latency References: <3B7C11E4.5010802@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > CAP has features to let the client specify that the server should not > spend more than X amount of time on a request. I believe that these > features should be removed, or made optional, because they are > essentially impossible to implement in a single-threaded server. If my > server is working on the client's request, the only way I could possibly > apply the latency limit would be by setting an alarm to interrupt me. > But such alarms are not safe; generally speaking, they can interrupt any > operation, whether or not it leaves the system in an unsafe state. This is not strictly true. A single-threaded server can take a break between parts of a large operation and see if there is something else requiring its attention, at safe intervals. > If the bounded latency stuff is cut, that means ABORT and CONTINUE must > be cut. how about downgrading them to MAY status. A client could always just drop the connection and let the server pick up the pieces. -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Tue Aug 21 21:45:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05445 for ; Tue, 21 Aug 2001 21:45:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7M1Y7B21050 for ietf-calendar-bks; Tue, 21 Aug 2001 18:34:07 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M1Y6N21045 for ; Tue, 21 Aug 2001 18:34:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15ZMpI-0006Gb-00; Tue, 21 Aug 2001 20:29:00 -0500 Message-ID: <3B830ADC.F1412C63@kasey.umkc.edu> Date: Tue, 21 Aug 2001 20:29:00 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke , calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B8185D0.95499F7F@kasey.umkc.edu> <3B82789E.2090900@ecal.com> <3B82FE58.33BE5EC@kasey.umkc.edu> 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 Oh, hell. I meant "become authorization certificates" "David L. Nicol" wrote: > At the risk of degenerating into name-calling again, if IDs become > authenticaion certificates, you want them being generated by whoever is > going to keep track of them. -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Wed Aug 22 10:38:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10899 for ; Wed, 22 Aug 2001 10:38:59 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7ME8Mp11480 for ietf-calendar-bks; Wed, 22 Aug 2001 07:08:22 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ME8LN11476 for ; Wed, 22 Aug 2001 07:08:21 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7MEAq624981 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 22 Aug 2001 10:10:53 -0400 Message-ID: <3B83BD6C.4050304@ecal.com> Date: Wed, 22 Aug 2001 10:10:52 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: Bounded latency References: <3B7C11E4.5010802@ecal.com> <3B83079D.EC24916A@kasey.umkc.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 David L. Nicol wrote: >John Stracke wrote: > >> CAP has features to let the client specify that the server should not >>spend more than X amount of time on a request. I believe that these >>features should be removed, or made optional, because they are >>essentially impossible to implement in a single-threaded server. >> > >This is not strictly true. A single-threaded server can take a break >between parts of a large operation and see if there is something else >requiring its attention, at safe intervals. > False. A server is typically implemented with some sort of backend store (say a database); the API to this database is quite likely to be blocking. In such a case, it would be impossible to take a break during the database access--and the database access is probably the largest chunk of time to service a CAP request. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |A computer without Windows is like a chocolate| |francis@ecal.com|cake without mustard. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 22 10:40:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10980 for ; Wed, 22 Aug 2001 10:40:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7ME6GR11442 for ietf-calendar-bks; Wed, 22 Aug 2001 07:06:16 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ME6FN11437 for ; Wed, 22 Aug 2001 07:06:15 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7ME8k624971 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 22 Aug 2001 10:08:47 -0400 Message-ID: <3B83BCEE.8070302@ecal.com> Date: Wed, 22 Aug 2001 10:08:46 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: autologout References: <3B7C11D7.7080705@ecal.com> <3B7FF900.AC1E9196@steltor.com> <3B8305F6.EB597BA7@kasey.umkc.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 David L. Nicol wrote: >Is there an event-notification channel written into the standard, so that >when something happens, the event description is sent to the client? > No. Event notification protocols have turned out to be surprisingly tricky in the past. It'd be useful, but we're probably better off waiting for a future rev of CAP. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |If you're going to walk on thin ice, you might| |francis@ecal.com|as well *dance*! | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 22 10:49:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11664 for ; Wed, 22 Aug 2001 10:49:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MEFcb11739 for ietf-calendar-bks; Wed, 22 Aug 2001 07:15:38 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MEFbN11734 for ; Wed, 22 Aug 2001 07:15:37 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7MEI8625003 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Wed, 22 Aug 2001 10:18:09 -0400 Message-ID: <3B83BF20.6000000@ecal.com> Date: Wed, 22 Aug 2001 10:18:08 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-calendar@imc.org CC: minutes@ietf.org Subject: Re: CALSCH meeting minutes - London 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 pregen@egenconsulting.com wrote: > Greg said it would be helpful to have a language property (like lang) > added to iCalendar. He said it could be called lang - John objected > to this idea. > > John objected because it was a French word. This was inconsistent with > all the other names which are all in English. Clarification: this discussion didn't happen in the meeting; it was referenced in the meeting. There was an old SkiCal proposal (over a year ago) for a property called LANGUE for "what languages are required to understand this event". At the time I objected (and Greg agreed) that it was problematic for developers whose native language is neither English nor French, because they'd have trouble keeping straight two very similar foreign words (LANGUE and LANGUAGE). At the meeting, Greg said it would be a useful property, with a better name (I agree), and mentioned the old discussion by way of pointing out that it had come up before. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Sometimes we in the media have to give the | |francis@ecal.com|copycat criminals a little kick-start." -- Tina| | |the Tech Writer, in _Dilbert_ | \================================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 22 11:24:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13290 for ; Wed, 22 Aug 2001 11:24:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MErQn14335 for ietf-calendar-bks; Wed, 22 Aug 2001 07:53:26 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MErPN14330 for ; Wed, 22 Aug 2001 07:53:25 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7ME7P624964 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 22 Aug 2001 10:07:26 -0400 Message-ID: <3B83BC9D.9060504@ecal.com> Date: Wed, 22 Aug 2001 10:07:25 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B8185D0.95499F7F@kasey.umkc.edu> <3B82789E.2090900@ecal.com> <3B82FE58.33BE5EC@kasey.umkc.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 David L. Nicol wrote: >John Stracke wrote: > >>David L. Nicol wrote: >> >>Yes, but we know how to generate unique IDs on the client side; MUAs >>have been doing it for nearly 20 years. Involving the server just adds >>an extra round trip. >> > >At the risk of degenerating into name-calling again, if IDs become >authenticaion certificates, you want them being generated by whoever is >going to keep track of them. > What you're talking about is not analogous to the problem with GENERATEUID. GENERATEUID just generates the string; your proposal also associates it with authorization semantics. The equivalent in this case would be if the client CREATEd an event with no UID, and the server assigned a UID and returned it. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |If you're omniscient, how do you know? | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 22 14:34:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19677 for ; Wed, 22 Aug 2001 14:34:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MILlE22963 for ietf-calendar-bks; Wed, 22 Aug 2001 11:21:47 -0700 (PDT) Received: from server1.egenconsulting.com ([216.143.5.254]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MILiN22949 for ; Wed, 22 Aug 2001 11:21:44 -0700 (PDT) To: John Stracke Cc: ietf-calendar@imc.org, minutes@ietf.org, owner-ietf-calendar@mail.imc.org Subject: Re: CALSCH meeting minutes - London MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.07a May 14, 2001 From: pregen@egenconsulting.com Message-ID: Date: Wed, 22 Aug 2001 14:21:11 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 08/22/2001 02:21:23 PM, Serialize complete at 08/22/2001 02:21:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0059600E85256AB0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059600E85256AB0_= Content-Type: text/plain; charset="us-ascii" John, thanks for the clarification. If anyone else sees items on the minutes that are "off a bit" please respond to the list. John Stracke Sent by: owner-ietf-calendar@mail.imc.org 08/22/01 10:18 AM To: ietf-calendar@imc.org cc: minutes@ietf.org Subject: Re: CALSCH meeting minutes - London pregen@egenconsulting.com wrote: > Greg said it would be helpful to have a language property (like lang) > added to iCalendar. He said it could be called lang - John objected > to this idea. > > John objected because it was a French word. This was inconsistent with > all the other names which are all in English. Clarification: this discussion didn't happen in the meeting; it was referenced in the meeting. There was an old SkiCal proposal (over a year ago) for a property called LANGUE for "what languages are required to understand this event". At the time I objected (and Greg agreed) that it was problematic for developers whose native language is neither English nor French, because they'd have trouble keeping straight two very similar foreign words (LANGUE and LANGUAGE). At the meeting, Greg said it would be a useful property, with a better name (I agree), and mentioned the old discussion by way of pointing out that it had come up before. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Sometimes we in the media have to give the | |francis@ecal.com|copycat criminals a little kick-start." -- Tina| | |the Tech Writer, in _Dilbert_ | \================================================================/ --=_alternative 0059600E85256AB0_= Content-Type: text/html; charset="us-ascii"
John, thanks for the clarification. If anyone else sees items on the minutes that are "off a bit" please respond to the list.


John Stracke <francis@ecal.com>
Sent by: owner-ietf-calendar@mail.imc.org

08/22/01 10:18 AM

       
        To:        ietf-calendar@imc.org
        cc:        minutes@ietf.org
        Subject:        Re: CALSCH meeting minutes - London




pregen@egenconsulting.com wrote:

> Greg said it would be helpful to have a language property (like lang)
> added to iCalendar.  He said it could be called lang - John objected
> to this idea.
>
> John objected because it was a French word. This was inconsistent with
> all the other names which are all in English.

Clarification: this discussion didn't happen in the meeting; it was
referenced in the meeting.

There was an old SkiCal proposal (over a year ago) for a property called
LANGUE for "what languages are required to understand this event".  At
the time I objected (and Greg agreed) that it was problematic for
developers whose native language is neither English nor French, because
they'd have trouble keeping straight two very similar foreign words
(LANGUE and LANGUAGE).  At the meeting, Greg said it would be a useful
property, with a better name (I agree), and mentioned the old discussion
by way of pointing out that it had come up before.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Sometimes we in the media have to give the    |
|francis@ecal.com|copycat criminals a little kick-start." -- Tina|
|                |the Tech Writer, in _Dilbert_                  |
\================================================================/

--=_alternative 0059600E85256AB0_=-- From owner-ietf-calendar@mail.imc.org Wed Aug 22 17:08:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24070 for ; Wed, 22 Aug 2001 17:08:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MKqOk25949 for ietf-calendar-bks; Wed, 22 Aug 2001 13:52:24 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MKqNN25943 for ; Wed, 22 Aug 2001 13:52:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15Zeu6-0006hd-00; Wed, 22 Aug 2001 15:47:10 -0500 Message-ID: <3B841A4E.A46AD1C3@kasey.umkc.edu> Date: Wed, 22 Aug 2001 15:47:10 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke , CalSched IETF Subject: Re: CAP: why does a calendar have a TZID? References: <3B7C1284.8070201@ecal.com> <3B81AF56.1E8301DE@kasey.umkc.edu> <3B827A63.7090204@ecal.com> <3B82FBBB.A57B81E@kasey.umkc.edu> <3B83B8CC.80603@ecal.com> <3B84168A.450ED7B@kasey.umkc.edu> <3B8418F4.5070903@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke (and I) wrote: > [ a variety of off-list back-and-forth ] And then there's daylight savings time and all that. It's a lot easier to simply pretend that daylight savings time doesn't happen and list events in local time than having all events switch between two different time zones in the future. Although date math libraries will take care of translating to and from GMT quite handily, so requiring one be embedded into a CUA is no big thing. The question is, is time zone transfer the responsibility of the CS or is it the responsibility of the clients? I would like to see some clearly defined but optional ways for the CS to do it, so I can do a telnet session to a CS and not have to express the times in GMT. Expressing times in GMT is a big PITA unless you've got BBC News on the radio to give you some bearing on it. -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Wed Aug 22 17:19:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24220 for ; Wed, 22 Aug 2001 17:19:25 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7ML6gC26237 for ietf-calendar-bks; Wed, 22 Aug 2001 14:06:42 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ML6fN26233 for ; Wed, 22 Aug 2001 14:06:41 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7ML9D626511 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 22 Aug 2001 17:09:15 -0400 Message-ID: <3B841F79.5060803@ecal.com> Date: Wed, 22 Aug 2001 17:09:13 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP: why does a calendar have a TZID? References: <3B7C1284.8070201@ecal.com> <3B81AF56.1E8301DE@kasey.umkc.edu> <3B827A63.7090204@ecal.com> <3B82FBBB.A57B81E@kasey.umkc.edu> <3B83B8CC.80603@ecal.com> <3B84168A.450ED7B@kasey.umkc.edu> <3B8418F4.5070903@ecal.com> <3B841A4E.A46AD1C3@kasey.umkc.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 David L. Nicol wrote: >And then there's daylight savings time and all that. It's a lot >easier to simply pretend that daylight savings time doesn't happen >and list events in local time than having all events switch between >two different time zones in the future. > It's not two different timezones, it's one timezone with different observances. Read RFC-2445. >I would like to see some clearly defined but optional ways >for the CS to do it, so I can do a telnet session to a CS > Kind of unlikely, unless your CS supports plaintext passwords. >Expressing times >in GMT is a big PITA unless you've got BBC News on the radio >to give you some bearing on it. > date -u -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"She gets kidnapped. He gets killed. But it | |francis@ecal.com|turns out okay." -- _Princess Bride_ poster | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Aug 22 18:38:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25581 for ; Wed, 22 Aug 2001 18:38:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MMRhT28064 for ietf-calendar-bks; Wed, 22 Aug 2001 15:27:43 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MMRfN28060 for ; Wed, 22 Aug 2001 15:27:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15ZgOK-0006rK-00; Wed, 22 Aug 2001 17:22:28 -0500 Message-ID: <3B8430A4.5263BE8C@kasey.umkc.edu> Date: Wed, 22 Aug 2001 17:22:28 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: CalSched IETF Subject: Re: CAP: why does a calendar have a TZID? References: <3B7C1284.8070201@ecal.com> <3B81AF56.1E8301DE@kasey.umkc.edu> <3B827A63.7090204@ecal.com> <3B82FBBB.A57B81E@kasey.umkc.edu> <3B83B8CC.80603@ecal.com> <3B84168A.450ED7B@kasey.umkc.edu> <3B8418F4.5070903@ecal.com> <3B841A4E.A46AD1C3@kasey.umkc.edu> <3B841F79.5060803@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > David L. Nicol wrote: > > >And then there's daylight savings time and all that. It's a lot > >easier to simply pretend that daylight savings time doesn't happen > >and list events in local time than having all events switch between > >two different time zones in the future. > > > It's not two different timezones, it's one timezone with different > observances. Read RFC-2445. No. CST and CDT are two timezones. I don't care what the reference says. Half the year my clock is five hours behind london, half the year its six. Vigo County, Indiana, is at GMT-5 all the time. > >I would like to see some clearly defined but optional ways > >for the CS to do it, so I can do a telnet session to a CS > > > Kind of unlikely, unless your CS supports plaintext passwords. Why won't it? My POP server supports plaintext passwords, so does my IMAP server. Selecting an appropriately secure authENTICATION method is up to the client. > >Expressing times > >in GMT is a big PITA unless you've got BBC News on the radio > >to give you some bearing on it. > > > date -u And how many Windows boxes does that work on? People are IDIOTS, John. We have to accomodate them. Wanting to switch the CAP standard from "every CS knows what timzone it uses by default and will tell you if you ask it" to "every CS must use GMT to be compliant" stinks, to my poorly read, non-compliant nose. If I telnet to port five thousand whatever of the campus calendar server to log in as anonymous and check on a class schedule, I would very much like to have my plain text responses return to me in the local time, including times on events that might have been loaded in from a different time zone. I haven't read the CalSch requirements document, but if "must be able to support a workable but awkward plain text session, the way NNTP, SMTP, POP, IMAP and so forth do" wasn't in there, it surely is missing due to mere oversight. Convince me different (that's right, convince me that telnetability is deprecated and verbose commands are in there for no reason at all) and I'll cheerfully abandon any hope of ever bringing the light of the truth of Authorization Certificates to this podunk, backwater, braindead standards committee and furthermore I will reccommend to whoever I can find that the lot of you be summarily shot. -- David Nicol 816.235.1187 "... raised indoors and tested by certified technicians" From owner-ietf-calendar@mail.imc.org Thu Aug 23 10:18:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23951 for ; Thu, 23 Aug 2001 10:18:05 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7NDokp20253 for ietf-calendar-bks; Thu, 23 Aug 2001 06:50:46 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NDojD20249 for ; Thu, 23 Aug 2001 06:50:45 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA22792; Thu, 23 Aug 2001 09:50:41 -0400 Received: from steltor.com (host8.vpn.cst.ca [192.168.6.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NDoeX26941; Thu, 23 Aug 2001 09:50:40 -0400 (EDT) Message-ID: <3B850A60.E10F3151@steltor.com> Date: Thu, 23 Aug 2001 09:51:28 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: changes needed for CRISP References: <3B7C1216.8090703@ecal.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 It is already on the list of CAP issues and outstanding tasks. (http://calsch.org/ietf/cap-ToDo.txt). George John Stracke wrote: > > If we want to support CRISP, then some changes are needed in CAP. In > section 7.1.5, CAPVERSION, CAR, and QUERYLEVEL all need to be able to > have values of NONE. > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |"How quietly do you think we can nail these back| > |francis@ecal.com |in?" --Calvin | > \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 23 10:18:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23966 for ; Thu, 23 Aug 2001 10:18:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NDn8D20215 for ietf-calendar-bks; Thu, 23 Aug 2001 06:49:08 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NDn6D20210 for ; Thu, 23 Aug 2001 06:49:06 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA22747; Thu, 23 Aug 2001 09:49:00 -0400 Received: from steltor.com (host8.vpn.cst.ca [192.168.6.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NDmxX26853; Thu, 23 Aug 2001 09:48:59 -0400 (EDT) Message-ID: <3B8509FB.FD8F23BE@steltor.com> Date: Thu, 23 Aug 2001 09:49:47 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: MUST anonymous auth? References: <3B7C120D.9070007@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I do not know why it is a must. Perhaps looking in the archives or people who were with CAP from the start can let us know. The CAP requirements document only states that CAP must specify how one can do anonymous login. It does not state that all implementations MUST support it. Even if all implementations MUST support it the CS owners can deny anonymous logins. George John Stracke wrote: > > CAP section 2.4.2.2 says that an implementation MUST support anonymous > authentication. Why? Why should a CS whose owners don't have any content > they're going to expose to anonymous users have code for anonymous auth? > > Also, in section 7.1.3.1, which discusses anon auth, it says "The user's > normal UPN MUST not be used for the subsequent CAP operations". (a) Why > not? (b) What happens if it is used? (c) Should that be "MUST NOT"? > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |It's not an optical illusion, it just looks like| > |francis@ecal.com |one. | > \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 23 10:33:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24365 for ; Thu, 23 Aug 2001 10:33:34 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7NE5Jw20527 for ietf-calendar-bks; Thu, 23 Aug 2001 07:05:19 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NE5HD20522 for ; Thu, 23 Aug 2001 07:05:18 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA23162; Thu, 23 Aug 2001 10:05:13 -0400 Received: from steltor.com (host8.vpn.cst.ca [192.168.6.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NE5CX28085; Thu, 23 Aug 2001 10:05:13 -0400 (EDT) Message-ID: <3B850DC8.E69D5EFE@steltor.com> Date: Thu, 23 Aug 2001 10:06:00 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: these are not legal iCalendar objects References: <3B7C1220.2030905@ecal.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 We replaced VCALENDAR with VCAP to contain all of the commands and responses since it would make things clearer and avoid having VCALENDARS in VCALENDARS. Looking at RFC 2445, all iCalendar objects must begin with BEGIN:VCALENDAR. Thus, we can change all VCAP back into VCALENDAR or simply have all VCAPs in VCALENDARs. As for queries returning invalid calendar components, there are very few required properties. Thus, specifying in CAP how a calendar component returned by a query may differ from the standard should not be too difficult. George John Stracke wrote: > > In all (I think) of the CAP examples, we have a Content-type: of > text/calendar, but the outermost BEGIN of the iCalendar is "VCAP". By > 2445, this is not legal; an iCalendar object always begins with > "BEGIN:VCALENDAR". > > We have similar problems scattered around; for example, in the first > example in 7.2.1.2.1, creating a VCALENDAR component is used to > represent a calendar to create. A VCALENDAR component *is* an iCalendar > object; it cannot (I think) appear inside another component. In the > responses to a query, if you request only some fields, you can get back > VEVENT components which are not legal VEVENTs (they don't have all the > required properties). > > We need to either change the syntax so these data structures do not > claim to be iCalendar objects, or add text to CAP clarifying that these > objects are not what they claim to be, and may not parse properly in a > parser based on RFC-2445. The latter is probably more reasonable; having > them look like iCalendars is probably more helpful than misleading. > Still, I would rather see some minor changes for better harmony with > 2445: have the VCAP contained inside a VCALENDAR, and define a new > component representing calendars. > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |"How quietly do you think we can nail these back| > |francis@ecal.com |in?" --Calvin | > \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 23 10:50:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24664 for ; Thu, 23 Aug 2001 10:50:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NEZQ621129 for ietf-calendar-bks; Thu, 23 Aug 2001 07:35:26 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NEZPD21125 for ; Thu, 23 Aug 2001 07:35:25 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA23765; Thu, 23 Aug 2001 10:35:21 -0400 Received: from steltor.com (host8.vpn.cst.ca [192.168.6.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NEZJX00354; Thu, 23 Aug 2001 10:35:19 -0400 (EDT) Message-ID: <3B8514D7.5B452B67@steltor.com> Date: Thu, 23 Aug 2001 10:36:07 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: stored queries References: <3B7C122E.9000107@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I see no reason why they are necessary. I found nothing in the CAP requirements doc. Anyone against making them optional? George John Stracke wrote: > > CAP's stored queries look problematic to me. Are they really > necessary? I would prefer to be able to build a CAP server as a frontend > to my existing server, which means I don't want to introduce too much > new items to be stored. > > In addition, I'm unhappy about the storage costs. It seems likely that > VQUERYs can't be shared between different users, which means that, if I > have 100K users, each using the same CUA, and that CUA creates 5 > VQUERYs, then I have to store 500K VQUERYs, even though there are only 5 > different ones. This seems wasteful. > > Can stored queries be made optional? > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |"And bring the search warrant." "You mean the| > |francis@ecal.com |sledgehammer, sir?" "Yes." | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 23 10:52:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24712 for ; Thu, 23 Aug 2001 10:52:35 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7NEb0M21186 for ietf-calendar-bks; Thu, 23 Aug 2001 07:37:00 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NEawD21181 for ; Thu, 23 Aug 2001 07:36:58 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA23782; Thu, 23 Aug 2001 10:36:54 -0400 Received: from steltor.com (host8.vpn.cst.ca [192.168.6.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NEarX00518; Thu, 23 Aug 2001 10:36:53 -0400 (EDT) Message-ID: <3B851536.1DEA96A8@steltor.com> Date: Thu, 23 Aug 2001 10:37:42 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: commands need definitions, not just examples References: <3B7C1238.7060101@ecal.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 Its on the CAP to do list. George John Stracke wrote: > > For most of the commands CAP defines, we don't actually get a formal > definition; we just get some informal descriptive text and some > examples. This is a problem, because, with a firm definition, it'll be > impossible to determine whether any given implementation is compliant. > For example, in the first example in 7.2.1.2.1, it is unclear whether > the two calendars created need to be created in the order specified. In > the second example, the text does not match the example: it says "The > response contains the calendar (CALID) and UID of the component"--but it > doesn't; there are no CALID or UID properties in the response. > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |Among animals, it's eat or be eaten. Among | > |francis@ecal.com |people, it's define or be defined. | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 23 11:30:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25793 for ; Thu, 23 Aug 2001 11:30:34 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7NFEpi24079 for ietf-calendar-bks; Thu, 23 Aug 2001 08:14:51 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NFEnD24075 for ; Thu, 23 Aug 2001 08:14:49 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA24630; Thu, 23 Aug 2001 11:14:45 -0400 Received: from steltor.com (host8.vpn.cst.ca [192.168.6.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NFEiX03395; Thu, 23 Aug 2001 11:14:44 -0400 (EDT) Message-ID: <3B851E14.6C9BDD0B@steltor.com> Date: Thu, 23 Aug 2001 11:15:32 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.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 The only thing that searching the archives revealed was the it was suggested that GENERATEUID be used to generate unique calids. But as you suggested in an other post in this thread, the create can return the UID for the component it created. Also, when you create a calendar, the calid can be returned to the client. This will save calls to the CS. George John Stracke wrote: > > GENERATEUID asks the CS to generate one or more unique UIDs. What is > this for? Why can't the client create its own UIDs, like any other CUA? > Why should we introduce extra round-trips, and extra work on the CS? > > If there's some strong reason the UID has to be generated by the CS, > then it should still not be done in a separate command; CREATE should > accept components without UIDs, and report back the UIDs they were assigned. > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |"Baldric, how did you manage to find a turnip| > |francis@ecal.com |that cost 400,000 pounds?" "Well, I had to | > | |haggle." --Blackadder III | > \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 23 11:39:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26015 for ; Thu, 23 Aug 2001 11:39:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NFMXp24304 for ietf-calendar-bks; Thu, 23 Aug 2001 08:22:33 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NFMWD24300 for ; Thu, 23 Aug 2001 08:22:32 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA24820; Thu, 23 Aug 2001 11:22:27 -0400 Received: from steltor.com (host8.vpn.cst.ca [192.168.6.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NFMOX04062; Thu, 23 Aug 2001 11:22:24 -0400 (EDT) Message-ID: <3B851FE0.59933E7D@steltor.com> Date: Thu, 23 Aug 2001 11:23:12 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: moving components References: <3B7C1254.1020001@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I Agree: - you should be able to move a component/calendar from one calendar to another as long as the calendars are owned by the same user - you should not be able to move a calendar/component owned by person X into a calendar owner by person Y. (If in the future, we may find this useful, we can add it to a latter version of CAP.) Any objections? George John Stracke wrote: > > The editors note for 7.2.1.6 (MOVE) says: > > > 1) Should one be able to move a calendar owned by person X into a > > calendar owned by person Y. (Can these such rights be specified in VCARs?) > > I think such a move is probably risky; if it's possible, though, then it > must be possible to write VCARs to control it. > > > 2) Should we also be able to move components from one calendar to another? > > Definitely--otherwise there's no way for a user to correct their mistake > if they create a component in the wrong calendar. > > > What if the calendars are owned by different users? > > As with moving calendars, I think this is problematic. Does ownership > change? (Permitting an arbitrary user to change ownership is potentially > risky; if nothing else, it permits someone to create incriminating data > and make it look like it was created by someone else.) If not, does the > new user have the ability to remove the component from their calendar? > They'd better be able to; but, if they can, where does it go? Can they > delete it? > > -- > /================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |===============================================| > |eCal Corp. |Stupid, adj.: Losing $25 on the game and $50 on| > |francis@ecal.com |the instant replay. | > \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 23 13:39:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27875 for ; Thu, 23 Aug 2001 13:39:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NHMnG01178 for ietf-calendar-bks; Thu, 23 Aug 2001 10:22:49 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NHMmD01174 for ; Thu, 23 Aug 2001 10:22:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15Zy6f-00079r-00; Thu, 23 Aug 2001 12:17:25 -0500 Message-ID: <3B853AA4.D73916F8@kasey.umkc.edu> Date: Thu, 23 Aug 2001 12:17:24 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: George Babics CC: John Stracke , calsch WG Subject: Re: CAP: moving components References: <3B7C1254.1020001@ecal.com> <3B851FE0.59933E7D@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Two thoughts: 1: moving, and editing existing, make sense as optional features rather than core features since they can both be accomplished in the CUA rather than the CS. Consider e-mail. An e-mailing system set up just for the dangerously outspoken might allow the cancelation of a message that was composed, but to edit a message you would cancel the old one and replace it with a new one. This is much simpler to define, since you don't need to have an editing language. 2: Questions of access rights following movement of events from calendar to calendar spring from a confusion which comes from thinking that the obvious law of physics that an item can only be in one container holds in the n-dimensional world of data structures. It doesn't. If the standard adopts an abstraction in which "Events" as such have lives (independent unique keys, at least) of their own, then common events, such as "The Workday Begins" can be included in everyone's calendar without needing to be repeated and repeated and repeated. -- David Nicol 816.235.1187 "In the world of the future, the new illiterate will be the person who has not learned how to ignore morons" -- Not Alvin Toffler From owner-ietf-calendar@mail.imc.org Thu Aug 23 15:19:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29678 for ; Thu, 23 Aug 2001 15:19:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NIspD02739 for ietf-calendar-bks; Thu, 23 Aug 2001 11:54:51 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NIsnD02735 for ; Thu, 23 Aug 2001 11:54:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15ZzXk-0007Bz-00; Thu, 23 Aug 2001 13:49:28 -0500 Message-ID: <3B855038.6777A21C@kasey.umkc.edu> Date: Thu, 23 Aug 2001 13:49:28 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: event notification ((was Re: CAP: autologout References: <3B7C11D7.7080705@ecal.com> <3B7FF900.AC1E9196@steltor.com> <3B8305F6.EB597BA7@kasey.umkc.edu> <3B83BCEE.8070302@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > David L. Nicol wrote: > > >Is there an event-notification channel written into the standard, so that > >when something happens, the event description is sent to the client? > > No. Event notification protocols have turned out to be surprisingly > tricky in the past. It'd be useful, but we're probably better off > waiting for a future rev of CAP. Here's a protocol definition. What surprising trickinesses do you see in it? Spontaneous Transmissions (STs): At any time except during the transmission of another response, the server MAY initiate a communication which is not immediately prompted by client command. Examples of such communications would be "chimes," event notifications, and timeout warnings. Every ST consists of a descriptive line which starts with the letters "ST" and a space, then a CRLF, then zero or more lines of data, and finally a line with a single dot. Clients MUST be prepared to accept a well-formed ST at any time except during the receiving of another transmission, for instance between issuing a command and receiving a response code. The exact contents of STs are beyond the scope of this document. A typical difficult example: C: SENDDATA C: Content-Type:text/calendar; method=CREATE; charset=US-ASCII C: Content-Transfer-Encoding:7bit C: C: BEGIN:VCAP C: VERSION:2.1 C: CMDID:abcde-2 C: METHOD:CREATE C: TARGET:cap://cal.example.com/relcal1 C: BEGIN:VQUERY C: BEGIN:VQUERY C: QUERYNAME:GetAlliTIPinQueue C: QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE' C: END:VQUERY C: END:VEVENT C: END:VCAP C: . S: ST quarter-hourly chime: The time is now 1:45 PM S: . S: ST urgent bell S: Get moving! Class is at two. S: . S: 2.0 S: Content-Type:text/calendar; method=RESPONSE; OPTINFO="CMDID:abcde" S: S: BEGIN:VCAP S: CMDID:abcde-2 S: METHOD:RESPONSE [...] -- David Nicol 816.235.1187 "In the world of the future, the new illiterate will be the person who has not learned how to ignore morons" -- Not Alvin Toffler From owner-ietf-calendar@mail.imc.org Thu Aug 23 17:20:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02004 for ; Thu, 23 Aug 2001 17:20:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NL4Pc04738 for ietf-calendar-bks; Thu, 23 Aug 2001 14:04:25 -0700 (PDT) Received: from mcncmdm1exims3.marriott.com (host254.marriott.com [162.130.1.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NL4ND04734 for ; Thu, 23 Aug 2001 14:04:24 -0700 (PDT) Received: from PickupDirectory by mcncmdm1exims3.marriott.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RPNQVRWH; Thu, 23 Aug 2001 17:04:11 -0400 Received: FROM above.proper.com BY mcncmscn2.marriott.com ; Thu Aug 23 10:25:27 2001 -0400 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NDn8D20215 for ietf-calendar-bks; Thu, 23 Aug 2001 06:49:08 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NDn6D20210 for ; Thu, 23 Aug 2001 06:49:06 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA22747; Thu, 23 Aug 2001 09:49:00 -0400 Received: from steltor.com (host8.vpn.cst.ca [192.168.6.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NDmxX26853; Thu, 23 Aug 2001 09:48:59 -0400 (EDT) Message-ID: <3B8509FB.FD8F23BE@steltor.com> Date: Thu, 23 Aug 2001 09:49:47 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG Subject: Re: CAP: MUST anonymous auth? References: <3B7C120D.9070007@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I do not know why it is a must. Perhaps looking in the archives or people who were with CAP from the start can let us know. The CAP requirements document only states that CAP must specify how one can do anonymous login. It does not state that all implementations MUST support it. Even if all implementations MUST support it the CS owners can deny anonymous logins. George John Stracke wrote: > > CAP section 2.4.2.2 says that an implementation MUST support anonymous > authentication. Why? Why should a CS whose owners don't have any content > they're going to expose to anonymous users have code for anonymous auth? > > Also, in section 7.1.3.1, which discusses anon auth, it says "The user's > normal UPN MUST not be used for the subsequent CAP operations". (a) Why > not? (b) What happens if it is used? (c) Should that be "MUST NOT"? > > -- > /=================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |================================================| > |eCal Corp. |It's not an optical illusion, it just looks like| > |francis@ecal.com |one. | > \=================================================================/ From subs-reminder@imc.org Thu Aug 23 20:43:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04457 for ; Thu, 23 Aug 2001 20:43:18 -0400 (EDT) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id f7O0iW723319; Thu, 23 Aug 2001 17:44:32 -0700 (PDT) Date: Thu, 23 Aug 2001 17:44:32 -0700 (PDT) Message-Id: <200108240044.f7O0iW723319@above.proper.com> To: calsch-archive@ietf.org Subject: [[462214896]] Subscription to ietf-calendar for calsch-archive@lists.ietf.org Greetings. This message is a periodic reminder that calsch-archive@lists.ietf.org is subscribed to the ietf-calendar mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-calendar mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-calendar@mail.imc.org Fri Aug 24 00:20:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08710 for ; Fri, 24 Aug 2001 00:20:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O3xLs09666 for ietf-calendar-bks; Thu, 23 Aug 2001 20:59:21 -0700 (PDT) Received: from war.elea.dhs.org (modemcable057.200-201-24.mtl.mc.videotron.ca [24.201.200.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O3xKD09661 for ; Thu, 23 Aug 2001 20:59:20 -0700 (PDT) Received: from famine.elea.dhs.org (famine.elea.dhs.org [192.168.27.2]) by war.elea.dhs.org (8.9.3/8.9.3) with ESMTP id AAA22395 for ; Fri, 24 Aug 2001 00:22:04 -0400 Received: (from dissent@localhost) by famine.elea.dhs.org (8.9.3/8.9.3) id XAA11710; Thu, 23 Aug 2001 23:59:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15237.53525.624006.661650@famine.elea.dhs.org> Date: Thu, 23 Aug 2001 23:59:17 -0400 X-Spook: Khaddafi Legion of Doom Ft. Meade New World Order SCUD missile security cypherpunk Saddam Hussein From: Alexander Taler To: calsch WG Subject: Re: CAP: why do we need GENERATEUID? In-Reply-To: <3B851E14.6C9BDD0B@steltor.com> References: <3B7C1243.5010601@ecal.com> <3B851E14.6C9BDD0B@steltor.com> X-Mailer: VM 6.92 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid X-Attribution: dissent Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit GENERATEUID is there for clients who have difficulty generating properly unique IDs. iCal recommends that UIDs be based on hostname or IP address to assure their uniqueness. This is a problem in environments where hostnames can be rapidly reassigned, (dial-up connections or wireless devices) or environments where hosts do not have properly unique hostnames or IP addresses (192.168.x.x or 10.x.x.x). In addition, it may allow applications on small devices to reduce their memory footprint. In response to some of John's earlier points: Using GENERATEUID doeesn't mean an additional round-trip for each create, a client can request many UIDs at once and store them locally for that session, or forever. Sometimes a single event requires multiple VEVENTs to represent it, in these cases the client needs to add the UID to indicate the proper linkage between the VEVENTs. Returning the UID is problematic in the case where multiple components are created, since the returned UIDs need to be correlated with the components which were sent. Alex >>>>> "George" == George Babics writes: George> To: John Stracke George> Subject: Re: CAP: why do we need GENERATEUID? George> Date: Thu, 23 Aug 2001 11:15:32 -0400 George> The only thing that searching the archives revealed George> was the it was suggested that GENERATEUID be used to generate unique George> calids. George> But as you suggested in an other post in this thread, George> the create can return the UID for the component it created. Also, George> when you create a calendar, the calid can be returned to the George> client. This will save calls to the CS. George> George George> John Stracke wrote: >> >> GENERATEUID asks the CS to generate one or more unique UIDs. What is this >> for? Why can't the client create its own UIDs, like any other CUA? Why >> should we introduce extra round-trips, and extra work on the CS? >> >> If there's some strong reason the UID has to be generated by the CS, then >> it should still not be done in a separate command; CREATE should accept >> components without UIDs, and report back the UIDs they were assigned. >> >> -- /==============================================================\ |John >> Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist >> |=============================================| |eCal Corp. |"Baldric, >> how did you manage to find a turnip| |francis@ecal.com >> |that cost 400,000 pounds?" "Well, I had to | | >> |haggle." --Blackadder III | >> \==============================================================/ -- --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-calendar@mail.imc.org Fri Aug 24 13:46:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10724 for ; Fri, 24 Aug 2001 13:46:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OHVbR26779 for ietf-calendar-bks; Fri, 24 Aug 2001 10:31:37 -0700 (PDT) Received: from smtp6.andrew.cmu.edu (SMTP6.ANDREW.CMU.EDU [128.2.10.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OHVaD26774 for ; Fri, 24 Aug 2001 10:31:36 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) (user=leg mech=KERBEROS_V4 (56 bits)) by smtp6.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f7OHVU68016022; Fri, 24 Aug 2001 13:31:30 -0400 Date: Fri, 24 Aug 2001 13:31:30 -0400 Message-Id: <200108241731.f7OHVU68016022@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: John Stracke , "David L. Nicol" Cc: calsch WG In-reply-to: <3B855038.6777A21C@kasey.umkc.edu> Subject: Re: event notification ((was Re: CAP: autologout References: <3B7C11D7.7080705@ecal.com> <3B7FF900.AC1E9196@steltor.com> <3B8305F6.EB597BA7@kasey.umkc.edu> <3B83BCEE.8070302@ecal.com> <3B855038.6777A21C@kasey.umkc.edu> 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: Thu, 23 Aug 2001 13:49:28 -0500 From: "David L. Nicol" [...] The exact contents of STs are beyond the scope of this document. This doesn't seem very useful. How does this lead to interoperability? What is a client suppose to do with the contents except discard them? Larry From owner-ietf-calendar@mail.imc.org Fri Aug 24 16:20:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14476 for ; Fri, 24 Aug 2001 16:20:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OK4ie06151 for ietf-calendar-bks; Fri, 24 Aug 2001 13:04:44 -0700 (PDT) Received: from nicol6.umkc.edu (mail@nicol6.umkc.edu [134.193.4.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OK4hD06147 for ; Fri, 24 Aug 2001 13:04:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=kasey.umkc.edu ident=david) by nicol6.umkc.edu with esmtp (Exim 3.12 #1 (Debian)) id 15aN6o-0007dz-00; Fri, 24 Aug 2001 14:59:14 -0500 Message-ID: <3B86B212.6011D36C@kasey.umkc.edu> Date: Fri, 24 Aug 2001 14:59:14 -0500 From: "David L. Nicol" Organization: UMKC Information Services Central Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield , CalSched IETF Subject: Re: event notification ((was Re: CAP: autologout References: <3B7C11D7.7080705@ecal.com> <3B7FF900.AC1E9196@steltor.com> <3B8305F6.EB597BA7@kasey.umkc.edu> <3B83BCEE.8070302@ecal.com> <3B855038.6777A21C@kasey.umkc.edu> <200108241731.f7OHVU68016022@smtp6.andrew.cmu.edu> 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 Lawrence Greenfield wrote: > > Date: Thu, 23 Aug 2001 13:49:28 -0500 > From: "David L. Nicol" > > [...] > > The exact contents of STs are beyond the scope of this document. > > This doesn't seem very useful. I don't know about you, but I am constantly typing things like echo echo Soccer Practice \| mail pagers-nicol | at 3:30 pm tomorrow into unix command lines. > How does this lead to > interoperability? With the protocol written into CAP, different CS implementations will issue event notifications regarding events affecting connected users in the same way. > What is a client suppose to do with the contents > except discard them? Display them to the user, in a pop-up window. Or send them to the user's pocket pager. That's between the user and their installation. Stracke said "event-notification protocols have problems" and I responded with one that as far as I can tell would be resilient against the problem I am aware of, which is confusion due to in-band data getting fouled by an out-of-band data that is produced in the middle of it. Having a CS implementation just send e-mails may be a lot cleaner, for certain installations, but not for all. The paradigm of many short sessions against a server that can only handle so many simultaneous sessions is but one possible paradigm. An even simpler way of addressing this kind of thing (and any other kinds of things that may appear) is to allow for open-ended vendor extensions somehow. Then a compliant implementation could define some extras that are not defined in the standard, without breaking their compliance. Well-formed vendor extensions would be guaranteed to not cause protocol participants (wither the C or the S) problems and implementors could compete with each other in a wide open space. Something like: Extended commands and transmissions may be sent from either side of the connection at any time except during the middle of another transmission of any time. Extended commands and transmissions start with an X and end with a dot on a line by itself. The first line of an Extended command SHOULD look like the definition of X-params, that is, X-[Vendor]-[Command] [arguments] When the Client sends an X-command, the server MUST respond with a numerical response from a response set defined to include at least one reserved numerical response which indicates that the server has no idea what the client is going on about. Such a defined syntax for Features That Have Been Left Out would take care of not only event notifications, but those Permission Tickets or whatever you want to call them that I've made so much stink about in the last month. -- David Nicol 816.235.1187 www.funnytimes.com From owner-ietf-calendar@mail.imc.org Mon Aug 27 11:12:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21261 for ; Mon, 27 Aug 2001 11:12:44 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7REnhw15215 for ietf-calendar-bks; Mon, 27 Aug 2001 07:49:43 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7REnfD15211 for ; Mon, 27 Aug 2001 07:49:41 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7REqM614376 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Mon, 27 Aug 2001 10:52:23 -0400 Message-ID: <3B8A5EA6.50405@ecal.com> Date: Mon, 27 Aug 2001 10:52:22 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B851E14.6C9BDD0B@steltor.com> <15237.53525.624006.661650@famine.elea.dhs.org> 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 Alexander Taler wrote: >Using GENERATEUID doeesn't mean an additional round-trip for each >create, a client can request many UIDs at once and store them >locally for that session, or forever. > Oh, that's a good point. >Returning the UID is problematic in the case where multiple >components are created, since the returned UIDs need to be >correlated with the components which were sent. > True. OK, so, I withdraw my objections. I do believe that many CUAs will create their own UIDs, though, and we should add explanatory text to that effect--otherwise, someone might try to build a CS that requires the UIDs in a CREATE to be ones that it generated. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |The Net was designed to survive nukes, but not| |francis@ecal.com|lawsuits. Wait a minute. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 27 11:13:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21280 for ; Mon, 27 Aug 2001 11:13:38 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7RErSe15293 for ietf-calendar-bks; Mon, 27 Aug 2001 07:53:28 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RErRD15289 for ; Mon, 27 Aug 2001 07:53:27 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7REu7614388 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Mon, 27 Aug 2001 10:56:08 -0400 Message-ID: <3B8A5F87.4050908@ecal.com> Date: Mon, 27 Aug 2001 10:56:07 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: MUST anonymous auth? References: <3B7C120D.9070007@ecal.com> <3B8509FB.FD8F23BE@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 George Babics wrote: >The CAP requirements document only states that CAP must specify >how one can do anonymous login. It does not state that all >implementations MUST support it. > OK, good. >Even if all implementations MUST support it the CS owners can >deny anonymous logins. > Mmm, from the protocol point of view, a CS that's configured to deny them is an implementation that doesn't support them. To me, this means that, if implementations MUST support them, the owners can't turn them off. That's why I want to see the MUST removed from the spec. Mandating that implementations contain features that can be turned off is not a statement of protocol requirements; it's a statement of market requirements . The IETF does not do marketing. :-) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"How can one conceive of a one party system in a| |francis@ecal.com|country that has over 200 varieties of cheese?" | | |--Charles de Gaulle | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Aug 27 12:09:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23140 for ; Mon, 27 Aug 2001 12:09:27 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7RFnEk19110 for ietf-calendar-bks; Mon, 27 Aug 2001 08:49:14 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RFnDD19103 for ; Mon, 27 Aug 2001 08:49:13 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f7RFn6i18012 for ; Mon, 27 Aug 2001 08:49:06 -0700 (PDT) Received: from netscape.com ([206.222.229.36]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GIQH9V00.1AQ; Mon, 27 Aug 2001 08:49:08 -0700 Message-ID: <3B8A6BF3.320404B@netscape.com> Date: Mon, 27 Aug 2001 08:49:07 -0700 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: John Stracke CC: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B851E14.6C9BDD0B@steltor.com> <15237.53525.624006.661650@famine.elea.dhs.org> <3B8A5EA6.50405@ecal.com> Content-Type: multipart/mixed; boundary="------------5708A2EF2F10EF1219720169" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5708A2EF2F10EF1219720169 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Alexander Taler wrote: > > >Using GENERATEUID doeesn't mean an additional round-trip for each > >create, a client can request many UIDs at once and store them > >locally for that session, or forever. > > > Oh, that's a good point. > > >Returning the UID is problematic in the case where multiple > >components are created, since the returned UIDs need to be > >correlated with the components which were sent. > > > True. > > OK, so, I withdraw my objections. I do believe that many CUAs will > create their own UIDs, though, and we should add explanatory text to > that effect--otherwise, someone might try to build a CS that requires > the UIDs in a CREATE to be ones that it generated. > This is a good point. I will add explanatory text. Basically, if you can generate GUIDs then you don't need to call GENERATEUID, but if you don't have guid generation code in your cua, then you can use the server to generate them for you. -Steve --------------5708A2EF2F10EF1219720169 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 x-mozilla-html:FALSE adr;dom;quoted-printable:;;501 East Middlefield Road=0D=0A;Mountain View;CA;94043; org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner tel;fax:(415) 428-4059 tel;work:(415) 937-2378 x-mozilla-cpt:;0 fn:Steve Mansour end:vcard --------------5708A2EF2F10EF1219720169-- From owner-ietf-calendar@mail.imc.org Tue Aug 28 10:12:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10948 for ; Tue, 28 Aug 2001 10:12:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SDuZZ22646 for ietf-calendar-bks; Tue, 28 Aug 2001 06:56:35 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SDuYD22642 for ; Tue, 28 Aug 2001 06:56:34 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7SDxG621223 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Tue, 28 Aug 2001 09:59:17 -0400 Message-ID: <3B8BA3B4.8010902@ecal.com> Date: Tue, 28 Aug 2001 09:59:16 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B851E14.6C9BDD0B@steltor.com> <15237.53525.624006.661650@famine.elea.dhs.org> <3B8A5EA6.50405@ecal.com> <3B8A6BF3.320404B@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: >Basically, if you can >generate GUIDs then you don't need to call GENERATEUID, but if you don't >have guid generation code in your cua, then you can use the server to >generate them for you. > You don't even need guids, really; if you know a reliable hostname for your machine, you can use the locallyUnique@hostname approach used for Message- Id:. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Unless. -- The Lorax | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 28 11:54:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13656 for ; Tue, 28 Aug 2001 11:54:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SFeHX28099 for ietf-calendar-bks; Tue, 28 Aug 2001 08:40:17 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SFeFD28092 for ; Tue, 28 Aug 2001 08:40:15 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f7SFeBr10146 for ; Tue, 28 Aug 2001 08:40:11 -0700 (PDT) Received: from netscape.com ([206.222.229.36]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GISBIZ00.D7J; Tue, 28 Aug 2001 08:40:11 -0700 Message-ID: <3B8BBB5B.CC4C11E7@netscape.com> Date: Tue, 28 Aug 2001 08:40:11 -0700 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: John Stracke CC: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B851E14.6C9BDD0B@steltor.com> <15237.53525.624006.661650@famine.elea.dhs.org> <3B8A5EA6.50405@ecal.com> <3B8A6BF3.320404B@netscape.com> <3B8BA3B4.8010902@ecal.com> Content-Type: multipart/mixed; boundary="------------545037F63F661F93F13845DE" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------545037F63F661F93F13845DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > Steve Mansour wrote: > > >Basically, if you can > >generate GUIDs then you don't need to call GENERATEUID, but if you don't > >have guid generation code in your cua, then you can use the server to > >generate them for you. > > > You don't even need guids, really; if you know a reliable hostname for > your machine, you can use the locallyUnique@hostname approach used for > Message- Id:. Remember that people may send this stuff via iMIP to anywhere. So, I think the only safe thing is to call them GUIDs. You just need to be sure the UIDs are unique in whatever calstore the component eventually arrives. So, from the spec point of view, it's best to call them GUIDs. But as a practical matter, your point is true. -Steve --------------545037F63F661F93F13845DE 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 x-mozilla-html:FALSE adr;dom;quoted-printable:;;501 East Middlefield Road=0D=0A;Mountain View;CA;94043; org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner tel;fax:(415) 428-4059 tel;work:(415) 937-2378 x-mozilla-cpt:;0 fn:Steve Mansour end:vcard --------------545037F63F661F93F13845DE-- From owner-ietf-calendar@mail.imc.org Tue Aug 28 12:14:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14293 for ; Tue, 28 Aug 2001 12:14:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SG3T801807 for ietf-calendar-bks; Tue, 28 Aug 2001 09:03:29 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SG3RD01802 for ; Tue, 28 Aug 2001 09:03:27 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7SG69619130 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Tue, 28 Aug 2001 12:06:11 -0400 Message-ID: <3B8BC170.2090409@ecal.com> Date: Tue, 28 Aug 2001 12:06:08 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: why do we need GENERATEUID? References: <3B7C1243.5010601@ecal.com> <3B851E14.6C9BDD0B@steltor.com> <15237.53525.624006.661650@famine.elea.dhs.org> <3B8A5EA6.50405@ecal.com> <3B8A6BF3.320404B@netscape.com> <3B8BA3B4.8010902@ecal.com> <3B8BBB5B.CC4C11E7@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: >John Stracke wrote: > >>You don't even need guids, really; if you know a reliable hostname for >>your machine, you can use the locallyUnique@hostname approach used for >>Message- Id:. >> > >Remember that people may send this stuff via iMIP to anywhere. So, I >think the only safe thing is to call them GUIDs. > Why's that? What's unsafe about @hostname? > You just need to be >sure the UIDs are unique in whatever calstore the component eventually >arrives. So, from the spec point of view, it's best to call them GUIDs. > I think that would be an unsafe thing to state in the text; it might mislead some implementors into thinking that UIDs have to be GUIDs, and reject UIDs that aren't. Note that RFC-2445 already has examples of the @hostname form. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |If God had meant us to be in the Army, we | |francis@ecal.com|would've been born with green, baggy skin. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Aug 28 13:07:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16072 for ; Tue, 28 Aug 2001 13:07:52 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SGsfl03142 for ietf-calendar-bks; Tue, 28 Aug 2001 09:54:41 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SGsdD03138 for ; Tue, 28 Aug 2001 09:54:39 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA27469 for ; Tue, 28 Aug 2001 11:51:09 -0500 From: "Shannon J. Clark" To: "calsch WG" Subject: RE: CAP: why do we need GENERATEUID? Date: Tue, 28 Aug 2001 11:54:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <3B8BC170.2090409@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well a few thoughts come to mind. Not all reasonable devices on which a CUA might be running have unique hostnames - PDAs for example, but also corporate desktops that may have only a DHCP assigned internal IP address - unique within that workgroup - but likely not within the whole corporation and certainly not within the context of the Internet (and many times with Windows boxes "hostname" is set to some default like "hostname" - rather than to something unique) This could fairly easily result in UIDs being generated, even of a @hostname form that are not unique - particularly if usage amongst non-unique machines is similar (everyone checking and making appointments first thing in the morning - not unlikely that two people would make a calObject at the same time on identically named/configured devices.) Remember that in many corporate environments machines are identically configured - relying on DHCP for networking - but not relying on unique hostnames. Particularly with laptops even DHCP assigned ip addresses are frequently assigned to multiple machines at the same time (one to a now disconnect laptop and one to a newly connected machine for example) These are not crushing difficulties - however it does point to a place where the standards document(s) should be careful and should define what is meant even by such seemingly "obvious" terms as "unique" - and furthermore it should be clearly spelled out what the standard assumes - and how to handle some types of common error cases. For example - one option might be for the server to use its GENERATEUID as a standard behavior in environments where CUA generated UIDs are unlikely to also be GUIDs (such as a PDA heavy use case, or a corporate environment in some cases) - I'm sure however there are all sorts of issues around this idea that need to be carefully considered and looked at. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Tuesday, August 28, 2001 11:06 AM To: calsch WG Subject: Re: CAP: why do we need GENERATEUID? Steve Mansour wrote: >John Stracke wrote: > >>You don't even need guids, really; if you know a reliable hostname for >>your machine, you can use the locallyUnique@hostname approach used for >>Message- Id:. >> > >Remember that people may send this stuff via iMIP to anywhere. So, I >think the only safe thing is to call them GUIDs. > Why's that? What's unsafe about @hostname? > You just need to be >sure the UIDs are unique in whatever calstore the component eventually >arrives. So, from the spec point of view, it's best to call them GUIDs. > I think that would be an unsafe thing to state in the text; it might mislead some implementors into thinking that UIDs have to be GUIDs, and reject UIDs that aren't. Note that RFC-2445 already has examples of the @hostname form. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |If God had meant us to be in the Army, we | |francis@ecal.com|would've been born with green, baggy skin. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Aug 30 10:54:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18864 for ; Thu, 30 Aug 2001 10:54:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UEbOR03971 for ietf-calendar-bks; Thu, 30 Aug 2001 07:37:24 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UEbMD03967 for ; Thu, 30 Aug 2001 07:37:23 -0700 (PDT) Received: from ecal.com (IDENT:francis@localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7UEc7611256 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Thu, 30 Aug 2001 10:39:59 -0400 Message-ID: <3B8E4FC5.70408@ecal.com> Date: Thu, 30 Aug 2001 10:37:58 -0400 From: John Stracke Organization: eCal Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: calsch WG Subject: Re: CAP: why do we need GENERATEUID? 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 Shannon J. Clark wrote: >Not all reasonable devices on which a CUA might be running have unique >hostnames > [...] >This could fairly easily result in UIDs being generated, even of a @hostname >form that are not unique > This is not news. This is why Message-ID:s are generated with as much randomness as possible, and, ideally, with some other bit of probably-unique data in the local-part (e.g., MAC address, if available). Perhaps what I should have said is, "Why is the @hostname form *less* safe than GUIDs?" GUIDs aren't magic, after all; if the system doesn't have any unique identifiers around, it won't be able to guarantee uniqueness of the GUID. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Almost no one has ever wanted a 1/4" drill bit;| |francis@ecal.com|all they ever wanted was a 1/4" hole. | \================================================================/