From subs-reminder@imc.org Mon Apr 1 18:20:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18737 for ; Mon, 1 Apr 2002 18:20:46 -0500 (EST) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g31NKkO01404; Mon, 1 Apr 2002 15:20:46 -0800 (PST) Date: Mon, 1 Apr 2002 15:20:46 -0800 (PST) Message-Id: <200204012320.g31NKkO01404@above.proper.com> To: calsch-archive@ietf.org Subject: [[516648126]] 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. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "calsch-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-calendar@mail.imc.org Fri Apr 5 09:51:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06256 for ; Fri, 5 Apr 2002 09:51:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35EaEb16273 for ietf-calendar-bks; Fri, 5 Apr 2002 06:36:14 -0800 (PST) Received: from eeyore.jsoft.com (archive.jsoft.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35EaDm16269 for ; Fri, 5 Apr 2002 06:36:13 -0800 (PST) Received: from jsoft.com (IDENT:yWxUPv8jOyfdroYULNgXa5EWzISrzp3O@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g35EY2004975 for ; Fri, 5 Apr 2002 08:34:03 -0600 Message-ID: <3CADB5DA.2090709@jsoft.com> Date: Fri, 05 Apr 2002 08:34:02 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalSched IETF Subject: Is there a way to test iCalendar 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 want to test that iCalendar data is valid. I'm generating iCalendar data and reading it with the calendar in mozilla. That app uses libical and does ok with finding errors. I was wondering if there were other ways to validate? Is there a service or ? that would validate iCalendar data? Gary From owner-ietf-calendar@mail.imc.org Mon Apr 8 04:13:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17555 for ; Mon, 8 Apr 2002 04:13:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g387u1i10228 for ietf-calendar-bks; Mon, 8 Apr 2002 00:56:01 -0700 (PDT) Received: from mail.xandmail.com ([212.155.184.97]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g387txm10217; Mon, 8 Apr 2002 00:55:59 -0700 (PDT) Received: from xandmail.com (localhost.localdomain [127.0.0.1]) by mail.xandmail.com (8.11.6/8.9.3) with ESMTP id g387twX13106; Mon, 8 Apr 2002 09:55:58 +0200 Date: Mon, 8 Apr 2002 09:55:58 +0200 Message-Id: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_=__=_XaM3_Boundary.1018252558.2A.164494.42.11299.52.42.101010.699723146" From: "=?iso-8859-1?Q?Claude_LALYRE?=" To: ietf-calendar@imc.org To: ietf-calendar-request@imc.org X-XaM3-API-Version: 3.1.1build6 X-type: 0 X-SenderIP: 212.155.184.109 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_=__=_XaM3_Boundary.1018252558.2A.164494.42.11299.52.42.101010.699723146 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 U1VCU0NSSUJFIGlldGYtY2FsZW5kYXJAaW1jLm9yZyAKCkRpc2NsYWltZXI6IGh0dHA6Ly93 d3cueGFuZG1haWwuY29tL2Rpc2NsYWltZXIuaHRtbAoKCg== --_=__=_XaM3_Boundary.1018252558.2A.164494.42.11299.52.42.101010.699723146 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PFA+U1VCU0NSSUJFIDxBIGhyZWY9Im1haWx0bzppZXRmLWNhbGVuZGFyQGltYy5vcmciPmll dGYtY2FsZW5kYXJAaW1jLm9yZzwvQT4gPC9QPg0KPFA+PEJSPiZuYnNwOzwvUD48ZGl2Pgo8 YSBocmVmPSJodHRwOi8vd3d3LnhhbmRtYWlsLmNvbS9kaXNjbGFpbWVyLmh0bWwiPkRpc2Ns YWltZXI8L2E+CjwvZGl2Pgo= --_=__=_XaM3_Boundary.1018252558.2A.164494.42.11299.52.42.101010.699723146-- From owner-ietf-calendar@mail.imc.org Mon Apr 8 17:56:16 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07726 for ; Mon, 8 Apr 2002 17:56:16 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g38Ll2g09299 for ietf-calendar-bks; Mon, 8 Apr 2002 14:47:02 -0700 (PDT) Received: from c005.snv.cp.net (h007.c005.snv.cp.net [209.228.33.142]) by above.proper.com (8.11.6/8.11.3) with SMTP id g38Ll1m09289 for ; Mon, 8 Apr 2002 14:47:01 -0700 (PDT) Received: (cpmta 27356 invoked from network); 8 Apr 2002 14:46:58 -0700 Received: from 209.228.8.150 (HELO eieio) by smtp.criticalpath.net (209.228.33.142) with SMTP; 8 Apr 2002 14:46:58 -0700 X-Sent: 8 Apr 2002 21:46:58 GMT From: "Karen Chu" To: Date: Mon, 8 Apr 2002 14:53:27 -0700 Message-ID: <002101c1df47$d022d3e0$9608e4d1@sfo1.us.cp.net> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit From owner-ietf-calendar@mail.imc.org Tue Apr 9 08:43:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03570 for ; Tue, 9 Apr 2002 08:43:24 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g39CWJU11386 for ietf-calendar-bks; Tue, 9 Apr 2002 05:32:19 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39CWIm11381 for ; Tue, 9 Apr 2002 05:32:18 -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 IAA24342 for ; Tue, 9 Apr 2002 08:32:18 -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 IAA11532 for ; Tue, 9 Apr 2002 08:32:18 -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 IAA03214 for ; Tue, 9 Apr 2002 08:32:07 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Tue, 9 Apr 2002 08:32:06 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: www.calsch.org moved to new server Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just FYI- if anyone sees problems with the website, please drop me a note. I think we got it all moved over correctly, but if anything is amiss, let me know. The new server should be stronger, faster and able to leap buildings in a single bound... :-) -Bob From owner-ietf-calendar@mail.imc.org Fri Apr 19 02:48:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12048 for ; Fri, 19 Apr 2002 02:48:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3J6aUs07087 for ietf-calendar-bks; Thu, 18 Apr 2002 23:36:30 -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 g3J6aTb07083 for ; Thu, 18 Apr 2002 23:36:29 -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 g3J6aKs24451 for ; Thu, 18 Apr 2002 23:36:20 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GUSYCM00.IVK for ; Thu, 18 Apr 2002 23:36:22 -0700 Message-ID: <3CBFBAA2.1708473A@netscape.com> Date: Thu, 18 Apr 2002 23:35:15 -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: CalSched IETF Subject: CAP Issue: Where to store METHOD info Content-Type: multipart/mixed; boundary="------------3A16A60AAE38410C1AEE52DD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3A16A60AAE38410C1AEE52DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Here's a summary of the next CAP issue to nail. We have not yet defined what we're going to do with METHOD information. We have stated that we want to move METHOD information into components. But we have not yet defined a property in which to store the info. We may not want to store it in a property named METHOD because that property is already used in iTIP and it appears in the VCALENDAR container (not a component container). We need to define the property we want to use. Once the method information is stored in a VEVENT, VTODO, or VJOURNAL, it is less an action and more a state. It's name should reflect its use. So, something like WORKFLOWSTATE is probably better (though I'm not wed to that name). We also need to define how the WORKFLOWSTATE property is added to a component, especially in the iTIP workflow. That is, when we store an iTIP request like BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT UID:012345 ORGAGNIZER:cap://cal.example.com/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/john-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites John and Robert END:VEVENT END:VCALENDAR then we do a query for the VEVENT with UID equal to 012345, will it have a WORKFLOWSTATE property? Put another way, is the WORKFLOWSTATE automatically added when we write the request to the calstore? Or do we require the CUA to specifically add the WORKFLOWSTATE property? Another problem is that if we only store the METHOD information into WORKFLOWSTATE, then we have a lossy transformation. There is other information in the iTIP request that we have not stored. For example, consider the following ITIP request: BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ... END:VEVENT END:VCALENDAR We are talking about migrating the METHOD:REQUEST value into a new component property like WORKFLOWSTATE. But what about information like PRODID and VERSION ? Might those or other values contained in the VCALENDAR become significant over time? Do we just toss them? One suggestion in Minneapolis was to create a new component called VITIP that would contain everything in the ITIP request. Do we need something like VITIP ? or is migrating the METHOD value into WORKFLOWSTATE good enough? Other thoughts? -Steve --------------3A16A60AAE38410C1AEE52DD Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650.937.3351 x-mozilla-html:FALSE org:AOL / Netscape adr:;;;;;; version:2.1 title:Director of Engineering fn:Steve Mansour end:vcard --------------3A16A60AAE38410C1AEE52DD-- From owner-ietf-calendar@mail.imc.org Fri Apr 19 09:28:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19220 for ; Fri, 19 Apr 2002 09:28:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JDHwF18946 for ietf-calendar-bks; Fri, 19 Apr 2002 06:17:58 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JDHvb18941 for ; Fri, 19 Apr 2002 06:17:57 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g3JDHhsk026673 for ; Fri, 19 Apr 2002 09:17:43 -0400 Received: from steltor.com ([101.0.0.8]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g3JDHbr14754 for ; Fri, 19 Apr 2002 09:17:37 -0400 (EDT) Message-ID: <3CC01986.E81ED903@steltor.com> Date: Fri, 19 Apr 2002 09:20:06 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP Issue: Where to store METHOD info References: <3CBFBAA2.1708473A@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > Do we need something like VITIP ? or is migrating the METHOD value into > WORKFLOWSTATE good enough? Other thoughts? Tossing PRODID, VERSION and CALSCALE is probably acceptable, but we should not forget that VCALENDAR components may have x-prop. Tossing x-prop is probably not acceptable. The VITIP component proposed in Minneapolis would cover this issue. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri Apr 19 12:30:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29299 for ; Fri, 19 Apr 2002 12:30:32 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3JGK0I01415 for ietf-calendar-bks; Fri, 19 Apr 2002 09:20:00 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JGJwb01408 for ; Fri, 19 Apr 2002 09:19:58 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g3JGJpCj023278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 19 Apr 2002 09:19:58 -0700 (PDT) Message-ID: <3CC0439F.2070104@Royer.com> Date: Fri, 19 Apr 2002 10:19:43 -0600 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: CalSched IETF Subject: Re: CAP Issue: Where to store METHOD info References: <3CBFBAA2.1708473A@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: > All, > > Here's a summary of the next CAP issue to nail. We have not yet defined > what we're going to do with METHOD information. We have stated that we > want to move METHOD information into components. But we have not yet > defined a property in which to store the info. We may not want to store > it in a property named METHOD because that property is already used in > iTIP and it appears in the VCALENDAR container (not a component > container). We need to define the property we want to use. (I'll address your VERSION and PRODID questions in a separate email) I think we are making this too complicated - lets go back to simple. So forget what you know and listen to my proposal :-) There are two kinds of objects - iTIP and non-iTIP objects. Non-iTIP objects are anything not defined in iTIP (or any later version of iTIP). These are also called scheduling requests (not REQUEST). The METHOD is never 'moved' into the component. It is an implementation detail on how the CS 'knows' that any object was stored into the CS where the iTIP object had a iTIP METHOD:{whatever} . SELECT * from VEVENT where METHOD = 'REQUEST' As long as the CS returns all VEVENTs that were stored into the CS with iTIP METHOD:REQUEST. And the CS returns a VALID iTIP object, it does not matter how the CS stored or tagged the data. It matters that the CS can respond to a valid query with valid data as defined in iTIP or CAP. We do NOT need to specify how the CS knows that it was METHOD:REQUEST. We MUST BE able to query by METHOD. We do NOT need to invent another over the wire format for METHOD:REQUEST when 100% of the time it is 'iTIP' METHOD:REQUEST (lets NOT add WORKFLOWSTATE over the wire). And 100% of all non-booked objects are iTIP objects. (you can not schedule a stored VCAR). Lets just say that when the CS stores iTIP objects, the CS MUST be able to somehow know that is there state to enable queries to work. Because 100% of all iTIP objects are non-booked. And for booked items, they have a mythical METHOD of CREATE that tells the CS to store them and not think of them as scheduling requests. From owner-ietf-calendar@mail.imc.org Fri Apr 19 12:53:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02960 for ; Fri, 19 Apr 2002 12:53:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JGhmW03163 for ietf-calendar-bks; Fri, 19 Apr 2002 09:43:48 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JGhlb03154 for ; Fri, 19 Apr 2002 09:43:47 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g3JGhYCj023319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 19 Apr 2002 09:43:40 -0700 (PDT) Message-ID: <3CC04931.507@Royer.com> Date: Fri, 19 Apr 2002 10:43:29 -0600 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP Issue: Where to store METHOD info References: <3CBFBAA2.1708473A@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: > All, > > Here's a summary of the next CAP issue to nail. > ... > > We are talking about migrating the METHOD:REQUEST value into a new > component property like WORKFLOWSTATE. But what about information like > PRODID and VERSION ? Might those or other values contained in the > VCALENDAR become significant over time? Do we just toss them? VERSION - it is the VERSION of the iCalendar wire format - not data. As long as the CS returns VALID iCalednar objects, and the CUA sends valid iCalendar objects - it DOES NOT MATTER if the CS stores VERSION or not. I say we leave it un-specified. I'll store it in case we ever bump the iCalednar object format version. I'll always return the correct VERSION over the wire to the CUA. How about we add to CAP: It is not valid to query by VERSION as it has no meaning. VERSION is the format over the wire format of the iCalendar object and it is NOT the VERSION of the data. A CS MAY store the VERSION. The CS MUST always return a correct VERSION in the iCalendar objects. A CUA MUST always send a valid VERSION. PRODID - It is my experience with working with IMAP that implementations sometimes need to know the PRODID so that an implementation can work around other implementation bugs or quirks. I would say that an implementation MAY store the PRODID with the data, however the PRODID over the wire MUST BE the CS (or CUA) PRODID. So like VERSION how about we add to CAP: It is not valid to query by PRODID as it has no meaning. PRODID is the product id of the implementation that created the over the wire iCalendar object. PRODID is NOT the PRODID of the data and is not the PRODID of the ATTENDEE or ORGANIZERs product. A CS MAY store the PRODID. The CS MUST always send the PRODID of the CS and the CUA MUST always send the PRODID of the CUA. > One suggestion in Minneapolis was to create a new component called VITIP > that would contain everything in the ITIP request. NO - they are 100% complete objects now. > Do we need something like VITIP ? or is migrating the METHOD value into > WORKFLOWSTATE good enough? Other thoughts? Nether - we just need to specify that the CS MUST be able to query by METHOD. We do not need to specify HOW the CS knows how to do that. -- - Doug Royer Doug@Royer.com http://Royer.com/People/Doug From owner-ietf-calendar@mail.imc.org Fri Apr 19 14:09:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13124 for ; Fri, 19 Apr 2002 14:09:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JHwwB08465 for ietf-calendar-bks; Fri, 19 Apr 2002 10:58:58 -0700 (PDT) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JHwvb08459 for ; Fri, 19 Apr 2002 10:58:57 -0700 (PDT) To: CalSched IETF Subject: Re: CAP Issue: Where to store METHOD info MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 19 Apr 2002 14:10:41 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/19/2002 02:10:49 PM, Serialize complete at 04/19/2002 02:10:49 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug wrote: >VERSION - it is the VERSION of the iCalendar wire format - not data. Doug, I don't think this is true. From 2445: >4.7.4 Version > > Property Name: VERSION > > Purpose: This property specifies the identifier corresponding to the > highest version number or the minimum and maximum range of the > iCalendar specification that is required in order to interpret the > iCalendar object. That says to me that VERSION refers to all layers of the spec, the format and the data. Suppose, in 2258, the IETF releases RFC-102245, which updates iCalendar with the ATMOSPHERE property, describing what type of atmosphere will be available at the meeting. Kosh, a methane breather, sends an invitation to Fred, an oxygen breather. Kosh's implementation sends "ATMOSPHERE:METHANE"; in order to interpret the iCalendar object correctly, Fred's implementation needs to understand RFC-102245. (It could just ignore the ATMOSPHERE property, but then Fred's estate will probably sue the software vendor.) This means that adding the ATMOSPHERE property to the spec requires a new VERSION. /=============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=============================================================| |Nondeterminism may or may not mean never having to say you're| |wrong. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 19 18:25:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11851 for ; Fri, 19 Apr 2002 18:24:59 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3JMDnI22114 for ietf-calendar-bks; Fri, 19 Apr 2002 15:13:49 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JMDlb22110 for ; Fri, 19 Apr 2002 15:13:48 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g3JMDjCj024135 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 19 Apr 2002 15:13:50 -0700 (PDT) Message-ID: <3CC09693.50202@Royer.com> Date: Fri, 19 Apr 2002 16:13:39 -0600 From: Doug Royer Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF CC: CalSched IETF Subject: Re: CAP Issue: Where to store METHOD info References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > Doug wrote: > > >>VERSION - it is the VERSION of the iCalendar wire format - not data. >> > > Doug, I don't think this is true. From 2445: > Let me clarify what I meant: VERSION - it is the VERSION of the iCalendar wire format - not the properly 'values'. So the CS MUST know the format of the object (VERSION), but it need not be stored. And the CS and CUA MUST generate objects with the correct VERSION on the wire. So it does not matter what version is in the STORE, it matters what is on the wire. A CS MAY wish to store the VERSION, and the CS is responsible for sending a correct VERSION - no matter what is in the STORE. Agree? -Doug From owner-ietf-calendar@mail.imc.org Mon Apr 22 10:35:35 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27160 for ; Mon, 22 Apr 2002 10:35:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MENc215016 for ietf-calendar-bks; Mon, 22 Apr 2002 07:23:38 -0700 (PDT) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MENWa15008 for ; Mon, 22 Apr 2002 07:23:37 -0700 (PDT) To: CalSched IETF Subject: Re: CAP Issue: Where to store METHOD info MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 22 Apr 2002 10:35:25 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/22/2002 10:35:39 AM, Serialize complete at 04/22/2002 10:35:39 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >VERSION - it is the VERSION of the iCalendar wire format - not the >properly 'values'. This is not so. The values are meaningless unless you can interpret them; and they must be interpreted in the context of a particular version. And there's no way you can reconstruct the VERSION from the values. Suppose version 9.0 says that, if you don't have the LOCATION property set, it implies that the meeting is being conducted via telepresence? (Could be a perfectly reasonable assumption by that time.) You get a version 1.0 VEVENT, which doesn't specify LOCATION; you discard the VERSION; when the time comes, your CUA starts trying to contact the other attendees, and failing. I believe the CUA MUST get the same VERSION that the CS received. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |Don't anthropomorphize computers. We don't like it. | \========================================================/ From owner-ietf-calendar@mail.imc.org Mon Apr 22 13:09:17 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03023 for ; Mon, 22 Apr 2002 13:09:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MH0Iv24180 for ietf-calendar-bks; Mon, 22 Apr 2002 10:00:18 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MH0Ha24173 for ; Mon, 22 Apr 2002 10:00:17 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g3MH0ECj004704 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 22 Apr 2002 10:00:18 -0700 (PDT) Message-ID: <3CC4419A.4030708@Royer.com> Date: Mon, 22 Apr 2002 11:00:10 -0600 From: Doug Royer Reply-To: CalSched IETF Organization: INET-Consulting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: CalSched IETF Subject: Re: CAP Issue: Where to store METHOD info References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: >>VERSION - it is the VERSION of the iCalendar wire format - not the >>properly 'values'. >> > > This is not so. The values are meaningless unless you can interpret them; > and they must be interpreted in the context of a particular version. And > there's no way you can reconstruct the VERSION from the values. You don't have to reconstruct them, you just have to make a valid packet. If the CS does not know the data that it already deposited into itself - it has bigger problems. > Suppose version 9.0 says that, if you don't have the LOCATION property set, it > implies that the meeting is being conducted via telepresence? Then when the CS gets a VERSION 9 packet it will know how to process it. If it wishes to send out a VERSION 10 packet it is not up to CAP to mandate it can not do that simply because the packet arrived with VERSION 9. > (Could be a perfectly reasonable assumption by that time.) You get a version 1.0 > VEVENT, which doesn't specify LOCATION; you discard the VERSION; when the > time comes, your CUA starts trying to contact the other attendees, and > failing. I NEVER said discard it. I said CAP does not need to specify if the CS saves the VERSION. It only needs to mandate that the CS gets and sends valid VERSIONs. > I believe the CUA MUST get the same VERSION that the CS received. I believe that the CUA MUST get a valid VERSION that the CUA understands which might not be the same - or might be the same as the CS got. - Doug Royer Doug@Royer.com http://Royer.com/People/Doug http://INET-Consulting.com From owner-ietf-calendar@mail.imc.org Mon Apr 22 13:28:58 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03921 for ; Mon, 22 Apr 2002 13:28:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MHGoo26166 for ietf-calendar-bks; Mon, 22 Apr 2002 10:16:50 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MHGma26160 for ; Mon, 22 Apr 2002 10:16:48 -0700 (PDT) Importance: Normal X-Priority: 3 (Normal) Subject: CALSCH working group minutes MIME-Version: 1.0 From: Pat_R_Egen/Egen_Consulting/01@egenconsulting.com To: ietf-calendar@imc.org Date: Mon, 22 Apr 2002 13:16:34 -0400 Message-ID: X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/22/2002 01:16:51 PM MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable
FYI, below is a copy of the minutes sent to the IETF = minutes list.  Thought the list might be interested in seeing them bef= ore the proceedings came out.
-----Forwarded= by Pat R Egen/Egen Consulting/01 on 04/22/2002 10:16AM -----

To: minutes@ietf.org
From: Pat R Egen/Egen Consulting/01
Date: 04/08= /2002 08:12AM
Subject: CALSCH working group minutes


IETF 52 CalSched Working Group Meeting
Thursd= ay 21-Mar-02
Minneapolis, MN

Introductions (Pat / Bob):
Quick= poll of those in the room: 5 are "new" to the WG: several already on the l= ist and
2 were "Curious Users"

Agenda:
Agenda Bashing
Guide to Internet Calendaring status
CalConnect status
CAP status

Bruce Ka= hn graciously steps up to be scribe.

Guide to Internet Calendaring (Pat):
The Guide has been appr= oved for release as an RFC; in the queue for the actual number. The guide i= s intended to be used by implementers of the C&S standards.

CalC= onnect III (Pat):
The one scheduled for next week was cancelled due to s= everal factors (proximity to IETF, travel concerns,
etc). Novell still w= ants to host the next non-virtual CalConnect in Provo, UT. The next CalConn= ect will be a 'virtual' one and is slated for the June timeframe, probably = before the next IETF in Japan. The goals/benefits of having it virtual are:=
        Decreased participation costs (supplement= ed by scheduled conference calls to keep things moving)
    &= nbsp;   We should be able to do this in a "virtual environment" given = our design criteria.
        We will rely on secure= instant messaging and regularly scheduled conference calls between partici= pants.

Virtual event will= have the following:
 - = Virtual environment will have the following:
-  POP/IMAP/SMTP/FTP/HTTP servers
-  A Secure collaborative environment for i= nstant messaging, electronic conferencing, and discussion
=96  All dialogs will be encrypted
-  Timed periodic conference = calls with all attendees
- &n= bsp;Expectation is you are available for the duration of the two days
-  A set of scenarios to test= and a table/matrix with items to test and "check off" as complete/broke/ne= eds more
   testin= g

Currently there are 7+= vendors interested in participating; no word on any Open Source interest y= et. Tentatively
targeting Au= gust/September 2002 as the timeframe for the next "in person" event.
Calendar Access Protocol (CAP):
Steve Mansour went over the CAP items
Steve went over major item= s since the last meeting review.  They were:
-  Information in= consistency between transport layer and application layer - there is no cle= ar separation between application and transport layers.

-  A review VCARS and Queries is in ord= er

-  We need to add= iCalendar extensions to draft

-  Scheduling restriction tables need more work

-  Obtaining the UPN after authentic= ation in BEEP - Getting UPNs from BEEP; Need UPN information to
properly= resolve other identity/security aspects in CAP but unclear how/if BEEP can= provide this.

Next Steve went over the status of version 7 of the d= raft.

Slide items:=
- Mixing of Transport and Applicati= on Data
- Fixed issues from l= ast time
- A few things remai= n (ex: get-capability)
- Obta= ining the UPN after authentication in BEEP
- Proposed Security Model Change:
- Current: deny unless explicitly granted
- Proposed: grant unless explicitly denied=

We still have some mixin= g of the Transport and Application layers.   This is due to lack of a = clear definition of what each layer really is (it varies by reader so we mu= st nail down the distinction and resolve the layering).      = ;    

Getting U= PNs from BEEP. Paul Hill, our security guy, went over this topic.  Pau= l is working with the BEEP and SASL folks to see what can be bubbled up for= CAP to get/use. Currently, only WebMail is known to support it. We want to= build BEEP and SASL on Windows (not only on Unix as is currently the case)= ;  Currently Paul is working on the port (as we have the WG meeting ev= en). The model as it exists should work;  He will look at it again to = be sure once we have some more information.

The next topic was the proposal to change the security m= odel: We want to go from an implicitly Deny w/explicit
Grants to an impl= icit Grant model w/explicit Denys. This scales better and is easier to eval= uate.
Essentially the evaluation of access is done from the CS -> Ca= lendar -> Entity levels where any Deny at any
point prevents access "= below" that point.
              &nb= sp;                     &= nbsp;                    =
Steve, Paul and others will= put together and propose some actual text pending tentative agreement on t= he conceptual change.

Sli= de items:
-  SCHEDULE is= gone, CREATE to cover it
&nb= sp;    - METHOD value verb or status (STATE)?
     - BOOKED versus CREATED
     - DELETED &n= bsp;(remember tombstoning?)
=        - What properties MUST be maintained?
= -  iTIP method
-  Abort versus bounded latency
<= font size=3D2 face=3D"Courier New">      - Do we need abort = capability other than latency
-  Reorder the draft so that it's easy to follow
      - iCal extensions are curren= tly at the end draft

The = SCHEDULE command is gone.  Reusing the CREATE command instead.   = This leads to some confusion about
the use of METHOD in 'booking'; is ME= THOD a verb or a state?

D= ELETED is a new METHOD value added to codify the "Tombstone" concept we pre= viously had [explicitly or
implicitly at some points -BK].  We need= to clearly define what the CS behavior is with respect to
deleted entri= es (ie: exactly what MUST be preserved for sync and other reasons, etc and = what MAY be
preserved, etc).

ABORT vs Bounded Latency - Do we need to have an ABORT command?

WE need to reorder the draft= to make it easier to follow.  The layout is more than a bit hard to r= ead [especially the ABNF that appears in the back after its used elsewhere<= br>
Slide items:
- UIDs fo= r components:
 - VCARs (Default, Predefined, Decreed)
 - = VALARMs
- Querys
  - Stored Queries =96 do we need th= em?
  - Scoping <= br>  - component.prop
    - USING=5FPROPERTIES=
    - USING=5FCOMPONENTS<= /font>
  - Querying for floatin= g time events
       
It is unclear how UIDs for some components should be added= and how to deal with uniqueness.  Also, it was questioned how some of= the VCARs function (ie: predefined ones: Are they 'templates' for creating= instances in each VAGENDA or are they copied.  If they are templates,= thats a new concept.  If they are copied then the UIDS are no longer = unique.)

Regarding queries, how useful are stored queries given that= the majority of queries used in C&S are 'time sensitive'
and we hav= e no ability to macro substitute values into saved queries.  For examp= le: Give me all my events
that have an alarm that triggers in the next h= our requires that the CUA send an explicit UTC time for
the bounds. &nbs= p; As such, tomorrow the query would be basically useless.

<= font size=3D2 face=3D"Courier New">There are questions/issues regarding the= scoping of queries: The design currently restricts them to COMPONENT.PROPE= RTY [without any clear reason apart from some apparently implicit assumptio= n about the
underlying actual search engine like SQL.

There is no clear definition for the use/ne= ed of USING=5FPROPERTIES and USING=5FCOMPONENTS.  They appear to
be= used as a form of shorthand at best without any functional need/descriptio= n for them.

There is no = way to query for "floating time" entries.  The query code expressly de= clares that all queried time must be in UTC but thats not possible for the = "Every morning I go jogging from 6AM - 7AM no matter where I am" case. &nbs= p;"Floating time" (aka Local only) entries have no associated time zone and= as such cannot be converted and stored in UTC.

Going forward:
Slide items:
- Post all issues to the list
=96 Analyses for all
=96 Recommendations for many
- Targeting getting issues posted by end of the month
- Work through the issues one a= t a time
                 =                     &nbs= p;          
All issues will be taken to the list.  There should be an an= alysis of each one and preferably a
recommendation for resolving them as= well (in the interest of time). Target posting all of the issues is by the= end of March 2002 to the WG list. We will work thru the issues 1 at a time= instead of "flailing" on several at once and seemingly resolving none. &nb= sp;
                  &nbs= p;    
Pat will be= the Keeper of Order.  TBD will be the Keeper of Issues. Pat noted tha= t there exist WG chair tools to aid in this process and she will investigat= e them and get the relevant parties up to speed on them.

The cochairs/editors want more WG feedback = on postings (ie: more than just 2 people going back and forth on a topic). =  Pat suggests that the "techies" take care to put the painful technica= l details/explainations into Plain English (TM) for the rest of the WG so t= hat "less techie folks" are more inclined to participate.

A quick poll shows that we may not have su= fficient people to have a WG meeting in Japan.  As such we want
to = get more progress done on the list before then.

We will deal with th= e layer issue first.  Much of this is due to the BEEP changeover. &nbs= p;We want to finish
off the concerns of "XML creep" and the layer bleedi= ng before we get back to the actual protocol details.

Pat put out a call for "anyone" with BEEPCORE= C and SASL implementations to get engaged in dealing with
this.
&nbs= p;      
Larry= noted that SASL is lightweight in design.  MD5 is "heavy duty" as the= minimum base for CAP authentication.  There are lots of SASL implemen= tations and they mostly interoperate. Larry asked why not just adopt XML no= w with the new work the WG is doing.  He finds it confusing to have bo= th XML and iCalendar in the draft.  This gets back
to the prior iss= ue about XML creep that we need to finally resolve.

Steve responded that we could do the change but= we need to make changed to xcal (which is expired now).  Also, its od= d to mix XML and iCalendar data but the mix is an artifact of the BEEP chan= geover.  One example is the SEARCh command that is in XML but it has n= o data.

Larry pointed out= the mix of data dn commands/actions (ie: search) in 1 blob is still confus= ing.

Steve: we need to be= tter explain the mix in the design text and descriptions.

Wrapup (Pa= t):

The WG site calsch.or= g (or www.calsch.org) is up and has the drafts, texts and relevant links. <= br>
Meeting adjourned.=

Respectively submitted by Pat E= gen.
= From owner-ietf-calendar@mail.imc.org Mon Apr 22 14:09:53 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06074 for ; Mon, 22 Apr 2002 14:09:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MI0et27457 for ietf-calendar-bks; Mon, 22 Apr 2002 11:00:40 -0700 (PDT) Received: from postman.incentivesystems.com (postman.incentivesystems.com [66.152.247.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MI0ca27452 for ; Mon, 22 Apr 2002 11:00:38 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: CALSCH working group minutes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 22 Apr 2002 14:12:32 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.9 |November 16, 2001) at 04/22/2002 02:12:41 PM, Serialize complete at 04/22/2002 02:12:41 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >MD5 is "heavy duty" as the minimum base for CAP authentication. Heavy duty in what sense? It's widely implemented; it's fairly easy to implement from the spec (I've done it); and I don't *think* it takes that much CPU. I just tried it on a 1MB file on my 233MHz Pentium MMX laptop running Linux; it took 0.150 seconds of user time (i.e., CPU time spent outside the kernel--which is the appropriate number, since the algorithm is outside the kernel). For digest authentication, you typically have to do the MD5 on something under 100 bytes. So, if you've got a gigahertz machine serving 100 CAP requests per second (unlikely), you can expect about 1/2500 of that second to be in MD5. If you've got a 25MHz PDA submitting an authentication request, MD5 will probably take something like 0.150 milliseconds (not seconds). Of course, this is very much back-of-the-envelope; it'll depend on the CPU architecture, for one thing. But, even if I'm off by an order of magnitude, I don't think this is expensive. And I, for one, don't know of a cheaper authentication scheme (plaintext is not an option). /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |"Who died and made you king?" "My father." | \========================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 23 00:07:10 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24571 for ; Tue, 23 Apr 2002 00:07:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3N40dC20450 for ietf-calendar-bks; Mon, 22 Apr 2002 21:00:39 -0700 (PDT) Received: from notes-int01.santista.com.br ([200.245.196.235]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3N40ba20437 for ; Mon, 22 Apr 2002 21:00:37 -0700 (PDT) Subject: Resposta =?iso-8859-1?q?Autom=E1tica_de_Walter_Sanches_[_Automatic_Reply_]?= From: wsanches@santista.com.br To: CalSched IETF Message-ID: Date: Tue, 23 Apr 2002 01:00:24 -0300 X-MIMETrack: Serialize by Router on NOTES-INT01/SANTISTA/BR(Release 5.0.4 |June 8, 2000) at 04/23/2002 01:00:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3N40ca20445 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I will be out of the office starting 22/04/2002 and will not return until 25/04/2002. I will respond to your message when I return. -------------- Estarei em Gaspar no período de 22 à 24/04. Se tiver urgência, por favor, contate Flávio Dias no ramal 4353. From owner-ietf-calendar@mail.imc.org Tue Apr 23 06:51:07 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11193 for ; Tue, 23 Apr 2002 06:51:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3NAflm02890 for ietf-calendar-bks; Tue, 23 Apr 2002 03:41:47 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3NAfja02884 for ; Tue, 23 Apr 2002 03:41:45 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g3NAfdsk016730; Tue, 23 Apr 2002 06:41:39 -0400 Received: from c2767 ([101.1.46.19]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g3NAfXr28159; Tue, 23 Apr 2002 06:41:33 -0400 (EDT) From: "ericp" To: Cc: Subject: RE: CALSCH working group minutes Date: Tue, 23 Apr 2002 06:39:35 -0400 Message-ID: <001e01c1eab3$2921efa0$132e0165@in.steltor.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C1EA91.A2104FA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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_001F_01C1EA91.A2104FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good Morning, regarding the minutes... a small correction should be noted, the xCal draft has not expired. The draft will expire on August 16th, 2002. Regards, Eric -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org] On Behalf Of Pat_R_Egen/Egen_Consulting/01@egenconsulting.com Sent: Monday, April 22, 2002 1:17 PM To: ietf-calendar@imc.org Subject: CALSCH working group minutes FYI, below is a copy of the minutes sent to the IETF minutes list. Thought the list might be interested in seeing them before the proceedings came out. -----Forwarded by Pat R Egen/Egen Consulting/01 on 04/22/2002 10:16AM ----- To: minutes@ietf.org From: Pat R Egen/Egen Consulting/01 Date: 04/08/2002 08:12AM Subject: CALSCH working group minutes IETF 52 CalSched Working Group Meeting Thursday 21-Mar-02 Minneapolis, MN Introductions (Pat / Bob): Quick poll of those in the room: 5 are "new" to the WG: several already on the list and 2 were "Curious Users" Agenda: Agenda Bashing Guide to Internet Calendaring status CalConnect status CAP status Bruce Kahn graciously steps up to be scribe. Guide to Internet Calendaring (Pat): The Guide has been approved for release as an RFC; in the queue for the actual number. The guide is intended to be used by implementers of the C&S standards. CalConnect III (Pat): The one scheduled for next week was cancelled due to several factors (proximity to IETF, travel concerns, etc). Novell still wants to host the next non-virtual CalConnect in Provo, UT. The next CalConnect will be a 'virtual' one and is slated for the June timeframe, probably before the next IETF in Japan. The goals/benefits of having it virtual are: Decreased participation costs (supplemented by scheduled conference calls to keep things moving) We should be able to do this in a "virtual environment" given our design criteria. We will rely on secure instant messaging and regularly scheduled conference calls between participants. Virtual event will have the following: - Virtual environment will have the following: - POP/IMAP/SMTP/FTP/HTTP servers - A Secure collaborative environment for instant messaging, electronic conferencing, and discussion - All dialogs will be encrypted - Timed periodic conference calls with all attendees - Expectation is you are available for the duration of the two days - A set of scenarios to test and a table/matrix with items to test and "check off" as complete/broke/needs more testing Currently there are 7+ vendors interested in participating; no word on any Open Source interest yet. Tentatively targeting August/September 2002 as the timeframe for the next "in person" event. Calendar Access Protocol (CAP): Steve Mansour went over the CAP items Steve went over major items since the last meeting review. They were: - Information inconsistency between transport layer and application layer - there is no clear separation between application and transport layers. - A review VCARS and Queries is in order - We need to add iCalendar extensions to draft - Scheduling restriction tables need more work - Obtaining the UPN after authentication in BEEP - Getting UPNs from BEEP; Need UPN information to properly resolve other identity/security aspects in CAP but unclear how/if BEEP can provide this. Next Steve went over the status of version 7 of the draft. Slide items: - Mixing of Transport and Application Data - Fixed issues from last time - A few things remain (ex: get-capability) - Obtaining the UPN after authentication in BEEP - Proposed Security Model Change: - Current: deny unless explicitly granted - Proposed: grant unless explicitly denied We still have some mixing of the Transport and Application layers. This is due to lack of a clear definition of what each layer really is (it varies by reader so we must nail down the distinction and resolve the layering). Getting UPNs from BEEP. Paul Hill, our security guy, went over this topic. Paul is working with the BEEP and SASL folks to see what can be bubbled up for CAP to get/use. Currently, only WebMail is known to support it. We want to build BEEP and SASL on Windows (not only on Unix as is currently the case); Currently Paul is working on the port (as we have the WG meeting even). The model as it exists should work; He will look at it again to be sure once we have some more information. The next topic was the proposal to change the security model: We want to go from an implicitly Deny w/explicit Grants to an implicit Grant model w/explicit Denys. This scales better and is easier to evaluate. Essentially the evaluation of access is done from the CS -> Calendar -> Entity levels where any Deny at any point prevents access "below" that point. Steve, Paul and others will put together and propose some actual text pending tentative agreement on the conceptual change. Slide items: - SCHEDULE is gone, CREATE to cover it - METHOD value verb or status (STATE)? - BOOKED versus CREATED - DELETED (remember tombstoning?) - What properties MUST be maintained? - iTIP method - Abort versus bounded latency - Do we need abort capability other than latency - Reorder the draft so that it's easy to follow - iCal extensions are currently at the end draft The SCHEDULE command is gone. Reusing the CREATE command instead. This leads to some confusion about the use of METHOD in 'booking'; is METHOD a verb or a state? DELETED is a new METHOD value added to codify the "Tombstone" concept we previously had [explicitly or implicitly at some points -BK]. We need to clearly define what the CS behavior is with respect to deleted entries (ie: exactly what MUST be preserved for sync and other reasons, etc and what MAY be preserved, etc). ABORT vs Bounded Latency - Do we need to have an ABORT command? WE need to reorder the draft to make it easier to follow. The layout is more than a bit hard to read [especially the ABNF that appears in the back after its used elsewhere Slide items: - UIDs for components: - VCARs (Default, Predefined, Decreed) - VALARMs - Querys - Stored Queries - do we need them? - Scoping - component.prop - USING_PROPERTIES - USING_COMPONENTS - Querying for floating time events It is unclear how UIDs for some components should be added and how to deal with uniqueness. Also, it was questioned how some of the VCARs function (ie: predefined ones: Are they 'templates' for creating instances in each VAGENDA or are they copied. If they are templates, thats a new concept. If they are copied then the UIDS are no longer unique.) Regarding queries, how useful are stored queries given that the majority of queries used in C&S are 'time sensitive' and we have no ability to macro substitute values into saved queries. For example: Give me all my events that have an alarm that triggers in the next hour requires that the CUA send an explicit UTC time for the bounds. As such, tomorrow the query would be basically useless. There are questions/issues regarding the scoping of queries: The design currently restricts them to COMPONENT.PROPERTY [without any clear reason apart from some apparently implicit assumption about the underlying actual search engine like SQL. There is no clear definition for the use/need of USING_PROPERTIES and USING_COMPONENTS. They appear to be used as a form of shorthand at best without any functional need/description for them. There is no way to query for "floating time" entries. The query code expressly declares that all queried time must be in UTC but thats not possible for the "Every morning I go jogging from 6AM - 7AM no matter where I am" case. "Floating time" (aka Local only) entries have no associated time zone and as such cannot be converted and stored in UTC. Going forward: Slide items: - Post all issues to the list - Analyses for all - Recommendations for many - Targeting getting issues posted by end of the month - Work through the issues one at a time All issues will be taken to the list. There should be an analysis of each one and preferably a recommendation for resolving them as well (in the interest of time). Target posting all of the issues is by the end of March 2002 to the WG list. We will work thru the issues 1 at a time instead of "flailing" on several at once and seemingly resolving none. Pat will be the Keeper of Order. TBD will be the Keeper of Issues. Pat noted that there exist WG chair tools to aid in this process and she will investigate them and get the relevant parties up to speed on them. The cochairs/editors want more WG feedback on postings (ie: more than just 2 people going back and forth on a topic). Pat suggests that the "techies" take care to put the painful technical details/explainations into Plain English (TM) for the rest of the WG so that "less techie folks" are more inclined to participate. A quick poll shows that we may not have sufficient people to have a WG meeting in Japan. As such we want to get more progress done on the list before then. We will deal with the layer issue first. Much of this is due to the BEEP changeover. We want to finish off the concerns of "XML creep" and the layer bleeding before we get back to the actual protocol details. Pat put out a call for "anyone" with BEEPCOREC and SASL implementations to get engaged in dealing with this. Larry noted that SASL is lightweight in design. MD5 is "heavy duty" as the minimum base for CAP authentication. There are lots of SASL implementations and they mostly interoperate. Larry asked why not just adopt XML now with the new work the WG is doing. He finds it confusing to have both XML and iCalendar in the draft. This gets back to the prior issue about XML creep that we need to finally resolve. Steve responded that we could do the change but we need to make changed to xcal (which is expired now). Also, its odd to mix XML and iCalendar data but the mix is an artifact of the BEEP changeover. One example is the SEARCh command that is in XML but it has no data. Larry pointed out the mix of data dn commands/actions (ie: search) in 1 blob is still confusing. Steve: we need to better explain the mix in the design text and descriptions. Wrapup (Pat): The WG site calsch.org (or www.calsch.org) is up and has the drafts, texts and relevant links. Meeting adjourned. Respectively submitted by Pat Egen. ------=_NextPart_000_001F_01C1EA91.A2104FA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Good=20 Morning,
 
regarding the minutes... a small correction should be=20 noted,
the=20 xCal draft has not expired. The draft will expire on August 16th,=20 2002.
 
Regards,
Eric
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org = [mailto:owner-ietf-calendar@mail.imc.org]=20 On Behalf Of=20 Pat_R_Egen/Egen_Consulting/01@egenconsulting.com
Sent: = Monday,=20 April 22, 2002 1:17 PM
To: = ietf-calendar@imc.org
Subject:=20 CALSCH working group minutes

FYI, below is a copy of the minutes sent to the IETF minutes = list. =20 Thought the list might be interested in seeing them before the = proceedings=20 came out.
-----Forwarded by Pat R = Egen/Egen=20 Consulting/01 on 04/22/2002 10:16AM -----

To:=20 minutes@ietf.org
From: Pat R Egen/Egen Consulting/01
Date: = 04/08/2002=20 08:12AM
Subject: CALSCH working group minutes


IETF 52 CalSched Working Group = Meeting
Thursday=20 21-Mar-02
Minneapolis, MN

Introductions (Pat / = Bob):
Quick poll=20 of those in the room: 5 are "new" to the WG: several already on the = list and=20
2 were "Curious Users"

Agenda:
Agenda Bashing
Guide to=20 Internet Calendaring status
CalConnect status
CAP=20 status

Bruce Kahn = graciously=20 steps up to be scribe.

Guide to=20 Internet Calendaring (Pat):
The Guide has been approved for release = as an=20 RFC; in the queue for the actual number. The guide is intended to be = used by=20 implementers of the C&S standards.

CalConnect III = (Pat):
The one=20 scheduled for next week was cancelled due to several factors = (proximity to=20 IETF, travel concerns,
etc). Novell still wants to host the next=20 non-virtual CalConnect in Provo, UT. The next CalConnect will be a = 'virtual'=20 one and is slated for the June timeframe, probably before the next = IETF in=20 Japan. The goals/benefits of having it virtual are:
    =  =20   Decreased participation costs (supplemented by scheduled = conference=20 calls to keep things moving)
        We should = be able=20 to do this in a "virtual environment" given our design = criteria.
 =20       We will rely on secure instant messaging and = regularly=20 scheduled conference calls between participants.

Virtual event will have the=20 following:
 - = Virtual=20 environment will have the following:
-  POP/IMAP/SMTP/FTP/HTTP servers
-  A Secure collaborative = environment for=20 instant messaging, electronic conferencing, and = discussion
–  All dialogs will be = encrypted=20
-  Timed periodic = conference=20 calls with all attendees
-=20  Expectation is you are available for the duration of the two=20 days
-  A set of = scenarios to=20 test and a table/matrix with items to test and "check off" as=20 complete/broke/needs more
 =20  testing

Currently there=20 are 7+ vendors interested in participating; no word on any Open Source = interest yet. Tentatively
targeting=20 August/September 2002 as the timeframe for the next "in person"=20 event.

Calendar Access Protocol (CAP):
Steve Mansour went = over the=20 CAP items

Steve went = over major=20 items since the last meeting review.  They were:
- =  Information=20 inconsistency between transport layer and application layer - there is = no=20 clear separation between application and transport = layers.

-  A review VCARS and Queries is in = order

-  We = need to add=20 iCalendar extensions to draft

-=20  Scheduling restriction tables need more work

-  Obtaining the UPN after = authentication in=20 BEEP - Getting UPNs from BEEP; Need UPN information to
properly = resolve=20 other identity/security aspects in CAP but unclear how/if BEEP can = provide=20 this.

Next Steve went over the status of version 7 of the=20 draft.

Slide=20 items:
- Mixing of = Transport and=20 Application Data
- Fixed = issues from=20 last time
- A few things = remain (ex:=20 get-capability)
- = Obtaining the UPN=20 after authentication in BEEP
-=20 Proposed Security Model Change:
-=20 Current: deny unless explicitly granted
- Proposed: grant unless explicitly denied

We still have some mixing of the = Transport and=20 Application layers.   This is due to lack of a clear definition = of what=20 each layer really is (it varies by reader so we must nail down the = distinction=20 and resolve the layering).        =20  

Getting UPNs = from BEEP.=20 Paul Hill, our security guy, went over this topic.  Paul is = working with=20 the BEEP and SASL folks to see what can be bubbled up for CAP to = get/use.=20 Currently, only WebMail is known to support it. We want to build BEEP = and SASL=20 on Windows (not only on Unix as is currently the case); =  Currently Paul=20 is working on the port (as we have the WG meeting even). The model as = it=20 exists should work;  He will look at it again to be sure once we = have=20 some more information.

The next=20 topic was the proposal to change the security model: We want to go = from an=20 implicitly Deny w/explicit
Grants to an implicit Grant model = w/explicit=20 Denys. This scales better and is easier to evaluate.
Essentially = the=20 evaluation of access is done from the CS -> Calendar -> Entity = levels=20 where any Deny at any
point prevents access "below" that = point.
 =20                     =  =20                     =  =20            
Steve, Paul and others will put together and propose some = actual text=20 pending tentative agreement on the conceptual = change.

Slide items:
-  SCHEDULE is gone, CREATE to cover it
     - METHOD value verb = or status=20 (STATE)?
    =  -=20 BOOKED versus CREATED
   =20  - DELETED  (remember tombstoning?)
       - What = properties MUST be=20 maintained?
-  iTIP = method
-  Abort = versus bounded=20 latency
    =   - Do we=20 need abort capability other than latency
-  Reorder the draft so that it's easy to = follow
      - iCal extensions = are currently=20 at the end draft

The = SCHEDULE=20 command is gone.  Reusing the CREATE command instead.   This = leads=20 to some confusion about
the use of METHOD in 'booking'; is METHOD a = verb or=20 a state?

DELETED is = a new METHOD=20 value added to codify the "Tombstone" concept we previously had = [explicitly=20 or
implicitly at some points -BK].  We need to clearly define = what the=20 CS behavior is with respect to
deleted entries (ie: exactly what = MUST be=20 preserved for sync and other reasons, etc and what MAY = be
preserved,=20 etc).

ABORT vs = Bounded Latency -=20 Do we need to have an ABORT command?

WE need to reorder the draft to make it easier to follow. =  The=20 layout is more than a bit hard to read [especially the ABNF that = appears in=20 the back after its used elsewhere

Slide items:
- UIDs for components:
 - VCARs = (Default,=20 Predefined, Decreed)
 - VALARMs
- Querys
  = - Stored=20 Queries – do we need them?
  -=20 Scoping
  -=20 component.prop
  =   -=20 USING_PROPERTIES
  =   -=20 USING_COMPONENTS
  = - Querying=20 for floating time events
      =  
It is unclear how UIDs for some = components should be=20 added and how to deal with uniqueness.  Also, it was questioned = how some=20 of the VCARs function (ie: predefined ones: Are they 'templates' for = creating=20 instances in each VAGENDA or are they copied.  If they are = templates,=20 thats a new concept.  If they are copied then the UIDS are no = longer=20 unique.)

Regarding queries, how useful are stored queries given = that=20 the majority of queries used in C&S are 'time sensitive'
and we = have no=20 ability to macro substitute values into saved queries.  For = example: Give=20 me all my events
that have an alarm that triggers in the next hour = requires=20 that the CUA send an explicit UTC time for
the bounds.   As = such,=20 tomorrow the query would be basically useless.

There are questions/issues regarding the = scoping of=20 queries: The design currently restricts them to COMPONENT.PROPERTY = [without=20 any clear reason apart from some apparently implicit assumption about=20 the
underlying actual search engine like SQL.

There is no clear definition for the = use/need of=20 USING_PROPERTIES and USING_COMPONENTS.  They appear to
be used = as a=20 form of shorthand at best without any functional need/description for = them.=20

There is no way to = query for=20 "floating time" entries.  The query code expressly declares that = all=20 queried time must be in UTC but thats not possible for the "Every = morning I go=20 jogging from 6AM - 7AM no matter where I am" case.  "Floating = time" (aka=20 Local only) entries have no associated time zone and as such cannot be = converted and stored in UTC.

Going forward:
Slide items:
- Post all issues to the list
– Analyses for all
–=20 Recommendations for many
- Targeting=20 getting issues posted by end of the month
- Work through the issues one at a time
    =    =20                     =  =20                    =20
All issues will be = taken to the=20 list.  There should be an analysis of each one and preferably=20 a
recommendation for resolving them as well (in the interest of = time).=20 Target posting all of the issues is by the end of March 2002 to the WG = list.=20 We will work thru the issues 1 at a time instead of "flailing" on = several at=20 once and seemingly resolving none.  
      =  =20                 =
Pat will be the Keeper of Order. =  TBD will be=20 the Keeper of Issues. Pat noted that there exist WG chair tools to aid = in this=20 process and she will investigate them and get the relevant parties up = to speed=20 on them.

The = cochairs/editors=20 want more WG feedback on postings (ie: more than just 2 people going = back and=20 forth on a topic).  Pat suggests that the "techies" take care to = put the=20 painful technical details/explainations into Plain English (TM) for = the rest=20 of the WG so that "less techie folks" are more inclined to=20 participate.

A quick = poll shows=20 that we may not have sufficient people to have a WG meeting in Japan. =  As=20 such we want
to get more progress done on the list before = then.

We=20 will deal with the layer issue first.  Much of this is due to the = BEEP=20 changeover.  We want to finish
off the concerns of "XML creep" = and the=20 layer bleeding before we get back to the actual protocol=20 details.

Pat put out = a call for=20 "anyone" with BEEPCOREC and SASL implementations to get engaged in = dealing=20 with
this.
       
Larry noted that SASL is lightweight in = design.=20  MD5 is "heavy duty" as the minimum base for CAP authentication.=20  There are lots of SASL implementations and they mostly = interoperate.=20 Larry asked why not just adopt XML now with the new work the WG is = doing.=20  He finds it confusing to have both XML and iCalendar in the = draft.=20  This gets back
to the prior issue about XML creep that we = need to=20 finally resolve.

Steve=20 responded that we could do the change but we need to make changed to = xcal=20 (which is expired now).  Also, its odd to mix XML and iCalendar = data but=20 the mix is an artifact of the BEEP changeover.  One example is = the SEARCh=20 command that is in XML but it has no data.

Larry pointed out the mix of data dn=20 commands/actions (ie: search) in 1 blob is still=20 confusing.

Steve: we = need to=20 better explain the mix in the design text and = descriptions.

Wrapup=20 (Pat):

The WG site = calsch.org=20 (or www.calsch.org) is up and has the drafts, texts and relevant = links.=20

Meeting=20 adjourned.

Respectively=20 submitted by Pat = Egen.
------=_NextPart_000_001F_01C1EA91.A2104FA0-- From owner-ietf-calendar@mail.imc.org Wed Apr 24 12:24:42 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21451 for ; Wed, 24 Apr 2002 12:24:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3OG9EK15010 for ietf-calendar-bks; Wed, 24 Apr 2002 09:09:14 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OG94a14984 for ; Wed, 24 Apr 2002 09:09:12 -0700 (PDT) Subject: RE: CALSCH working group minutes To: "ericp" Cc: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 24 Apr 2002 12:09:00 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/24/2002 12:09:14 PM 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 see there has been a bit of discussion about the XML on iCalendar draft expiration date. I will post a correction to the minutes. Thanks for catching this and hopefully this has not caused too much of a problem. If anyone sees any other items please let me know. From owner-ietf-calendar@mail.imc.org Thu Apr 25 19:20:19 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08852 for ; Thu, 25 Apr 2002 19:20:18 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g3PN8NQ11562 for ietf-calendar-bks; Thu, 25 Apr 2002 16:08:23 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PN8Ea11556 for ; Thu, 25 Apr 2002 16:08:22 -0700 (PDT) To: ietf-calendar@imc.org Subject: Yokahama MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Thu, 25 Apr 2002 19:08:07 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 04/25/2002 07:08:25 PM, Serialize complete at 04/25/2002 07:08:25 PM Content-Type: multipart/alternative; boundary="=_alternative 007F161285256BA6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007F161285256BA6_= Content-Type: text/plain; charset="us-ascii" We are trying to determine how many people will be in Yokahama. If you are planning on attending this meeting, please post to the list. --=_alternative 007F161285256BA6_= Content-Type: text/html; charset="us-ascii"
We are trying to determine how many people will be in Yokahama. If you are planning on attending this meeting, please post to the list. --=_alternative 007F161285256BA6_=--