From owner-ietf-calendar@mail.imc.org Thu Feb 1 01:21:34 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08997 for ; Thu, 1 Feb 2001 01:21:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA17695 for ietf-calendar-bks; Wed, 31 Jan 2001 21:54:09 -0800 (PST) Received: from ledig.paf.se (c193.150.248.34.cm-upc.chello.se [193.150.248.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA17620 for ; Wed, 31 Jan 2001 21:51:45 -0800 (PST) Received: from [192.168.1.22] (dhcp-22.paf.se [192.168.1.22]) by ledig.paf.se (8.9.3/8.9.3) with ESMTP id GAA98999; Thu, 1 Feb 2001 06:58:15 +0100 (CET) (envelope-from paf@cisco.com) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 1 Feb 2001 06:53:38 +0100 To: "Shannon J. Clark" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: SV: The SKiCal extensions Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id VAA17695 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA08997 At 5:34 PM -0600 1/31/01, Shannon J. Clark wrote: >I thought that one of the purposes of the X- properties were to allow for >properties specific to one application. Why shouldn't this still be used for >extensions to iCalendar such as SKiCal? (X-SKI- is what is currently used by >the SKiCal draft) X- is to be used for private properties which are not registered anywhere. As soon as the property is well known, it should not have an X- name. X- names should NOT be registered by inclusion in an RFC. paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Thu Feb 1 06:38:12 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23636 for ; Thu, 1 Feb 2001 06:38:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA24002 for ietf-calendar-bks; Thu, 1 Feb 2001 03:14:36 -0800 (PST) Received: from smtp1.home.se (smtphost4.home.se [195.66.35.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA23998 for ; Thu, 1 Feb 2001 03:14:34 -0800 (PST) Received: from metamatrix.se [212.75.64.184] by smtp2.home.se with Novonyx SMTP Server $Revision: 2.74 $; Thu, 01 Feb 2001 12:19:44 +0100 (ECTD) Message-ID: <3A794675.E57DE383@metamatrix.se> Date: Thu, 01 Feb 2001 12:20:21 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: SKiCal component property extension - LANGUE References: <3A770F64.7BC6E019@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id DAA24002 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA23636 John Stracke wrote: > Greg FitzPatrick wrote: > > Property Name: LANGUE > This sounds like a useful property to have, but the name is pretty confusing; > it's too close to LANGUAGE. Perhaps EVENTLANGUAGE? Entendu :) This is not a very important decision, but we thought it would be nice to mix in french when doing an internationalization property. LANGUAGE is a property parameter, while LANGUE is a property, so the risk of confusion shouldn't be that great. Besides, mostly _machines_ will read the raw files and data streams, and if somebody attempts to implement a calendaring app by reading sample files instead of specs. he will probably recognize that "LANGUE:de" has something to do with languages, and what could that be except for an indication of what language is being used at the event? Pär From owner-ietf-calendar@mail.imc.org Thu Feb 1 11:01:32 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29845 for ; Thu, 1 Feb 2001 11:01:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA12229 for ietf-calendar-bks; Thu, 1 Feb 2001 07:39:16 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12225 for ; Thu, 1 Feb 2001 07:39:15 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f11Fpg419273 for ; Thu, 1 Feb 2001 10:51:42 -0500 Message-ID: <3A79860D.D708A174@ecal.com> Date: Thu, 01 Feb 2001 10:51:41 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extension - LANGUE References: <3A770F64.7BC6E019@ecal.com> <3A794675.E57DE383@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id HAA12229 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA29845 Pär Lannerö wrote: > This is not a very important decision, but we thought it would be nice > to mix in french when doing an internationalization property. Mmm, I can understand that; but I think it's counterproductive. First, in order to work with this standard, you pretty much have to be able to read English, since that's the only language the RFC is published in. Using non-English words feels like being inclusive, but it's really being *exclusive*, because you make it harder on the reader; they now have to understand *more* languages. Second, using a word that's close to another word in the same specification is confusing to everybody, no matter what their language. In particular, consider the case of someone who does not natively speak any European language; it's not necessarily going to be obvious to them that LANGUAGE and LANGUE are different words. (Or, contrariwise, it might not be obvious that they're *similar* words.) > LANGUAGE is a property parameter, while LANGUE is a property, so the > risk of confusion shouldn't be that great. Besides, mostly _machines_ > will read the raw files and data streams If that were relevant, we'd still be using ASN.1. We're doing a text-based protocol because text-based protocols are easier to prototype, understand, and debug. Those advantages are usability advantages, advantages of human interface. They go away if you ignore the rules of usability; and one of the most important rules is that you must not confuse the user (in this case, the programmer). If two entities in the interface are different, they must not look the same. Context helps a bit, but it's not enough. > he > will probably recognize that "LANGUE:de" has something to do with > languages, Provided his native language and/or his understand of English allows him to recognize that LANGUE is related to LANGUAGE. It seems obvious to me, but I'm steeped in European languages. I would have no clue how to recognize related kanji; I don't think it's fair to expect a native speaker of an Asian language to recognize related English and French words. (Nobody take offense, please; I'm *not* saying I assume Asians would have trouble--I'm sure many or most would handle it fine--I just don't think it's a reasonable burden to impose.) > and what could that be except for an indication of what > language is being used at the event? Lots. It could be the default value of the LANGUAGE parameter. It could be the language in which the ORGANIZER wishes you to reply. It could be a bit of random cruft, inserted by a nonstandard CUA, indicating the language of the user who composed the iCalendar. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Both candidates are better than a megalomaniac | |francis@ecal.com|mutant lab mouse bent on world domination...but| | |it's pretty close. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Feb 1 12:03:32 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03278 for ; Thu, 1 Feb 2001 12:03:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16785 for ietf-calendar-bks; Thu, 1 Feb 2001 08:45:35 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16773 for ; Thu, 1 Feb 2001 08:45:28 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id E0A18B34F9 for ; Thu, 1 Feb 2001 17:52:19 +0100 (CET) From: "Greg FitzPatrick" To: Subject: SKiCal component property extension - PROMO Date: Thu, 1 Feb 2001 17:53:17 +0100 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3A79860D.D708A174@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit While preparing the submission of the SKiCal PROMO property, I ran into a little trouble and I wonder if anybody can help me out? The idea with PROMO is that it would help to keep promotional verbosity under control by keeping advertisements in appointed places so that clients could decide themselves if they wanted to pull down 30 second commercial to their PDAs and so on. We based PROMO on ATTACH, which is basically a URI place holder. Looking again at ATTACH it appears to me that there is no method for describing what the attachment actually contains. Though you can say what type of attachment it is - you can not say "what it is about". In the 2445 examples this is not readily apparent since the URIs exemplified use self explanatory names like; ATTACH:http://xyz.com/public/quarterly-report.docor FMTTATTACHYPE=application/postscript:ftp://xyzCorp.com/pub/ conf/bkgrnd.ps We surely cant count on this always being the case. In the example below the DESCRIPTION is used to solve the problem, but that seems not to be a good approach - certainly not in the interest of promoting machine understanding; DESCRIPTION:A draft agenda needs to be sent out to the attendees to the weekly managers meeting (MGR-LIST). Attached is a pointer the document template for the agenda file. ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen da.doc It seems what is missing is the altrep mechanism, which gives both the URI and a textual representation of what is to be found at that URI, but altrep is not given as a value option for ATTACH. Any comments? btw. Erik there is a 2445 typo in that last example .. a pointer (to) the document.. From owner-ietf-calendar@mail.imc.org Thu Feb 1 12:21:56 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03702 for ; Thu, 1 Feb 2001 12:21:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17900 for ietf-calendar-bks; Thu, 1 Feb 2001 09:02:58 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17890 for ; Thu, 1 Feb 2001 09:02:56 -0800 (PST) From: par.lannero@metamatrix.se Received: from finnegan.metamatrix.se (finnegan.metamatrix.se [193.14.119.142]) by ljudo.shortlist.se (Postfix) with ESMTP id D1AA1B34F9 for ; Thu, 1 Feb 2001 18:09:48 +0100 (CET) Date: Thu, 1 Feb 2001 18:09:48 +0100 (CET) X-Sender: To: Subject: Re: SKiCal component property extension - LANGUE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id JAA17900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03702 John Stracke wrote: > Pär Lannerö wrote: > > This is not a very important decision, but we thought it would be nice > > to mix in french when doing an internationalization property. > > Mmm, I can understand that; but I think it's counterproductive. Your argumentation seems valid to me, so I am happy go along with EVENTLANGUAGE. /Pär From owner-ietf-calendar@mail.imc.org Thu Feb 1 12:51:45 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04479 for ; Thu, 1 Feb 2001 12:51:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19329 for ietf-calendar-bks; Thu, 1 Feb 2001 09:32:13 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19325 for ; Thu, 1 Feb 2001 09:32:10 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f11Hib419566 for ; Thu, 1 Feb 2001 12:44:37 -0500 Message-ID: <3A79A085.41907B88@ecal.com> Date: Thu, 01 Feb 2001 12:44:37 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extension - PROMO 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 Greg FitzPatrick wrote: > The idea with PROMO is that it would help to keep promotional verbosity > under control by keeping advertisements in appointed places so that clients > could decide themselves if they wanted to pull down 30 second commercial to > their PDAs and so on. A feature designed to contain advertisements, which gives the user control over whether to view the advertisement, will never be used; it's not in the advertiser's interests. Several of your features seem to be targeted at advertisers, but would not be useful to them. Case in point: the example you give in the section on SUMMARY (section 4.8.1.12, which is contained in section 4.1). You advocate replacing: SUMMARY:Macy's once a year white sale. Up to 50% off on some items. We are featuring Cramer & Houghton bedding, Epousant pillow covers, Jantzen towels. CATEGORY:Department Store with: TITLE:Macy's once a year white sale(c) CATEGORY:Department Store.sale THINGS;ROLE=onsale:Cramer & Houghton bedding, Epousant pillow covers, Jantzen towels, In the latter version, there is no free-form text, no chance for the advertiser to be persuasive. Sure, it's searchable, but so what? Some people will manage to find the ad by searching for "pillow covers"; but the ad won't be persuasive when they find it, and it certainly won't get the attention of people who weren't already in the market. The advertiser might benefit from being able to do *both*--provide both the metadata and the full text--but your 4.8.1.12 recommends using SUMMARY for a very brief title, or not at all. (This actually calls up another point: SKiCal objects may be technically compatible with iCalendar; but, as things stand, there's a strong risk that someone using a base iCalendar implementation won't be able to see much information. If SUMMARY goes away and is replaced with metadata which is invisible to iCalendar, then my iCalendar app will show an event with no summary, and the users will be left scratching their heads.) Similarly, the PERSONS, THINKS, and THINGS properties may be useful as metadata, but they're woefully inadequate for a rich description of the event. Your "THINGS;ROLE=PRESENT:Car models of 2001" (section 3.2) is much less useful to an advertiser than "SUMMARY:Come on down and see the new 2001 Ford Pinto! Now with 35% fewer fatal explosions!" -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Te audire no possum. Musa sapientum fixa est in| |francis@ecal.com|aure. | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Feb 1 14:55:27 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10182 for ; Thu, 1 Feb 2001 14:55:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26679 for ietf-calendar-bks; Thu, 1 Feb 2001 11:29:53 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26675 for ; Thu, 1 Feb 2001 11:29:52 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f11Jamg15169 for ; Thu, 1 Feb 2001 13:36:48 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 1 Feb 2001 13:36:40 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS5JVH>; Thu, 1 Feb 2001 13:36:40 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361F9FE@daeis06nok> To: greg.fitzpatrick@metamatrix.se, ietf-calendar@imc.org Subject: RE: SKiCal component property extension - PROMO Date: Thu, 1 Feb 2001 13:29:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > We based PROMO on ATTACH, which is basically a URI place > holder. Looking > again at ATTACH it appears to me that there is no method for > describing what > the attachment actually contains. Though you can say what type of > attachment it is - you can not say "what it is about". > Greg: Are you looking for a comment about the attachment? Or are you looking for a plain/text alternative to a richer content contained in the attachment? For the former, you could use the existing COMMENT property. For the latter you could use the ALTREP on the ATTACH property. If you are worried about what format the attachment is in, then on your HTTP request you would issue ACCEPT header to specify what format you can accept. -- Frank From owner-ietf-calendar@mail.imc.org Thu Feb 1 17:08:34 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12742 for ; Thu, 1 Feb 2001 17:08:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA06731 for ietf-calendar-bks; Thu, 1 Feb 2001 13:38:11 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06727 for ; Thu, 1 Feb 2001 13:38:10 -0800 (PST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA25418; Thu, 1 Feb 2001 13:44:41 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f11LiXk03712; Thu, 1 Feb 2001 13:44:33 -0800 (PST) Received: from [130.242.18.113] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id NAA07623; Thu, 1 Feb 2001 13:44:21 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3A79A085.41907B88@ecal.com> References: <3A79A085.41907B88@ecal.com> Date: Thu, 1 Feb 2001 22:23:26 +0100 To: John Stracke , ietf-calendar@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: SKiCal component property extension - PROMO Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12.44 -0500 01-02-01, John Stracke wrote: >Greg FitzPatrick wrote: > >> The idea with PROMO is that it would help to keep promotional verbosity >> under control by keeping advertisements in appointed places so that clients >> could decide themselves if they wanted to pull down 30 second commercial to >> their PDAs and so on. > >A feature designed to contain advertisements, which gives the user >control over >whether to view the advertisement, will never be used; it's not in the >advertiser's interests. I don't agree. It is in the advertiser's interest to reach the people which are interested in whatever things the adevertisment is about, and at the same time not create negative value on the trademark he owns. One way of making people happy while still sending out information is to let the user have control over whether the information should be displayed or not. >(This actually calls up another point: SKiCal objects may be technically >compatible with iCalendar; but, as things stand, there's a strong risk that >someone using a base iCalendar implementation won't be able to see much >information. If SUMMARY goes away and is replaced with metadata which is >invisible to iCalendar, then my iCalendar app will show an event with no >summary, and the users will be left scratching their heads.) A specification of a schema will always be extended. See the SNMP specs. I presume that if someone want to create a really good iCalendar application, it should be able to understand the current RFC for iCalendar (which might be updated one day) and also the extensions also published as RFC's. The one day a spring cleaning is happening and a new version of iCalendar is published and that might include the properties that SKiCal have. So, I would be a little bit less negative to new properties than what I feel many people (I am not pointing at you John) on the iCalendar list has. Instead, see that iCalendar is a success, just because the SKiCal group want to use it, BUT, need some new properties because the iCalendar objects are no longer used to describe the same kind of "things" as what was (maybe) originally planned. Yes, you should (as you do John) see if the problem which the SKiCal people have can be solved by existing properties, but if that is not possible, then "just" create new ones and extend iCalendar to be able to use for this new usage. paf -- as individual and not as area director, the call of where this discussion is going, and consensus, is with the wg chair From owner-ietf-calendar@mail.imc.org Thu Feb 1 17:12:26 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12856 for ; Thu, 1 Feb 2001 17:12:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA07452 for ietf-calendar-bks; Thu, 1 Feb 2001 13:49:40 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07446 for ; Thu, 1 Feb 2001 13:49:38 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f11M25420333 for ; Thu, 1 Feb 2001 17:02:06 -0500 Message-ID: <3A79DCDA.D794065C@ecal.com> Date: Thu, 01 Feb 2001 17:02:02 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extension - PROMO References: <3A79A085.41907B88@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id NAA07452 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12856 Patrik Fältström wrote: > One way of making people happy while still sending out information is > to let the user have control over whether the information should be > displayed or not. Um...I agree that this could make sense in theory; but advertisers obviously don't believe it. That's why there's no way to skip TV ads (it'd be trivial to include "this is an ad" markers in the subchannel, for VCRs to spot), or to go to a Web site and say, "don't give me ads" (*). Advertisers pay money to get their ads to you; they're not going to pay nearly as much if you can ignore them easily. If you go to a company and say, "we've got this format in which you can advertise your events; it has a feature where you can put your information out of band so users don't have to see it", they're going to stare at you in blank incomprehension. Why would they go to extra effort *not* to show the user the entire ad? > A specification of a schema will always be extended. Yes, but SKiCal doesn't just extend; it more or less deprecates some of the existing properties. A specification for "iCalendar plus new metadata" would be good; one that says "OK, make an iCalendar, but don't bother with SUMMARY, because it's redundant with these extensions" is not backward compatible. (*) If someone tells me there are sites that do this, I won't dispute it; but they're at least rare enough that I've never seen one. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"What now, Brain?" "We should flee in terror.| |francis@ecal.com|Yes, that would be the wisest course." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Feb 1 17:48:42 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13597 for ; Thu, 1 Feb 2001 17:48:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08841 for ietf-calendar-bks; Thu, 1 Feb 2001 14:29:00 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08836 for ; Thu, 1 Feb 2001 14:28:58 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id QAA28602 for ; Thu, 1 Feb 2001 16:11:42 -0600 From: "Shannon J. Clark" To: Subject: ToDo's and a thought Date: Thu, 1 Feb 2001 16:34:53 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A curious thought occurred to me today while at work, does the current standard have built in functionality to within an object store a version history? For example: With ToDo's - frequently there is a DueDate set - and fairly frequently situations may cause that date to need to be changed or modified - within the current standard is there is mechanism to capture this change or changes and maintain it? I know that various events can be modified - but the question is, once modified can the previous version still be maintained as a "previous state"? So, in the case of changing ToDo a user could be presented with the change history of that task. Just my 2 cents. Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Thu Feb 1 17:51:27 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13656 for ; Thu, 1 Feb 2001 17:51:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09130 for ietf-calendar-bks; Thu, 1 Feb 2001 14:33:14 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09126 for ; Thu, 1 Feb 2001 14:33:13 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f11MeBg07824 for ; Thu, 1 Feb 2001 16:40:11 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 1 Feb 2001 16:40:07 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1C0LA0MB>; Thu, 1 Feb 2001 16:35:02 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FA09@daeis06nok> To: paf@cisco.com, francis@ecal.com, ietf-calendar@imc.org Subject: RE: SKiCal component property extension - PROMO Date: Thu, 1 Feb 2001 16:33:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > A specification of a schema will always be extended. See the SNMP > specs. I presume that if someone want to create a really good > iCalendar application, it should be able to understand the current > RFC for iCalendar (which might be updated one day) and also the > extensions also published as RFC's. The one day a spring cleaning is > happening and a new version of iCalendar is published and that might > include the properties that SKiCal have. Patrik: Tend to agree with your comments about extensibility is good for the schema! Good points. However, you point out that "extensions also published as RFC's". But the iCalendar specification includes a property registration process that doesn't require RFC publication. Right? >>7.2 Registration of New Properties >> >> This section defines procedures by which new properties or enumerated >> property values for the MIME Calendaring and Scheduling Content Type >> can be registered with the IANA. Non-IANA properties can be used by >> bilateral agreement, provided the associated properties names follow >> the "X-" convention. Just want to make sure that this registration process hasn't been dumped. Thanks. -- Frank From owner-ietf-calendar@mail.imc.org Thu Feb 1 18:53:27 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14916 for ; Thu, 1 Feb 2001 18:53:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13138 for ietf-calendar-bks; Thu, 1 Feb 2001 15:32:02 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13123 for ; Thu, 1 Feb 2001 15:31:59 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f11Ncvg12935 for ; Thu, 1 Feb 2001 17:38:57 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 1 Feb 2001 17:38:47 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS5NQH>; Thu, 1 Feb 2001 17:38:47 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FA13@daeis06nok> To: shannon@jigzaw.com, ietf-calendar@imc.org Subject: RE: ToDo's and a thought Date: Thu, 1 Feb 2001 17:31:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > A curious thought occurred to me today while at work, does the current > standard have built in functionality to within an object > store a version > history? > Shannon: Good question. The iCalendar specification includes support for a to-do object, called the VTODO component. One of the component level properties involves maintaining change control over the object representation. This is primarily addressed by the SEQUENCE property. The initial version is nominally zero and autoincremented for each significant modifications. However, maintenance of delta changes from version to version is assumed to be something that an implementation might be designed to track. It is not codified by the current version of the specification. -- Frank From owner-ietf-calendar@mail.imc.org Fri Feb 2 05:25:26 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05689 for ; Fri, 2 Feb 2001 05:25:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA24980 for ietf-calendar-bks; Fri, 2 Feb 2001 02:02:17 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA24970 for ; Fri, 2 Feb 2001 02:02:15 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 9DF9DB34F9; Fri, 2 Feb 2001 11:09:10 +0100 (CET) From: "Greg FitzPatrick" To: "John Stracke" , Subject: SV: SKiCal component property extension - please Date: Fri, 2 Feb 2001 11:10:08 +0100 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3A79A085.41907B88@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Please refrain from jumping around all over this. Please let us introduce one issue at a time and debate the merits of that issue. Pat once told me, and I value this highly, "don't submit concepts and ideas, submit proposals formulated in the syntax of the working group." That is what we are now trying to do, after waiting patiently in the wings for CAP do be resolved. We started with "LANGUE." You made good arguments for calling it EVENT-LANGUAGE and we agree. But then you referenced PROMO, which we had not yet submitted and then you cited our examples of SUMMARY, which we have not either submitted. And now we are about to get side tracked in discussing the motives of advertisers. Please let us just submit these items one at a time so that we can concentrate on the merits and weaknesses of each per se. Greg From owner-ietf-calendar@mail.imc.org Fri Feb 2 06:03:51 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06014 for ; Fri, 2 Feb 2001 06:03:51 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA29351 for ietf-calendar-bks; Fri, 2 Feb 2001 02:43:04 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29345 for ; Fri, 2 Feb 2001 02:43:02 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id E10B6B34F9 for ; Fri, 2 Feb 2001 11:49:58 +0100 (CET) From: "Greg FitzPatrick" To: Subject: SKiCal component property extension - PROMO - philosophy Date: Fri, 2 Feb 2001 11:50:55 +0100 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3A79A085.41907B88@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Reluctantly I take up this glove. But I suggest that any one with a limited time schedule for philosophizing can skip all this and concentrate on the issues. Our proposals for the properties cited here will be presented to the list shortly. John: A feature designed to contain advertisements, which gives the user control over whether to view the advertisement, will never be used; it's not in the advertiser's interests. Greg: And what is a banner? What is a "for more information call xxx"? You are really off here John. Look at any commercial web page on the Internet. And do you suggest that WAP and IMODE users will have no control what-so-ever over the size of things they download? John: Several of your features seem to be targeted at advertisers, but would not be useful to them. Case in point: the example you give in the section on SUMMARY (section 4.8.1.12, which is contained in section 4.1). You advocate replacing:... Greg: No, No, No, we don't advocate replacing anything!! John:... SUMMARY:Macy's once a year white sale. Up to 50% off on some items. We are featuring Cramer & Houghton bedding, Epousant pillow covers, Jantzen towels. CATEGORY:Department Store with: TITLE:Macy's once a year white sale(c) CATEGORY:Department Store.sale THINGS;ROLE=onsale:Cramer & Houghton bedding, Epousant pillow covers, Jantzen towels, In the latter version, there is no free-form text, no chance for the advertiser to be persuasive. Sure, it's searchable, but so what? Some people will manage to find the ad by searching for "pillow covers"; but the ad won't be persuasive when they find it, and it certainly won't get the attention of people who weren't already in the market. The advertiser might benefit from being able to do *both*--provide both the metadata and the full text--but your 4.8.1.12 recommends using SUMMARY for a very brief title, or not at all. Greg: The issue is machine discovery and machine readability. The authors of a schema must think in terms of place-holders which will give machines a reasonable chance to discover what they are looking for. These place-holders will sort somewhere between being universally generic and domain specific. These are design issues. But the authors can not know to what extent machine discovery and readability will become part of our daily transactions, so the authors offer o p t i o n s. The authors offer mechanisms of possibilities. Publishers and users and the market itself will decide to what extent these are used. John (This actually calls up another point: SKiCal objects may be technically compatible with iCalendar; but, as things stand, there's a strong risk that someone using a base iCalendar implementation won't be able to see much information. If SUMMARY goes away and is replaced with metadata which is invisible to iCalendar, then my iCalendar app will show an event with no summary, and the users will be left scratching their heads.) Greg: Again I repeat, we don't advocate doing away with SUMMARY!!! Please stop inferring this. From owner-ietf-calendar@mail.imc.org Fri Feb 2 06:13:36 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06112 for ; Fri, 2 Feb 2001 06:13:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00114 for ietf-calendar-bks; Fri, 2 Feb 2001 02:50:42 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA00109 for ; Fri, 2 Feb 2001 02:50:40 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 47B87B34F9; Fri, 2 Feb 2001 11:57:37 +0100 (CET) From: "Greg FitzPatrick" To: , Subject: SV: SKiCal component property extension - PROMO Date: Fri, 2 Feb 2001 11:58:34 +0100 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <30F2DED23724D311902D0008C7EABAFB0361F9FE@daeis06nok> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Frank Would not that cause problems - using ALTREP on ATTACH? Frank wrote: :Are you looking for a comment about the attachment? Or are you looking for a :plain/text alternative to a richer content contained in the attachment? :For the former, you could use the existing COMMENT property. For the latter :you could use the ALTREP on the ATTACH property. From owner-ietf-calendar@mail.imc.org Fri Feb 2 10:10:12 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11298 for ; Fri, 2 Feb 2001 10:10:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA17863 for ietf-calendar-bks; Fri, 2 Feb 2001 06:48:35 -0800 (PST) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17854 for ; Fri, 2 Feb 2001 06:48:34 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f12F0dx21167 for ; Fri, 2 Feb 2001 10:00:39 -0500 Message-ID: <3A7ACB96.6D5915CE@ecal.com> Date: Fri, 02 Feb 2001 10:00:38 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extension - PROMO - philosophy 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 Greg FitzPatrick wrote: > Greg: No, No, No, we don't advocate replacing anything!! 4.8.1.12: Due to the additional SkiCal properties such as TITLE, PERSONS, THINGS, THINKS, it is expected that Summary be used as a short abstract describing the SKiSource rather then a general placeholder for text values sorting naturally under the new SKiCal properties. In other words, Summary will hold less information, because of the metadata. Then, in your example, you don't have a Summary at all. > Publishers and users and the market itself > will decide to what extent these are used. OK, fine. But your draft, as written, anticipates less free-form text. I would be more comfortable seeing that weakened. I'll drop this now. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Beware of wizards, for you are crunchy and good| |francis@ecal.com|with ketchup. | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 2 10:15:34 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11468 for ; Fri, 2 Feb 2001 10:15:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA18107 for ietf-calendar-bks; Fri, 2 Feb 2001 06:53:01 -0800 (PST) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18103 for ; Fri, 2 Feb 2001 06:53:00 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f12F55x21192 for ; Fri, 2 Feb 2001 10:05:05 -0500 Message-ID: <3A7ACCA0.1A54F8D2@ecal.com> Date: Fri, 02 Feb 2001 10:05:05 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SV: SKiCal component property extension - please 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 Greg FitzPatrick wrote: > Please let us introduce one issue at a time and debate the merits of that > issue. I'm not sure that's a good process; it winds up being too myopic. You're introducing a *lot* of new properties and parameters, which work together; to some extent, at least, they need to be considered together. At a minimum, the group needs a guarantee that no decisions will be made on any proposal until we've discussed all of them, so that, if the discussion of proposal #17 uncovers a problem with proposal #3, we're not already committed to accepting #3. > But then you referenced PROMO, which we had > not yet submitted You published it as a Draft, which implies you're looking for comments. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Veni, Vidi, Ridi: I came, I saw, I mocked. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 2 10:15:42 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11485 for ; Fri, 2 Feb 2001 10:15:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA18369 for ietf-calendar-bks; Fri, 2 Feb 2001 06:56:59 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18361 for ; Fri, 2 Feb 2001 06:56:57 -0800 (PST) From: pregen@egenconsulting.com To: "Greg FitzPatrick" Cc: "John Stracke" , ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: SV: SKiCal component property extension - please X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 2 Feb 2001 15:03:35 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/02/2001 10:03:51 AM, Serialize complete at 02/02/2001 10:03:51 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00378127802569E7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00378127802569E7_= Content-Type: text/plain; charset="us-ascii" Greg, John is doing what many people do on an IETF mailing list and that is responding with "enthusiasm." I don't think he is "jumping" on the items. At least he is commenting (notice the relative silence from the majority of the remaining list). All working group lists react the same way. The comments are either lively and active or silent with no feedback whatsoever. Since you are relatively new to the IETF process, you may not be familiar with how the lists tend to work. One thing I like to make sure we do is not "attack" or "condem" someone for making comments. Do that and no one will respond to a request. So, take John's opinions and thoughts as just that - opinions and thoughts. Also, make sure you see that he usually tries to make some sense out of what he reads. He does take the trouble to read the items you submit. Read around his style of responding and look for the suggestions he makes. This goes for all the responses to the list. IETF mailing lists are always "interesting reading." It took me a while to also get used to the noise factor. I only step in when I think things are starting to get "touchy." ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 00378127802569E7_= Content-Type: text/html; charset="us-ascii"
Greg, John is doing what many people do on an IETF mailing list and that is responding with "enthusiasm."  I don't think he is "jumping" on the items.  At least he is commenting (notice the relative silence from the majority of the remaining list).  All working group lists react the same way.  The comments are either lively and active or silent with no feedback whatsoever.  Since you are relatively new to the IETF process, you may not be familiar with how the lists tend to work.  One thing I like to make sure we do is not "attack" or "condem" someone for making comments.  Do that and no one will respond to a request.  So, take John's opinions and thoughts as just that -  opinions and thoughts.  Also, make sure you see that he usually tries to make some sense out of what he reads.  He does take the trouble to read the items you submit.  Read aro! und his style of responding and look for the suggestions he makes.  This goes for all the responses to the list.  IETF mailing lists are always "interesting reading."  It took me a while to also get used to the noise factor.  I only step in when I think things are starting to get "touchy."  
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 00378127802569E7_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 2 11:45:28 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14919 for ; Fri, 2 Feb 2001 11:45:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25428 for ietf-calendar-bks; Fri, 2 Feb 2001 08:22:07 -0800 (PST) Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25424 for ; Fri, 2 Feb 2001 08:22:05 -0800 (PST) Received: from metamatrix.se (IDENT:pbb@[213.88.195.121]) by smtp.wineasy.se with ESMTP id f12GT3O21050; Fri, 2 Feb 2001 17:29:03 +0100 Message-ID: <3A7B42BF.2A17B993@metamatrix.se> Date: Sat, 03 Feb 2001 00:29:03 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: SKiCal component property extension - PROMO - philosophy References: <3A7ACB96.6D5915CE@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id IAA25428 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA14919 John Stracke wrote: > In other words, Summary will hold less information, because of the metadata. > Then, in your example, you don't have a Summary at all. You're right, we should put a Summary in the example. We never intended to change anything about SUMMARY. Only to add other properties. > I'll drop this now. John, we (ie. the authors of the SKICal draft) are very thankful for your efforts to read and comment on the draft. I sincerely appreciate your contributions and I hope you will not drop this altogether! /Pär From owner-ietf-calendar@mail.imc.org Fri Feb 2 11:46:27 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14943 for ; Fri, 2 Feb 2001 11:46:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25598 for ietf-calendar-bks; Fri, 2 Feb 2001 08:27:49 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25583 for ; Fri, 2 Feb 2001 08:27:44 -0800 (PST) Received: from metaacer (unknown [213.88.195.104]) by ljudo.shortlist.se (Postfix) with SMTP id 559FFB34FA; Fri, 2 Feb 2001 17:34:41 +0100 (CET) From: "Greg FitzPatrick" To: Cc: "John Stracke" , , Subject: SV: SV: SKiCal component property extension - please Date: Fri, 2 Feb 2001 17:34:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C08D3E.60A52BA0" 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.2919.6600 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_0002_01C08D3E.60A52BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Gosh Pat - I have been contributing to this list for over two years. When does one become a member of the club? :-) But seriously, if I overreacted please accept my apologies - John and everybody else. Pat wrote: Since you are relatively new to the IETF process, you may not be familiar with how the lists tend to work. ------=_NextPart_000_0002_01C08D3E.60A52BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Gosh=20 Pat - I have been contributing to this list for over two years.  = When does=20 one become a member of the club? :-)
 
But=20 seriously, if I overreacted please accept my apologies - John and = everybody=20 else. 
 
Pat wrote:  Since you = are=20 relatively new to the IETF process, you may not be familiar with how = the lists=20 tend to work.  
 
= ------=_NextPart_000_0002_01C08D3E.60A52BA0-- From owner-ietf-calendar@mail.imc.org Fri Feb 2 11:58:38 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15887 for ; Fri, 2 Feb 2001 11:58:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25962 for ietf-calendar-bks; Fri, 2 Feb 2001 08:37:59 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25954 for ; Fri, 2 Feb 2001 08:37:57 -0800 (PST) From: pregen@egenconsulting.com To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: SV: SKiCal component property extension - please X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 2 Feb 2001 16:44:49 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/02/2001 11:44:51 AM, Serialize complete at 02/02/2001 11:44:51 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0040C5D9802569E7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0040C5D9802569E7_= Content-Type: text/plain; charset="us-ascii" John, the reason I suggested that Greg submit items in separate notes is because his list was so large, that if he posted it as one note, either no one would read it or people would grumble about the size. Things get lost in dialogs on a mailing list and I wanted to make sure people read his items. We really need to make sure they are correct and are going in the proper direction and do not "break" iCalendar or CAP. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0040C5D9802569E7_= Content-Type: text/html; charset="us-ascii"
John, the reason I suggested that Greg submit items in separate notes is because his list was so large, that if he posted it as one note, either no one would read it or people would grumble about the size.  Things get lost in dialogs on a mailing list and I wanted to make sure people read his items.  We really need to make sure they are correct and are going in the proper direction and do not "break" iCalendar or CAP.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0040C5D9802569E7_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 2 12:00:11 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15939 for ; Fri, 2 Feb 2001 12:00:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26185 for ietf-calendar-bks; Fri, 2 Feb 2001 08:40:50 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26179 for ; Fri, 2 Feb 2001 08:40:49 -0800 (PST) Received: from metaacer (unknown [213.88.195.104]) by ljudo.shortlist.se (Postfix) with SMTP id D562FB34F9; Fri, 2 Feb 2001 17:47:33 +0100 (CET) From: "Greg FitzPatrick" To: "John Stracke" , Subject: SV: SV: SKiCal component property extension - please Date: Fri, 2 Feb 2001 17:47:09 +0100 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.2919.6600 Importance: Normal In-Reply-To: <3A7ACCA0.1A54F8D2@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit No argument here. It is just that we are trying to consider each SKiCal item very carefully ourselves as we submit them here, in that sense we are reviewing the draft you quote. Once this round is completed we will correct and deplete and amend before the last call. For example your EVENT-LANGUAGE name change suggestion looks like it will be incorporated. Of course the draft is published hoping for comments, but I hope it will be easier to focus on the items in the order we introduce them. Greg Greg FitzPatrick wrote: > Please let us introduce one issue at a time and debate the merits of that > issue. John wrote: I'm not sure that's a good process; it winds up being too myopic. You're introducing a *lot* of new properties and parameters, which work together; to some extent, at least, they need to be considered together. At a minimum, the group needs a guarantee that no decisions will be made on any proposal until we've discussed all of them, so that, if the discussion of proposal #17 uncovers a problem with proposal #3, we're not already committed to accepting #3. > But then you referenced PROMO, which we had > not yet submitted You published it as a Draft, which implies you're looking for comments. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Veni, Vidi, Ridi: I came, I saw, I mocked. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 2 12:00:36 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15961 for ; Fri, 2 Feb 2001 12:00:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25758 for ietf-calendar-bks; Fri, 2 Feb 2001 08:32:34 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25750 for ; Fri, 2 Feb 2001 08:32:32 -0800 (PST) From: pregen@egenconsulting.com To: "Greg FitzPatrick" Cc: "John Stracke" , ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: SV: SV: SKiCal component property extension - please X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 2 Feb 2001 16:39:14 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/02/2001 11:39:26 AM, Serialize complete at 02/02/2001 11:39:26 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004042FC802569E7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004042FC802569E7_= Content-Type: text/plain; charset="us-ascii" Actually, two years is a while by some standards, and very short by others. Thanks for understanding. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "Greg FitzPatrick" 02/02/01 04:34 PM To: cc: "John Stracke" , , Subject: SV: SV: SKiCal component property extension - please Gosh Pat - I have been contributing to this list for over two years. When does one become a member of the club? :-) But seriously, if I overreacted please accept my apologies - John and everybody else. Pat wrote: Since you are relatively new to the IETF process, you may not be familiar with how the lists tend to work. --=_alternative 004042FC802569E7_= Content-Type: text/html; charset="us-ascii"
Actually, two years is a while by some standards, and very short by others.  Thanks for understanding.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

02/02/01 04:34 PM

       
        To:        <pregen@egenconsulting.com>
        cc:        "John Stracke" <francis@ecal.com>, <ietf-calendar@imc.org>, <owner-ietf-calendar@mail.imc.org>
        Subject:        SV: SV: SKiCal component property extension - please



Gosh Pat - I have been contributing to this list for over two years.  When does one become a member of the club? :-)
 
But seriously, if I overreacted please accept my apologies - John and everybody else.  
 
Pat wrote:  Since you are relatively new to the IETF process, you may not be familiar with how the lists tend to work.  
 

--=_alternative 004042FC802569E7_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 2 12:04:53 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16135 for ; Fri, 2 Feb 2001 12:04:52 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA26354 for ietf-calendar-bks; Fri, 2 Feb 2001 08:43:54 -0800 (PST) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26350 for ; Fri, 2 Feb 2001 08:43:52 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f12Gtvx21591 for ; Fri, 2 Feb 2001 11:55:57 -0500 Message-ID: <3A7AE69D.E53A5516@ecal.com> Date: Fri, 02 Feb 2001 11:55:57 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SV: SKiCal component property extension - please 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 pregen@egenconsulting.com wrote: > John, the reason I suggested that Greg submit items in separate notes is because his list was so large, that if he posted it as one note, either no one would read it or people would grumble about the size. Things get lost in dialogs on a mailing list and I wanted to make sure people read his items. OK, that makes sense as a guide; I just didn't want it to be too rigid. -- /==============================================================\ |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 Sat Feb 3 17:37:01 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13352 for ; Sat, 3 Feb 2001 17:37:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07134 for ietf-calendar-bks; Sat, 3 Feb 2001 14:07:44 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07129 for ; Sat, 3 Feb 2001 14:07:42 -0800 (PST) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: Calconnect2 Details X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Sat, 3 Feb 2001 22:14:40 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/03/2001 05:14:42 PM, Serialize complete at 02/03/2001 05:14:42 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005EFA16802569E8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005EFA16802569E8_= Content-Type: text/plain; charset="us-ascii" Here is the link for information on Calconnect2. http://www.egenconsulting.com/ietf/website/calconnect1.html ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 005EFA16802569E8_= Content-Type: text/html; charset="us-ascii"
Here is the link for information on Calconnect2.

http://www.egenconsulting.com/ietf/website/calconnect1.html
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 005EFA16802569E8_=-- From owner-ietf-calendar@mail.imc.org Sat Feb 3 22:19:34 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09633 for ; Sat, 3 Feb 2001 22:19:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12576 for ietf-calendar-bks; Sat, 3 Feb 2001 18:59:01 -0800 (PST) Received: from mail.monaco-interactive.com ([195.78.8.73]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA12572 for ; Sat, 3 Feb 2001 18:58:59 -0800 (PST) From: bigjoe@japan.com Received: (qmail 14522 invoked by uid 514); 3 Feb 2001 18:57:33 -0000 Received: from 1cust46.tnt3.irving2.tx.da.uu.net (HELO 1Cust46.tnt3.irving2.tx.da.uu.net??63.24.178.46?) (63.24.178.46) by 195.78.8.73 with SMTP; 3 Feb 2001 18:57:33 -0000 Received: from mailer.ug.eds.com by 1Cust46.tnt3.irving2.tx.da.uu.net with ESMTP; Sat, 03 Feb 2001 12:02:55 -0600 Message-ID: <0000457c0c01$00002e88$00002b21@mailer.ug.eds.com> To: Subject: Brand New E-Mail pager for FR-EE! 11041 Date: Sat, 03 Feb 2001 12:02:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: bigjoe@japan.com Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE! From owner-ietf-calendar@mail.imc.org Sun Feb 4 03:14:16 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01359 for ; Sun, 4 Feb 2001 03:14:16 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA00574 for ietf-calendar-bks; Sat, 3 Feb 2001 23:53:10 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00549 for ; Sat, 3 Feb 2001 23:53:07 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA13964 for ietf-calendar@imc.org; Sun, 4 Feb 2001 00:00:03 -0800 (PST) Date: Sun, 4 Feb 2001 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200102040800.AAA13964@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com Tuesday discussion: DONE Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. DONE Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). DONE Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) DONE Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. DONE Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text DONE Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 DONE Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. DONE Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Mon Feb 5 06:17:54 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03245 for ; Mon, 5 Feb 2001 06:17:54 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA20987 for ietf-calendar-bks; Mon, 5 Feb 2001 02:42:44 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20980 for ; Mon, 5 Feb 2001 02:42:41 -0800 (PST) Received: from metaacer (unknown [193.14.119.80]) by ljudo.shortlist.se (Postfix) with SMTP id 97E99B34F9; Mon, 5 Feb 2001 11:49:47 +0100 (CET) From: "Greg FitzPatrick" To: "Eric Busboom" , Subject: SKiCal component property extensions - SKUID Date: Mon, 5 Feb 2001 11:47:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2919.6600 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id CAA20987 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA03245 We would like to submit the following component property as an addition to the properties described in RFC2445. Property Name: SKUID Purpose: This property specifies a persistent, globally unique identifier for the resource described by the calendar object. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Description: This property provides a method for determining the definite, authoritative and unique identification of a resource. SKUID differs from the UID property defined in RFC2445 section 4.8.4.7. Whereas UID identifies a calendar component (SKiCal object), SKUID identifies the resource being described by the calendar component. The SKUID itself MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the RFC822 addr-spec. A good method to assure uniqueness is described in RFC-2445 , section 4.8.4.7 Unique Identification Numbers. Format Definition: The property is defined by the following notation: skuid = "SKUID" skuidparam ":" text CRLF skuidparam *( ; the following is optional, ; and MAY occur more than ; once (";" xparam) ) Example: The following is an example of this property: SKUID:20021001T090045Z-4000F192713-0052@qwack.com Motivation: If George and Steve wish to plan a business meeting, they might well initiate it through their calendar program. They might be in the midst of some sort of project and this meeting merely one in a series of many. This meeting might not have any special name. The only reference to it might just be the iCal calendar object describing the time, place and other details. In this example the iCal object shared between George and Steve is the identifier of the meeting/event. It is easy to see why nothing else is really necessary. The UID of the calendar object simply doubles as the UID of the meeting. As I write this, my family is watching a handball game on television. I know most people in America haven’t the slightest what that sport is, but over here it is a big deal and the game being watched just happens to be the world championship final between Sweden and France. Quite a few Swedes and French are interested in this event and some of them surely had it marked in their desk top calendar or PDA schedulers. They might have entered the event themselves or they might have downloaded a readymade object from some sport site, perhaps in SkiCal, possibly they subscribe to a service which sends out objects in accordance with some preference profile they have on file. In any case unless everyone got their calendar object from the same source, they won’t share identical UIDs, and if they made the entry themselves, they don’t share them with anybody at all. This is the way it should be, because the UID is the identifier of the calendar object and NOT the event it is pointing to. Here is what 2445 says: 4.8.4.7 Unique Identifier Property Name: UID Purpose: This property defines the persistent, globally unique identifier for the calendar component. The point we are trying to make is that we also need an ID placeholder for the unique identifier of the event itself. Of course there may not always be a unique ID for an event. We know for example that the International Federation of Handball, who are the “owners” of the World championships, do not publish their game schedules in SkiCal (not yet in any case). Actually it might just be one or more Infomediaries who takes it upon themselves to define a unique identifier for events within their sphere. If that sounds difficult to imagine, think about the ShowView system that gives unique identifiers to all TV programs on European television. Another parallel to this is travel books and the place they are describing. The travel books have their ISBN numbers, edition sequencing, copyright dates and so on but the place they are describing has its own identification which all the books must somehow refer to. From owner-ietf-calendar@mail.imc.org Mon Feb 5 11:55:42 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11754 for ; Mon, 5 Feb 2001 11:55:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16069 for ietf-calendar-bks; Mon, 5 Feb 2001 08:18:11 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16065 for ; Mon, 5 Feb 2001 08:18:10 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f15GV2o02366 for ; Mon, 5 Feb 2001 11:31:03 -0500 Message-ID: <3A7ED546.1464EC3B@ecal.com> Date: Mon, 05 Feb 2001 11:31:02 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extensions - SKUID 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 Greg FitzPatrick wrote: > Description: This property provides a method for determining the definite, > authoritative and unique identification of a resource. SKUID differs from > the UID property defined in RFC2445 section 4.8.4.7. Whereas UID identifies > a calendar component (SKiCal object), SKUID identifies the resource being > described by the calendar component. How exactly do you expect guarantee that the SKUID will be the same across all SKiCal objects that describe the same resource? If the resource's own organizer does not generate a SKUID, then everybody who publishes a SKiCal object for it will generate their own SKUID. If the resource's organizer does generate a SKUID, then they're probably publishing their own SKiCal object, so why would somebody else publish a different one? -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Millions of dollars of profits is what happens| |francis@ecal.com|in the absence of good design." -- Keith Moore | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 5 16:15:11 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17742 for ; Mon, 5 Feb 2001 16:15:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00419 for ietf-calendar-bks; Mon, 5 Feb 2001 12:51:11 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00415 for ; Mon, 5 Feb 2001 12:51:10 -0800 (PST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07767; Mon, 5 Feb 2001 12:58:07 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f15Kvpb24913; Mon, 5 Feb 2001 12:57:51 -0800 (PST) Received: from [10.0.1.8] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA21047; Mon, 5 Feb 2001 12:57:06 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <30F2DED23724D311902D0008C7EABAFB0361FA09@daeis06nok> References: <30F2DED23724D311902D0008C7EABAFB0361FA09@daeis06nok> Date: Mon, 5 Feb 2001 21:46:05 +0100 To: Frank.Dawson@nokia.com, francis@ecal.com, ietf-calendar@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: SKiCal component property extension - PROMO 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 16.33 -0600 01-02-01, Frank.Dawson@nokia.com wrote: > > A specification of a schema will always be extended. See the SNMP >> specs. I presume that if someone want to create a really good >> iCalendar application, it should be able to understand the current >> RFC for iCalendar (which might be updated one day) and also the >> extensions also published as RFC's. The one day a spring cleaning is >> happening and a new version of iCalendar is published and that might >> include the properties that SKiCal have. > >Patrik: > >Tend to agree with your comments about extensibility is good for the schema! >Good points. However, you point out that "extensions also published as >RFC's". But the iCalendar specification includes a property registration >process that doesn't require RFC publication. Right? You know this better than me. Point is though that regardless of how the registrations are done, X- should NEVER be registered. The whole idea behind X- is that one can safely use those names in private applications as one know that they will NEVER be official in any way. paf > >>>7.2 Registration of New Properties >>> >>> This section defines procedures by which new properties or enumerated >>> property values for the MIME Calendaring and Scheduling Content Type >>> can be registered with the IANA. Non-IANA properties can be used by >>> bilateral agreement, provided the associated properties names follow >>> the "X-" convention. > >Just want to make sure that this registration process hasn't been dumped. >Thanks. > >-- Frank From owner-ietf-calendar@mail.imc.org Mon Feb 5 18:56:59 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20827 for ; Mon, 5 Feb 2001 18:56:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA08002 for ietf-calendar-bks; Mon, 5 Feb 2001 15:35:36 -0800 (PST) Received: from smtp1.home.se (smtphost4.home.se [195.66.35.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07993 for ; Mon, 5 Feb 2001 15:35:33 -0800 (PST) Received: from metamatrix.se [212.75.66.150] by smtp2.home.se with Novonyx SMTP Server $Revision: 2.74 $; Tue, 06 Feb 2001 00:41:00 +0100 (ECTD) Message-ID: <3A7F3A31.91C74A16@metamatrix.se> Date: Tue, 06 Feb 2001 00:41:37 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org, Niklas Hjelm Subject: Re: SKiCal component property extensions - SKUID References: <3A7ED546.1464EC3B@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id PAA08002 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA20827 John Stracke wrote: > How exactly do you expect guarantee that the SKUID will be the same across all > SKiCal objects that describe the same resource? We cannot guarantee this. But it would be useful if one day all public events and other resources (skisources) would have a globally unique id. (For example, it would be possible to quickly find out what different public calendars write about the same event if all use the same identifier.) Defining a property to keep such an id is a first step towards that scenario. The next logical step is to specify how these id:s should be located and passed around. That work remains to be done. It will never be possible to guarantee that no two objects (with non-identical SKUID values) refer to the same skisource, but it is quite nice for people who *want* to indicate that their SKiCal object refers to the same skisource as another to be *able* to do this. In a perhaps not-so-distant future there will be large calendar databases containing SKiCal objects describing lots of skisources of public interest. In many cases it will be a matter of a simple search through one of those databases to find out whether or not the skisource is already mentioned by somebody. If it is, you can copy the SKUID, thus augmenting the information value of the SKiCal object you're about to create. > If the resource's own organizer > does not generate a SKUID, then everybody who publishes a SKiCal object for it > will generate their own SKUID. If the resource's organizer does generate a > SKUID, then they're probably publishing their own SKiCal object, so why would > somebody else publish a different one? Well, most publishers of public calendars, since they are editors, want to formulate the SUMMARY and DESCRIPTION using their own words (and perhaps language). Perhaps they want to add lots of new properties to the SKiCal object as well. Hopefully they will reuse the SKUID, though. /Pär It's in the middle of the night here, hope my writing is not too confusing! :) From owner-ietf-calendar@mail.imc.org Mon Feb 5 23:52:13 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25624 for ; Mon, 5 Feb 2001 23:52:12 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA14795 for ietf-calendar-bks; Mon, 5 Feb 2001 20:30:58 -0800 (PST) Received: from agony.busboom.org (24-25-200-53.san.rr.com [24.25.200.53]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14791 for ; Mon, 5 Feb 2001 20:30:57 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f164c2E27507; Mon, 5 Feb 2001 20:38:03 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 5 Feb 2001 20:38:02 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Greg FitzPatrick cc: ietf-calendar@imc.org, "Pregen@Egenconsulting. Com" , Bob Mahoney , =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= Subject: Re: The SKiCal extensions In-Reply-To: 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: On Tue, 30 Jan 2001, Greg FitzPatrick wrote: > It is our sincere hope that each of these will be accepted as an update to > RFC2445. If this happens then SKiCal and iCal will be identical! Even in > the event that this does not happen the comments and criticisms received > will be of great benefit in preparing the SKiCal draft for its last call. Greg, The model for sharing event information that you and your team have created is very impressive! The SkiCal additions definitly make iCal useful in a broader range of services, and will probably hasten its adoption in a wide audience. But, valuable are they are, I don't think these properties belong in rfc2445, for two reasons: 1) They are oriented towards a specific application -- public events -- so they are more specific that the rest of iCalendar. 2) They are extensions of a type we will probably see in the future. Adding them the the RFC will cost us the opportunity to create a more general method for incorporating additions The SkiCal properties are for a general set of public events, but they are still more specialized that the rest of iCalendar. Every meeting will have a UID and a DTSTART, but broad classes of meetings will never have a THINKS or PRICE -- like any TODO, JOURNAL, and most group meetings. This makes the SkiCal properties slightly non-cohesive, and suggest that they should be in their own specification. Note that you are proposing about 20 new properties, and the existing spec has 65 or so -- SkiCal is a 30% addition. That is a substantial change. SkiCal is a great idea, but I don't think it will be the only improvement on iCalendar. What happens when someone proposes extensions for project management? or the construction industry? If we are going to make iCalendar more useful to a specific application, we should take the time to create an extension mechanism. Here is an idea for such a mechanism: Property Name: EXTENSIONS Purpose: List extensions used in an object Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property Conformance: The property can be specified in an iCalendar object. Description: This property lists all of the prefixes for extension properties that are included in the object. For instance, the SkiCal properties all begin with "SKI-", and if any of them appear in the object, it must also have an EXTENSIONS property with the value "SKI" BEGIN:VCALENDAR VERSION:2.0 EXTENSIONS:SKI PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z DTEND:19970715T035959Z SUMMARY:Bastille Day Party SKI-LANGUE: English END:VEVENT END:VCALENDAR extensions = "EXTENSIONS" extenparam ":" text *("," text) CRLF extenparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" xparam) ) Then, we would also add REQUEST-STATUS values for "Success, ignored extensions properties" and maybe "Failure, unsupported extensions properties" Then, all future extensions, beginning with SkiCal, can have their own RFC. Implementors don't need to implement them all, and can accept or reject them as a group. And, if another group wants propose new standard extensions, there is a path to do it. I do want to see these properties incorporated into standard calendaring and scheduling applictions, but I much perfer they they be kept together as a unit and added to iCalendar as a group. I think that some extension mechanism would make iCalendar more robust while still permitting the SkiCal additions. eric. From owner-ietf-calendar@mail.imc.org Tue Feb 6 01:00:56 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26050 for ; Tue, 6 Feb 2001 01:00:56 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA15723 for ietf-calendar-bks; Mon, 5 Feb 2001 21:37:01 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA15719 for ; Mon, 5 Feb 2001 21:36:59 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id XAA05489 for ; Mon, 5 Feb 2001 23:18:07 -0600 From: "Shannon J. Clark" To: Subject: RE: The SKiCal extensions Date: Mon, 5 Feb 2001 23:43:09 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id VAA15723 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA26050 This sounds like a good proposal but a few questions. One - would it be attached to every object? (i.e. would you need to add this property to each vEvent, vToDo, vJournal etc inside of a vCalendar that has the extension? I can think of many situations where individual events might be added to a calendar from a different application - potentially one app which understands the Extensions, and another that does not. Two - Shouldn't we us a standard naming schema and reference for extensions (i.e. what defines SKI as an extension? Ideally it should probably use something akin to XML document definitions - if a given app doesn't understand it potentially the reference for it could be obtain across the network? This then also leads to the thought that extensions should probably also have a version attached to them (i.e. what happens if SKI is changed?) Three - What is the overall goal of adding many additional properties? Is it for individual users of applications? or for the software packages themselves? (i.e. is it for human organization or for electronic searches?) Many of the proposed criteria seem to fit into a vision of events being defined by a series of properties that can serve as restrictions for a search (i.e. is the event in English? does it cost less than X?) Does this standard propose a simple way to handle cases where events do not have the given extensions? Are all of the proposed properties optional? If optional, how frequently will they be utilized? If not utilized do they serve a useful purpose? My company is writing an application where in the future I certainly see a very useful role for many of the SKiCal proposals - however I am also concerned about how to exchange information between SKiCal systems and more general iCalendar systems - it seems that many of the SKiCal extensions (or additions to iCalendar) will be useful for some types of events - and will be used by certain types of users and under some situations, but for many general situations most if not all of the new properties will go unused. anyway, my immediate and quick response to Eric's suggestion - I think that an extension type system is a potentially good idea but needs some additional work. Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Eric Busboom Sent: Monday, February 05, 2001 10:38 PM To: Greg FitzPatrick Cc: ietf-calendar@imc.org; Pregen@Egenconsulting. Com; Bob Mahoney; Patrik Fältström Subject: Re: The SKiCal extensions On Tue, 30 Jan 2001, Greg FitzPatrick wrote: > It is our sincere hope that each of these will be accepted as an update to > RFC2445. If this happens then SKiCal and iCal will be identical! Even in > the event that this does not happen the comments and criticisms received > will be of great benefit in preparing the SKiCal draft for its last call. Greg, The model for sharing event information that you and your team have created is very impressive! The SkiCal additions definitly make iCal useful in a broader range of services, and will probably hasten its adoption in a wide audience. But, valuable are they are, I don't think these properties belong in rfc2445, for two reasons: 1) They are oriented towards a specific application -- public events -- so they are more specific that the rest of iCalendar. 2) They are extensions of a type we will probably see in the future. Adding them the the RFC will cost us the opportunity to create a more general method for incorporating additions The SkiCal properties are for a general set of public events, but they are still more specialized that the rest of iCalendar. Every meeting will have a UID and a DTSTART, but broad classes of meetings will never have a THINKS or PRICE -- like any TODO, JOURNAL, and most group meetings. This makes the SkiCal properties slightly non-cohesive, and suggest that they should be in their own specification. Note that you are proposing about 20 new properties, and the existing spec has 65 or so -- SkiCal is a 30% addition. That is a substantial change. SkiCal is a great idea, but I don't think it will be the only improvement on iCalendar. What happens when someone proposes extensions for project management? or the construction industry? If we are going to make iCalendar more useful to a specific application, we should take the time to create an extension mechanism. Here is an idea for such a mechanism: Property Name: EXTENSIONS Purpose: List extensions used in an object Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property Conformance: The property can be specified in an iCalendar object. Description: This property lists all of the prefixes for extension properties that are included in the object. For instance, the SkiCal properties all begin with "SKI-", and if any of them appear in the object, it must also have an EXTENSIONS property with the value "SKI" BEGIN:VCALENDAR VERSION:2.0 EXTENSIONS:SKI PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z DTEND:19970715T035959Z SUMMARY:Bastille Day Party SKI-LANGUE: English END:VEVENT END:VCALENDAR extensions = "EXTENSIONS" extenparam ":" text *("," text) CRLF extenparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" xparam) ) Then, we would also add REQUEST-STATUS values for "Success, ignored extensions properties" and maybe "Failure, unsupported extensions properties" Then, all future extensions, beginning with SkiCal, can have their own RFC. Implementors don't need to implement them all, and can accept or reject them as a group. And, if another group wants propose new standard extensions, there is a path to do it. I do want to see these properties incorporated into standard calendaring and scheduling applictions, but I much perfer they they be kept together as a unit and added to iCalendar as a group. I think that some extension mechanism would make iCalendar more robust while still permitting the SkiCal additions. eric. From owner-ietf-calendar@mail.imc.org Tue Feb 6 05:06:21 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10514 for ; Tue, 6 Feb 2001 05:06:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA17596 for ietf-calendar-bks; Tue, 6 Feb 2001 01:43:11 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA17586 for ; Tue, 6 Feb 2001 01:43:09 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id C057FB34F9; Tue, 6 Feb 2001 10:50:25 +0100 (CET) From: "Greg FitzPatrick" To: "Eric Busboom" Cc: , "Pregen@Egenconsulting. Com" , "Bob Mahoney" , =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= Subject: The SKiCal extensions Date: Tue, 6 Feb 2001 10:51:24 +0100 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.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Congratulations Eric! You just invented NAMESPACES :-) ... and no, that is not my only response, but it is going to take a few cups of coffee to put something together. Greg From owner-ietf-calendar@mail.imc.org Tue Feb 6 09:02:09 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14022 for ; Tue, 6 Feb 2001 09:02:09 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA07387 for ietf-calendar-bks; Tue, 6 Feb 2001 05:36:43 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07377 for ; Tue, 6 Feb 2001 05:36:39 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 8365DB34F9; Tue, 6 Feb 2001 14:43:39 +0100 (CET) From: "Greg FitzPatrick" To: "Shannon J. Clark" , Subject: SV: The SKiCal extensions - sorting theory Date: Tue, 6 Feb 2001 14:44:37 +0100 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.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Shannon wrote: ...Three - What is the overall goal of adding many additional properties? Is it for individual users of applications? or for the software packages themselves? (i.e. is it for human organization or for electronic searches?) Many of the proposed criteria seem to fit into a vision of events being defined by a series of properties that can serve as restrictions for a search (i.e. is the event in English? does it cost less than X?) Greg replies: I like this question. These are important points. Why do we do this? Why would we move certain types of information from the all encompassing basket of DESCRIPTION to little nooks and crannies of their own. Face it, anything you can say as the value of an extra property, can also be said in DESCRIPTION or briefly in SUMMARY. You can always say ---ex. 1 DESCRIPTION: to attend this get-together non-members must pay 50 French francs. DESCRIPTION: to participate you must have a valid certificate in XTL999. DESCRIPTION: The topic of the lecture will be Madonna. DESCRIPTION: 99 good reasons for joining our club; Reason #1 Because we care... ... Reason #99 Because we dare. --- or perhaps we should aggregate these since only one description can occur in a calendar object. ---ex 2. DESCRIPTION: to attend this get-together non-members must pay 50 French francs. Y you must have a valid certificate in XTL999. The topic of the lecture will be Madonna. There are 99 good reasons for joining our club; Reason #1 Because we care... ... Reason #99 Because we dare. --- Cutting this description up into specific nooks (properties) is called SORTING and giving each item their own type-name is called LABELING. There is only one reason to SORT and LABEL and that is to REUSE. You will not bother to sort anything you will never reuse (more than once that is - "save it or trash it", is also a sort). Traditional sorting is manual - you file some papers here and some there. HERE and THERE are usually little containers with LABELS on them. But also LAYOUT is sorting. The way information is presented (sorted out) on a screen or paper is crucial to our REUSE of that information. If we find that a gathering of objects which we intend for REUSE share significant commonalities we can create a DIRECTORY using salient commonalities as sort keys. All directories are SORTED. But the level of sorting as well as the amount of information included in a directory are dependent upon CIRCUMSTANCES. These CIRCUSTANCES are: The availability of information. The physical restraints of the publishing media. The existence, extent and scope of the commonalties identified. With these circumstances known, utilitarian calculus can then be used to determine the optimal granularity of the SORT. Benefit = (GAINS from USE) minus (effort expended) --- So far half-easy. We know that almost all public resources are publicized in one manner or another, that almost any publication notice makes use of the WHAT, WHERE and WHEN commonalities, though not in standardized formats and we believe that the Internet has removed many of the restraints of paper based publishing which would render this discussion irrelevant. But on the other hand we don't really know what "GAINS from USE" to expect. We assume that if there was a directory in which identical commodities where marked with their PRICE, users would use that information in making buying decisions. We assume that the same goes for the availability of parking and payment methods, languages spoken, restrictions, recommendations and so on, but since this sort of directory does not exist in more that a few isolated (and somewhat experimental) instances, it may seem to many resource publishers that the gains do not merit the effort. But we are not resource publishers. Nor are we tool makers. We are architects trying to create structures where resource publishers can comfortably move in and where tools can work effectively. I don't think this is a chicken-egg problem. I think we must go first and create infostructures. These infostructures are based on possibilities but also from pragmatics learned in pre-automated usage. We can not guarantee that these possibilities will be realized, but without the structures where are the possibilities? Initially this just might lead to better "layout" on a humanly readable page (that which Shannon refers to as human organization), but in the long run we are building infostructures for Shannon's "electronic searches". In the long run we expect that as extensive directories come into existence the use-value of automated searches for criteria such as those described in SKiCal will be significant. Finally though, I will make the same reservation here which I have made in the Semantic Web efforts in which I participate; Metadata is not the only solution. As the digitalized and networked contextual information base grows, it will be increasingly possible to "discover" specific answers in resource descriptions, even in the absence of specific tags. We need to strike a balance. At this moment, no one suggests eliminating the specific properties of iCal in favor of one big blob of text and no one suggests that every atomic grain of information needs its own markup tag. The answer is somewhere in between but take care - this is a moving target! From owner-ietf-calendar@mail.imc.org Tue Feb 6 10:27:01 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17948 for ; Tue, 6 Feb 2001 10:27:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA11750 for ietf-calendar-bks; Tue, 6 Feb 2001 06:49:47 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11745 for ; Tue, 6 Feb 2001 06:49:45 -0800 (PST) From: pregen@egenconsulting.com To: Eric Busboom Cc: Bob Mahoney , Greg FitzPatrick , ietf-calendar@imc.org, Patrik =?iso-8859-1?q?F=E4ltstr=F6m?= Subject: Re: The SKiCal extensions X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 6 Feb 2001 14:56:57 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/06/2001 09:57:05 AM, Serialize complete at 02/06/2001 09:57:05 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0036E4AA802569EB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0036E4AA802569EB_= Content-Type: text/plain; charset="us-ascii" Eric, I like your thoughts about the SKICAL extensions. They make a lot of sense. The way you put it, it does make more sense (especially since there are 20 entries) to do some sort of independent RFC. One of the reasons Greg posted the items to this list is to gain an acceptance for the fact that they do want to do these events and want to make sure they do not break iCalendar. As long as the draft makes sure that people understand they are extensions and may not work with other products if they do not fully implement iCalendar specs - then OK. Greg had posted a last call on his draft and wanted to make sure all the entries were worded appropriately so implementors could use them. Since there are several calendar implementors on this list, it is a perfect place for him to get feedback. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0036E4AA802569EB_= Content-Type: text/html; charset="us-ascii"
Eric, I like your thoughts about the SKICAL extensions.  They make a lot of sense.  The way you put it, it does make more sense (especially since there are 20 entries) to do some sort of independent RFC.  One of the reasons Greg posted the items to this list is to gain an acceptance for the fact that they do want to do these events and want to make sure they do not break iCalendar.  As long as the draft makes sure that people understand they are extensions and may not work with other products if they do not fully implement iCalendar specs - then OK.  Greg had posted a last call on his draft and wanted to make sure all the entries were worded appropriately so implementors could use them. Since there are several calendar implementors on this list, it is a perfect place for him to get feedback.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0036E4AA802569EB_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 6 10:45:51 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18804 for ; Tue, 6 Feb 2001 10:45:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA12507 for ietf-calendar-bks; Tue, 6 Feb 2001 07:16:11 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12498 for ; Tue, 6 Feb 2001 07:16:07 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 82AB3B34F9; Tue, 6 Feb 2001 16:23:24 +0100 (CET) From: "Greg FitzPatrick" To: "Eric Busboom" Cc: , "Pregen@Egenconsulting. Com" , "Bob Mahoney" , =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= Subject: SV: The SKiCal extensions - namespaces Date: Tue, 6 Feb 2001 16:24:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id HAA12507 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18804 Eric At the IETF in San Diego there where quite a few discussion within the applications area as to how to utilize namespaces and schemas. Personally I have had email discussions with Graham Klyne on how to approach this subject and Patrik Fältström and I once talked about it at a lunch. The cluster-modularity that the namespace-schema mechanism offers is undeniable. The problem so far seems to be coordination. Coordination seems to be a big problem. Why couldn't (for example) the date-time and recurrence rules of 2445 be coordinated with the date-time and recurrence rules of XML-Schemas? http://www.w3.org/TR/xmlschema-2/ Frank Dawson has some input on that perhaps? I just don't know where we could find the force to accomplish something like this. Since the semantics of SKiCal will also be published as a schema using XML syntax - it would be just wonderful if your Sword-of-Alexander suggestion was to gain ground, but also a bit perilous for us if it was to lead to diversion in the current discussions. Hopefully the ongoing SKiCal submissions are serving to enlighten. The ensuing discussions certainly do so for me. I don't think it is simply so that the SKiCal submissions as a group fall outside the basic 2445 framework. I think, for example, that the issue of dualism (the calendar object as a pointer versus the calendar object as a sovereign entity) should be resolved and many of the SKiCal properties address that problem. I think that the RECOMMENDED, REQUIRED and PROHIBITED properties certainly pertain to meetings as well as events. Actually I think all the properties and property parameters at least to some degree fall with in the business meeting model. On the other hand in conjecture with Shannon's mail, there is a valid point as to what extent automated discovery will be exercised on business meetings! And consequently to what extent application designers wish to offer this sort of extensibility. I surely hope that others will speak up on this namespace issue and I only wish there was a convenient method to cross post on this thread with the other groups within which the issue is being considered. Greg From owner-ietf-calendar@mail.imc.org Tue Feb 6 12:02:30 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22662 for ; Tue, 6 Feb 2001 12:02:29 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19819 for ietf-calendar-bks; Tue, 6 Feb 2001 08:40:38 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19815 for ; Tue, 6 Feb 2001 08:40:35 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f16GrZJ04593 for ; Tue, 6 Feb 2001 11:53:35 -0500 Message-ID: <3A802C0F.72126F5F@ecal.com> Date: Tue, 06 Feb 2001 11:53:35 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extensions - SKUID References: <3A7ED546.1464EC3B@ecal.com> <3A7F3A31.91C74A16@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id IAA19819 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA22662 Pär Lannerö wrote: > John Stracke wrote: > > How exactly do you expect guarantee that the SKUID will be the same across all > > SKiCal objects that describe the same resource? > > We cannot guarantee this. But it would be useful if one day all public > events and other resources (skisources) would have a globally unique id. Perhaps. But why can't it be called UID? > > If the resource's organizer does generate a > > SKUID, then they're probably publishing their own SKiCal object, so why would > > somebody else publish a different one? > > Well, most publishers of public calendars, since they are editors, want > to formulate the SUMMARY and DESCRIPTION using their own words (and > perhaps language). But this doesn't scale; with hundreds of thousands of events published per day, you just can't afford to edit their descriptions. A much more common scenario is one in which the description of the event is created by one person and then sent out via some sort of feed, which may be forwarded, amalgamated, or filtered, but is not subjected to any human scrutiny before it reaches the end users. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Due to circumstances beyond your control, you| |francis@ecal.com|are master of your fate, and captain of your | | |soul. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 6 12:36:08 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24396 for ; Tue, 6 Feb 2001 12:36:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20882 for ietf-calendar-bks; Tue, 6 Feb 2001 09:08:07 -0800 (PST) Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20878 for ; Tue, 6 Feb 2001 09:07:59 -0800 (PST) Received: from metamatrix.se (IDENT:pbb@[213.88.195.121]) by smtp.wineasy.se with ESMTP id f16HEw704698; Tue, 6 Feb 2001 18:14:58 +0100 Message-ID: <3A803125.578E1644@metamatrix.se> Date: Tue, 06 Feb 2001 18:15:17 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: SKiCal component property extensions - SKUID References: <3A7ED546.1464EC3B@ecal.com> <3A7F3A31.91C74A16@metamatrix.se> <3A802C0F.72126F5F@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id JAA20882 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA24396 John Stracke wrote: > > We cannot guarantee this. But it would be useful if one day all public > > events and other resources (skisources) would have a globally unique id. > > Perhaps. But why can't it be called UID? It could, but "UID" is already defined by 2445 to be a value automatically generated whenever a new iCalendar object is created. There is no ambition in 2445 to have one shared id between all calendar objects (in separate calendaring systems) which refer to the same real life event. Is there? > > > If the resource's organizer does generate a > > > SKUID, then they're probably publishing their own SKiCal object, so why would > > > somebody else publish a different one? > > > > Well, most publishers of public calendars, since they are editors, want > > to formulate the SUMMARY and DESCRIPTION using their own words (and > > perhaps language). > > But this doesn't scale; with hundreds of thousands of events published per day, you > just can't afford to edit their descriptions. Right, but not all calendars will keep hundreds of thousands of events per day. One calendar site could specialize in for example "wine related events in the London area". The editor of such a site will have his search engine find every such SKiCal object (using the metadata of SKiCal objects). He or she will probably be able to put his own wording to most of those events. /Pär From owner-ietf-calendar@mail.imc.org Tue Feb 6 16:04:51 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01899 for ; Tue, 6 Feb 2001 16:04:50 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA03086 for ietf-calendar-bks; Tue, 6 Feb 2001 12:41:08 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03082 for ; Tue, 6 Feb 2001 12:41:06 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id A4724B34FD; Tue, 6 Feb 2001 21:48:16 +0100 (CET) From: "Greg FitzPatrick" To: =?iso-8859-1?B?UORyIExhbm5lcvY=?= , "John Stracke" Cc: Subject: SV: SKiCal component property extensions - SKUID Date: Tue, 6 Feb 2001 21:49:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A803125.578E1644@metamatrix.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id MAA03086 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA01899 Both of you make good points in this discussion. I always think of the example of a comet sighting. Lets say that the Stracke-Lannerö comet is going to visible at a certain time in certain areas and that all sorts of infomediaries publish this as SKiCal objects . Well obviously nobody has the "right" or "ownership" to this event. So there can never be a single SKUID, though there might be one astronomical society that does this, there could just as well be none or many. This goes for all kinds of natural phenomena which find their way in to almanacs and calendars So we are going to have to live with multiple (or null) SKUIDs, but on the other hand it is quite conceivable that theatre chains and universities and sports organizations and what-have-you, including the organizers of meetings do implement a system of UIDs even if only within their own sphere. We need a placeholder for such useful and rigid designators. The present UID placeholder in 2445 was never meant for that function - and if we tried to use it as such, where would be put the UID for the calendar object itself? Once again; there are resources and there are descriptions of resources and these are separate entities. Greg John Stracke wrote: > > We cannot guarantee this. But it would be useful if one day all public > > events and other resources (skisources) would have a globally unique id. > > Perhaps. But why can't it be called UID? It could, but "UID" is already defined by 2445 to be a value automatically generated whenever a new iCalendar object is created. There is no ambition in 2445 to have one shared id between all calendar objects (in separate calendaring systems) which refer to the same real life event. Is there? > > > If the resource's organizer does generate a > > > SKUID, then they're probably publishing their own SKiCal object, so why would > > > somebody else publish a different one? > > > > Well, most publishers of public calendars, since they are editors, want > > to formulate the SUMMARY and DESCRIPTION using their own words (and > > perhaps language). > > But this doesn't scale; with hundreds of thousands of events published per day, you > just can't afford to edit their descriptions. Right, but not all calendars will keep hundreds of thousands of events per day. One calendar site could specialize in for example "wine related events in the London area". The editor of such a site will have his search engine find every such SKiCal object (using the metadata of SKiCal objects). He or she will probably be able to put his own wording to most of those events. /Pär From owner-ietf-calendar@mail.imc.org Tue Feb 6 16:13:11 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02119 for ; Tue, 6 Feb 2001 16:13:10 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA02956 for ietf-calendar-bks; Tue, 6 Feb 2001 12:39:36 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02952 for ; Tue, 6 Feb 2001 12:39:34 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA08972; Tue, 6 Feb 2001 15:46:20 -0500 Received: from steltor.com (cc-1106.int.cst.ca [192.168.1.105]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1KBJZPVF; Tue, 6 Feb 2001 15:45:30 -0500 Message-ID: <3A80628F.C3C25720@steltor.com> Date: Tue, 06 Feb 2001 15:46:07 -0500 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: Extensions To iCalendar [Was: Re: The SKiCal extensions] 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 Eric Busboom wrote: > Greg, > > The model for sharing event information that you and your team have > created is very impressive! The SkiCal additions definitly make iCal > useful in a broader range of services, and will probably hasten its > adoption in a wide audience. I agree. > > But, valuable are they are, I don't think these properties belong in > rfc2445, for two reasons: > > 1) They are oriented towards a specific application -- public > events -- so they are more specific that the rest of iCalendar. > > 2) They are extensions of a type we will probably see in the > future. Adding them the the RFC will cost us the opportunity to > create a more general method for incorporating additions > > The SkiCal properties are for a general set of public events, but they are > still more specialized that the rest of iCalendar. Every meeting will have > a UID and a DTSTART, but broad classes of meetings will never have a > THINKS or PRICE -- like any TODO, JOURNAL, and most group meetings. This > makes the SkiCal properties slightly non-cohesive, and suggest that they > should be in their own specification. > > Note that you are proposing about 20 new properties, and the existing spec > has 65 or so -- SkiCal is a 30% addition. That is a substantial change. Many people may want to add new properties and parameters to iCalendar. They may be industry, domain or even country specific. If we add all these extensions to iCalendar, it may grow to be hundreds of pages long. (It is already about 150 pages in length.) Furthermore, most implementors will probably not implement all properties. We will end up with people asking questions such as, does implementation A support properties X, Y, and Z? Asking which extensions are supported is much easier. Before adding new properties and parameters to iCalendar, we should try to solve the general questions that have been posed in this group recently. They include, Do we really need to worry about many people wanting to add new properties and parameters? Perhaps only Skical and one or two other sets of properties will need to be added. When does a new type of information need to go into a new property instead of in the DESCRIPTION or SUMMARY? This may be difficult to answer. What type of new properties should go into iCalendar? All? non- domain specific ones? What is the purpose of iCalendar? A repository of all properties? Basic properties? Fundamental properties? If we add all of them we may have the problems described above. If we do not add them all, we may run into problems with interoperability? Product A supports extensions X, Y, Z and product B supports extensions X, V, W ... If we choose to have all extensions in extension rfcs, then we need to evaluate each proposed property. We need to ask if it is domain specific or fundamental. For some properties it may be a difficult question to answer. For instance, is SKUID domain specific? Furthermore, people writing extensions must make sure that things they add are not already in or consistent with other extensions. What if extension A has a property that is very similar or identical to a property in extension B? How do other standards handle exceptions? (I believe Patrik mentioned SNMP.) I am sure others have encountered similar problems. How easy it is to add extensions to iCalendar? Eric had an idea to make it easily extensible. What mechanisms do other standards provide? If we do answer these questions, we should put the answers into iCalendar. If we decide to use extensions, we can have a section or appendix on how to create an extension to iCalendar. > > SkiCal is a great idea, but I don't think it will be the only improvement > on iCalendar. What happens when someone proposes extensions for project > management? or the construction industry? If we are going to make > iCalendar more useful to a specific application, we should take the time > to create an extension mechanism. I agree. I am leaning towards a well defined extension mechanism for iCalendar. George From owner-ietf-calendar@mail.imc.org Tue Feb 6 16:27:23 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02453 for ; Tue, 6 Feb 2001 16:27:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA03922 for ietf-calendar-bks; Tue, 6 Feb 2001 12:54:25 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03912 for ; Tue, 6 Feb 2001 12:54:23 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f16L7MJ05436 for ; Tue, 6 Feb 2001 16:07:23 -0500 Message-ID: <3A806789.9100E27C@ecal.com> Date: Tue, 06 Feb 2001 16:07:21 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SV: SKiCal component property extensions - SKUID 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 Greg FitzPatrick wrote: > The present > UID placeholder in 2445 was never meant for that function - and if we tried > to use it as such, where would be put the UID for the calendar object > itself? I don't think that UID *does* refer to the calendar object. If it did, it'd have to change on every iTIP message (or, at least, it couldn't be used in REFRESH messages). I think it refers to the event; the fact that there may be multiple UIDs referring to the same event is regrettable, but not fatal. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Your reality, sir, is lies & balderdash, and I| |francis@ecal.com|am pleased to say I have no grasp on it | | |whatsoever!" --Baron Munchausen | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 6 16:39:41 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02792 for ; Tue, 6 Feb 2001 16:39:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04101 for ietf-calendar-bks; Tue, 6 Feb 2001 12:56:59 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04095 for ; Tue, 6 Feb 2001 12:56:57 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f16L9wJ05458 for ; Tue, 6 Feb 2001 16:09:58 -0500 Message-ID: <3A806825.D858D556@ecal.com> Date: Tue, 06 Feb 2001 16:09:58 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extensions - SKUID References: <3A7ED546.1464EC3B@ecal.com> <3A7F3A31.91C74A16@metamatrix.se> <3A802C0F.72126F5F@ecal.com> <3A803125.578E1644@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id MAA04101 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA02792 Pär Lannerö wrote: > John Stracke wrote: > > > We cannot guarantee this. But it would be useful if one day all public > > > events and other resources (skisources) would have a globally unique id. > > > > Perhaps. But why can't it be called UID? > > It could, but "UID" is already defined by 2445 to be a value > automatically generated whenever a new iCalendar object is created. See my reply to Greg on why I think this definition of UID is wrong (I know it's what 2445 says, but then 2446 is inconsistent). > One calendar site could specialize in for example "wine related > events in the London area". The editor of such a site will have his > search engine find every such SKiCal object (using the metadata of > SKiCal objects). He or she will probably be able to put his own wording > to most of those events. Then he'll have to worry about copyright problems; he may well have permission to redistribute the data, but not to modify it. Far safer to annotate it with out-of-band comments. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Using strong crypto on the Internet is like | |francis@ecal.com|using an armored car to transport money from | | |someone living in a tent to someone living in a| | |cardboard box. | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 6 17:07:42 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03400 for ; Tue, 6 Feb 2001 17:07:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA06320 for ietf-calendar-bks; Tue, 6 Feb 2001 13:27:17 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06315 for ; Tue, 6 Feb 2001 13:27:15 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f16LZxw12255 for ; Tue, 6 Feb 2001 15:35:59 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Feb 2001 15:34:19 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS6RNN>; Tue, 6 Feb 2001 15:34:19 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FA78@daeis06nok> To: greg.fitzpatrick@metamatrix.se Cc: ietf-calendar@imc.org Subject: RE: The SKiCal extensions - namespaces Date: Tue, 6 Feb 2001 15:27:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The problem so far seems to be coordination. Coordination > seems to be a big > problem. Why couldn't (for example) the date-time and > recurrence rules of > 2445 be coordinated with the date-time and recurrence rules > of XML-Schemas? > Not sure the only problem is "coordination". There may have also been that old nemesis, "NIH" involved in this situation. The W3C group specing the Schema stuff DID know about the iCalendar work in this area. They chose to ignore it (my representative told me that they were made aware of the IETF CALSCH WG work in this area) and instead create their own schema for date and time. I am not certain that the Schemas spec will get wide spread usage. Common infrastructures such as SOAP might help, but there is a natural tendency in XML applications to just format the data as PCDATA and let the application handle data integrity (can't be enforced anyway in XML) and data type checking (where it matters the most). -- Frank From owner-ietf-calendar@mail.imc.org Tue Feb 6 17:48:29 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04168 for ; Tue, 6 Feb 2001 17:48:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09235 for ietf-calendar-bks; Tue, 6 Feb 2001 14:24:07 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09227 for ; Tue, 6 Feb 2001 14:24:01 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f16MVJg18696 for ; Tue, 6 Feb 2001 16:31:20 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Feb 2001 16:30:08 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1C0LCHYG>; Tue, 6 Feb 2001 16:24:59 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FA81@daeis06nok> To: eric@softwarestudio.org Cc: ietf-calendar@imc.org Subject: RE: The SKiCal extensions Date: Tue, 6 Feb 2001 16:23:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric: Good suggestion. I would like to take your extensions suggestion a step further. As iCalendar gains acceptance, there are bound to be many proposals broad "sets" of property extensions, such as the SKiCal work. As such, we need to be prepared to enable interoperability between different iCalendar implementations for different sets of these extensions. Your proposal would facilitate this. What we also would benefit from knowing what base iCalendar property sets are included. Adding registration of tags for the base version of iCalendar would be helpful too. For example: EXTENSIONS:RFC2445-BASIC,RFC2445-VEVENT,RFC2445-VTIMEZONE,SKICAL Additionally, would it be helpful to remoniker this property to recognize that you are exchanging the needed capabilities for parsing and processing the received iCalendar object? Maybe call it CAPABILITIES, instead of EXTENSIONS? -- Frank From owner-ietf-calendar@mail.imc.org Tue Feb 6 18:44:42 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04684 for ; Tue, 6 Feb 2001 18:44:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA11613 for ietf-calendar-bks; Tue, 6 Feb 2001 15:08:31 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11608 for ; Tue, 6 Feb 2001 15:08:29 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id QAA07460 for ; Tue, 6 Feb 2001 16:49:20 -0600 From: "Shannon J. Clark" Cc: Subject: RE: The SKiCal extensions Date: Tue, 6 Feb 2001 17:14:46 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <30F2DED23724D311902D0008C7EABAFB0361FA81@daeis06nok> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Frank, You bring up an good point which bears clarification. Will this feature be used as part of an exchange of information BETWEEN calendaring systems (perhaps should be considered as part of CAP?) - which already has a Capabilities property I think. Or should it be a characteristic of EACH individual object within an iCalendar system? I certainly think there is a valuable role for interactions between systems to include a progamatic method of identify expectations of those systems (i.e. similar to an HTML version registration of a given page to take a commonly used but rarely looked at example) - especially if the systems involved will be changing/expanding on a frequently basis, programs need to know what features they understand. Ideally in some cases there should be mechanism to expand a program's features without requiring a new program version to be written - i.e. if you can parse XML pages - you may be able to handle a "new" Document definition type by getting the standard from a documented location. To use an example that people have probably experienced, the ability of browsers to with some accuracy "get" new plugins - not always perfectly implemented, but a greatly valuable application. From am implementer's perspective however it is critical to know where extended capabilities will be referenced, and where they will be used. If they are attached to individual objects - which can be exchanged between systems, then perhaps they need to also be attached to the objects (though alternatively they could be attached to the communication - if all methods of communication could be handled) Just my 2 cents Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Frank.Dawson@nokia.com Sent: Tuesday, February 06, 2001 4:23 PM To: eric@softwarestudio.org Cc: ietf-calendar@imc.org Subject: RE: The SKiCal extensions Eric: Good suggestion. I would like to take your extensions suggestion a step further. As iCalendar gains acceptance, there are bound to be many proposals broad "sets" of property extensions, such as the SKiCal work. As such, we need to be prepared to enable interoperability between different iCalendar implementations for different sets of these extensions. Your proposal would facilitate this. What we also would benefit from knowing what base iCalendar property sets are included. Adding registration of tags for the base version of iCalendar would be helpful too. For example: EXTENSIONS:RFC2445-BASIC,RFC2445-VEVENT,RFC2445-VTIMEZONE,SKICAL Additionally, would it be helpful to remoniker this property to recognize that you are exchanging the needed capabilities for parsing and processing the received iCalendar object? Maybe call it CAPABILITIES, instead of EXTENSIONS? -- Frank From owner-ietf-calendar@mail.imc.org Tue Feb 6 18:49:21 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04763 for ; Tue, 6 Feb 2001 18:49:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA12814 for ietf-calendar-bks; Tue, 6 Feb 2001 15:24:34 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12807 for ; Tue, 6 Feb 2001 15:24:33 -0800 (PST) From: pregen@egenconsulting.com To: George Babics Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Extensions To iCalendar [Was: Re: The SKiCal extensions] X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 6 Feb 2001 23:31:49 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/06/2001 06:31:54 PM, Serialize complete at 02/06/2001 06:31:54 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006607ED802569EB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006607ED802569EB_= Content-Type: text/plain; charset="us-ascii" George, your comments on creating a well-defined extension process for iCalendar is just what we need to do. Any ideas, list? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 006607ED802569EB_= Content-Type: text/html; charset="us-ascii"
George, your comments on creating a well-defined extension process for iCalendar is just what we need to do.  Any ideas, list?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 006607ED802569EB_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 6 19:57:21 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05368 for ; Tue, 6 Feb 2001 19:57:20 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA15543 for ietf-calendar-bks; Tue, 6 Feb 2001 16:22:09 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15539 for ; Tue, 6 Feb 2001 16:22:07 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA07629 for ; Tue, 6 Feb 2001 18:02:37 -0600 From: "Shannon J. Clark" Cc: Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions] Date: Tue, 6 Feb 2001 18:28:04 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C0906A.8B4EBC20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C0906A.8B4EBC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A few thoughts: (I will use REQUIRED below not in the RFC 2445 context of required by all implementations, but in the sense of "inherently required by the object type") There are REQUIRED properties that nearly all instances of objects of a given type need - example a description (at least a short one), a date for a vEvent. I would postulate that this is very SMALL list and could represent the base set (probably smaller than even our current standard) Then for each CONTEXT of iCalendar implementation and use there are other properties that are more (and some that are less) useful. For example, in the public event context of the SKiCal context the entire set of properties about ATTENDEES, DELEGATES etc are fairly useless, and the simple property of LOCATION may not be sufficient. In reading over the current standards documents it is clear that a large part of the problem set they are solving is business meeting scheduling related - this is a large problem. I propose the following - we may want to consider this as another set to apply to our well-defined extension process should we develop one. This would allow (and the current standard does this to a degree with the large set of features that are "optional") for very efficient but basic implementations for general sets of the calendaring and scheduling problem, and more domain specific implementations for certain problem areas (such as business meeting scheduling, commercial service scheduling (doctor's offices for example), public event sharing, events not tied to time shares (such as possible events not yet fixed in time), and other domains not yet defined or publicly revealed. So, one route we may want to take is when considering this extension process look at the current standard as well as the proposed SKiCal and use these two domains as the first two possible extensions: a.. Business meetings (much of the current standard) b.. Public Events (SKiCal) It seems to me that there are problems that are very general (reoccurrence rules, timezone issues) and problems that are very problem specific (delegation and other attendee negotiations). Additionally there are "types" of objects which are fairly general (deadlines - "vToDos; scheduled by some time characteristic either date or time and date - vEvent) Other objects have been added to accommodate requirements (vUsers, vQueries, vJournals) of many applications. There are also many problems that are interrelated but specific - many types of events do not have a "Price" attached to them, for those that do internationalization issues such as currency need to be dealt with. We may want to formally recognize to some degree the difference between these types of properties - with an extension context of some type we may also be able to group and arrange properties in a way that is helpful BOTH to computer programs and humans. Hope this is helpful to everyone - I am trying to offer ideas and probing questions. Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of pregen@egenconsulting.com Sent: Tuesday, February 06, 2001 5:32 PM To: George Babics Cc: ietf-calendar@imc.org; owner-ietf-calendar@mail.imc.org Subject: Re: Extensions To iCalendar [Was: Re: The SKiCal extensions] George, your comments on creating a well-defined extension process for iCalendar is just what we need to do. Any ideas, list? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 ------=_NextPart_000_0027_01C0906A.8B4EBC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A few=20 thoughts:
 
(I = will use REQUIRED=20 below not in the RFC 2445 context of required by all implementations, = but in the=20 sense of "inherently required by the object type")
 
There = are=20 REQUIRED properties that nearly all instances of = objects of a=20 given type need - example a description (at least a short one), a date = for a=20 vEvent. I would postulate that this is very SMALL list and could = represent the=20 base set (probably smaller than even our current = standard)
 
Then = for each=20 CONTEXT of iCalendar implementation and use there are = other=20 properties that are more (and some that are less) useful. For example, = in the=20 public event context of the SKiCal context the entire set of properties = about=20 ATTENDEES, DELEGATES etc are fairly useless, and the simple property of = LOCATION=20 may not be sufficient.
 
In = reading over the=20 current standards documents it is clear that a large part of the problem = set=20 they are solving is business meeting scheduling related - this is a = large=20 problem. I propose the following - we may want to consider this as = another set=20 to apply to our well-defined extension process should we develop=20 one.
 
This = would allow=20 (and the current standard does this to a degree with the large set of = features=20 that are "optional") for very efficient but basic implementations for = general=20 sets of the calendaring and scheduling problem, and more domain specific = implementations for certain problem areas (such as business meeting = scheduling,=20 commercial service scheduling (doctor's offices for example), public = event=20 sharing, events not tied to time shares (such as possible events not yet = fixed=20 in time), and other domains not yet defined or publicly=20 revealed.
 
So, = one route we may=20 want to take is when considering this extension process look at the = current=20 standard as well as the proposed SKiCal and use these two domains as the = first=20 two possible extensions:
  •    =20 Business meetings (much of the current standard)
  •    =20 Public Events (SKiCal)
It = seems to me that=20 there are problems that are very general (reoccurrence rules, timezone = issues)=20 and problems that are very problem specific (delegation and other = attendee=20 negotiations). Additionally there are "types" of objects which are = fairly=20 general (deadlines - "vToDos; scheduled by some time characteristic = either date=20 or time and date - vEvent) Other objects have been added to accommodate=20 requirements (vUsers, vQueries, vJournals) of many=20 applications.
 
There = are also many=20 problems that are interrelated but specific - many types of events do = not have a=20 "Price" attached to them, for those that do internationalization issues = such as=20 currency need to be dealt with.
 
We may = want to=20 formally recognize to some degree the difference between these types of=20 properties - with an extension context of some type we may also be able = to group=20 and arrange properties in a way that is helpful BOTH to computer = programs and=20 humans.
 
Hope = this is helpful=20 to everyone - I am trying to offer ideas and probing=20 questions.
 
Shannon
 

Shannon J. Clark
CEO - JigZaw, = Inc
1.800.4.JIGZAW=20 (454.4929)
shannon@jigzaw.com
www.jigzaw.com=20

 
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of=20 pregen@egenconsulting.com
Sent: Tuesday, February 06, = 2001 5:32=20 PM
To: George Babics
Cc: ietf-calendar@imc.org;=20 owner-ietf-calendar@mail.imc.org
Subject: Re: Extensions To=20 iCalendar [Was: Re: The SKiCal = extensions]


George, your comments on creating a = well-defined=20 extension process for iCalendar is just what we need to do.  Any = ideas,=20 list?
___________________
Patricia Egen=20 = Consulting
www.egenconsulting.com
423-875-2652
<= /BODY> ------=_NextPart_000_0027_01C0906A.8B4EBC20-- From owner-ietf-calendar@mail.imc.org Tue Feb 6 20:04:24 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05501 for ; Tue, 6 Feb 2001 20:04:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16865 for ietf-calendar-bks; Tue, 6 Feb 2001 16:38:21 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16860 for ; Tue, 6 Feb 2001 16:38:19 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f170jdg07526 for ; Tue, 6 Feb 2001 18:45:39 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Feb 2001 18:45:01 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1C0LCJFB>; Tue, 6 Feb 2001 18:39:53 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FAA7@daeis06nok> To: shannon@jigzaw.com Cc: ietf-calendar@imc.org Subject: RE: The SKiCal extensions Date: Tue, 6 Feb 2001 18:38:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Will this feature be used as part of an exchange of > information BETWEEN > calendaring systems (perhaps should be considered as part of > CAP?) - which > already has a Capabilities property I think. The scope of the discussion was iCalendar; which doesn't have such a capability at present. From owner-ietf-calendar@mail.imc.org Tue Feb 6 20:05:39 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05517 for ; Tue, 6 Feb 2001 20:05:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16930 for ietf-calendar-bks; Tue, 6 Feb 2001 16:41:29 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16924 for ; Tue, 6 Feb 2001 16:41:18 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f170o3w19961 for ; Tue, 6 Feb 2001 18:50:03 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Feb 2001 18:48:38 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1C0LCJF7>; Tue, 6 Feb 2001 18:43:30 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FAA8@daeis06nok> To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions] Date: Tue, 6 Feb 2001 18:41:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0909E.C04F5130" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0909E.C04F5130 Content-Type: text/plain; charset="iso-8859-1" > George, your comments on creating a well-defined extension process for iCalendar is just what we need to do. Any ideas, list? Of course RFC 2445 does define a "process" for registering extensions (see section 7, I believe). It is based on the one defined for text/directory MIME type; which is based on the MIME media type registration process. Maybe you mean something different? -- Frank ------_=_NextPart_001_01C0909E.C04F5130 Content-Type: text/html; charset="iso-8859-1"
> George, your comments on creating a well-defined extension process for iCalendar is just what we need to do.  Any ideas, list?

Of course RFC 2445 does define a "process" for registering extensions (see section 7, I believe). It is based on the one defined for text/directory MIME type; which is based on the MIME media type registration process.
 
Maybe you mean something different?
 
-- Frank
------_=_NextPart_001_01C0909E.C04F5130-- From owner-ietf-calendar@mail.imc.org Tue Feb 6 20:45:23 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05980 for ; Tue, 6 Feb 2001 20:45:23 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA17741 for ietf-calendar-bks; Tue, 6 Feb 2001 17:22:58 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17735 for ; Tue, 6 Feb 2001 17:22:57 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f171UHg09617 for ; Tue, 6 Feb 2001 19:30:17 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 6 Feb 2001 19:30:17 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1C0LCJN6>; Tue, 6 Feb 2001 19:25:08 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions] Date: Tue, 6 Feb 2001 19:23:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C090A4.914EF100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C090A4.914EF100 Content-Type: text/plain; charset="iso-8859-1" Pat, The registration process scope is to be focused on just registering new properties and parameters and the lot. It doesn't have the scope of triaging what registered extensions would get put into a new version of iCalendar. You are correct. It appears that the discussion on the list was also highlighting the need to have the ability in a transferred iCalendar object to declare what capabilities are needed by the recipient's iCalendar processor. This would seem to be helpful, but only have experience with this capability as it was defined in the CGM and CGI graphics standards. Before volunteering, it is always prudent to understand the mission ;-) I still don't understand what we are saying the scope of the problem is. * RFC2445 has a formal registration process for iCalendar extensions. * Is there a need for a new way to identify sets of extensions? * Is there a need for declaring what extensions (or even base iCalendar features) are included in a given iCalendar object? * Would a disection of iCalendar into features aid interoperability testing? * Is there a need for defining a triage process for selecting which registered extensions get included in subsequent updates to the iCalendar standard? -- Frank Frank, I'm saying we must need a more well-defined extension when we have at least two areas where we need extensions made and there are comments regarding putting them in or out of RFC2445. That to me says maybe section 7 needs to be revisited. Are you volunteering?? ___________________ ------_=_NextPart_001_01C090A4.914EF100 Content-Type: text/html; charset="iso-8859-1"
Pat, The registration process scope is to be focused on just registering new properties and parameters and the lot. It doesn't have the scope of triaging what registered extensions would get put into a new version of iCalendar. You are correct.
 
It appears that the discussion on the list was also highlighting the need to have the ability in a transferred iCalendar object to declare what capabilities are needed by the recipient's iCalendar processor. This would seem to be helpful, but only have experience with this capability as it was defined in the CGM and CGI graphics standards.
 
Before volunteering, it is always prudent to understand the mission ;-) I still don't understand what we are saying the scope of the problem is.
 
* RFC2445 has a formal registration process for iCalendar extensions.
* Is there a need for a new way to identify sets of extensions?
* Is there a need for declaring what extensions (or even base iCalendar features) are included in a given iCalendar object?
* Would a disection of iCalendar into features aid interoperability testing?
* Is there a need for defining a triage process for selecting which registered extensions get included in subsequent updates to the iCalendar standard?
 
-- Frank
Frank, I'm saying we must need a more well-defined extension when we have at least two areas where we need extensions made and there are comments regarding putting them in or out of RFC2445.  That to me says maybe section 7 needs to be revisited.  Are you volunteering??
___________________
------_=_NextPart_001_01C090A4.914EF100-- From owner-ietf-calendar@mail.imc.org Tue Feb 6 20:46:28 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05998 for ; Tue, 6 Feb 2001 20:46:28 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA17519 for ietf-calendar-bks; Tue, 6 Feb 2001 17:13:26 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17515 for ; Tue, 6 Feb 2001 17:13:25 -0800 (PST) From: pregen@egenconsulting.com To: Frank.Dawson@nokia.com Cc: ietf-calendar@imc.org Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions] X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 7 Feb 2001 01:20:46 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/06/2001 08:20:46 PM, Serialize complete at 02/06/2001 08:20:46 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00700178802569EB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00700178802569EB_= Content-Type: text/plain; charset="us-ascii" Frank, I'm saying we must need a more well-defined extension when we have at least two areas where we need extensions made and there are comments regarding putting them in or out of RFC2445. That to me says maybe section 7 needs to be revisited. Are you volunteering?? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Frank.Dawson@nokia.com 02/07/01 12:41 AM To: pregen@egenconsulting.com cc: ietf-calendar@imc.org Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions] > George, your comments on creating a well-defined extension process for iCalendar is just what we need to do. Any ideas, list? Of course RFC 2445 does define a "process" for registering extensions (see section 7, I believe). It is based on the one defined for text/directory MIME type; which is based on the MIME media type registration process. Maybe you mean something different? -- Frank --=_alternative 00700178802569EB_= Content-Type: text/html; charset="us-ascii"
Frank, I'm saying we must need a more well-defined extension when we have at least two areas where we need extensions made and there are comments regarding putting them in or out of RFC2445.  That to me says maybe section 7 needs to be revisited.  Are you volunteering??
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Frank.Dawson@nokia.com

02/07/01 12:41 AM

       
        To:        pregen@egenconsulting.com
        cc:        ietf-calendar@imc.org
        Subject:        RE: Extensions To iCalendar [Was: Re: The SKiCal extensions]



> George, your comments on creating a well-defined extension process for iCalendar is just what we need to do.  Any ideas, list?

Of course RFC 2445 does define a "process" for registering extensions (see section 7, I believe). It is based on the one defined for text/directory MIME type; which is based on the MIME media type registration process.
 
Maybe you mean something different?
 
-- Frank

--=_alternative 00700178802569EB_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 7 09:28:43 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00105 for ; Wed, 7 Feb 2001 09:28:43 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA09714 for ietf-calendar-bks; Wed, 7 Feb 2001 05:46:51 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09710 for ; Wed, 7 Feb 2001 05:46:49 -0800 (PST) Received: from metaacer (unknown [193.14.119.80]) by ljudo.shortlist.se (Postfix) with SMTP id B4DEDB34FD; Wed, 7 Feb 2001 14:54:08 +0100 (CET) From: "Greg FitzPatrick" To: "John Stracke" , Subject: SKiCal component property extensions - SKUID - dualism Date: Wed, 7 Feb 2001 14:46:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A806789.9100E27C@ecal.com> 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: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id FAA09714 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00105 Ok, we have several discussions ongoing - I am not addressing extensibility in this note, but "dualism" I would really like to get some more comments on this. John feels that iCal as it stands can express dualism. The SkiCal group reached the conclusion that it can not and I think that Frank once explicitly said that there is no issue of dualism what so ever. I think he said, though I cant find that mail just now, that the calendar object IS the event and that there does not exist two separate identities. Since we feel that the iCal object is the pointer to an entity, we add properties for the identification of that entity. SKUID is only one of a group of proposed SKiCal extensions that are meant to solve that problem. We spent some long afternoons reviewing each 2445 property per se and asking ourselves does this property serve the calendar object, the entity being pointed to, or both. We found for example that DTSTART and DTEND points to the entity, while date/time created points back to the calendar object itself. Since the date/time created property is sorted under Change Management in 2445, I assume the authors reached the same conclusion. What is confusing is that a meeting could originate (be conceived) in an Calendar application or it could be conceived in some other method predating the Calendar object. For example, I assume that is how IETF meetings evolve. Now lets say that the IETF had their own non-iCal method for scheduling meetings, this may not be the case, but certainly all meetings are not planned in iCal applications - some are merely originated on pen and paper, but the attendees, having desktop and PDAs, will do there own scheduling on a personal or company basis in iCal applications. There will be "authorities" for the meetings and as subsequent calendar objects are created there will be "authorities" for these objects viz. ORGANIZER. To be able to describe this dualism we felt necessitated to create a new property as a place holder for the "organizer" of the actual meeting. We didn't want to "borrow" the ORGANIZER property for this purpose, since it serves a necessary function as it stands. Alas we wish that the ORGANIZER term had not been used in 2445, because we feel that PUBLISHER would have been more semantically apt. So we, after hair pulling semantics discussions, arrived at the property name; CONTROL. In a meeting (fictitious) meeting organized by Patrik Fältström, and where someone in my company made up a schedule for the employees attending, the calendar object could now reflect both "organizers" SUMMARY: A particular applications area meeting ORGANIZER;CN="Jenny Magnusson":MAILTO:jenny@metamatrix.se CONTROL;ROLE="Area Director";CN="Patrik Fältström":MAILTO:paf@ietf.org Or take the property RELATED-TO for example, as it is defined in 2445. "The property is used to represent a relationship or reference between one calendar component and another." So here again, how do we express that the event itself is related to another event? How do we say that? Our solution was to create a new property named PARTREL so that in a situation where a particular (smaller) meeting was being held at a particular (larger) conference the relationship of the two could be defined even if there was no calendar object for the larger conference itself. SUMMARY: SKiCal BOF PARTREL;RELTYPE=CHILD;CN=Joint W3C WAP Forum:<19990401T080045Z-F192713@w3.org or in reverse SUMMARY: Joint W3C-WAP Forum PARTREL;RELTYPE=PARENT;CN=SKiCal BOF:<19990402T012045Z-8j232l@skical.org Please understand that we are not out to increase the amount of properties, we are only interested in improving the functionality. BTW, this dualism discussion occurs everywhere infostructure architects tread. Dublin Core, for example, had to address the same problems, quite some time after their original spec was mapped out. Greg FitzPatrick wrote: > The present > UID placeholder in 2445 was never meant for that function - and if we tried > to use it as such, where would be put the UID for the calendar object > itself? John Stracke: I don't think that UID *does* refer to the calendar object. If it did, it'd have to change on every iTIP message (or, at least, it couldn't be used in REFRESH messages). I think it refers to the event; the fact that there may be multiple UIDs referring to the same event is regrettable, but not fatal. From owner-ietf-calendar@mail.imc.org Wed Feb 7 11:01:09 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02354 for ; Wed, 7 Feb 2001 11:01:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17485 for ietf-calendar-bks; Wed, 7 Feb 2001 07:32:56 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17478 for ; Wed, 7 Feb 2001 07:32:55 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17Fk1k07080 for ; Wed, 7 Feb 2001 10:46:01 -0500 Message-ID: <3A816DB9.586A668A@ecal.com> Date: Wed, 07 Feb 2001 10:46:01 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: The SKiCal extensions 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: > Ideally in some cases there should be > mechanism to expand a program's features without requiring a new program > version to be written - i.e. if you can parse XML pages - you may be able to > handle a "new" Document definition type by getting the standard from a > documented location. Not really; all the DTD can give you is the syntax. To extend the semantics you would have to... > To use an example that people have probably experienced, the ability of > browsers to with some accuracy "get" new plugins ...download code. This is amazingly insecure, and not something that the IETF can really standardize anyway, since the code you'd need would be highly implementation-specific. I suppose, if we had an extension mechanism, your implementor could provide a repository of plugins; when you saw an extension you didn't understand, you'd go check the repository. It would necessarily be a proprietary system, though. -- /===============================================================\ |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 Wed Feb 7 11:04:57 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02411 for ; Wed, 7 Feb 2001 11:04:56 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA17721 for ietf-calendar-bks; Wed, 7 Feb 2001 07:36:25 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17717 for ; Wed, 7 Feb 2001 07:36:24 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17FnUk07092 for ; Wed, 7 Feb 2001 10:49:30 -0500 Message-ID: <3A816E8A.2ECF659A@ecal.com> Date: Wed, 07 Feb 2001 10:49:30 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Extensions To iCalendar [Was: Re: The SKiCal extensions] References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> 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 Frank.Dawson@nokia.com wrote: > * Is there a need for a new way to identify sets of extensions? > * Is there a need for declaring what extensions (or even base > iCalendar features) are included in a given iCalendar object? Possibly not--after all, you can examine the iCalendar object to see what properties it uses. If you understand the extensions, you know what properties they use; if you don't understand the extensions, knowing their names won't help. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Vote for Ron, and nobody gets hurt! --actual | |francis@ecal.com|campaign poster from Chicago | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 7 11:05:10 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02422 for ; Wed, 7 Feb 2001 11:05:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17696 for ietf-calendar-bks; Wed, 7 Feb 2001 07:34:43 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17692 for ; Wed, 7 Feb 2001 07:34:42 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17Fllk07084 for ; Wed, 7 Feb 2001 10:47:47 -0500 Message-ID: <3A816E23.76EB0D68@ecal.com> Date: Wed, 07 Feb 2001 10:47:47 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Extensions To iCalendar [Was: Re: The SKiCal extensions] 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: (Side note: please don't post in HTML--especially not from Outlook Express [or any other MS implementation], since it generates illegal HTML that Netscape has trouble replying to.) > There are REQUIRED properties that nearly all instances of > objects of a given type need - example a description (at least > a short one), a date for a vEvent. A VEVENT that's intended for machine consumption (e.g., in something like cron) might well not have a description. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |They prayed for their fates to be quick, | |francis@ecal.com|painless, and, ideally, someone else's. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 7 11:05:53 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02477 for ; Wed, 7 Feb 2001 11:05:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA16937 for ietf-calendar-bks; Wed, 7 Feb 2001 07:29:32 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16929 for ; Wed, 7 Feb 2001 07:29:30 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17FgYk07072 for ; Wed, 7 Feb 2001 10:42:35 -0500 Message-ID: <3A816CEA.7A3AAF94@ecal.com> Date: Wed, 07 Feb 2001 10:42:34 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extensions - SKUID - dualism References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id HAA16937 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02477 Greg FitzPatrick wrote: > In a meeting (fictitious) meeting organized by Patrik Fältström, and where > someone in my company made up a schedule for the employees attending, the > calendar object could now reflect both "organizers" OK, yeah, this is a good example. Another would be a group of friends organizing a trip to, say, a concert. The concert was published with SKiCal; the friends want to use iTIP to coordinate; a reasonable approach might be to use iTIP had have the VEVENT contain the SKiCal extensions. The concert's identifier can't be used as the identifier in iTIP; what if two separate sets of friends invite me to join them at the same concert? So, most likely, you'd exchange iTIP messages whose VEVENTs were derived from the original SKiCal VEVENT; in particular, they'd share the same SKUID. -- /==============================================================\ |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 Wed Feb 7 12:35:19 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04461 for ; Wed, 7 Feb 2001 12:35:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23172 for ietf-calendar-bks; Wed, 7 Feb 2001 09:10:34 -0800 (PST) Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23168 for ; Wed, 7 Feb 2001 09:10:32 -0800 (PST) Received: from metamatrix.se (IDENT:pbb@[213.88.195.121]) by smtp.wineasy.se with ESMTP id f17HHGM02541 for ; Wed, 7 Feb 2001 18:17:16 +0100 Message-ID: <3A818330.15606335@metamatrix.se> Date: Wed, 07 Feb 2001 18:17:36 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Extensions To iCalendar References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id JAA23172 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA04461 John Stracke wrote: > Frank.Dawson@nokia.com wrote: > > * Is there a need for a new way to identify sets of extensions? > > > * Is there a need for declaring what extensions (or even base > > iCalendar features) are included in a given iCalendar object? > > Possibly not--after all, you can examine the iCalendar object to > see what properties it uses. If you understand the extensions, > you know what properties they use; if you don't understand the > extensions, knowing their names won't help. I believe it is a good idea to declare what extensions are included in a given iCalendar object. But just declaring the extension (identified by a prefix) might not be enough, since any 3 letter prefix could be used by more than one extension set. But if the prefix is associated with a uri (being, for example, the official url to an RFC specifying the extension), it will be easy for an application to know whether or not it understands the extension set. Based on Eric Busbooms earlier suggestion, and inspired by XML namespaces, I suggest we use something like this: ----------- Property Name: EXTENSION Purpose: Declare an extension set used in an object Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property Conformance: The property can be specified in an iCalendar object. Description: This property declares a prefix for extension properties that are included in the object. For instance, the SkiCal properties all begin with "EXT-SKI-", and if any of them appear in the object, it must also have an EXTENSION property with the value "SKI". Multiple EXTENSION properties can be used in the same iCalendar component. BEGIN:VCALENDAR VERSION:2.0 EXTENSION;URI="http://www.ietf.org/internet-drafts/draf t-many-ical-ski-03.txt":SKI PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z DTEND:19970715T035959Z SUMMARY:Bastille Day Party EXT-SKI-EVENT-LANGUAGE:fr END:VEVENT END:VCALENDAR extension = "EXTENSION" extenparam ":" text *("," text) CRLF extenparam = *( (";" uriparam) ; the following is optional, ; but MUST NOT occur more than once (";" xparam) ) ---------- Parameter Name: URI Purpose: To specify a URI identifier. Format Definition: The property parameter is defined by the following notation: uriparam = "URI" "=" DQUOTE uri DQUOTE Description: The parameter specifies a URI that points to a definition of a textual property value. ----------- Note that I put the "EXT-" prefix first, so that all domain specific extension properties can be easily identified as such. Should there be a restriction on the number of characters in a prefix? /Pär From owner-ietf-calendar@mail.imc.org Wed Feb 7 12:45:23 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04635 for ; Wed, 7 Feb 2001 12:45:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23344 for ietf-calendar-bks; Wed, 7 Feb 2001 09:18:10 -0800 (PST) Received: from firsttech.co.za ([195.75.131.143]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23339 for ; Wed, 7 Feb 2001 09:18:06 -0800 (PST) From: bigjoe@japan.com Received: from 1Cust31.tnt12.dfw5.da.uu.net_[63.44.237.31] ([63.44.237.31]) by firsttech.co.za with Microsoft SMTPSVC(5.0.2172.1); Wed, 7 Feb 2001 19:17:50 +0200 Received: from mail.zuellig.com by 1Cust31.tnt12.dfw5.da.uu.net with ESMTP; Wed, 07 Feb 2001 11:23:51 -0600 Message-ID: <00003759277e$00002a3d$00004598@mail.zuellig.com> To: Subject: Brand New E-Mail pager for FR-EE! 17816 Date: Wed, 07 Feb 2001 11:23:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: bigjoe@japan.com X-OriginalArrivalTime: 07 Feb 2001 17:17:51.0468 (UTC) FILETIME=[E69672C0:01C09129] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE! No long term contract From owner-ietf-calendar@mail.imc.org Wed Feb 7 12:59:18 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04981 for ; Wed, 7 Feb 2001 12:59:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23750 for ietf-calendar-bks; Wed, 7 Feb 2001 09:25:36 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23746 for ; Wed, 7 Feb 2001 09:25:34 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA17923 for ; Wed, 7 Feb 2001 12:32:28 -0500 Received: from pc152 (pc-152.CST.CA [193.77.49.137]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1KBJZSR8; Wed, 7 Feb 2001 12:31:38 -0500 Message-ID: <003d01c0912b$ed9e7520$89314dc1@cst.ca> From: "Graham Gilmore" To: References: <3A816CEA.7A3AAF94@ecal.com> Subject: Re: SKiCal component property extensions - SKUID - dualism Date: Wed, 7 Feb 2001 12:32:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 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: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id JAA23750 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA04981 ----- Original Message ----- From: "John Stracke" To: Sent: 07 February, 2001 10:42 Subject: Re: SKiCal component property extensions - SKUID - dualism > Greg FitzPatrick wrote: > > > In a meeting (fictitious) meeting organized by Patrik Fältström, and where > > someone in my company made up a schedule for the employees attending, the > > calendar object could now reflect both "organizers" > > OK, yeah, this is a good example. Another would be a group of friends > organizing a trip to, say, a concert. The concert was published with SKiCal; > the friends want to use iTIP to coordinate; a reasonable approach might be to > use iTIP had have the VEVENT contain the SKiCal extensions. The concert's > identifier can't be used as the identifier in iTIP; what if two separate sets > of friends invite me to join them at the same concert? So, most likely, you'd > exchange iTIP messages whose VEVENTs were derived from the original SKiCal > VEVENT; in particular, they'd share the same SKUID. > Isn't this type of tying-together of calendar objects the purpose of the RELATED-TO property? Graham Gilmore From owner-ietf-calendar@mail.imc.org Wed Feb 7 13:13:33 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05286 for ; Wed, 7 Feb 2001 13:13:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24482 for ietf-calendar-bks; Wed, 7 Feb 2001 09:38:50 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24475 for ; Wed, 7 Feb 2001 09:38:48 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA18077 for ; Wed, 7 Feb 2001 12:45:42 -0500 Received: from pc152 (pc-152.CST.CA [193.77.49.137]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1KBJZSTX; Wed, 7 Feb 2001 12:44:52 -0500 Message-ID: <005801c0912d$c7201be0$89314dc1@cst.ca> From: "Graham Gilmore" To: References: Subject: RFC 2445 contradiction [Was: Re: Extensions To iCalendar] Date: Wed, 7 Feb 2001 12:45:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 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 ----- Original Message ----- From: "Shannon J. Clark" Cc: Sent: 06 February, 2001 19:28 Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions] > A few thoughts: > > (I will use REQUIRED below not in the RFC 2445 context of required by > all implementations, but in the sense of "inherently required by the > object type") > > There are REQUIRED properties that nearly all instances of objects of a > given type need - example a description (at least a short one), a date > for a vEvent. I would postulate that this is very SMALL list and could > represent the base set (probably smaller than even our current standard) In spite of Shannon's disclaimer, I noted a contradiction in the RFC on the topic of REQUIRED properties in the VEVENT. I looked through the issues list (http://www.softwarestudio.org/iCal/2445Issues.html), and I didn't see it (though that doesn't mean it wasn't there :) : In section 4.6.1, describing the grammar for VEVENT components, the DTSTART property is listed as optional (in fact, none of the properties are required, according to the grammar). However, in section 4.8.2.4, the description of the DTSTART property clearly states: Within the "VEVENT" calendar component, this property defines the start date and time for the event. The property is REQUIRED in "VEVENT" calendar components. Obviously, both sections can't be correct. Which is it? I don't think it makes a lot of sense to publish a VEVENT without a start date, but as I understand it for some iTIP methods (such as cancelling an event) it isn't needed. Graham From owner-ietf-calendar@mail.imc.org Wed Feb 7 13:28:37 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05803 for ; Wed, 7 Feb 2001 13:28:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25525 for ietf-calendar-bks; Wed, 7 Feb 2001 10:04:28 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25520 for ; Wed, 7 Feb 2001 10:04:26 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17IHWk07499 for ; Wed, 7 Feb 2001 13:17:32 -0500 Message-ID: <3A81913C.1964572A@ecal.com> Date: Wed, 07 Feb 2001 13:17:32 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Extensions To iCalendar References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> <3A818330.15606335@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id KAA25525 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05803 Pär Lannerö wrote: > John Stracke wrote: > > If you understand the extensions, > > you know what properties they use; if you don't understand the > > extensions, knowing their names won't help. > > I believe it is a good idea to declare what extensions are included > in a given iCalendar object. Why? > But if the prefix is > associated with a uri (being, for example, the official url to an RFC > specifying the extension), it will be easy for an application to > know whether or not it understands the extension set. The application will know whether or not it understands the properties it sees--and that's more reliable than hoping that the sender specified the extension set correctly. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |I am destined to build a bridge to China out of| |francis@ecal.com|live sheep. | \================================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 7 14:06:45 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06677 for ; Wed, 7 Feb 2001 14:06:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA27177 for ietf-calendar-bks; Wed, 7 Feb 2001 10:29:24 -0800 (PST) Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27169 for ; Wed, 7 Feb 2001 10:29:22 -0800 (PST) Received: from metamatrix.se (IDENT:pbb@[213.88.195.121]) by smtp.wineasy.se with ESMTP id f17Iamr18213 for ; Wed, 7 Feb 2001 19:36:48 +0100 Message-ID: <3A8195D4.76C700EB@metamatrix.se> Date: Wed, 07 Feb 2001 19:37:08 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Extensions To iCalendar References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> <3A818330.15606335@metamatrix.se> <3A81913C.1964572A@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id KAA27177 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA06677 John Stracke wrote: > Pär Lannerö wrote: > > John Stracke wrote: > > > If you understand the extensions, > > > you know what properties they use; if you don't understand the > > > extensions, knowing their names won't help. > > > > I believe it is a good idea to declare what extensions are included > > in a given iCalendar object. > > Why? Because 1. Using X- properties will cause confusion whenever two vendors happen to use the same property name. 2. I don't want to wait for the next version of iCalendar before putting such vital information as price into a calendar object. (Without the "X-" an iCalendar object containing price information will be incompatible with existing iCalendar applications.) /Pär From owner-ietf-calendar@mail.imc.org Wed Feb 7 14:48:02 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07529 for ; Wed, 7 Feb 2001 14:48:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00585 for ietf-calendar-bks; Wed, 7 Feb 2001 11:20:09 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00545 for ; Wed, 7 Feb 2001 11:19:08 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 222A2B34FD; Wed, 7 Feb 2001 20:26:22 +0100 (CET) From: "Greg FitzPatrick" To: "John Stracke" , Subject: SV: Extensions To iCalendar Date: Wed, 7 Feb 2001 20:27:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3A81913C.1964572A@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit just in case, in the event, unlikely, that someone might not have these links: the namespace spec: http://www.w3.org/TR/1999/REC-xml-names-19990114/ the use of relative URI references in namespace declarations: http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html No the XML solution is not all in place, but the framework is clear. There will be XML documents - they will comply to the XML syntax There will be multiple namespaces which will guarantee uniqueness There will be schemas referenced by namespaces There will be constraints made on element- and attribute values through typing mechanisms expressed in the schemas I don't believe it is wrong to work for this sort of extensibility. I believe these avenues are open to us as well using mime-directory syntax and something like the EXTENSION property being discussed here. When John replies to Shannon as below, I think he is being a tad bit negative. We must plan for the future - yet make sure the present works. I think that is possible. We should be considering schemas and not DTDs. Furthermore, there are nuances of what an application can do. It can crash on, or bypass the syntactically incorrect It can bypass the syntactically correct yet semantically unknown. It can verify media type and size and make style sheet presentations with out semantic understanding - this is what XSL is all about or It can launch an atomic missile in the direction of Waikiki, after making an educated guess about some semantic meaning it just parsed. What kind of applications does your eCal corp make? :-) I think Shannon was giving plug-ins as an example not a cure. snip.. John replying to Shannon: Not really; all the DTD can give you is the syntax. To extend the semantics you would have to... > To use an example that people have probably experienced, the ability of > browsers to with some accuracy "get" new plugins ...download code. This is amazingly insecure, and not something that the IETF can really standardize anyway, since the code you'd need would be highly implementation-specific. I suppose, if we had an extension mechanism, your implementor could provide a repository of plugins; when you saw an extension you didn't understand, you'd go check the repository. It would necessarily be a proprietary system, though. From owner-ietf-calendar@mail.imc.org Wed Feb 7 15:13:32 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08103 for ; Wed, 7 Feb 2001 15:13:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01383 for ietf-calendar-bks; Wed, 7 Feb 2001 11:35:57 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01377 for ; Wed, 7 Feb 2001 11:35:54 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 5FC4AB34FD; Wed, 7 Feb 2001 20:43:15 +0100 (CET) From: "Greg FitzPatrick" To: "Graham Gilmore" , Subject: SV: SKiCal component property extensions - SKUID - dualism Date: Wed, 7 Feb 2001 20:44:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <003d01c0912b$ed9e7520$89314dc1@cst.ca> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id LAA01383 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA08103 Graham Gilmore wrote: Isn't this type of tying-together of calendar objects the purpose of the RELATED-TO property? Greg: I don't think so. RELATED-TO allows us to express a relationship between two calendar components, describing related yet different events. As I understand it RELATED-TO is our cure for iCal's "flat" structure. We can not nest events and therefore we "relate" them. But I think John meant this: Cal object 1 | | ---------- Event 1 (SKUID) | Cal object 2 Correct me if I am wrong John > Greg FitzPatrick wrote: > > > In a meeting (fictitious) meeting organized by Patrik Fältström, and where > > someone in my company made up a schedule for the employees attending, the > > calendar object could now reflect both "organizers" > > OK, yeah, this is a good example. Another would be a group of friends > organizing a trip to, say, a concert. The concert was published with SKiCal; > the friends want to use iTIP to coordinate; a reasonable approach might be to > use iTIP had have the VEVENT contain the SKiCal extensions. The concert's > identifier can't be used as the identifier in iTIP; what if two separate sets > of friends invite me to join them at the same concert? So, most likely, you'd > exchange iTIP messages whose VEVENTs were derived from the original SKiCal > VEVENT; in particular, they'd share the same SKUID. > From owner-ietf-calendar@mail.imc.org Wed Feb 7 15:24:58 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08232 for ; Wed, 7 Feb 2001 15:24:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02033 for ietf-calendar-bks; Wed, 7 Feb 2001 11:50:18 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02028 for ; Wed, 7 Feb 2001 11:50:18 -0800 (PST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA05335; Wed, 7 Feb 2001 11:57:25 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f17JvAe28130; Wed, 7 Feb 2001 11:57:10 -0800 (PST) Received: from [192.168.1.22] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA03358; Wed, 7 Feb 2001 11:57:01 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3A8195D4.76C700EB@metamatrix.se> References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> <3A818330.15606335@metamatrix.se> <3A81913C.1964572A@ecal.com> <3A8195D4.76C700EB@metamatrix.se> Date: Wed, 7 Feb 2001 20:39:44 +0100 To: =?iso-8859-1?Q?P=E4r?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Lanner=F6?= , ietf-calendar@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Extensions To iCalendar Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id LAA02033 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA08232 At 19.37 +0100 01-02-07, Pär Lannerö wrote: >Because >1. Using X- properties will cause confusion whenever two vendors happen >to use the same property name. X- properties should _NOT_ be treated as something that "work" on the global Internet for any definition of "work". I will not allow any RFC which specifies an attribute which have a name which starts with 'X-'. paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Wed Feb 7 15:27:20 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08257 for ; Wed, 7 Feb 2001 15:27:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02014 for ietf-calendar-bks; Wed, 7 Feb 2001 11:50:06 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02010 for ; Wed, 7 Feb 2001 11:50:05 -0800 (PST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA06635; Wed, 7 Feb 2001 11:57:10 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f17Juu819019; Wed, 7 Feb 2001 11:56:56 -0800 (PST) Received: from [192.168.1.22] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA03235; Wed, 7 Feb 2001 11:56:44 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3A818330.15606335@metamatrix.se> References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> <3A818330.15606335@metamatrix.se> Date: Wed, 7 Feb 2001 20:37:27 +0100 To: =?iso-8859-1?Q?P=E4r?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Lanner=F6?= , ietf-calendar@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Extensions To iCalendar Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id LAA02014 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA08257 At 18.17 +0100 01-02-07, Pär Lannerö wrote: >John Stracke wrote: >> Frank.Dawson@nokia.com wrote: >> > * Is there a need for a new way to identify sets of extensions? >> >> > * Is there a need for declaring what extensions (or even base >> > iCalendar features) are included in a given iCalendar object? >> >> Possibly not--after all, you can examine the iCalendar object to >> see what properties it uses. If you understand the extensions, >> you know what properties they use; if you don't understand the >> extensions, knowing their names won't help. > >I believe it is a good idea to declare what extensions are included >in a given iCalendar object. You might want to declare what extensions you use when you have basically a dialogue with someone else, and negotiating what extensions you can use when you produce an object. When the object is created, the name of the extensions are not necessary, as you can look at each individual part of the object and "read" the parts you understand. You have no way of getting the information in a different format. So, in whatever protocols you develop -- have lists of extensions. In the object itself, not necessary at all. See how ESMTP work for SMTP. paf From owner-ietf-calendar@mail.imc.org Wed Feb 7 15:53:38 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08545 for ; Wed, 7 Feb 2001 15:53:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA03001 for ietf-calendar-bks; Wed, 7 Feb 2001 12:20:32 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02994 for ; Wed, 7 Feb 2001 12:20:27 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17KXYk08017 for ; Wed, 7 Feb 2001 15:33:34 -0500 Message-ID: <3A81B11D.31F38209@ecal.com> Date: Wed, 07 Feb 2001 15:33:33 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SV: SKiCal component property extensions - SKUID - dualism 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 Greg FitzPatrick wrote: > But I think John meant this: > > Cal object 1 > | > | ---------- Event 1 (SKUID) > | > Cal object 2 > > Correct me if I am wrong John Uh...not sure. All I meant was that the event in the iTIP conversation could start out as a copy of the SKiCal VEVENT, just as the event in a current iTIP conversation starts out as a copy of a base iCalendar VEVENT. The VEVENT in a REQUEST, for example, would have the various SKiCal extensions. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"You're nothing but a pack of ringleaders!" | |francis@ecal.com|--_Wyrd Sisters_, Terry Pratchett | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 7 15:55:05 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08595 for ; Wed, 7 Feb 2001 15:55:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA03029 for ietf-calendar-bks; Wed, 7 Feb 2001 12:21:25 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03021 for ; Wed, 7 Feb 2001 12:21:23 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17KYUk08021 for ; Wed, 7 Feb 2001 15:34:30 -0500 Message-ID: <3A81B156.38528CDD@ecal.com> Date: Wed, 07 Feb 2001 15:34:30 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Extensions To iCalendar References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> <3A818330.15606335@metamatrix.se> <3A81913C.1964572A@ecal.com> <3A8195D4.76C700EB@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id MAA03029 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA08595 Pär Lannerö wrote: > John Stracke wrote: > > Pär Lannerö wrote: > > > > I believe it is a good idea to declare what extensions are included > > > in a given iCalendar object. > > > > Why? > > Because > 1. Using X- properties will cause confusion whenever two vendors happen > to use the same property name. > 2. I don't want to wait for the next version of iCalendar before putting > such vital information as price into a calendar object. That's why we have the property registration process, defined in section 7.2 of 2445. -- /================================================================\ |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 Wed Feb 7 15:59:50 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08648 for ; Wed, 7 Feb 2001 15:59:49 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA03202 for ietf-calendar-bks; Wed, 7 Feb 2001 12:31:07 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03198 for ; Wed, 7 Feb 2001 12:31:06 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA09659 for ; Wed, 7 Feb 2001 14:11:38 -0600 From: "Shannon J. Clark" To: Subject: RE: Extensions To iCalendar Date: Wed, 7 Feb 2001 14:37:30 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for the links Greg, saves me looking for them. I intended plug-ins as an example - yes it involves executable code, but not all such examples need to require executable code, frequently a data-only download can extend functionality in many way, XML in theory being a good example of this. Greg's discussion of applications does raise an interesting point - syntax correctness vs. semantic understanding. It could be a useful way of looking at properties to consider those that REQUIRE a program to understand semantics as well as syntax vs. those that may be used by an application with no semantical understanding. An example of something that requires semantic understanding would be reoccurrence rules - these are an encapsulation of an algorithm and are intended for the application to parse and act upon. Date fields are probably another example. Most of the "description" related fields are not required that a semantical understanding be present - Description, etc are not acted upon by the application - but are "merely" displayed in some manner (perhaps mapped into an application specific location) What of the existing (or proposed) fields REQUIRE semantical understanding by applications? Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Greg FitzPatrick Sent: Wednesday, February 07, 2001 1:27 PM To: John Stracke; ietf-calendar@imc.org Subject: SV: Extensions To iCalendar just in case, in the event, unlikely, that someone might not have these links: the namespace spec: http://www.w3.org/TR/1999/REC-xml-names-19990114/ the use of relative URI references in namespace declarations: http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html No the XML solution is not all in place, but the framework is clear. There will be XML documents - they will comply to the XML syntax There will be multiple namespaces which will guarantee uniqueness There will be schemas referenced by namespaces There will be constraints made on element- and attribute values through typing mechanisms expressed in the schemas I don't believe it is wrong to work for this sort of extensibility. I believe these avenues are open to us as well using mime-directory syntax and something like the EXTENSION property being discussed here. When John replies to Shannon as below, I think he is being a tad bit negative. We must plan for the future - yet make sure the present works. I think that is possible. We should be considering schemas and not DTDs. Furthermore, there are nuances of what an application can do. It can crash on, or bypass the syntactically incorrect It can bypass the syntactically correct yet semantically unknown. It can verify media type and size and make style sheet presentations with out semantic understanding - this is what XSL is all about or It can launch an atomic missile in the direction of Waikiki, after making an educated guess about some semantic meaning it just parsed. What kind of applications does your eCal corp make? :-) I think Shannon was giving plug-ins as an example not a cure. snip.. John replying to Shannon: Not really; all the DTD can give you is the syntax. To extend the semantics you would have to... > To use an example that people have probably experienced, the ability of > browsers to with some accuracy "get" new plugins ...download code. This is amazingly insecure, and not something that the IETF can really standardize anyway, since the code you'd need would be highly implementation-specific. I suppose, if we had an extension mechanism, your implementor could provide a repository of plugins; when you saw an extension you didn't understand, you'd go check the repository. It would necessarily be a proprietary system, though. From owner-ietf-calendar@mail.imc.org Wed Feb 7 16:06:31 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08756 for ; Wed, 7 Feb 2001 16:06:30 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA03238 for ietf-calendar-bks; Wed, 7 Feb 2001 12:32:53 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03233 for ; Wed, 7 Feb 2001 12:32:51 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17Kjwk08066 for ; Wed, 7 Feb 2001 15:45:59 -0500 Message-ID: <3A81B406.7545989F@ecal.com> Date: Wed, 07 Feb 2001 15:45:58 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SV: Extensions To iCalendar 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 Greg FitzPatrick wrote: > When John replies to Shannon as below, I think he is being a tad bit > negative. No, I'm being realistic. The only way to specify semantics to an implementation is in code. You might come up with some sort of pseudocode that lets you specify semantics without sending around object code; but it's still code. If it's useful, it's dangerous. > We should be considering schemas and not DTDs. Schemas are still just syntax. This is not to say that we shouldn't have an extension mechanism; it's just that we need to make sure we don't run down a blind alley trying to have it permit applications to be upgraded on the fly. -- /================================================================\ |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 Wed Feb 7 16:30:55 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09381 for ; Wed, 7 Feb 2001 16:30:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA04548 for ietf-calendar-bks; Wed, 7 Feb 2001 13:00:57 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04543 for ; Wed, 7 Feb 2001 13:00:55 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA09774 for ; Wed, 7 Feb 2001 14:41:27 -0600 From: "Shannon J. Clark" To: Subject: RE: Extensions To iCalendar Date: Wed, 7 Feb 2001 15:07:20 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id NAA04548 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA09381 Just a quick note for clarification, This then requires that there is a standard way to NAME all properties and clearly handle unknown properties (currently an application has to "know" about all properties that do not start with X- ) So, are we suggesting that in addition the X- property names that there is also an EXT- property name standard, sets of which are defined by extensions in some manner, and which individual applications will have to ignore or not if they understand that extension or not. thanks, Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Patrik Fältström Sent: Wednesday, February 07, 2001 1:37 PM To: Pär Lannerö; ietf-calendar@imc.org Subject: Re: Extensions To iCalendar At 18.17 +0100 01-02-07, Pär Lannerö wrote: >John Stracke wrote: >> Frank.Dawson@nokia.com wrote: >> > * Is there a need for a new way to identify sets of extensions? >> >> > * Is there a need for declaring what extensions (or even base >> > iCalendar features) are included in a given iCalendar object? >> >> Possibly not--after all, you can examine the iCalendar object to >> see what properties it uses. If you understand the extensions, >> you know what properties they use; if you don't understand the >> extensions, knowing their names won't help. > >I believe it is a good idea to declare what extensions are included >in a given iCalendar object. You might want to declare what extensions you use when you have basically a dialogue with someone else, and negotiating what extensions you can use when you produce an object. When the object is created, the name of the extensions are not necessary, as you can look at each individual part of the object and "read" the parts you understand. You have no way of getting the information in a different format. So, in whatever protocols you develop -- have lists of extensions. In the object itself, not necessary at all. See how ESMTP work for SMTP. paf From owner-ietf-calendar@mail.imc.org Wed Feb 7 16:39:50 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09521 for ; Wed, 7 Feb 2001 16:39:50 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA04960 for ietf-calendar-bks; Wed, 7 Feb 2001 13:05:27 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04954 for ; Wed, 7 Feb 2001 13:05:26 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f17LCog24206 for ; Wed, 7 Feb 2001 15:12:50 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Feb 2001 15:12:50 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS6837>; Wed, 7 Feb 2001 15:12:49 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FAE3@daeis06nok> To: francis@ecal.com, ietf-calendar@imc.org Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions] Date: Wed, 7 Feb 2001 15:05:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > * Is there a need for a new way to identify sets of extensions? > > > * Is there a need for declaring what extensions (or even base > > iCalendar features) are included in a given iCalendar object? > > Possibly not--after all, you can examine the iCalendar object to > see what properties it uses. If you understand the extensions, > you know what properties they use; if you don't understand the > extensions, knowing their names won't help. Good points that you and Patrik made. From owner-ietf-calendar@mail.imc.org Wed Feb 7 16:41:24 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09555 for ; Wed, 7 Feb 2001 16:41:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05604 for ietf-calendar-bks; Wed, 7 Feb 2001 13:12:08 -0800 (PST) Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05599 for ; Wed, 7 Feb 2001 13:12:07 -0800 (PST) Received: from metamatrix.se (IDENT:pbb@[213.88.195.121]) by smtp.wineasy.se with ESMTP id f17LJZ513072 for ; Wed, 7 Feb 2001 22:19:35 +0100 Message-ID: <3A81BBF9.A02B60E2@metamatrix.se> Date: Wed, 07 Feb 2001 22:19:53 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Extensions To iCalendar References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> <3A818330.15606335@metamatrix.se> <3A81913C.1964572A@ecal.com> <3A8195D4.76C700EB@metamatrix.se> <3A81B156.38528CDD@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id NAA05604 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA09555 John Stracke wrote: > Pär Lannerö wrote: > > John Stracke wrote: > > > Pär Lannerö wrote: > > > > I believe it is a good idea to declare what extensions are included > > > > in a given iCalendar object. > > > Why? > > Because > > 1. Using X- properties will cause confusion whenever two vendors happen > > to use the same property name. > > 2. I don't want to wait for the next version of iCalendar before putting > > such vital information as price into a calendar object. > > That's why we have the property registration process, defined in section > 7.2 of 2445. Most iCalendar implementations seem to reject any iCalendar object containing a property unknown to them. Therefore, anybody who whishes to use a newly registered property will have to wait until most parties he wants to communicate with have upgraded their software. (To a version with support for the current list of IANA tokens.) This is why I do not want to depend on the IANA registration process. Maybe I have made a wrong assumption somewhere? /Pär From owner-ietf-calendar@mail.imc.org Wed Feb 7 17:17:19 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10106 for ; Wed, 7 Feb 2001 17:17:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA07420 for ietf-calendar-bks; Wed, 7 Feb 2001 13:41:51 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07416 for ; Wed, 7 Feb 2001 13:41:49 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17Lsuk08408 for ; Wed, 7 Feb 2001 16:54:56 -0500 Message-ID: <3A81C42F.368D4763@ecal.com> Date: Wed, 07 Feb 2001 16:54:56 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Extensions To iCalendar References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> <3A818330.15606335@metamatrix.se> <3A81913C.1964572A@ecal.com> <3A8195D4.76C700EB@metamatrix.se> <3A81B156.38528CDD@ecal.com> <3A81BBF9.A02B60E2@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id NAA07420 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA10106 Pär Lannerö wrote: > > That's why we have the property registration process, defined in section > > 7.2 of 2445. > > Most iCalendar implementations seem to reject any iCalendar object > containing a property unknown to them. Then they're broken. Anybody who writes an iCalendar implementation should keep in mind the "iana-token" clauses all through the ABNF; since the implementation can't know what tokens the IANA has registered, it has to ignore any values that it doesn't understand. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Any sufficiently rigged demo is | |francis@ecal.com|indistinguishable from advanced technology. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 7 17:31:15 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10348 for ; Wed, 7 Feb 2001 17:31:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08624 for ietf-calendar-bks; Wed, 7 Feb 2001 14:03:37 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08615 for ; Wed, 7 Feb 2001 14:03:35 -0800 (PST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA21236; Wed, 7 Feb 2001 14:10:42 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f17MAX928727; Wed, 7 Feb 2001 14:10:33 -0800 (PST) Received: from [192.168.1.22] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA28804; Wed, 7 Feb 2001 14:10:23 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3A81BBF9.A02B60E2@metamatrix.se> References: <30F2DED23724D311902D0008C7EABAFB0361FAB0@daeis06nok> <3A816E8A.2ECF659A@ecal.com> <3A818330.15606335@metamatrix.se> <3A81913C.1964572A@ecal.com> <3A8195D4.76C700EB@metamatrix.se> <3A81B156.38528CDD@ecal.com> <3A81BBF9.A02B60E2@metamatrix.se> Date: Wed, 7 Feb 2001 23:06:13 +0100 To: =?iso-8859-1?Q?P=E4r?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Lanner=F6?= , ietf-calendar@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Extensions To iCalendar Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id OAA08624 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA10348 At 22.19 +0100 01-02-07, Pär Lannerö wrote: >Most iCalendar implementations seem to reject any iCalendar object >containing a property unknown to them. This seems to be an excellent thing to test at an interoperability test. Has this not been tested before? What do the RFC(s) say about unknown properties? What is the recommended action? paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Wed Feb 7 18:10:53 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11887 for ; Wed, 7 Feb 2001 18:10:52 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA11312 for ietf-calendar-bks; Wed, 7 Feb 2001 14:46:19 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11302 for ; Wed, 7 Feb 2001 14:46:17 -0800 (PST) From: pregen@egenconsulting.com To: Patrik =?iso-8859-1?q?F=E4ltstr=F6m?= Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, =?iso-8859-1?q?P=E4r_Lanner=F6?= Subject: Re: Extensions To iCalendar X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 7 Feb 2001 22:53:44 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/07/2001 05:53:43 PM, Serialize complete at 02/07/2001 05:53:43 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00628CA3802569EC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00628CA3802569EC_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Patrik, I'm not sure this exact thing was tested. I am putting it on the=20 Testing page for CalConnect2 =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 Patrik F=E4ltstr=F6m Sent by: owner-ietf-calendar@mail.imc.org 02/07/01 10:06 PM =20 To: P=E4r Lanner=F6 , ietf-calendar@= imc.org cc:=20 Subject: Re: Extensions To iCalendar At 22.19 +0100 01-02-07, P=E4r Lanner=F6 wrote: >Most iCalendar implementations seem to reject any iCalendar object >containing a property unknown to them. This seems to be an excellent thing to test at an interoperability=20 test. Has this not been tested before? What do the RFC(s) say about unknown properties? What is the=20 recommended action? paf --=20 Patrik F=E4ltstr=F6m Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC --=_alternative 00628CA3802569EC_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Patrik, I'm not sure this exact thin= g was tested.  I am putting it on the Testing page for CalConnect2
=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


Patrik F=E4ltstr=F6m <paf@cisc= o.com>
Sent by: owner-ietf-calendar@mail.im= c.org

02/07/01 10:06 PM

       
        To: &nbs= p;      P=E4r Lanner=F6 <par.lannero@metamatrix.se>, i= etf-calendar@imc.org
        cc: &nbs= p;      
        Subject:=        Re: Extensions To iCalendar



At 22.19 +0100 01-02-07, P=E4r Lanner=F6 wrote:
>Most iCalendar implementations seem to reject any iCalendar object
>containing a property unknown to them.

This seems to be an excellent thing to test at an interoperability
test. Has this not been tested before?

What do the RFC(s) say about unknown properties? What is the
recommended action?

   paf


--
Patrik F=E4ltstr=F6m <paf@cisco.com>       Internet En= gineering Task Force
Area Director, Applications Area             =       http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (= San Jose) +1-408-525-0940
       PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 5= 1D9 7D25 B8DC

--=_alternative 00628CA3802569EC_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 7 19:29:35 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12899 for ; Wed, 7 Feb 2001 19:29:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA15428 for ietf-calendar-bks; Wed, 7 Feb 2001 16:05:29 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15422 for ; Wed, 7 Feb 2001 16:05:27 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f180Cng11347 for ; Wed, 7 Feb 2001 18:12:49 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Feb 2001 18:12:37 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS605T>; Wed, 7 Feb 2001 18:12:37 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FAF9@daeis06nok> To: francis@ecal.com, ietf-calendar@imc.org Subject: RE: Extensions To iCalendar Date: Wed, 7 Feb 2001 18:05:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Agree with John! Also the "X-token" or whatever the ABNF calls them are also in the grammar for conformance. I am also not certain that "most" implementations gag on this situation. Pat and Patrik are right-on in suggesting that we make sure that this is a test case for the CalConnects. > Then they're broken. Anybody who writes an iCalendar > implementation should > keep in mind the "iana-token" clauses all through the ABNF; since the > implementation can't know what tokens the IANA has > registered, it has to ignore > any values that it doesn't understand. From owner-ietf-calendar@mail.imc.org Thu Feb 8 15:10:48 2001 Received: from ns.secondary.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18468 for ; Thu, 8 Feb 2001 15:10:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA08580 for ietf-calendar-bks; Thu, 8 Feb 2001 11:40:05 -0800 (PST) Received: from agony.busboom.org (24-25-200-53.san.rr.com [24.25.200.53]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08574 for ; Thu, 8 Feb 2001 11:40:03 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f18JlRn13394; Thu, 8 Feb 2001 11:47:28 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 8 Feb 2001 11:47:27 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Graham Gilmore cc: ietf-calendar@imc.org Subject: Re: RFC 2445 contradiction [Was: Re: Extensions To iCalendar] In-Reply-To: <005801c0912d$c7201be0$89314dc1@cst.ca> 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: On Wed, 7 Feb 2001, Graham Gilmore wrote: > Obviously, both sections can't be correct. Which is it? I don't > think it makes a lot of sense to publish a VEVENT without a start > date, but as I understand it for some iTIP methods (such as cancelling > an event) it isn't needed. The broader question is: why do we have this kind of text in RFC2445? Shouldn't the association between properties and components be left solely to RFC2446? Would there be any detriment to removing the ABNF for the components and the "Conformance" sections for the Properties? It seems that both of these sections are redundant with RFC2446. As an implementer, I ignored both sections in RFC2445 and only used RFC2446. eric. From owner-ietf-calendar@mail.imc.org Thu Feb 8 16:25:59 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 QAA20012 for ; Thu, 8 Feb 2001 16:25:58 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA01697 for ietf-calendar-bks; Thu, 8 Feb 2001 13:04:12 -0800 (PST) Received: from web12604.mail.yahoo.com (web12604.mail.yahoo.com [216.136.173.227]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA01689 for ; Thu, 8 Feb 2001 13:04:10 -0800 (PST) Message-ID: <20010208210405.98220.qmail@web12604.mail.yahoo.com> Received: from [195.92.67.87] by web12604.mail.yahoo.com; Thu, 08 Feb 2001 21:04:05 GMT Date: Thu, 8 Feb 2001 21:04:05 +0000 (GMT) From: =?iso-8859-1?q?Andrew=20Proud?= Subject: MS Outlook To: ietf-calendar@imc.org MIME-Version: 1.0 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 Hi Firstly can I ask if there is a separate mailing group for problems people are encountering during projects that make use of I/VCalendar files ? I realise this list is probably not the correct forum for my problem. The Problem. When Double clicking on a 'Multi Event' .ics file after a standard MS Office 2000 install only 1 of the events is imported into the Calendar. However when performing 'File-Import' from the menu all events are imported correctly. Does anybody know if there is a fix for this ? Is it a bug ? All help will be greatfully received. Andy ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From owner-ietf-calendar@mail.imc.org Thu Feb 8 19:12:10 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 TAA21750 for ; Thu, 8 Feb 2001 19:12:10 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id PAA10503 for ietf-calendar-bks; Thu, 8 Feb 2001 15:41:53 -0800 (PST) Received: from smtp2.home.se (smtphost5.home.se [195.66.35.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA10499 for ; Thu, 8 Feb 2001 15:41:50 -0800 (PST) Received: from metamatrix.se [212.75.66.66] by smtp1.home.se with Novonyx SMTP Server $Revision: 2.74 $; Fri, 09 Feb 2001 00:39:47 +0100 (ECTD) Message-ID: <3A832E6E.8C169333@metamatrix.se> Date: Fri, 09 Feb 2001 00:40:30 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: SKiCal component property extensions - TITLE 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 would like to submit the following component property as an addition to the properties described in RFC2445. (This property has already been discussed on the list, but we continue to submit the SKiCal extensions one by one, so that we will know which ones should go into iCalendar core, which ones should be dropped or modified, and which ones should be specified in a separate SKiCal extensions rfc.) Property Name: TITLE Purpose: This property specifies the title of the SKiSource being described. Value Type: TEXT. Property Parameters: Non-standard and language property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: Public SKiSources often have titles. The title may not be a good SUMMARY of the SKiSource. It might be a copyrighted name that the publisher wishes to see included in the calendar object. The following example illustrates the difference between SUMMARY and TITLE: A photo exhibition by photographer Collier Schorr in New York City called "Excuse Me While I Kiss the Sky" can be described by these two lines in a SKICal file: SUMMARY:Collier Schorr photos on exhibit in NYC TITLE:Excuse Me While I Kiss the Sky Format Definition: The property is defined by the following notation: title = "TITLE" titleparam ":" text CRLF ; It is RECOMMENDED, when feasible, that the ; text value be chosen from a list, ; as described in Section 5 of the SKiCal specification titleparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: TITLE:Les Miserables TITLE;LANGUAGE=sv:En kvall med Victor Borge TITLE;LANGUAGE=en:One night with Victor Borge TITLE;LANGUAGE=en:Around the World in 80 Days TITLE:MacDonald's TITLE:WWW11 From owner-ietf-calendar@mail.imc.org Thu Feb 8 22:44:48 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 WAA26295 for ; Thu, 8 Feb 2001 22:44:47 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA16332 for ietf-calendar-bks; Thu, 8 Feb 2001 19:16:44 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA16316 for ; Thu, 8 Feb 2001 19:16:29 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f193GSg16460 for ; Thu, 8 Feb 2001 21:16:28 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 8 Feb 2001 21:16:14 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS7MW6>; Thu, 8 Feb 2001 21:16:14 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FB04@daeis06nok> To: eric@softwarestudio.org Cc: ietf-calendar@imc.org Subject: RE: RFC 2445 contradiction [Was: Re: Extensions To iCalendar] Date: Thu, 8 Feb 2001 21:09:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The broader question is: why do we have this kind of text in > RFC2445? Shouldn't the association between properties and > components be > left solely to RFC2446? > > Would there be any detriment to removing the ABNF for the > components and > the "Conformance" sections for the Properties? It seems that > both of these > sections are redundant with RFC2446. Eric: Good question. But the question ought to be more one of what is the purpose of iCalendar. Is it just a compendium of calendar properties and parameters? Or is it the basic definition of an exchange format for calendar information. You came to iCalendar recently, but from the beginning it has always been an exchange format for calendar information. This was also true about vCalendar, that came before that. What iTIP (RFC 2446) gave us was the "verbs" beyond the default "PUBLISH" implicit in the "nouns" defined by iCalendar (RFC 2445). There could very well be other "verb" sets beyond iTIP. If we didn't have the basic component structure that we have defined in the ABNF in iCalendar, we would have a mess. Every set of "verbs" for scheduling would be based on a potentially different concept of what an iCalendar object was. This would not be a sound foundation upon which to build scheduling applications. Basically, your suggestion would not foster the basic level of interoperability that we have today with common support for iCalendar. I strongly disagree with disabling the fundamental structure of iCalendar which is to define both a setup of basic properties and parameter, but also a set of calendar components that an iCalendar parser need understand. -- Frank From owner-ietf-calendar@mail.imc.org Fri Feb 9 01: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 SMTP id BAA04320 for ; Fri, 9 Feb 2001 01:54:55 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id WAA21038 for ietf-calendar-bks; Thu, 8 Feb 2001 22:34:18 -0800 (PST) Received: from agony.busboom.org (24-25-200-53.san.rr.com [24.25.200.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA21033 for ; Thu, 8 Feb 2001 22:34:16 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f196Y8614540; Thu, 8 Feb 2001 22:34:08 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 8 Feb 2001 22:34:07 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Frank.Dawson@nokia.com cc: ietf-calendar@imc.org Subject: RE: RFC 2445 contradiction In-Reply-To: <30F2DED23724D311902D0008C7EABAFB0361FB04@daeis06nok> 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: On Thu, 8 Feb 2001 Frank.Dawson@nokia.com wrote: > Basically, your suggestion would not foster the basic level of > interoperability that we have today with common support for iCalendar. I > strongly disagree with disabling the fundamental structure of iCalendar > which is to define both a setup of basic properties and parameter, but also > a set of calendar components that an iCalendar parser need understand. Frank, I definately don't want to disable the fundamental structure of iCalendar, but I also don't see how redundancy in the specifications aids interoperability. As it is, if you want to know where a DTSTART can appear, you have three places to look: The Conformance section of 2.8.4.4, "Date/Time Start" The ABNF of 4.6.1, "Event Component" The Restriction tables of iTIP As Graham Gilmore noted, there is a conflict between the Conformance section of DTSTART and the ABNF for EVENT. So, the question is: do we remove the redundancy or make the redundant elements consistent? eric. From owner-ietf-calendar@mail.imc.org Fri Feb 9 02:35:51 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 CAA12222 for ; Fri, 9 Feb 2001 02:35:50 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id XAA26313 for ietf-calendar-bks; Thu, 8 Feb 2001 23:13:29 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA26305 for ; Thu, 8 Feb 2001 23:13:28 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f197Esw12534 for ; Fri, 9 Feb 2001 01:14:54 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 9 Feb 2001 01:13:13 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1PCJGNY6>; Fri, 9 Feb 2001 01:08:03 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FB0B@daeis06nok> To: eric@softwarestudio.org, Frank.Dawson@nokia.com Cc: ietf-calendar@imc.org Subject: RE: RFC 2445 contradiction Date: Fri, 9 Feb 2001 01:06:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I definately don't want to disable the fundamental structure > of iCalendar, Good. I agree. > but I also don't see how redundancy in the specifications aids > interoperability. > There isn't any redundancy between the iCalendar machine processable ABNF and the iCalendar human readable prose and a separate iTIP specification that specifies a "scheduling" protocol. Each have a precise rationale. > As it is, if you want to know where a DTSTART can appear, you > have three > places to look: > > The Conformance section of 2.8.4.4, "Date/Time Start" > Provides a human readable section that aids in interpreting the ABNF. There is an error in the text that goes back to when the iCalendar drafts had less flexible semantics. > The ABNF of 4.6.1, "Event Component" > Provides a machine processable formal notation for iCalendar grammar. > The Restriction tables of iTIP > Provides the specification for restrictions on iCalendar usage for a particular "scheduling" (e.g., inter-personal scheduling) semantics. There are actually a number of restriction tables, not one. But this isn't redundant because there are multiple primitives in iTIP. > As Graham Gilmore noted, there is a conflict between the Conformance > section of DTSTART and the ABNF for EVENT. > > So, the question is: do we remove the redundancy or make the redundant > elements consistent? Obviously, just fix the typo in the propose sections of iCalendar! Hope that is now obvious to you too. From owner-ietf-calendar@mail.imc.org Fri Feb 9 08:42:26 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 IAA16754 for ; Fri, 9 Feb 2001 08:42:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA03973 for ietf-calendar-bks; Fri, 9 Feb 2001 05:24:03 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA03958 for ; Fri, 9 Feb 2001 05:23:59 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 6CC26B34FD; Fri, 9 Feb 2001 14:23:53 +0100 (CET) From: "Greg FitzPatrick" To: "Greg FitzPatrick" , "Eric Busboom" , Cc: "Pregen@Egenconsulting. Com" , "Bob Mahoney" , =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= Subject: The SKiCal extensions - argument for WHOW Date: Fri, 9 Feb 2001 14:24:53 +0100 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit There is a part of the SKiCal model that I would like to clarify before presenting the actual properties and property parameters involved therein. The motivating force behind this group or extensions comes from a series of meetings held with customer service reps at Stockholm City's Information office. The meetings strived to reach a consensus on what "customers" were mainly interested in knowing about "events". The "events" were just about any thing the City had to offer to a resident or a tourist. This included typical tourist attractions, food and lodging, municipal services, sporting events and not least convention facilities. We soon found that many of the city's offerings were not what you would typically call an event. A museum, open most of the days of the year, is not normally called an event. So we began to use the term "resources" We also had some trouble giving a name to the users of these resources. They were not necessarily tourists or businessmen, but actually anybody who was interested in spending time doing something. We began to use the term "TimeSpenders" since we felt that was a fitting semantic match. This terms implies that there is a temporal aspect to our resources, which differentiates them from traditional directory offerings. From this TimeSpender perspective, it does not really matter if one is going to go watch a football game or go get ones teeth pulled. One is about to "spend some time". For a TimeSpender tourist visiting Stockholm for just one day, it really would not matter if a particular exhibition was an "event", say Friday between 19.00 and 21.00 or a persistent resource open all year. They were both equally viable time spending opportunities on the Friday our tourist was visiting town. Opening Times As a participant to these meetings I wrote to the CALSCH list explaining the need for something I called "Opening Times". My point was that our 2445 recurrence rules were not really meant for describing Opening Times and I hoped that others might see the value of such a property even in the business meeting domain. One might benefit from knowing when a particular meeting hall was open, beyond the actual hours described in the DTSTART DTEND. One problem with such a property, is of course, that Calendars would quickly fill up and overflow if we, for example, were to load them with the opening times of all the restaurants and stores in our neighborhood. We obviously don't need to have that information in front of us all of the time, only when desiring to access such a resource. After some discussion with Bruce Kahn in San Diego, it seemed to both of us that the ability to define opening (or operating, or accusable) times might be better served though a set of property parameters. And that is what we have now done. Now back to Stockholm working group and those most common TimeSpender questions: The WHOWS? A list was made up of a dozen of most important aspects. In no particular order they were: Parking, payment-methods, Alcohol served, smoking allowed, Age requirements, need for reservations, requirements made upon the TimeSpender, Price, Handicap facilities, pet restrictions, dress codes or dress recommendations, the availability of transportation. There were also some particular foreign language related items. With this list in hand we asked ourselves for each item: a) Is this item important enough to warrant a visual and consistent place holder(Something like a burning cigarette icon or a cocktail glass icon and so forth) in brochures or webpage layouts? b) Is in important enough to serve as the key to an automated search? For example show me all the resources where I can take my dog? Concerts that are free to attend? Where children are admitted? and so on. c) Will the resource Publishers go to the trouble of declaring this particular item of information. The answers to all three questions for most of the items were qualified. The most common qualifier was "if we reach critical mass". But it was decided that if nothing was made compulsory eventually the market would prove the need for each individual item. So we decided to create place-holders for all. The first draft of SKiCal reflects this, but also a complicated set of description mechanisms, which not even the authors really understood when looking back on our own examples. Therefore we decided on a softer simplified KISS approach. We determined that all these particulars (and many more) were either; 1. an available resource, such as parking 2. a requirement, such as you must be at least 18 3. a recommendation, such as dress warmly or RTFM before coming 4. A restriction, such as NO SMOKING, or NO HAND GUNS and that it would be sufficient to reduce the whole property list into becoming the values of four properties, one of which was already part of 2445 - AVAILABLE so the result would look something like this REQUIRED: Drivers License AVAILABLE: free IEEE 802.11 Wireless LAN PROHIBITED: Flash photography Now you as you can see we have made things a little harder for automated searches, but the consensus is that the market when provided with the opportunity will reach consensus on codes or terms to alleviate the problem. For example a rather complicated schema for the suitability of seeing particular movies is reduced to standardized codes such as PG13 Some of the original WHOWs fell outside of this model and they are PRICE - because you don't prohibit or require a "price" and to recommend a "price" would be confusing HANDICAP FACILITIES - because we have been waiting for our partners in this area to supply us with a particular mechanism more advanced than merely saying AVAILABLE: Wheel Chair ramp BOOKINGS - because we are looking for an address as an answer so that one could publish a combination like: REQUIRED: Advanced bookings BOOKINGS: www.tickettron.com PAYMENT-METHOD - because this also fell outside the model. So there you have the WHOW properties and the motivation behind them. We will follow the standard procedure and present them for inclusion one for one - but the use-argument is basically the same for all. In a separate mail I will explain the OpeningTimes parameters (TERM, OPTIME, OPRULES), that our common to all the WHOWS. Greg From owner-ietf-calendar@mail.imc.org Fri Feb 9 11:07:51 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 LAA21420 for ; Fri, 9 Feb 2001 11:07:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA13840 for ietf-calendar-bks; Fri, 9 Feb 2001 07:33:50 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA13831 for ; Fri, 9 Feb 2001 07:33:48 -0800 (PST) From: pregen@egenconsulting.com To: Andrew Proud Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: MS Outlook X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 9 Feb 2001 15:33:48 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/09/2001 10:33:52 AM, Serialize complete at 02/09/2001 10:33:52 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 003A4456802569EE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 003A4456802569EE_= Content-Type: text/plain; charset="us-ascii" Andrew, I don't know of any other list that handles these questions, so this list is as good as any. However, what your question looks like is a specific problem with a specific vendor's implementation of iCalendar. I would direct the question to them as well. Posting it on this list may help you find "users" who have seen the problem or "vendors" who have seen it as part of their interoperability testing. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Andrew Proud Sent by: owner-ietf-calendar@mail.imc.org 02/08/01 09:04 PM To: ietf-calendar@imc.org cc: Subject: MS Outlook Hi Firstly can I ask if there is a separate mailing group for problems people are encountering during projects that make use of I/VCalendar files ? I realise this list is probably not the correct forum for my problem. The Problem. When Double clicking on a 'Multi Event' .ics file after a standard MS Office 2000 install only 1 of the events is imported into the Calendar. However when performing 'File-Import' from the menu all events are imported correctly. Does anybody know if there is a fix for this ? Is it a bug ? All help will be greatfully received. Andy ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie --=_alternative 003A4456802569EE_= Content-Type: text/html; charset="us-ascii"
Andrew, I don't know of any other list that handles these questions, so this list is as good as any.  However, what your question looks like is a specific problem with a specific vendor's implementation of iCalendar. I would direct the question to them as well.  Posting it on this list may help you find "users" who have seen the problem or "vendors" who have seen it as part of their interoperability testing.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Andrew Proud <andywproud@yahoo.co.uk>
Sent by: owner-ietf-calendar@mail.imc.org

02/08/01 09:04 PM

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        MS Outlook



Hi
Firstly can I ask if there is a separate mailing group
for problems people are encountering during projects
that make use of I/VCalendar files ? I realise this
list is probably not the correct forum for my problem.

The Problem.

When Double clicking on a 'Multi Event' .ics file
after a standard MS Office 2000 install only 1 of the
events is imported into the Calendar. However when
performing 'File-Import' from the menu all events are
imported correctly.

Does anybody know if there is a fix for this ?
Is it a bug ?

All help will be greatfully received.

Andy

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

--=_alternative 003A4456802569EE_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 9 11:56:17 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 LAA23327 for ; Fri, 9 Feb 2001 11:56:17 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA17390 for ietf-calendar-bks; Fri, 9 Feb 2001 08:13:52 -0800 (PST) Received: from agony.busboom.org (24-25-200-53.san.rr.com [24.25.200.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17384 for ; Fri, 9 Feb 2001 08:13:49 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f19GDpC28792 for ; Fri, 9 Feb 2001 08:13:51 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Fri, 9 Feb 2001 08:13:51 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: iCalendar Issue #9, Weeknumber independent of start of week? 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: In Issue #9 of the ICalendar issue list, Frank asks: If so, then should we view "Week Number" as a non-permutable concept? Or should the display of "Week Number" vary as the "start of the week" varies? The threaded message is online at http://www.imc.org/ietf-calendar/mail-archive/msg01752.html Unless we get strong comments otherwise, I am leaning towards leaving the iCalendar text as it is -- that is, the week numbers in recurrence rules will depend on the value of WKST. This definition conflicts with ISO8601 except when WKST is Monday. eric. From owner-ietf-calendar@mail.imc.org Fri Feb 9 12:04:21 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 MAA23594 for ; Fri, 9 Feb 2001 12:04:20 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA17414 for ietf-calendar-bks; Fri, 9 Feb 2001 08:14:22 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17409 for ; Fri, 9 Feb 2001 08:14:20 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 48D95B3571; Fri, 9 Feb 2001 17:14:11 +0100 (CET) From: "Greg FitzPatrick" To: "Andrew Proud" , Subject: SV: MS Outlook Date: Fri, 9 Feb 2001 17:15:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010208210405.98220.qmail@web12604.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id IAA17414 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA23594 Andrew Would you like to post that file so that we can look at it? Greg -----Ursprungligt meddelande----- Från: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]För Andrew Proud Skickat: den 8 februari 2001 22:04 Till: ietf-calendar@imc.org Ämne: MS Outlook Hi Firstly can I ask if there is a separate mailing group for problems people are encountering during projects that make use of I/VCalendar files ? I realise this list is probably not the correct forum for my problem. The Problem. When Double clicking on a 'Multi Event' .ics file after a standard MS Office 2000 install only 1 of the events is imported into the Calendar. However when performing 'File-Import' from the menu all events are imported correctly. Does anybody know if there is a fix for this ? Is it a bug ? All help will be greatfully received. Andy ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From owner-ietf-calendar@mail.imc.org Fri Feb 9 12:05:51 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 MAA23667 for ; Fri, 9 Feb 2001 12:05:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA17622 for ietf-calendar-bks; Fri, 9 Feb 2001 08:22:53 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17618 for ; Fri, 9 Feb 2001 08:22:52 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f19GSfZ14310 for ; Fri, 9 Feb 2001 11:28:41 -0500 Message-ID: <3A841AB9.37EFF720@ecal.com> Date: Fri, 09 Feb 2001 11:28:41 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: The SKiCal extensions - argument for HOW 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 Greg FitzPatrick wrote: > becoming the values of four properties, one of which was already part of > 2445 - AVAILABLE There is no AVAILABLE property in 2445. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I will not buy this .signature, it is scratched.| |francis@ecal.com| | \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 9 12:13:42 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 MAA24067 for ; Fri, 9 Feb 2001 12:13:41 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA17694 for ietf-calendar-bks; Fri, 9 Feb 2001 08:25:46 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17690 for ; Fri, 9 Feb 2001 08:25:45 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f19GVXZ14331 for ; Fri, 9 Feb 2001 11:31:34 -0500 Message-ID: <3A841B65.FE61FB1A@ecal.com> Date: Fri, 09 Feb 2001 11:31:33 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RFC 2445 contradiction References: <30F2DED23724D311902D0008C7EABAFB0361FB0B@daeis06nok> 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 Frank.Dawson@nokia.com wrote: > There isn't any redundancy between the iCalendar machine processable ABNF > and the iCalendar human readable prose and a separate iTIP specification > that specifies a "scheduling" protocol. Each have a precise rationale. But, unless otherwise marked, all text in an RFC is normative, so that both the prose and the ABNF specify the standard. That's redundancy. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I will not buy this .signature, it is scratched.| |francis@ecal.com| | \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 9 12:28:55 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 MAA24902 for ; Fri, 9 Feb 2001 12:28:55 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA18841 for ietf-calendar-bks; Fri, 9 Feb 2001 08:41:03 -0800 (PST) Received: from agony.busboom.org (24-25-200-53.san.rr.com [24.25.200.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA18837 for ; Fri, 9 Feb 2001 08:41:02 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f19Gf5S28851 for ; Fri, 9 Feb 2001 08:41:05 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Fri, 9 Feb 2001 08:41:05 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: RFC2445 Proposed Changes 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've put a text file of proposed changes to RFC2445 online at: http://www.softwarestudio.org/iCal/ProposedChanges.txt This is a first draft of the proposed changes for issues #1 to #23, excluding typos. It is a lightly edited collection of text from a variety of sources. Please review it to check for anything outrageous. eric. From owner-ietf-calendar@mail.imc.org Fri Feb 9 12:36:23 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 MAA25416 for ; Fri, 9 Feb 2001 12:36:23 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA19126 for ietf-calendar-bks; Fri, 9 Feb 2001 08:50:59 -0800 (PST) Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA19122 for ; Fri, 9 Feb 2001 08:50:57 -0800 (PST) Received: from metamatrix.se (IDENT:pbb@[213.88.195.121]) by smtp.wineasy.se with ESMTP id f19Gp2I04328 for ; Fri, 9 Feb 2001 17:51:02 +0100 Message-ID: <3A842009.B89ED4B8@metamatrix.se> Date: Fri, 09 Feb 2001 17:51:21 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extensions - TITLE References: <3A832E6E.8C169333@metamatrix.se> <3A841960.A7309B74@ecal.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id IAA19126 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA25416 John Stracke wrote: > Pär Lannerö wrote: > > The following example illustrates the difference between SUMMARY and > > TITLE: A photo exhibition by photographer Collier Schorr in New York > > City called "Excuse Me While I Kiss the Sky" can be described by > > these two lines in a SKICal file: > > > > SUMMARY:Collier Schorr photos on exhibit in NYC > > TITLE:Excuse Me While I Kiss the Sky > > Again, this is poor form, because it means that someone with a base > iCalendar implementation won't ever see the title at all. A more > appropriate approach would be: > > SUMMARY:"Excuse Me While I Kiss the Sky", an exhibit of Collier > Schorr photos in NYC. > TITLE:Excuse Me While I Kiss the Sky Sure, I will change the example in the spec. But sometimes you have to accept that not all information will be presented to all users. For example, an iCalendar application for kids might not bother to show CATEGORIES, or perhaps show it only if you toggle to "advanced mode". Have a nice week-end! /Pär From owner-ietf-calendar@mail.imc.org Fri Feb 9 12:46:52 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 MAA25817 for ; Fri, 9 Feb 2001 12:46:52 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA20232 for ietf-calendar-bks; Fri, 9 Feb 2001 09:09:19 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA20225 for ; Fri, 9 Feb 2001 09:09:17 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f19HF6Z14501 for ; Fri, 9 Feb 2001 12:15:06 -0500 Message-ID: <3A84259A.A7360BA0@ecal.com> Date: Fri, 09 Feb 2001 12:15:06 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iCalendar Issue #9, Weeknumber independent of start of week? 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 Eric Busboom wrote: > Unless we get strong comments otherwise, I am leaning towards leaving the > iCalendar text as it is -- that is, the week numbers in recurrence rules > will depend on the value of WKST. This definition conflicts with ISO8601 > except when WKST is Monday. Even if we don't change the definition, we should probably add a comment saying that we know it's in conflict. -- /==============================================================\ |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 Fri Feb 9 12:58:14 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 MAA26593 for ; Fri, 9 Feb 2001 12:58:13 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA17480 for ietf-calendar-bks; Fri, 9 Feb 2001 08:17:09 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17476 for ; Fri, 9 Feb 2001 08:17:08 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f19GMvZ14298 for ; Fri, 9 Feb 2001 11:22:57 -0500 Message-ID: <3A841960.A7309B74@ecal.com> Date: Fri, 09 Feb 2001 11:22:56 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extensions - TITLE References: <3A832E6E.8C169333@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id IAA17480 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA26593 Pär Lannerö wrote: > Description: Public SKiSources often have titles. The title may not > be a good SUMMARY of the SKiSource. It might be a copyrighted name I think you mean trademarked. > The following example illustrates the difference between SUMMARY and > TITLE: A photo exhibition by photographer Collier Schorr in New York > City called "Excuse Me While I Kiss the Sky" can be described by > these two lines in a SKICal file: > > SUMMARY:Collier Schorr photos on exhibit in NYC > TITLE:Excuse Me While I Kiss the Sky Again, this is poor form, because it means that someone with a base iCalendar implementation won't ever see the title at all. A more appropriate approach would be: SUMMARY:"Excuse Me While I Kiss the Sky", an exhibit of Collier Schorr photos in NYC. TITLE:Excuse Me While I Kiss the Sky -- /==============================================================\ |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 Fri Feb 9 13:16:15 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 NAA27269 for ; Fri, 9 Feb 2001 13:16:15 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA22551 for ietf-calendar-bks; Fri, 9 Feb 2001 09:50:50 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA22546 for ; Fri, 9 Feb 2001 09:50:49 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f19HubZ14710 for ; Fri, 9 Feb 2001 12:56:38 -0500 Message-ID: <3A842F54.36D8563F@ecal.com> Date: Fri, 09 Feb 2001 12:56:36 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKiCal component property extensions - TITLE References: <3A832E6E.8C169333@metamatrix.se> <3A841960.A7309B74@ecal.com> <3A842009.B89ED4B8@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id JAA22551 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA27269 Pär Lannerö wrote: > But sometimes you have to accept that not all information will be > presented to all users. For example, an iCalendar application for kids > might not bother to show CATEGORIES, or perhaps show it only if you > toggle to "advanced mode". That's a different matter; that's a CUA which decides that the user doesn't need all the data. Since the CUA is chosen by the user (usually), it's essentially a matter of the user choosing what fields to ignore. If a SKiCal object has only a terse SUMMARY because other information has been moved to the extension fields, the publisher is preventing *all* base iCalendar users from seeing the information. Now, sure, the publisher has that right; but they probably don't want to, and they should be advised on why it's a bad idea. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |A ship is safe in a harbor, but that's not what| |francis@ecal.com|a ship is for. | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 9 13:21:25 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 NAA27525 for ; Fri, 9 Feb 2001 13:21:24 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA22885 for ietf-calendar-bks; Fri, 9 Feb 2001 10:01:30 -0800 (PST) Received: from grendel.csc.smith.edu (grendel.csc.smith.edu [131.229.222.23]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA22876 for ; Fri, 9 Feb 2001 10:01:27 -0800 (PST) Received: from localhost (slandrum@localhost) by grendel.csc.smith.edu (8.9.3/8.9.3) with ESMTP id NAA06286; Fri, 9 Feb 2001 13:52:21 -0500 Date: Fri, 9 Feb 2001 13:52:21 -0500 (EST) From: srl To: pregen@egenconsulting.com cc: ietf-calendar@imc.org Subject: Interoperability tests (was Re: MS Outlook) In-Reply-To: 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: On Fri, 9 Feb 2001 pregen@egenconsulting.com wrote: > Andrew, I don't know of any other list that handles these questions, so > this list is as good as any. However, what your question looks like is a > specific problem with a specific vendor's implementation of iCalendar. I > would direct the question to them as well. Posting it on this list may > help you find "users" who have seen the problem or "vendors" who have seen > it as part of their interoperability testing. This reminds me: is there a freely-available, common set of interoperability tests that iCalendar implementors are using to verify that their code behaves in a standard fashion, other than the iCalendar examples provided in the RFC? srl -- Shane R. Landrum slandrum@cs.smith.edu we generate our own light to compensate for the lack of light from above -AD GPG public key: http://cs.smith.edu/~slandrum/srl_pgpkey.txt From owner-ietf-calendar@mail.imc.org Fri Feb 9 13:27:22 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 NAA27720 for ; Fri, 9 Feb 2001 13:27:22 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA23378 for ietf-calendar-bks; Fri, 9 Feb 2001 10:11:37 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA23367 for ; Fri, 9 Feb 2001 10:11:33 -0800 (PST) From: pregen@egenconsulting.com To: Eric Busboom Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: RFC2445 Proposed Changes X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 9 Feb 2001 18:11:35 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/09/2001 01:11:38 PM, Serialize complete at 02/09/2001 01:11:38 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0048B6C6802569EE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0048B6C6802569EE_= Content-Type: text/plain; charset="us-ascii" Eric, thank you for your continued efforts on iCalendar. We do appreciate it! ;-) ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0048B6C6802569EE_= Content-Type: text/html; charset="us-ascii"
Eric, thank you for your continued efforts on iCalendar.  We do appreciate it!  ;-)
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0048B6C6802569EE_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 9 14:16:46 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 OAA29213 for ; Fri, 9 Feb 2001 14:16:45 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA26581 for ietf-calendar-bks; Fri, 9 Feb 2001 11:02:19 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA26576 for ; Fri, 9 Feb 2001 11:02:17 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f19J3nw28285 for ; Fri, 9 Feb 2001 13:03:49 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 9 Feb 2001 13:02:21 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <1PCJG4D7>; Fri, 9 Feb 2001 12:57:10 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FB19@daeis06nok> To: francis@ecal.com, ietf-calendar@imc.org Subject: RE: RFC 2445 contradiction Date: Fri, 9 Feb 2001 12:55:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > But, unless otherwise marked, all text in an RFC is > normative, so that both the > prose and the ABNF specify the standard. That's redundancy. Redundant is the wrong word. They are complementary. Certainly, we want both a machine processable and a human readable description of the specifications in the IETF. Hence, the use of a standard ABNF and also the prose. Redundant implies you can remove one or the other. They are not redundant. Yes, they are both normative. But the introduction is clear that in cases of discrepancy, the ABNF rules. And our responsibility is to correct any such errors so that they two align properly. From owner-ietf-calendar@mail.imc.org Fri Feb 9 14:25:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29449 for ; Fri, 9 Feb 2001 14:25:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA26713 for ietf-calendar-bks; Fri, 9 Feb 2001 11:03:30 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA26709 for ; Fri, 9 Feb 2001 11:03:29 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f19J3Wg12578 for ; Fri, 9 Feb 2001 13:03:33 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 9 Feb 2001 13:03:26 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS7TDG>; Fri, 9 Feb 2001 13:03:26 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FB1A@daeis06nok> To: eric@softwarestudio.org, ietf-calendar@imc.org Subject: RE: iCalendar Issue #9, Weeknumber independent of start of week? Date: Fri, 9 Feb 2001 12:56:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Unless we get strong comments otherwise, I am leaning towards > leaving the > iCalendar text as it is -- that is, the week numbers in > recurrence rules > will depend on the value of WKST. This definition conflicts > with ISO8601 > except when WKST is Monday. I would agree with Eric. From owner-ietf-calendar@mail.imc.org Fri Feb 9 14:30:16 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 OAA29575 for ; Fri, 9 Feb 2001 14:30:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA27269 for ietf-calendar-bks; Fri, 9 Feb 2001 11:10:33 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA27263 for ; Fri, 9 Feb 2001 11:10:31 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f19JGKZ15123 for ; Fri, 9 Feb 2001 14:16:20 -0500 Message-ID: <3A844203.BCF5AD51@ecal.com> Date: Fri, 09 Feb 2001 14:16:19 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: IPTEL spec and iCalendar References: <3A718F44.C7A5317C@ecal.com> Content-Type: multipart/mixed; boundary="------------62AD46418C825F1750962E83" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------62AD46418C825F1750962E83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > "Shannon J. Clark" wrote: > > > It seems to me that monitoring the announcements and passing along important > > ones would be a useful tool, might want to be shared with other working > > groups as well > > That did occur to me, but I don't want to have to keep the tool running for > everybody in the world. I'll probably ask my boss's permission to release the > tool under the GPL. And here it is: It's not perfectly general, but it makes an attempt, anyway. I've got it running to look for the keywords "iCal", "icalendar", "calsch", "calendar", "scheduling", "CAP", and "RFC-2445" through "RFC-2447". (Most of those are case-insensitive, but CAP and the RFCs are case-sensitive; and "iCal", matches only "iCal" or "ICal"--it doesn't do whole-word matching, and I kept getting false positives for things like "theoretical".) When it finds something, it'll send mail to this list. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"I use emacs, which might be thought of as a | |francis@ecal.com|thermonuclear word processor." -- Neal | | |Stephenson | \==============================================================/ --------------62AD46418C825F1750962E83 Content-Type: application/x-gzip; name="draft-monitor.tar.gz" Content-Disposition: inline; filename="draft-monitor.tar.gz" Content-Transfer-Encoding: base64 H4sIAJ87hDoAA+xbe3PbxnbPv8L0Q2wVZ0y6ECVKtlWLYSaKLSe648iuJNeTqZPOElySG4MA gwVEsx7dz97zWmDBh5N2ctvp9Gpyry1gcfbsef7OOetxoSflwTzPbJkXh1/8TX6Ojh4fnT55 An8eHZ0+fUx/9h/zn/LzxdHp8eP+0cmTpyfwvH9yfHzyhXryt2Gn/VO5UhdKfTEpdJZY95l1 ptj99v/sz7il/0WRJ8a5F/jwRzf9k/Y46h99Tv+n/eOntf4fn5zA+qfHT06/UEd/0v6f/fl/ rv8v//GwcsXhyGaHC1OkUfSlep4vVoWdzkrVed5Vx6AhZZ7rFJ4Xi94ZLFDqyfGReqfTrCrV TVkYU6rjbKwmaZ4XPVrwZmZTPTbpYmZ1rN6cq/6z/tFTevX25jz6kv7WPzjuPzk47Z8enJwe HdGjWVkuzg4Pl8tlzyQ67SX5HJ7Df7cz6xSY57TQcwV/ncCuyuWTcqkLM1CrvFKJzlRhxtaV hR1VpVG2VDobH+YFfD/Px3aywkdVNjaFKmdGlaaYO5VP6Jfvr96q701mCjjpm2qU2kS9sonJ nIGvNeyNz9zMjNVoRR+8RA5uhAP1Mge6urR5NlDGwvtC3YHBwO/qGAjIJkIxVnmhOrpEtguV L/CzLvC6Uqkumy9724/enHCsbEZ0Z/kCjjMDinDApU1TNTIKLHZSpTFQgLXq3eXtD6/f3qrz q5/Uu/Pr6/Or258GsLac5fDW3BmmZOeL1AJhOBQ4RLkCzoHAjxfXz3+AL86/u3x1efsTsv/y 8vbq4uZGvXx9rc5Bw9e3l8/fvjq/Vm/eXr95fXPRU+rGIFMov93CVROgNc9BgmNTaps6OfRP oFAHrKVjNdN3BhSbGHsHjGmVgH3+Ma2leTalI8LaRoYDZScqy8tYLQsLZlLmm/qErxuNxuoy S3qxevJM3RqQj1FvUp0YdaBuKiRwcnIUq+9yV+LSH8+VOjru9/sH/ZOjU5Q+GHwvikAb6vLi 9uXZGUXXs7N/qUxlBpvPL7KyWA2iaL5SX80MOFHh3oEmzHjYAU6H36h+DNafz+Wvrhr9apJS fnuY5LA0Kw/K1cI8pIddoAWL1NSUPzC56FMErqZwgyVT/vbfB/7Rg1Q7WVg/+6owbthBQvhg Cb5tVOfrb7rqU7SXzPL5At7s4Xco2cNfHhwOor3MfJRfXyKzh7gEfu24w1/eu8ND+hap0boq SyHttPfm1w9g60/B8/ve8AEwu3evTAqSEyLIN8tqmCaKFtDH/EwN/6rc4dl713v04PDQU8Zv 7nRamWGznn7n5b/82y9nPz86Q179F8j+A5bYJyF9T+fYW+dy6F8PmaTQb5jewyg0aR+Yl8DR Iv4L/VGYsioy0sAgumdNjqv5YlOVM9JircakEv2BgxmdzOiJ6nwwKwdrie1FYbNS7b8v8dWZ 2o9BYJ/w7/cxPM32B8KIbAvxNc/Ox+Oi2fSBhl+HbmYnpWxNMsKnKMXDr3uPvmFV189Asr1H X6NQw2ff1KqRA9O7QSiJYPX7Tu/R+y6uX3sBpvVPWx7DU6YeSFQ2kLPN9QdDjhcKlEU8bByn 03ZI7xBfiiApYihZclYL8MtAXzUF/y2IBuWIDj2sBdwR83Gf8Pk9rN3ze9DCIa2nDWqBsUGJ I3U66Aa4qKvMb+ohfGqKzJQHBPfct9aUk15eTB92B1uMrU0KKDX8lPl9t0uqRRIHOsvgzIk5 DAxPAtKw/kYe3AdrMj0Ht5MXg91700JR7eXBC3X+/Pby9RUABOGbCeHr2BuQ32JE4ZsiaSBn DIsNZ+1oiQzSopF25pYW4nM0VP+EWRnUxoqrFxpyigMY1CyvH9WhZPDzo8F796j+6lta8kZb sC8HGbfsoJEexs2nXVn5FT/h8LtXe/Ye5k126YBWNwyI4OoUDXk9iQseMUvDXaEwWNwOhsOf Hw3XQmG94PCX/d6j/QeHEgzDD/fJ01vP9mlniXayFx/yEzIYxEx8XSty6Bf5B/ct2/UOUi8f 1l+yo9AidfPBLjDjI+ovEUVMQGylAtLlluTW5LSDg5rcg8PWxj5nvtPu1papGR6J26trMLOA fm939ty9UbRHUY0sZw8jmdcbaSDct9a9p9XBTNz1GguenlcA+or3Hfe+C/TOcA1roUQ6veE+ ZNB9eebFSq9ApvQnCbTO3qIopk2sMFXPjwue1j7Q7Nek39/Zqy3l/mAtU6IeDIbw4SacOvgm M8uODxqGHzlT3nAE6vhQtLmCNuswK5tvryD8cJDqrmUXwyjunnCc8FUnGeREDtsQK6xO7X8Y 8nNSLr1BKbY2neVLQWKbaPLsLM2TDzVQw51/w+fDzaW1RJj6b/xsUZV+XzFi/wb3PU/Tz2wN MVs2v4/+t6vav//80Z92/+f56zc/XV59/yfvgf2fp9Lv2ez/PD7pH5+u9f8eHz89/nv/53/i Z49CK5XRF1cX1+evoH7/7tXlcwX/u7i6uYh4Afz8q29nxOovVWZU/9mzPsSCdreo/+yfn8X0 amd/hKvpSG3/Waux498vsbmjpC7uTLHKgS8s9E0xtyX2RyDTU7tAAzAPOkOwdgTMzPGlNS7i dgJ8mUpXYpwn1RwCYUy9k2Sms6nNpthdgUVZXiqdpvnSjKGw32MJvYEqaz5KDYbH25nxlJw0 OCD5+m6V0tTtcHaaMYcl5AWll3pF/aAIW1tjKJkRpcxoPTBPLGBLq6fUdyuFwLWAdBjv6IJE vr0C7CL4B1RNW00rjW0d0Ay1nj63Fb6LPM8HB7AE85dyVUFdneY4vhuHBwWxAI9Okbf0FPWu oh2dH73AVpPDzUk+0tJp92Eau3noAglmdBrsmOXUa/PtseUsR8oEcBxIaQ52ACujyrH6gKXO TQ41BX+2y0Zbh0tyMBfq+0Ve2K/sqACAtqunZTNXAvbrdRX1sbAxiYel9iMwQ6IXjh1oMM97 aDXvZiZTSxDswugPBE3DHmeMr5CjwkxMUeBxQAKiwBhtMgJEkRg44Wsgv50zt2F7oU65IRlR vw1PGlhH4DvsMhv8qY7YTjElU4jIn8AM7mBrBJ7Yol1aN+vG9Va+qwdEqiJB0mODvUUUGFTd IK7IfwhGC78Gn+IasdSWNcLn2FIDHhPmEolkAFSXzK+X+4CNyJP7kOXLmu6YOoIOKYOcHWnn NsdPS2y1kf4o5jnSSmYCWRYGJZWgFTkmD8IY2XEExorhCYVpMnJ12YQpIeNo0u4Dv8pRK4Wp m9W8qhfd8jetXcClHXaOKdyZotQWO+FuAS/tyEJ1aSUOIWWWaLRVo6EkqUkt4q+75ySKl/DC fNQYpWO/Yis5VyUzpb3IQVYzg24XwW+lpRNTzFATA4RoH8jGamrF/sA6LJDKQDgYVxopkFzR jag33GMvo2/XzBk+WZGDxbWpBeaFvenA8oDOOZhEzQdCXlwz98ZA4wJHtrFig4G/2SLyqkEf NtusRHrQSyw7zcKdqU6/S3mJE2db6mCWUee4C/IDPxczCTIT1I8gVJSRo5epmYKbU8ZzlJ8l 5cWhhnkM4tUY7kdcn6cOJIS6oE4hh8+Hzh8FqaKzwIHY4MkbvcGLwUUkcOOzME1ZAFplY1er gsNpljfDBdySTtdKNqCIy8lGjiHmLc9fHIRw3IXaqcjaQjsHrxAdLE0k0cKFFgTsisqAmaU3 Dh4uSE7HHXNQic10GsMefCRMMiAISO1zyqVFPq4SZoOSiOOBCxKA0Jyi6vOsRSuSfPQQFkCF RRmGzeUlvk5XMW0ShidkqZwBpIDUDXtBukdZlpBC6PSSHBf4usQ8C3aHsZUiyF1ux7T/GKNj wScOBmOYGcE5NQu9zpx4CJuN7Z0dV8iUykcUSHiTGs/EOHMyYJsJeRvloVlDBv6ENGQAU696 EjRxtlSSmsl4SOJzPab5XJIaLRyCCORA7H6jGkON2TTFtB4K3MAoD49R7vU6TcCs5zHYAvVf ey7lpxxOyFETaaKjwAniJnyJrUdsbQmjgUmOaK8X/UP0u3AZ3t5eXP94o86vXqjnr69eXGLH ksdkUl3F6sXlze315Xdv8RUt/PH1i8uXl8/P8QEyf9Tjqd8WqCTmSMKGEzCOWebFB4kMiAxB bS7SKBrMvQsE0vXYsgk7szzF5OL0SqDtHBAoSD2YL0Zbh6XA2HZ40WOx779h/vYBPRsQXBwR ZqnZp7QQnAG5p7gHNrlPR8F+69i7kacWzQ3kOT9dDd4gDaQLrNo70BjYF1Fh5psDp3p5xj5t iRc4OWzLa0VsYs4tymqRF2QGBCbiqBnvcg2BJ8D4HpqM8yG3zs04q6Xzk8aiFHyz0lMUWecH iIwQCCYg4rj+ADck8J6kFYJ3P6lNLUBaeZ1FXjNqP9x9H5HnBYZy8QwKcTjwMBQmtVP7kDv2 wVHOIbzfMUDIRa4IrHb5ReuQBCYReDYIma1DzGHAIZZQWVU6Sy4PGRSoe1PRGC0nUVFlG6KX oOyRjhnHgtiIGsRRnoIGn0QBWM8zhNsT2lC6/I7DqC0pI6oNQ4v8zh0Ig2aB0CujqgQiFjI3 MoDPKXDBObdw3O1F7xjgqNrIigrhNtJyuIvPO/Uhx7nhTNDvMYjRqz9SsHqsJmQeuhDHoHpD cI2w2WbkIXPIAhUAMXA+CPOmwb8RimZhkyqvXMq7Q8yhWA62C0/k+gMegjCCMBmuihpPk8gj h0hSbecgFWDaZ/6B+mDMAl0CLUDQXcSfOZ+xEP/QcD6MhFz54eH1yJkMdsFcBmerSUe4hkBk Ux8GQKAtutZ9gmafqHV3oF4Nqqq1xJUOgVfBMRBqZysHzpGKXbMz+3KNd2KAtxIq7Tsggvlq eBTgL0y6H31l7kEzWc5xYzmC74gin6rYbjA+YkpkiziywYqK8uKc2d0ZimPJpWynIdCk0N4O hBLgt927uZHD9SM9Ar/dYpdgGgC453jDCI2ET+FMkMfPuIOtu00RkOjKcQVRY8aJTTl9JiBb EiycEd1bTI5oOIyr5NO+xiR5c8xhCj4CjbHaEsPjVT3mY7TBB9kmCqAmG8gLhCOeJaUtxHSe EuUpvSUAVpR1WqdnjlMdnmstBIpiiQZ9R7A7n2AR1EJUECO07KJRCt6eMUWRN9piXFNBA9qF BHzq5+MnXQ/da9H7RJ+BXRGuBFQ75t4MVQc0m9aYhiDOyOEh0EKADWpCFiXaKL2k6R3Q9lEY PQJNj68gNAQJJModKe4xFWPItAVGCyoMFU9h4HNQCgAlNGi2J5lsYxNQkjA5RSviqa0RTxMB ebC79ukgpk3xMpggsNo+xAuYj/qDbtOwoO4aeXzrvhtFIJE2qYsorDuMpFGTpj5/ITlFxW6u 7qxZrsVEotIgvM7Fx8RQuDrDBNtK2aUz6cT3HL0OgDcigbmOUnptCSx87hJkLZHHHMRaEcif ZhMh/FbZglswTHGNWK8LyN33TWjtnJsK1JOTbFLbK+3ZuAcVo5FFLADvNZSByhlpvJCAsJyk TxgM7XTNmPIS9h5GyId2eQbUqJWL0KgghNjgDlzsDI68S4azTvDeHGR8h3VYOaM7e40PsmYR 8ZCLxtjHol51c84cUlvNPrnSWkCifod2a1tj07kq6w+iNaNzeEujJouXJWW47kMMlybWtZJK tJ5UKLCGgFOSFtPwRaF85aNQ1JYAN4CbdgjXeQwCPBiGGuIjtsRF9RGqtpBtPMisKFtwOwQe UPHJxyrMVBdjup+CgGYGLo1pmptjt/BhHIwJ6Eoloc86YIqcKBkhMAr6fwRUXRmFrSNYxtVd gRMNQAHELDcCYN1AgZZmVDg0W1F5E5mPpuDy1zfOuDeELYx0q7CDAiovAM6l2M3w5ZTbCgXg zJcZlhaWZztzjHR6OkUpebJS8/A5UCrbCEXrWIsCJD38DBLp4u9a3eVphU39CVS9rswLKKwk pjfnY+zbRKFR4eNfwB2HTbJprFK2ZrmTz0P19SOsc48lJCdTD3+Ou5ijcr7H6XvgoL2kKine ICLbkn+jG+9xfeLhWBGK2gWiIBhgy0x8ilsaIIEGP50nkJMXCFfoErFoA5+lhnJdwT1lSoRz 8AxAUAeYzJFJBlBNERKLz3uvDS8t70aCnGvaxyEFi/ISoJbPdWHB/ivfGGqahJh0GI0NQIRx jcg2T6ZrfyLIHas7nVomBzJLDV6Wwf4bn2tldEGDmqasIIBEAWEVCyAXBJXlfJ+ZCmka6BEw kgmXrxAw+5nCY20RXGivMWVhlj3f5liTeOsedFs5LT0Q8OME/Md0sFv+fJL/hg6SXdZlMxQB R4qgZiV8KomZFMS5f20OtePIiFGoe6ZTvPXI8UxgjIxtuT0wofZhhkgUIyWUbRvtDt9GwKTH 13uEvxBr/b7z0nlrgKprq8OyHORScHtH3VQjnx1GLH2ALohcWgOySRNUuCPGvNBYkNUxrzMn LsJhnHRq25UZyJMmoi+paAiZ5o5c7fq8e0S785Z+HrPBFzyHTSqslWxTtUBll1aOKhPtXJ5Y 3xADF8Cb9GMzsZnlXivWWbKe43BhFzxRxoQd+fyFzFnpkxHswQ55muoQODQnglP+AIq/Q6Ej tovcwpDGjQez8cZ5QnehER9mDenH4TSPhoN1q6cGteFnHSzbuV0olEFGI6pAItRTt/GEuf6V EMAcLJrQaYdPiBx/wMu7KUMTh2G8KyeMIEcVXLS6lSsBulGTCQNv+/xYKYFU5V4t8VxvFQls 1+Kh1GhuSw+S/GQDLQTUEWIFHoDTGumTkaEDfxFQp63lQgahYy2jaLKGBd/3IFTrv1II1yE0 I5drBDasz8NtAqNEDF5UhPNdtA1WtqKk/AOYvJrOgthuZWLOTc75Aoqm4FJJQGStXRQIA6cG Sj1uMANaETeCuF1D/4QjDf5h0HYsEbGlovWajwts5FIBJaneh/MAquA0ExtMYBWLMiKMsyQ0 mO/cfvfuGD9xrsQ2SLMiXWEaKCWZYRaxqMjW3HMLW1Hth17ACKHb/8aHe1YkDD9mJ/VihvAI LegJ1vM3f3PBFs31m5oxch1SE5Y3GIs9A1AP4qAL/ptUKUeW1GooHgnuPWHV+fIurDbRJBfl Wg3mLDYl/XCaTEeuW1CwrY+PoJhMHGeYUyzxuW3bHuVKSw9C+A7FYD+odOuzD757gxWv9lVZ QUO6mR3Zklv1qV7W03spFDfPw3QgueQ4mx6teDBG/YoWwF5r3nekwbizyd7l5g4OHJPaanh/ LU3dlo5LArA4psaOo79m9F8Z7DHHNfvRmhDXShy56vC0x3OU0s6NAJTPQf3fOXEZXmpYcyAx fiyRvTf6kBb5QbK84Zsi7MTtXmIw4Pd8+X8fVuI42+wYhvorFBKeLGQG6VxOqoLmVa0LJ1KD NU31h6ouNiW4SgAguzb4j2JwxNWL2p4kN1QYJUFlC/+foJ4aD5SRUhCO6RxrFdlpT11OOLFT OwVctJ4MYBKAqv3XajylXh6DlKA65ZlzBEgUM47xiyaiTz8/wH6N6vC0eW7lbqHMq8FdK+O6 cRRYIYFhkiMZAtpOR+6/4KGYK0B+hEigXPYbN5G66/M0XvUDNykF6ddbrPlIzOM29mVMF9j8 xH3r1Lj7W75yIfef8POwp58LGnd4awfMy9l5lYKbGh4W8QADcshUcGUT9aNwbBPc1jOgS2q/ B59J6t9QIkJvb5g7fE/G/ps3k7TXbn17hv5FKZLiO6KqyFdQJqwO6EpB4NwBTvC7QPBj2JvT NZy8HrDJiGUMaSHBKxrUtq9/gzKSUAWcg49IkYcKC7nyicYAXHnxjkBI8m+X2zGQmR9hMMSJ eoFJq24HkZI/wz5juGDos9GQgr/OTIpImothvEmXsVMaQnmceokEOmNSpRoirS2Sau4oanOE G+m0CeEmJB/cRI24KennKX5RMJZYu7kqFygzNqEo3BYnqJetltuiKiiCbem5gWYqyc/0G3t9 cPvENdcqsNEPprqS7hm16/xFPenVcePA0j+UJiLUzeaVg/bmMy0VDZ4u4NBP+eQmDR56WgjF Uq5h/md7T9vUNpL0Z/QrdD7qMdwag7Mk2YUVF4NF0MXYrG2SpZJUzmABfhZbPguHdaX479dv M5qR5JdkU1zdlbVbFSzN9PT09PR09/T0JAa2NcSs9Je0f9XB49skSXiJH3F4huL+EbnkkWCu e0rjGEYYaq1DcpwbjOuAac1SR5rRpvgDbuGPaQ8So/syKIU9R3E7iS6xSSgaUeR5NGSHd0yC k+JargybrQvKElXaFyfqZKS3eymIarsXDXkAerD69CiylEKt3PiWeAaVQVreLWeBxlXhlwgj QZLDT3S8hIhBWQlZEN9GfdIJO6lZY7IphcQhotgKevcpwOlBjMRLIEP4mSfAZZhdrXhVje8z 4pmMiJ/KanMt7afYlqjXlMTqx0b4BG4fqOBQMozGKLTEOkVeSbj/cprsbJl2OsvoRB3JxBKh VCTTK7bwyJoBJNG7vR77HZAJYLhvQiw+uqUddKuLRtALrGu8F+ewINZdKXFoZvfermodB2B3 zpCUgAGYAk5CCBYdk1gaCHu4JA55c+qqy6urIYtByY9gBuMWSUwC3UAR5jlwpXIwyvbjZdTL RBmQ8vJzmSJhZoaiI6VU9MU4/Nyn3VsecgxqllwRsaMyIsxIs0A6AGqxOJ3gX8zPgH0zYdDk QcaEFb6Pwh1wj0f9MYWtKzdTjBNXavDxCMQQ9E4MXYAKnMeBRDwHHFETOoKStzmAESkEkpRr lSgDCIP+VfQ34hDCGE+g0ygXVYnhZHAZjpP4UGUbkzfnmqz1VNmMIcGi0giok5W2gMLbSr9R KCVWHC3ZKkYjcZ4bDlRboVZBYmqHUCEVjVXUgNVUfnYRJ4cdMn1PNjSYCNM8EqQ2yaY6hiVS er6qgrbpglwnxpkMDl3aKSvlUcWgGrODdIVM/AnFwrH8NaNQY9m/s2ZwSqlmTqM9Yit/B68P jsTQo/qeWNKiGupVQO9HmmJuAeXnpQux0r/gEY5oEOIkix1aD7STMdYRz3JMAxcxortK2gIs 30twwZDxm6h7R7Ob5t74s2I7VgtA5Ew4nBfqJ04AeqVO+FjnZhhSNIi0zY4nfzi2oQcCRpYR XeWG5cndNDnq1GjqDDI0/pWye+gfVc/bvts58d2zVvN1q3rqBm0VFVtzj1u+7zaP3aOTauu1 X8JyLR9LmLAwRtYAAKWa9Nv/reM3Ou6Z3zoNOh2AdnjhVs/OAHj1sO679eo7oKb/25F/1nHf nfgNp4ng3wWAT7tTxQpBw33XCjpB4zUBxEDcVvD6pOOeNOs1v0XRutvQOlXkZDZ+2wE83gY1 u1OFahvQLuh0Ogp57Bym1nkTNGol1w8IkP/bWctvQ/8dgB2cAsY+fAwaR/XzGgUCHwKERrMD dIKeAZ6dJpFGlVXQARmA76Sz8GDk8BJpeIiEAAQI3grab9xq2xHC/npe1YCAugDjtNo4ooFK DSR2171onuOqAf2u17CAowogoXy35h/7R53gLQwvlIRm2uenvtC73SEC1etuwz8CfKutC7ft t94GR0gHp+WfVQMgP8ZIt1o+ZXlg2fKsjIMHXOK/RR44b9Sxty3/13PoTw4nIIzqa+A2JKYx 7s67ABrHEUoPfomqwIdk8C+AjZruafWCA7MvhD0ATR25bXMFMEXCndXDJtLgEPAJCC1ABAmC Q1SrnlZf++2So5mAmpZg8pLbPvOPAvwDvgPrwVjXmSowi349x1GEFwLErcJwYteQD2XIcA4i rzUUj0Db6Xm5kbSd4j/ki3qzjcwGjXSqLmEM/x76WLrlN4BeNJ2qR0fnLZhaWAJrADbtc5hs QYMGxcH+0mwOWjU1n4jO7nE1qJ+3MjwGLTeBhAiSeE0PiGKy9maJeMANjqGpoxMZPdeatRfu CQzFoQ/FqrW3AUoebseBudAOhCZNgSB0JMFGh0+hf1Q+J4AfY/+xyAmHSVXJGmUPa4fWf3h5 gQK3AcqOrHIxHZUXDyssrHfRCBZn0YaSOErjfJtE6clieUPnP+J7B2wQdpNNYr3+sGknFjea DOhMIJ/0LZoYrPRwnDutQf17x14LeA3UB3Yy2dOMo6B6s1i5D9WJOOWSvb/vypZTohrpYF6l ObIbAihCplDcvcauIca69kAV1tk5KABH9lhwZ1AfFuUTKBwzCArC53Aqe1agvMeipiXBxhTC g6AIhplXTO32kw5f0OpAAfT5obit3FFEFhCF4lAkH3V0wpsOdLoR13UgkgRB/oL0pPoqYsAg QBGUNdyhYtCXYHtcu7DkdzmYiDO4UVT4AcFKH6+eTgE+AcA1n1SeA271T2XIE88xx09+Q468 dIY8Hau3fJa8nBx5BGWZPHm5BPjaPHkULPLnMuUhiD+XK08fL1o2Wx7V+PPZ8jg44tvz5WH9 hRnzlj7N7zh4JJEcBGaECDrRWP5SYAEfskRdOcRAtXE0hA7xaUBQ/UHs9e/Y62kFa1jBqSUl HNWZki7Scazjee/6v7ModSj2EcqRaIr5QIUV5gozKJRgqtdD0K8/s2Kv+PvFz6W8yWxP5Uzt KzAk5Pho9bDdrIPiUb8wleZ9YgnhBhcTULn/pIOrD8VyMivS4iBZeGglCO+wHaRrSjoQBDlG pV1HyhrbN5u7KpqIlDlq5XY6QhuPtriSgG+FH+Ggawv7qkO31sESy4ScefSseU27KrIRkrRH u8YxOjin6NvA7TbaDAYTjZwLxrmnXNTkGBM76Wn6X4bOIAKQW1eAwe/k0xiEwwkQLBzEW1so xsmOjid93tTVx/3lAIl0luLy8CQyFcGJEk2h2oY69K4jkaX2IBxvunyMe+zEaL3f8TbHkIPZ cZ8Zz9Alfrnk9E0hOaSilI/+tTPEU/IxH9Y8kSD1LoZQwJzd5wAqqoNsykctLqJp1JsOQzXF cUG8nOqGODQoQYBmCKonIoGlcQD0T4PPi7g3RuGCMBtjPs0buxKkgjEw8ab2p0Fj/0Bs3JPu 1e/hmCTgLxxFgue+gUs6U5hp0fCg5FZAURv37ygtCWos/KGEyTrivjre9RY4SJy6M6SudrHI plHi3kD+MceXHBuOcQhW5xvQO2xjUxR1cX92HOH2NAobyiqh/TOOCg2nw5ko9Xmpop1HxgS0 DArsMls0nOqxDklxBLjyH7FQeFARoupEdw+0OXV4JifRhZOf6CLr1/xPp7VZPUs+dv4nzOv1 /ZPAf03+92e7lP/95e7LVf73p3hyxp/Sun1PLvia8d99WYHxf75TqazG/ymemeNPiQrLo8F3 aGN+/red3UrlmR7/H3eeYf7/3R93V/nfnuJZpftfpftfpfv//un+R2Cc4Cm03NT+qGGfBqc+ 5k6NYFzP8NSqpOkfhg9GfnWwqeJYJVhXLzFa3/ui8mlfcup8fFni8mYybkorawKg1LL8mhOz Y8Wtg16YZKBVn/Nyg1NxnTY9SaFr4EzoGS1KCzoPuPr2qO8lWAzDbN0AZSJCmXqXQINS+eYg sah+CgUGYyKAyYCXaB9N6ZzmF9ROtU5AzMaD2hJN93s5Dc+tmWoWABiNCr/MqY7v8O6IYnHG zQTWrQRUnZkSKpW9At1LgOmf+Xc4xAMVn/412lD40GUFm7qAeWmBhb51e0K4LOb25FGvX6Fn X7K2u9sfhtslKbg/r4dcizqnbsbYoC+UPv3D8O+SqlslbpdE7EnG9j0r6byVrT3n2gouqclE adV7oSYfVdDzWw3obfQwhyKSr5pBWumqoX5lf2Xy/1c+M/V/yur9FPp/pQK6f2L/Vej+r91n z1f6/1M8K/1/pf+v9P8n0v/lyq+5d36t9/pjr7gd3l9t27K5+K0GAt1l1I1v5WfvcgDsM+R3 JWrPLbtFuuehWHJ3Xrx44azR2b5wo3BEYfAuVagdnnL8BI4hFd9z1/9S0HdIiLKBYB+9D2aT eSbKTJsC+jdTJZX9SLkcyGwQdWLQq4Lao2nVpL/hrSGGeqjU0xml97P9MkBhzR8q+zP1TFCt aVjfhNMFema/l6NyF+kajk9FGBsooKGOJvPMpOSukZTSim1IR4i+OXehwEsotZkAIjWU6xh9 MQqlKSO39+TeaDKrPLLeJyRp8dGju59mg6aimE4Wiqa/49Uwit/Fws1+31S3QCGQNzN6l1tx P8tRCojZARoog79ygSWlZjEyXRmUz8f8yWxI+OIaBMbt0nxmMpp14xYBXp4DDCsplxnsEdE+ B2l51j09Kf+DvjTPRDjVfUBvoRkKxhLeAjBnaqTIvDSdDBlC42BQiLo+FsvPEhNZM5VbkBqC rZo7bH21OzW/1XILeffvAAk2Nvckqk2unQpqfEJjGLk0K0l0c86P/h8AvZxcjYWWbSgjHHs3 43AEdinLoPc7Wz9//GF9GxNRoJ3+xSLX475dP6jBeoQhNF/Wu+4v3oG7fvnoDroj90usAIJ1 6q5/ejQatHpZOCbkYQnHKwkV0Pc7H81rCWfNDKO4DbTezYGpUd6qzIUuMze3npJuBhfgWFQ2 0+uVYgN7LMvlMg4RxRT2/4Bltzcsckq58jLuDHQdgfT5pkVh1vwWCU7OoY1NY67z2pc71w05 uJ/1GOqJwRA2E2/MOBp984Jm45m6R/Bb5BmYMJjvZp4s+xoyLACZJZlanOYB5xVwOeCqbCKK hP5qJcSfs1ZCPVTZtU+qWSsy452W2TMmklXYQI/fL7VQS9Fll2buzSL0lBSxSpsOsurd3Tzd FHXt3mTkZWWkNV5QxFYyzQ9q8Um/N3WcBesWFpGLBpG5FTl5JuWsVPouWCIvX126lr5yTt8X y/eOLpxQa4QhYp5l9jWzYzK9Mu8sFs7/as40g49wDMwrbmv9nuTdwbA8jFBDitGa2A/lqlbq 0QZCLmn/qLMmVLTeexhKzm3oSw6Tu3TJY+uJi5Yp+ZjwEd0WGV39joaUZ9leZXytjDz8W/iM bK968+jNcVD3YY06ONAACq5hpxXFTFMflXGGMK7xpQHkmZa/fGufNJUu9hPXvrrDM3nq9crf +7/02D6G0TjCeFBSLEmt/C5toP93dvxPpVLZNeJ/fnyO/t8XOy9W/t+neP76l+1JPN6+7A+3 R+H4znFWDuGVQ3jlEP7+DuGMz1ecwbN8wfi+/u5sb+8cBE/1JsQAEXx30unAyxYmDYnl1SnQ bW+vHQ574kIeRv14ivdQs4467KHf05l7X7C69/y8VfeKxixUN8Vvp66QR3c01pl0RWPBtEv9 IQqK2HRE8e3IJb5AubSOWTA2vVefEusOlDGPr3kHRejDkPydVNj4jbVso7LC5gJqcnQZ/RXm iOx1x9t92wxMlXvfDz4ChttzC11RFxZAWrJBABT2JpiQZkHBo+rZfKxax0fvt9yPf3+2u/v+ +YuXH7dTN07vaJVORiIYjEZPPg7Q5oKO9vkmM3eA504WUaU/GEYPC8p0R+EfS5Lu5cv3P/28 mHK17uenJtxDeNnrfl7Q01r17fyOwoJ7vxCKpsbzyk/5pEBX3hhT+HobX4B/wSTwDtyiNcGL JTZ7MMULfUU5saUmxav+4AqFhir1cENleGIV+d0jf8s2gHybAS/a2SulFKQgI98tgguj+rVg eVQU4E1b0hluABzejBtAnXwCKpoXsufFBhGxtZVOmFNsD1j09APNXxzD/+NvG8yF2vZc1019 kVoPN4+PCgJ29tEwQs3xTpBMNpjYBDB6l/W/sScJFxnTyD7jmpTTdI4bwcCCFpAxTB9ZeXCq JD49jIjbyDhRJ13eGJl0PXt51DfapxoY81LpWQsnF37td7wDxMBwcUpWSjDOJ92tA6m8oaDk +XSpeI5jN2NM7aGKCmY6eV4SP7TRWTDv99zzqnsNK3rYY/olU9PoWKb9rYN+/CmeUI5kzUmc HcYzCvGbTxiMtv+98JVmGFtkDRMrDDnb9LzdnV3NrkosIU9qR5wthGxm1VPMgktXXaSHgybG UkPBIhu0QkyPPJ1DalKooKyXw5rqO8l7swAFkxolDGkg4iNvXTGmV1JBjeYrPM98H8UeOZZi a+7S94eb2OMNGuMLj4gxWbEBmbBMAtGyb0ALjmTKWrJqLSWsBA0Ctpa4veBjUvkRR5B5cBDf eImCyvNO4n1RxhYCwRXFBuumTO5CCdMNrXUiLPX/ERg6xRL+r9qnr+RlhBZoA3ujcDyOBoVS QaT6By3WCzq08vpWeJTU4kSCXt96DAddaBsF/IjtYMUUk2LRD38DxgJjap+7KZGR1zBH/hHd DtEkxqOpRTDVsEOueFfccXRJSeYwNeA9mWsfhvDfPUog/Kuwb8EakA3O6UD0MVoxVrQHtuHh uOtxbnheJTXMCGsdyvD+GW0sIa1vxtFkVBb/pNVDBeiZOcQpKJQxrcRvcAeMR12DIdT6aIGs rWk/9C8AdavCy1Yefuv9H35A4CXs3RpR1mi8iE0Wpcm+btJJdzXVw1h10Zkx7iBK0L1JDu7H 1O7A7KnTiCifn0omACPDxjixru30tVQxpV+tk8vXy5pkehWT+edxSd5SRDZW5IRviJSaqr1o GHoi5vhjar/KBIQbhlYh6iiC4LVVSuLenCpm9IXRQpjUmzyzkr3KiO9/2r+1elbP6lk9q2f1 rJ7s82/4RxROAKAAAA== --------------62AD46418C825F1750962E83-- From owner-ietf-calendar@mail.imc.org Fri Feb 9 14:33:11 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 OAA29698 for ; Fri, 9 Feb 2001 14:33:11 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA27566 for ietf-calendar-bks; Fri, 9 Feb 2001 11:18:19 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA27562 for ; Fri, 9 Feb 2001 11:18:18 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f19JO8Z15151 for ; Fri, 9 Feb 2001 14:24:08 -0500 Message-ID: <3A8443D7.79A022BA@ecal.com> Date: Fri, 09 Feb 2001 14:24:07 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RFC 2445 contradiction References: <30F2DED23724D311902D0008C7EABAFB0361FB19@daeis06nok> 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 Frank.Dawson@nokia.com wrote: > > But, unless otherwise marked, all text in an RFC is > > normative, so that both the > > prose and the ABNF specify the standard. That's redundancy. > > Redundant is the wrong word. They are complementary. But, at the moment, they're in contradiction, right? And the only way that can happen is if they cover the same topic; i.e., they're redundant. And that's why redundancy in a spec is risky: you can get different answers depending on which section you're looking at. > Certainly, we want both > a machine processable and a human readable description of the specifications > in the IETF. I'm not so sure. Another approach would be to have a formal definition of the syntax, with a prose definition of the semantics. The prose would reference the formal definition, but would not duplicate it. (I prefer to think of it as "formal" rather than "machine processable" because, commonly, parser generators don't accept ABNF as such, and wouldn't do much useful if it if they did--with lex/yacc, for example, you usually need to intermingle C code into your grammar.) This is all theoretical, of course; the approach that was actually taken is certainly Good Enough, and I definitely don't advocate wholesale rewriting at this late date--we might theoretically fix some bugs, but we'd almost certainly end up introducing new ones. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Stock up and save! Limit one. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 9 16:16: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 QAA02124 for ; Fri, 9 Feb 2001 16:16:54 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA01551 for ietf-calendar-bks; Fri, 9 Feb 2001 12:51:19 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01544 for ; Fri, 9 Feb 2001 12:51:17 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA15185 for ; Fri, 9 Feb 2001 14:23:34 -0600 From: "Shannon J. Clark" Cc: Subject: RE: Interoperability tests (was Re: MS Outlook) Date: Fri, 9 Feb 2001 14:50:17 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This gives rise to a few thoughts: One - Has anyone created a set of sample iCalendar files that exercise each are of the standard? That is, an iCalendar file that implements each property and object type, as well as perhaps exercising multiple varieties of some of the complex properties (like the reoccurrence rules?) Two - When testing interoperability from just a RFC2445 standpoint - what is the methodology of that test - i.e. without implementing iTip, CAP, iMip etc. are we simply testing that flat files can be parsed and handled by each of our companies' software products? Three - are there any publicly available reports from previous interop tests that while they may not name product names, might mention the areas most prone to interop issues? For example, I would assume that various degrees of conformance/non-conformance/non-implementation of reoccurrence rules are a major area of problems. Four - Do the tests also include tests for LACK of information - that is, is there a minimum amount of information needed to be present in a given iCalendar, or iCalendar object for applications to recognize and deal with it. Five - Methodology to test the generation of iCalendar objects, to take a simple example - do applications correctly handle data entries that have content that could potentially itself be parsed by iCalendar applications. Do all applications correctly close out and end each object - to look at an issue facing other standards bodies, HTML generated by many applications does not close all tags, resulting in potentially unforeseen results when various applications try to parse it. Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of srl Sent: Friday, February 09, 2001 12:52 PM To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: Interoperability tests (was Re: MS Outlook) On Fri, 9 Feb 2001 pregen@egenconsulting.com wrote: > Andrew, I don't know of any other list that handles these questions, so > this list is as good as any. However, what your question looks like is a > specific problem with a specific vendor's implementation of iCalendar. I > would direct the question to them as well. Posting it on this list may > help you find "users" who have seen the problem or "vendors" who have seen > it as part of their interoperability testing. This reminds me: is there a freely-available, common set of interoperability tests that iCalendar implementors are using to verify that their code behaves in a standard fashion, other than the iCalendar examples provided in the RFC? srl -- Shane R. Landrum slandrum@cs.smith.edu we generate our own light to compensate for the lack of light from above -AD GPG public key: http://cs.smith.edu/~slandrum/srl_pgpkey.txt From owner-ietf-calendar@mail.imc.org Sat Feb 10 04:12:55 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 EAA24813 for ; Sat, 10 Feb 2001 04:12:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA08670 for ietf-calendar-bks; Sat, 10 Feb 2001 00:52:08 -0800 (PST) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA08666 for ; Sat, 10 Feb 2001 00:52:06 -0800 (PST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA22926 for ; Sat, 10 Feb 2001 03:55:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9B0G>; Sat, 10 Feb 2001 03:48:29 -0500 Message-ID: From: Jonathan Rosenberg To: "'ietf-calendar@imc.org'" Subject: iptel and iCalendar Date: Sat, 10 Feb 2001 03:48:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, Let me introduce myself - my name is Jonathan Rosenberg and I'm the chair of the iptel group. We're the group which has generated the CPL specification: http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt which makes use of iCalendar. As Patrik has mentioned, the draft is currently blocked within IESG until this group gives its OK that the usage of iCalendar is reasonable. I saw from the list notes a bunch of comments on this subject. I'll address some of them now. I've asked the CPL author, Jonathan Lennox, to also join the list to make additional comments, as he defined the subset and also built a running implementation. So: 1. The issue was raised as to why iptel didn't talk to calsch at the time they decided to use the specification. Well, there is no good reason for it; it was an error on my part, and I apologize. Groups often use rfc's from other groups in their own work without consulting that group, especially for mature documents. I should have contacted calsch as soon as the group began to consider the implementation of a subset. In our own defense, we did elect to use rfc2445 as opposed to something completely different. In fact, the original cpl draft used a crontab style time definition. There were several implementations built around it. We decided to move to rfc2445, breaking backwards compatibility, in order to be consistent with other IETF efforts - namely yours. Therefore, please do not interpret our usage of a subset as an attempt to be purposefully incompatible. Rather, we wanted to be compatible but had certain constraints that needed to be addressed. 2. Another issue was raised regarding syntax. I saw two proposals; one of which was to use more deeply nested XML tags to contain things like the byday value, rather than use attributes, and another was to use the actual syntax defined in rfc2445 (please correct me if I misrepresent the statements made). The first proposal doesn't work at all for us. The CPL syntax has a very specific structure, and the use of nested tags has a CPL specific meaning that prevents us from using them to do other things. Usage of the existing syntax within an attribute would work, but requires additional code for both the XML and recurrence parsing. We didn't see syntax compatibility as a real issue, so we opted to represent the exact same data, but in a format which was easiest for us. 3. The reason we selected a subset was based on the really important property of an O(1) computation to determine if the current time is within a recurrence. Since these computations happen in real time for call setups, we have both processing and latency constraints. There was also the concern about implementation complexity. The algorithm in the document was the maximal subset we could discover which was still computable in O(1) time. The pieces we needed to eliminate didn't seem like they would be commonly used at all, and so we were happy that we achieved our goal with something with would cover most, if not all, real usage cases. What I'd love to hear more about from this group is how we could meet our constraint of O(1) time and not have to implement a subset. More to come, Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From owner-ietf-calendar@mail.imc.org Sun Feb 11 12:41:06 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 MAA11360 for ; Sun, 11 Feb 2001 12:41:05 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA06628 for ietf-calendar-bks; Sun, 11 Feb 2001 09:19:48 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA06621 for ; Sun, 11 Feb 2001 09:19:45 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 78A5EB34FA; Sun, 11 Feb 2001 18:19:40 +0100 (CET) From: "Greg FitzPatrick" To: Cc: =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= Subject: parallel namespace developments Date: Sun, 11 Feb 2001 18:20:42 +0100 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3A842009.B89ED4B8@metamatrix.se> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I asked Graham Kline if he would like to add anything to our namespace discussion based on his participation in other efforts. He was kind enough to write the following, which I believe is of interest to us all. Greg, I've taken a quick look at a few messages on your list, but can't really get any traction on the specific problem you're trying to solve. So rather than wade in, I'll refer you to some other work-in-progress. Feel free to post this, in part or in whole, to the CALSCH list if you think it's relevant to your discussion. I've just submitted an I-D for IMPP, developed with Derek Atkins, that proposes a message format based on MIME but incorporating the XML namespaces extension model. The syntax may be too strict for some folks taste -- I'm not fixated on that. But in other ways, it shows how one can take an extensibility model that seems to be working very well (in the XML world) and apply it to a more traditional IETF style of protocol. Basically, it allows anybody to create extensions to the base protocol by associating those extensions with a globally unique URI. The URI is quoted just once, so it doesn't involve using URI syntax for the new protocol elements themselves. The advantage of URIs is that there are several ways of creating unique identifiers, and they do form a universal namespace in that any other namespace can be embedded in URI form. I am working with some others on a proposal for a URN namespace (a subset or URIs) that can be used for IANA registered values. Another aspect of this proposal is that it borrows from SIP a mechanism to indicate whether or not an extension MUST be understood -- this is another very important aspect of protocol extensibility: some extensions can be ignored if not understood, without harm; others require that they must be understood if the associated protocol elements are to be processed correctly. Look out for . You might find it interesting to compare this with , which embeds much of RFC822 semantics in an XML message format. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-ietf-calendar@mail.imc.org Sun Feb 11 12:51:49 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 MAA11438 for ; Sun, 11 Feb 2001 12:51:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA09110 for ietf-calendar-bks; Sun, 11 Feb 2001 09:37:35 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA09098 for ; Sun, 11 Feb 2001 09:37:33 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id D33E3B3573; Sun, 11 Feb 2001 18:37:32 +0100 (CET) From: "Greg FitzPatrick" To: "John Stracke" , Subject: The SKiCal extensions - argument for HOW Date: Sun, 11 Feb 2001 18:38:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3A841AB9.37EFF720@ecal.com> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id JAA09110 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11438 whoops - I meant RESOURCES thanks for the correction -----Ursprungligt meddelande----- Från: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]För John Stracke Skickat: den 9 februari 2001 17:29 Till: ietf-calendar@imc.org Ämne: Re: The SKiCal extensions - argument for HOW Greg FitzPatrick wrote: > becoming the values of four properties, one of which was already part of > 2445 - AVAILABLE There is no AVAILABLE property in 2445. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I will not buy this .signature, it is scratched.| |francis@ecal.com| | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 12 05:57:31 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 FAA03505 for ; Mon, 12 Feb 2001 05:57:31 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id CAA11705 for ietf-calendar-bks; Mon, 12 Feb 2001 02:41:51 -0800 (PST) Received: from web12603.mail.yahoo.com (web12603.mail.yahoo.com [216.136.173.226]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA11700 for ; Mon, 12 Feb 2001 02:41:50 -0800 (PST) Message-ID: <20010212104150.44262.qmail@web12603.mail.yahoo.com> Received: from [195.92.67.78] by web12603.mail.yahoo.com; Mon, 12 Feb 2001 10:41:50 GMT Date: Mon, 12 Feb 2001 10:41:50 +0000 (GMT) From: =?iso-8859-1?q?Andrew=20Proud?= Subject: MS Outlook 2 To: ietf-calendar@imc.org In-Reply-To: MIME-Version: 1.0 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 Hi, ( Regarding my previous post about Outlook only importing one event ) I have found a page on a support area of MS that I'll quote from. "Tip You can also double-click the vCalendar file or drag it onto Calendar on the Outlook bar. These methods work best with a single vCalendar appointment because only the first appointment in a file is imported when you double-click or drag the file." To my mind the word 'best' should be replaced with 'only'. This kind of 'Half' support for the I/Vcalendar standard is a disaster for anybody relying on it. Does this committee/organisation have enough weight to make MS support the standard fully? Are there any other examples of products that people know of, where the vendor claims to support the standard but in fact they do not ? Has anybody written a fix to Outlook yet (COM ?) Andy ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From owner-ietf-calendar@mail.imc.org Mon Feb 12 11:25:24 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 LAA13430 for ; Mon, 12 Feb 2001 11:25:24 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA06733 for ietf-calendar-bks; Mon, 12 Feb 2001 08:06:35 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA06729 for ; Mon, 12 Feb 2001 08:06:33 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f1CGCPG29021 for ; Mon, 12 Feb 2001 11:12:25 -0500 Message-ID: <3A880B68.C471E722@ecal.com> Date: Mon, 12 Feb 2001 11:12:24 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: MS Outlook 2 References: <20010212104150.44262.qmail@web12603.mail.yahoo.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 Andrew Proud wrote: > Does this committee/organisation have enough weight to > make MS support the standard fully? Insert hollow laughter here. -- /================================================================\ |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 Mon Feb 12 11:43:41 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 LAA14229 for ; Mon, 12 Feb 2001 11:43:41 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA07128 for ietf-calendar-bks; Mon, 12 Feb 2001 08:22:34 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA07124 for ; Mon, 12 Feb 2001 08:22:33 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f1CGM3F24939 for ; Mon, 12 Feb 2001 08:22:03 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G8NK4S00.Q8T; Mon, 12 Feb 2001 08:22:04 -0800 Message-ID: <3A880E07.717ACB91@netscape.com> Date: Mon, 12 Feb 2001 08:23:35 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: MS Outlook 2 References: <20010212104150.44262.qmail@web12603.mail.yahoo.com> <3A880B68.C471E722@ecal.com> Content-Type: multipart/mixed; boundary="------------164AFA6204A2591FC0678612" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------164AFA6204A2591FC0678612 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > Andrew Proud wrote: > > > Does this committee/organisation have enough weight to > > make MS support the standard fully? > > Insert hollow laughter here. I think the only way that's going to happen is if the rest of the industry supports these standards in their products -- this will allow for interoperability that has never been available before (in calendaring). Customers will expect support. Imagine trying to release a proprietary email system today -- something incompatible with SMTP. That's the sort of thing we need to make happen with calendaring standards. -Steve --------------164AFA6204A2591FC0678612 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------164AFA6204A2591FC0678612-- From owner-ietf-calendar@mail.imc.org Mon Feb 12 11:48:44 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 LAA14461 for ; Mon, 12 Feb 2001 11:48:44 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA08172 for ietf-calendar-bks; Mon, 12 Feb 2001 08:34:08 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA08168 for ; Mon, 12 Feb 2001 08:34:07 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f1CGdrG29088; Mon, 12 Feb 2001 11:39:58 -0500 Message-ID: <3A8811D6.E335FF6A@ecal.com> Date: Mon, 12 Feb 2001 11:39:50 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "'ietf-calendar@imc.org'" CC: jdrosen@dynamicsoft.com Subject: Re: iptel and iCalendar 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 Jonathan Rosenberg wrote: > 1. The issue was raised as to why iptel didn't talk to calsch at the time > they decided to use the specification. Well, there is no good reason for it; > it was an error on my part, and I apologize. Groups often use rfc's from > other groups in their own work without consulting that group, especially for > mature documents. Sure. Meanwhile, on our part, we didn't realize that we should be watching out for Drafts that referenced iCalendar, until Patrik mentioned it. > Therefore, please do not interpret our usage of a subset as an > attempt to be purposefully incompatible. Sure. Your approach makes sense for your needs; the only serious concern is where you say, "This allows CPLs to be generated automatically from calendar books." > 3. The reason we selected a subset was based on the really important > property of an O(1) computation to determine if the current time is within a Yeah, that makes sense. However, it seems to me that there may be calendaring applications which want a simpler recurrence system, too. I have *never* used a calendar whose recurrence rules were as complex as iCalendar's--and, in fact, I hope I never do; the UI would be horrendous. Most iCalendar implementations are going to have UIs that support only subsets of the iCalendar recurrence rules, which is a good way to run into interop problems, since they'll support different subsets. So, if you send me an event that uses recurrence syntax my UI doesn't handle, my CUA may *understand* the full syntax, and expand the recurrence set correctly; but I won't be able to see and understand the rule, or modify it (if I want to COUNTER). I, for one, would be interested in working up a simplified subset for general-purpose use, which would be easier for users to work with. If it turned out to be implementable in O(1) time, that would solve both our problems. As for the XML representation--maybe we can resurrect the old iCalendar-in-XML draft. I opposed it at the time, because having two syntaxes for the same data model gets messy; but it's becoming clear that we need to be able to embed iCalendar data in other people's XML. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |When rats leave a sinking ship, where exactly do| |francis@ecal.com|they think they're going? | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 12 11:54:37 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 LAA14648 for ; Mon, 12 Feb 2001 11:54:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA08254 for ietf-calendar-bks; Mon, 12 Feb 2001 08:36:55 -0800 (PST) Received: from server1.egenconsulting.com (holder194.net18.block16.connectsouth.net [66.16.18.194]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA08245 for ; Mon, 12 Feb 2001 08:36:54 -0800 (PST) From: pregen@egenconsulting.com To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: MS Outlook 2 X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 12 Feb 2001 16:36:46 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 02/12/2001 11:36:55 AM, Serialize complete at 02/12/2001 11:36:55 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00400BA4802569F1_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00400BA4802569F1_= Content-Type: text/plain; charset="us-ascii" Andrew, I'm afraid John is correct. No one, not even the Department of Justice, it seems, can force Microsoft to do anything. For that matter, any vendor can choose to implement a standard partially. However, if they expect to sell their product, it would be wise to have it implement a standard so it can interoperate. I guess Microsoft feels they are so large, they can do things "halfway." Getting Microsoft to fully endorse standards has always been a challenge. We keep trying. They actually participated on the first CalConnect. All we can hope is they continue to participate. Thanks for your comments and hopefully someone will respond with an item about what they have done to work around the partial Microsoft implementation. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 John Stracke Sent by: owner-ietf-calendar@mail.imc.org 02/12/01 04:12 PM To: ietf-calendar@imc.org cc: Subject: Re: MS Outlook 2 Andrew Proud wrote: > Does this committee/organisation have enough weight to > make MS support the standard fully? Insert hollow laughter here. -- /================================================================\ |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. | \================================================================/ --=_alternative 00400BA4802569F1_= Content-Type: text/html; charset="us-ascii"
Andrew, I'm afraid John is correct.  No one, not even the Department of Justice, it seems, can force Microsoft to do anything.  For that matter, any vendor can choose to implement a standard partially.  However, if they expect to sell their product, it would be wise to have it implement a standard so it can interoperate.  I guess Microsoft feels they are so large, they can do things "halfway."  Getting Microsoft to fully endorse standards has always been a challenge.  We keep trying.  They actually participated on the first CalConnect.  All we can hope is they continue to participate.  Thanks for your comments and hopefully someone will respond with an item about what they have done to work around the partial Microsoft implementation.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

02/12/01 04:12 PM

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: MS Outlook 2



Andrew Proud wrote:

> Does this committee/organisation have enough weight to
> make MS support the standard fully?

Insert hollow laughter here.

--
/================================================================\
|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.           |
\================================================================/

--=_alternative 00400BA4802569F1_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 12 13:07:37 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 NAA16880 for ; Mon, 12 Feb 2001 13:07:37 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA11302 for ietf-calendar-bks; Mon, 12 Feb 2001 09:48:24 -0800 (PST) Received: from biz1.mailsrvcs.net (biz1.gte.net [207.115.153.50]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11298 for ; Mon, 12 Feb 2001 09:48:22 -0800 (PST) Received: from [4.3.146.172] by biz1.mailsrvcs.net (Post.Office MTA v3.5.3 release 223 ID# 0-64117L5000S0V35) with ESMTP id net for ; Mon, 12 Feb 2001 11:03:14 -0600 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Mon, 12 Feb 2001 09:36:02 -0800 Subject: Cuba From: Rives McDow To: ietf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Paul and all, Cuba's start date for 2001 dst is March 25, 2001. Rives McDow From owner-ietf-calendar@mail.imc.org Mon Feb 12 17:00:39 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 RAA22504 for ; Mon, 12 Feb 2001 17:00:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA22879 for ietf-calendar-bks; Mon, 12 Feb 2001 13:32:21 -0800 (PST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA22872 for ; Mon, 12 Feb 2001 13:32:15 -0800 (PST) Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA23566; Mon, 12 Feb 2001 16:31:59 -0500 (EST) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id QAA26588; Mon, 12 Feb 2001 16:31:55 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14984.22090.209994.416002@conrail.cs.columbia.edu> Date: Mon, 12 Feb 2001 16:31:54 -0500 (EST) To: ietf-calendar@imc.org Cc: Jonathan Rosenberg , Henning Schulzrinne , John Stracke Subject: Re: iptel and iCalendar In-Reply-To: <3A8811D6.E335FF6A@ecal.com> References: <3A8811D6.E335FF6A@ecal.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, February 12 2001, "John Stracke" wrote to "ietf-calendar@imc.org, jdrosen@dynamicsoft.com": > Jonathan Rosenberg wrote: > > > 1. The issue was raised as to why iptel didn't talk to calsch at the time > > they decided to use the specification. Well, there is no good reason for > > it; it was an error on my part, and I apologize. Groups often use rfc's > > from other groups in their own work without consulting that group, > > especially for mature documents. > > Sure. Meanwhile, on our part, we didn't realize that we should be watching > out for Drafts that referenced iCalendar, until Patrik mentioned it. As the primary person behind the use of iCalendar in CPL, I'll take responsibility for this too. I've asked some questions about iCalendar use here, but never explicitly expliained to the group what I was doing. > > Therefore, please do not interpret our usage of a subset as an > > attempt to be purposefully incompatible. > > Sure. Your approach makes sense for your needs; the only serious concern is > where you say, "This allows CPLs to be generated automatically from calendar > books." > > > 3. The reason we selected a subset was based on the really important > > property of an O(1) computation to determine if the current time is within > > a > > Yeah, that makes sense. However, it seems to me that there may be > calendaring applications which want a simpler recurrence system, too. I > have *never* used a calendar whose recurrence rules were as complex as > iCalendar's--and, in fact, I hope I never do; the UI would be horrendous. > Most iCalendar implementations are going to have UIs that support only > subsets of the iCalendar recurrence rules, which is a good way to run into > interop problems, since they'll support different subsets. So, if you > send me an event that uses recurrence syntax my UI doesn't handle, my CUA > may *understand* the full syntax, and expand the recurrence set correctly; > but I won't be able to see and understand the rule, or modify it (if I > want to COUNTER). The phrase "can be generated automatically from calendar books" is indeed somewhat glib -- no, you can't generate a general CPL script from a general iCalendar template without an O(n) (I believe) space blow-up in the number of rules. I'm pretty sure, though, that the the iCalendar subset we use in CPL does indeed contain the rules that would be generated by any of the actual calendaring UIs you describe. (I explored a number of them in the process of working out a subset; I can send these results to this list if it would be helpeful.) The one exception is 'count', but 'count' and 'until' are pretty trivially transformable to one another if you're willing to enumerate. In particular, I find it somewhat hard to imagine a UI that could sucessfully describe the general case of 'bysetpos'. Maybe this is a failure of imagination on my part, though. > I, for one, would be interested in working up a simplified subset for > general-purpose use, which would be easier for users to work with. If it > turned out to be implementable in O(1) time, that would solve both our > problems. Yes, I agree, Indeed, I suspect that CPL's iCalendar superset may indeed still be too *big* for reasonable UI representation, though this could still be a matter of debate. > As for the XML representation--maybe we can resurrect the old > iCalendar-in-XML draft. I opposed it at the time, because having two > syntaxes for the same data model gets messy; but it's becoming clear that > we need to be able to embed iCalendar data in other people's XML. As Jonathan Rosenberg mentioned in his initial mail, CPL maps a fairly strong semantic structure onto XML's nesting model, so the way you'd want to do iCalendar-in-XML in the general case probably doesn't match very well with how you'd want to do iCalendar-RRULEs-in-CPL. On the question of whether a generic iCalendar-in-XML would be useful, I'm agnostic. When I designed the iCalendar-RRULEs-in-CPL syntax, though, I tried to keep the syntax transformations as simple as possible. Thus, a rule with a rule part like: RRULE;BYMONTHDAY=5,17,23 is transformed into a CPL node with a parameter expressed as an XML attribute: