From owner-ietf-calendar@mail.imc.org Sun Apr 1 19:47:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28942 for ; Sun, 1 Apr 2001 19:47:33 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA04718 for ietf-calendar-bks; Sun, 1 Apr 2001 16:11:30 -0700 (PDT) Received: from joeco.com.cn ([202.102.44.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA04711 for ; Sun, 1 Apr 2001 16:11:28 -0700 (PDT) From: mb644@arabia.com Received: from 44mexi7server42 by joeco.com.cn (8.8.8+Sun/SMI-SVR4) id HAA15793; Mon, 2 Apr 2001 07:17:51 +0800 (CST) Date: Mon, 2 Apr 2001 07:17:51 +0800 (CST) Message-Id: <200104012317.HAA15793@joeco.com.cn> To: Subject: ADV: Top Search Engine Rankings MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Removal instructions below. I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 To be removed call: 888-800-6339 X1377 From owner-ietf-calendar@mail.imc.org Mon Apr 2 00:35:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18031 for ; Mon, 2 Apr 2001 00:35:21 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id VAA10270 for ietf-calendar-bks; Sun, 1 Apr 2001 21:24:51 -0700 (PDT) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA10265 for ; Sun, 1 Apr 2001 21:24:49 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f324OpQ29995; Sun, 1 Apr 2001 21:24:52 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Sun, 1 Apr 2001 21:24:51 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Steve Mansour cc: CalSched IETF Subject: CAP Data Exchanges In-Reply-To: <3AB7D979.97DE1A9C@netscape.com> 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: Steve, In the CAP draft, the example in section 7.1.3 has this text: S: BEGIN:VCAP S: PRODID:-//ACME/CAPserver//EN S: VERSION:2.1 S: IDENTITY=bill@example.com S: CAPVERSION=1.0 S: ITIPVERSION=1.0 S: AUTH=KERBEROS_V4 S: AUTH=DIGEST_MD5 S: CAR=CAR-FULL-1 S: MINDATE=19700101T000000Z S: MAXDATE=20370201T000000Z S: END:VCAP How should we interpret this? I hope that this means that all of those equal signs are supposed to be ":" and that AUTHENTICATE will return data as an iCalendar component. I also saw a hint of a CALID property. Can we expect that CALIDEXPAND and UPNEXPAND will also return iCalendar components? I'd much prefer if all of the data in CAP, outside of commands and response codes, was encapsulated in iCalendar. eric. From owner-ietf-calendar@mail.imc.org Mon Apr 2 16:00: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 QAA28142 for ; Mon, 2 Apr 2001 16:00:16 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA12623 for ietf-calendar-bks; Mon, 2 Apr 2001 12:46:10 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA12616 for ; Mon, 2 Apr 2001 12:46:08 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA13411 for ; Mon, 2 Apr 2001 14:38:52 -0500 From: "Shannon J. Clark" To: "CalSched IETF" Subject: Questions from RFC2445 - Member, Range, "group schedule" and periods Date: Mon, 2 Apr 2001 14:45:21 -0500 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) Importance: Normal In-Reply-To: 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 above.proper.com id MAA12623 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA28142 In my periodic and ongoing studying of the standard, a few questions that occurred to me in my most recent reading, especially in light of our ongoing current discussion about DURATION, some questions follow. 1. Why is there a "Member" parameter? The examples that are shown do not seem to clearly identify a useful role for this parameter. 2. Why is there a RANGE parameter – it also does not seem to clearly have a useful role? Certainly the examples do not show why this is there or how it will be used in "real" world applications. 3. p26. uses a reference to a "group schedule calendar component" which is not, I think, ever defined anywhere else in the standards document. 4. p36 – Says only that for periods the start time must be before the end time. It should also be specific that there should be a UNIQUE rendering of the period. i.e. the time values MUST be in the same format (you can’t have a floating time and a UTC or TZID formatted time and get a sensible result.) This probably should be clarified and specified. 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 Tue Apr 3 16:33:05 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15957 for ; Tue, 3 Apr 2001 16:33:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA01750 for ietf-calendar-bks; Tue, 3 Apr 2001 13:09:00 -0700 (PDT) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA01745 for ; Tue, 3 Apr 2001 13:08:59 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f33K91I28250 for ; Tue, 3 Apr 2001 13:09:01 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Tue, 3 Apr 2001 13:09:01 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Omit VTIMEZONE when using global identifiers? 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: RFC2445 section 4.2.19 mentions that a "/" in front of a timezone name indicates a globally unique name, but it explicitly avoids identifying these globally unique names. We've talked about using the Olsen database for these global identifiers, but have not made any concrete decisions. Can we tie this down now? Do we have a global timezone registry? If not, what will it take to get one? Also, if we define the global TZ registry, can we remove the requirement to include a VTIMEZONE in a component when the TZID parameters reference global names? eric. From owner-ietf-calendar@mail.imc.org Thu Apr 5 03:54:45 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24896 for ; Thu, 5 Apr 2001 03:54:45 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA10478 for ietf-calendar-bks; Thu, 5 Apr 2001 00:35:10 -0700 (PDT) Received: from mail.fihoca.com ([212.0.109.34]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA10473 for ; Thu, 5 Apr 2001 00:35:07 -0700 (PDT) Received: (apparently) from srvxhgbcn.fihoca.int ([212.0.109.38]) by mail.fihoca.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 5 Apr 2001 09:34:50 +0200 Received: from pcaortega (pcaortega.fihoca.int [192.168.45.209]) by srvxhgbcn.fihoca.int with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HB5ZQC66; Thu, 5 Apr 2001 09:36:05 +0200 Message-ID: <006101c0bda3$1b28ee00$d12da8c0@fihoca.int> From: "Antonio Ortega" To: Subject: A beginner needs help Date: Thu, 5 Apr 2001 09:36:19 +0200 Organization: Fihoca MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C0BDB3.DE9C6140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C0BDB3.DE9C6140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello to everybody! I am a student of computer science at the University and I'm interested about ICalendar.=20 During the last two months i have been working with an Apache framework, Turbine, an someone toldme about an ICalendar=20 app. I tried to make it function butI can't, and I want to work on it = more because I think it's so pretty idea. Well ... the subject of this message is if somebody could advise me some place to begin. If I can, would prefer not to have to read the RFC = ;) 1 - Can someone refer me about any simply and clear summary about = ICalendar. 2 - Has someone a Java example on how does it function. See you later, thaks! _________________ Toni Ortega aortega@fihioca.com _________________ ------=_NextPart_000_005E_01C0BDB3.DE9C6140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
    Hello to = everybody!  I am a=20 student of computer science at the
University and I'm interested about=20 ICalendar.
    During the last two = months i=20 have been working with an
Apache framework, Turbine, an someone = toldme about=20 an ICalendar
app. I tried to make it function butI = can't, and I=20 want to work on it more
because I think it's so pretty=20 idea.
    Well ... the subject = of this=20 message is if somebody could advise me
some place to begin. If I can, would = prefer not to=20 have to read the RFC ;)
 
1 - Can someone refer me about any = simply and=20 clear summary about ICalendar.
2 - Has someone a Java example on how = does it=20 function.
See you later, = thaks!
_________________
     =20 Toni Ortega
aortega@fihioca.com
__________= _______
------=_NextPart_000_005E_01C0BDB3.DE9C6140-- From owner-ietf-calendar@mail.imc.org Thu Apr 5 06:54:28 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27018 for ; Thu, 5 Apr 2001 06:54:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id DAA02244 for ietf-calendar-bks; Thu, 5 Apr 2001 03:34:44 -0700 (PDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02236 for ; Thu, 5 Apr 2001 03:34:42 -0700 (PDT) Message-Id: <200104051034.DAA02236@above.proper.com> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:00:21 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:57:53 +0200 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From owner-ietf-calendar@mail.imc.org Thu Apr 5 09:53:28 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02321 for ; Thu, 5 Apr 2001 09:53:28 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA15856 for ietf-calendar-bks; Thu, 5 Apr 2001 06:37:39 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA15848 for ; Thu, 5 Apr 2001 06:37:37 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA32498; Thu, 5 Apr 2001 09:36:26 -0400 Received: from steltor.com (c-1106.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f35Da1j23972; Thu, 5 Apr 2001 09:36:11 -0400 (EDT) Message-ID: <3ACC7487.7B72D56D@steltor.com> Date: Thu, 05 Apr 2001 09:35:03 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Busboom CC: ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? 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: > > RFC2445 section 4.2.19 mentions that a "/" in front of a timezone name > indicates a globally unique name, but it explicitly avoids identifying > these globally unique names. > > We've talked about using the Olsen database for these global identifiers, > but have not made any concrete decisions. Can we tie this down now? Do we > have a global timezone registry? If not, what will it take to get one? We were trying to get the Olson database registered with IANA. Last I heard we contacted someone from IANA and now are waiting for a reply from someone at Olson. Pat or Bob make haven more information? > > Also, if we define the global TZ registry, can we remove the requirement > to include a VTIMEZONE in a component when the TZID parameters reference > global names? Good idea. What happens when an application encounters a timezone from the the global TZ registry that was recently added, and that the application is not aware about? Should it assume that it came from the global registry and print a message saying something like: "your timezone registry may be out of date, please update." We also have to worry about old applications that support iCalendar, iMIP and iTIP, since they expect a timezone. However, for CAP it should be OK. > > eric. From owner-ietf-calendar@mail.imc.org Fri Apr 6 00:37:14 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21512 for ; Fri, 6 Apr 2001 00:37:13 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id VAA05974 for ietf-calendar-bks; Thu, 5 Apr 2001 21:21:24 -0700 (PDT) Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA05968 for ; Thu, 5 Apr 2001 21:21:19 -0700 (PDT) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.11.3/8.11.3) id f364Kk020697; Fri, 6 Apr 2001 00:20:46 -0400 (EDT) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9865308451.020683; Fri, 6 Apr 01 00:20:45 -0400 Received: (from uucp@localhost) by hqvsbh1.ms.com (8.11.3/8.11.3) id f364Kji20669; Fri, 6 Apr 2001 00:20:45 -0400 (EDT) Received: from unknown(144.14.206.187) by hqvsbh1 via smap (4.1) id sma.9865308441.020655; Fri, 6 Apr 01 00:20:44 -0400 Received: from morganstanley.com (vpn2766031.morgan.com [172.27.66.31]) by pismh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id AAA08463; Fri, 6 Apr 2001 00:20:43 -0400 (EDT) Message-ID: <3ACD441A.3CFC9750@morganstanley.com> Date: Fri, 06 Apr 2001 00:20:42 -0400 From: David Madeo Reply-To: David.Madeo@morganstanley.com Organization: Morgan Stanley X-Mailer: Mozilla 4.75 [en]C-CCK-MCD MS4.75 V20000913.1 (Windows NT 5.0; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: Greg Black CC: Paul Eggert , tz@elsie.nci.nih.gov, ietf-calendar@imc.org Subject: Re: Updated Australian time zone names/strings References: <200104051703.KAA01034@shade.twinsun.com> Content-Type: multipart/mixed; boundary="------------CADBDB9D16FFF7952207F0C6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CADBDB9D16FFF7952207F0C6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Since I'm a lurker on both the tz and ietf lists, occasionally I see that it's appropriate to mix the audiences. This thread from the tz list is whether the tz maintainers should be trying to uniquify the timezone abbreviations such as "EST" which can mean several different timezones around the world, depending on whether you ask an Australian or an American. Greg Black wrote: > Paul Eggert wrote: > > | * How important are unique time zone abbreviations? > | > | Here I tend to agree with the point (most recently made by Chris > | Newman) that unique abbreviations should not be essential for proper > | operation of software. > > I think this flies in the face of common sense and the old > principle about being flexible in handling input while trying to > make output as good as possible. I'd certainly prefer unique and unambiguous abbreviations (AEST) as well as unique names "Australia/Sydney" based on the Continent/Largest City. Anytime we can reduce confusion and make something easier for people *and* computers to understand, we should. > || The final decision is Arthur David Olson's, since he's maintaining > | the database. My own mild preference for now (given what's been said > | so far) would be to leave it alone. > > I know the decision is in Arthur David Olson's hands, but I > would imagine that he will be responsive to the wishes of the > affected parties. I'm keen to see more input into this. The tz database is the closest thing to a "standard" timezone listing. As such, there's a lot of benefit if it does the "right" thing. I've cc'd the ietf list since they are effectively "users" of this sort of data and might have some input. dmadeo --------------CADBDB9D16FFF7952207F0C6 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;pager:dmadeo@skytel.com or 888-354-8513 tel;cell:917-295-9893 tel;fax:1877-545-8846 tel;work:212-762-2348 x-mozilla-html:TRUE url:http://www.morganstanley.com org:Information Technology;Morgan Stanley adr:;;750 Seventh Ave;New York;NY;10019;US version:2.1 email;internet:david.madeo@morganstanley.com title:Vice President fn:David Madeo end:vcard --------------CADBDB9D16FFF7952207F0C6-- From owner-ietf-calendar@mail.imc.org Fri Apr 6 05:16:52 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06663 for ; Fri, 6 Apr 2001 05:16:52 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id CAA07302 for ietf-calendar-bks; Fri, 6 Apr 2001 02:03:44 -0700 (PDT) Received: from dymwsm07.mailwatch.com (dymwsm07.mailwatch.com [204.253.83.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA07296 for ; Fri, 6 Apr 2001 02:03:42 -0700 (PDT) Received: from dymw0114.mailwatch.com (dymw0114.allegro.net [204.253.83.107]) by dymwsm07.mailwatch.com (8.11.0/8.11.0) with SMTP id f3693mE30180 for ; Fri, 6 Apr 2001 05:03:48 -0400 Received: from 204.253.83.34 by dymw0114.mailwatch.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Fri, 06 Apr 01 05:03:10 -0400 X-Server-Uuid: 17085090-7ecb-11d4-ba0b-00508bd371a2 Received: from eccmfw5.ford.com (mailfw5.ford.com [136.1.1.29]) by dymwsm12.mailwatch.com (8.11.0/8.11.0) with ESMTP id f3693Ae32316 for ; Fri, 6 Apr 2001 05:03:10 -0400 Message-ID: <200104060903.f3693Ae32316@dymwsm12.mailwatch.com> Received: by mailfw5.ford.com id EAA17157 (InterLock SMTP Gateway 4.2 for ietf-calendar@imc.org); Fri, 6 Apr 2001 04:57:15 -0400 (EDT) Received: by mailfw5.ford.com (Internal Mail Agent-1); Fri, 6 Apr 2001 04:57:15 -0400 (EDT) Received: by mailfw5.ford.com (Internal Mail Agent-0); Fri, 6 Apr 2001 04:57:15 -0400 (EDT) From: "rchapma6 ford.com" To: "'David.Madeo@morganstanley.com'" , "Greg Black" cc: "Paul Eggert" , tz@elsie.nci.nih.gov, ietf-calendar@imc.org Subject: RE: Updated Australian time zone names/strings Date: Fri, 6 Apr 2001 04:54:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) X-WSS-ID: 16D359C4730726-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Your cross posting caution was noted I similarly lurk on the ietf list and occasionally sally forth to pass comment. The issue of the ambiguity of abbreviations like "EST" might best be solved by prefixing the three initials with the ISO Country Code see http://itl5.itlnet.com/isocodes.htm for examples. So the Australian EST would be AUEST and the US EST would be USEST. There may be another advantage to do with Daylight Savings/Summer Time. These (I believe) are determined at national or regional level so those countries who do observe Daylight Savings/Summer Time would have two entries per time zone. for example:- USEST UTC -5:00 USEDT UTC -4:00 Add to this the entry and exit criteria for Daylight Savings/Summer Time (and I hope I get this correct!) USEST UTC -5:00 Last Sunday in September USEDT UTC -4:00 Last Sunday in March GBGMT UTC 0:00 Last Sunday in October GBBST UTC +1:00 4th Sunday in March?? or the explicit dates if there is no sensible way of determining when the clocks change! For countries like Japan where they do not observe Daylight Savings the entry would look like JPxxx UTC +8:00 The absence of date showing non-observation Hope that helps a bit Roger Chapman Specilaist, Collaborative Applications Ford Systems Integration Center Information Technology and eBusiness Ford Motor Company -----Original Message----- From: David Madeo [mailto:David.Madeo@morganstanley.com] Sent: 06 April 2001 05:21 To: Greg Black Cc: Paul Eggert; tz@elsie.nci.nih.gov; ietf-calendar@imc.org Subject: Re: Updated Australian time zone names/strings Since I'm a lurker on both the tz and ietf lists, occasionally I see that it's appropriate to mix the audiences. This thread from the tz list is whether the tz maintainers should be trying to uniquify the timezone abbreviations such as "EST" which can mean several different timezones around the world, depending on whether you ask an Australian or an American. Greg Black wrote: > Paul Eggert wrote: > > | * How important are unique time zone abbreviations? > | > | Here I tend to agree with the point (most recently made by Chris > | Newman) that unique abbreviations should not be essential for proper > | operation of software. > > I think this flies in the face of common sense and the old > principle about being flexible in handling input while trying to > make output as good as possible. I'd certainly prefer unique and unambiguous abbreviations (AEST) as well as unique names "Australia/Sydney" based on the Continent/Largest City. Anytime we can reduce confusion and make something easier for people *and* computers to understand, we should. > || The final decision is Arthur David Olson's, since he's maintaining > | the database. My own mild preference for now (given what's been said > | so far) would be to leave it alone. > > I know the decision is in Arthur David Olson's hands, but I > would imagine that he will be responsive to the wishes of the > affected parties. I'm keen to see more input into this. The tz database is the closest thing to a "standard" timezone listing. As such, there's a lot of benefit if it does the "right" thing. I've cc'd the ietf list since they are effectively "users" of this sort of data and might have some input. dmadeo From owner-ietf-calendar@mail.imc.org Fri Apr 6 10:31:58 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10328 for ; Fri, 6 Apr 2001 10:31:57 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA29387 for ietf-calendar-bks; Fri, 6 Apr 2001 07:10:38 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29380 for ; Fri, 6 Apr 2001 07:10:36 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f36EHJ606210 for ; Fri, 6 Apr 2001 10:17:19 -0400 Message-ID: <3ACDCFEE.7B456017@ecal.com> Date: Fri, 06 Apr 2001 10:17:19 -0400 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: Omit VTIMEZONE when using global identifiers? References: <3ACC7487.7B72D56D@steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit George Babics wrote: > Eric Busboom wrote: > > > Also, if we define the global TZ registry, can we remove the requirement > > to include a VTIMEZONE in a component when the TZID parameters reference > > global names? > > Good idea. > > What happens when an application encounters a timezone from the > the global TZ registry that was recently added, and that the application > is not aware about? Or, worse, if it's a TZID that the receiver recognizes, but whose definition has changed. The sender knows the change, the receiver doesn't. Result: the receiver will show up to the meeting at the wrong time--unacceptable. I think we have to keep the VTIMEZONE in, no matter what. -- /================================================================\ |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 Fri Apr 6 10:56:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11147 for ; Fri, 6 Apr 2001 10:56:20 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA01409 for ietf-calendar-bks; Fri, 6 Apr 2001 07:39:58 -0700 (PDT) Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA01403 for ; Fri, 6 Apr 2001 07:39:56 -0700 (PDT) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.11.3/8.11.3) id f36EdvX29104; Fri, 6 Apr 2001 10:39:57 -0400 (EDT) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9865679951.028978; Fri, 6 Apr 01 10:39:55 -0400 Received: (from uucp@localhost) by hqvsbh1.ms.com (8.11.3/8.11.3) id f36EdsJ28929; Fri, 6 Apr 2001 10:39:54 -0400 (EDT) Received: from unknown(144.14.206.187) by hqvsbh1 via smap (4.1) id sma.9865679931.028849; Fri, 6 Apr 01 10:39:53 -0400 Received: from morganstanley.com (openmadeo.morgan.com [144.14.42.219]) by pismh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id KAA27324; Fri, 6 Apr 2001 10:39:53 -0400 (EDT) Message-ID: <3ACDD53A.592AE8DC@morganstanley.com> Date: Fri, 06 Apr 2001 10:39:54 -0400 From: David Madeo Reply-To: David.Madeo@morganstanley.com Organization: Morgan Stanley X-Mailer: Mozilla 4.75 [en]C-CCK-MCD MS4.75 V20001029.1 (Windows NT 5.0; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? References: <3ACC7487.7B72D56D@steltor.com> <3ACDCFEE.7B456017@ecal.com> Content-Type: multipart/mixed; boundary="------------B9BDE611E60C3B485570D8F4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B9BDE611E60C3B485570D8F4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > George Babics wrote: > > Eric Busboom wrote: > > > Also, if we define the global TZ registry, can we remove the requirement > > > to include a VTIMEZONE in a component when the TZID parameters reference > > > global names? > > > > Good idea. > > > > What happens when an application encounters a timezone from the > > the global TZ registry that was recently added, and that the application > > is not aware about? > > Or, worse, if it's a TZID that the receiver recognizes, but whose definition has > changed. The sender knows the change, the receiver doesn't. Result: the receiver > will show up to the meeting at the wrong time--unacceptable. > > I think we have to keep the VTIMEZONE in, no matter what. Or a version number with the TZID. The tz database has a simple yearletter code (eg: 2001b) for it's versioning. If the ietf does somehow codify the tz database, that might come in handy. dmadeo --------------B9BDE611E60C3B485570D8F4 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;pager:dmadeo@skytel.com or 888-354-8513 tel;cell:917-295-9893 tel;fax:877-545-8846 tel;work:212-762-2348 x-mozilla-html:TRUE url:http://www.morganstanley.com org:Morgan Stanley;Information Technology adr:;;750 Seventh Ave;New York;NY;10019;United States version:2.1 email;internet:David.Madeo@morganstanley.com title:Vice President fn:David Madeo end:vcard --------------B9BDE611E60C3B485570D8F4-- From owner-ietf-calendar@mail.imc.org Fri Apr 6 11:01:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11330 for ; Fri, 6 Apr 2001 11:01:43 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA02031 for ietf-calendar-bks; Fri, 6 Apr 2001 07:50:25 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA02023 for ; Fri, 6 Apr 2001 07:50:22 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f36Ev5606426 for ; Fri, 6 Apr 2001 10:57:06 -0400 Message-ID: <3ACDD941.7BF5A917@ecal.com> Date: Fri, 06 Apr 2001 10:57:05 -0400 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: Omit VTIMEZONE when using global identifiers? References: <3ACC7487.7B72D56D@steltor.com> <3ACDCFEE.7B456017@ecal.com> <3ACDD53A.592AE8DC@morganstanley.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 David Madeo wrote: > John Stracke wrote: > > > Or, worse, if it's a TZID that the receiver recognizes, but whose definition has > > changed. The sender knows the change, the receiver doesn't. Result: the receiver > > will show up to the meeting at the wrong time--unacceptable. > > > > I think we have to keep the VTIMEZONE in, no matter what. > > Or a version number with the TZID. That's almost as bad--then you send me a TZID with a version number I don't recognize. I'm not misleading the user any more, but I'm not getting them useful information, either. I have a basic question about this thread: WHY? We have a *wonderful* mechanism which lets two people schedule a meeting, at the same time, even if their CUAs don't have the same timezone definitions. Why are we talking about sabotaging it? -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Yes, sir, we've graphed the data. It's a smiley| |francis@ecal.com|face, sir. | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 6 11:03:52 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11427 for ; Fri, 6 Apr 2001 11:03:52 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA02130 for ietf-calendar-bks; Fri, 6 Apr 2001 07:52:45 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA02126 for ; Fri, 6 Apr 2001 07:52:44 -0700 (PDT) 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 KAA18693 for ; Fri, 6 Apr 2001 10:52:15 -0400 Received: from c-1244.steltor.com (C-1244 [101.1.46.10]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2M0X4SS0; Fri, 6 Apr 2001 10:50:34 -0400 Message-Id: <5.0.0.25.0.20010406101607.025628b0@apollo> X-Sender: aland@apollo X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Apr 2001 10:52:00 -0400 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: Omit VTIMEZONE when using global identifiers? In-Reply-To: <3ACDCFEE.7B456017@ecal.com> References: <3ACC7487.7B72D56D@steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:17 2001-04-06 -0400, John Stracke wrote: >Or, worse, if it's a TZID that the receiver recognizes, but whose >definition has >changed. The sender knows the change, the receiver doesn't. Result: the >receiver >will show up to the meeting at the wrong time--unacceptable. > >I think we have to keep the VTIMEZONE in, no matter what. So what's the point of using the unique name? All of the timezone information is available in the VTIMEZONE, and it has to be parsed (unless the names are also unique by TZ db version) to double-check that the sender isn't using an older/newer version of the TZ database than the receiver. One reason for using the unique TZ name could be to ensure that both sender and receiver refer to the timezone by the same Country/City pair, when multiple cities share the same timezone rules. Perhaps some users would object to a system that, for example, always assumes EST is /US/New-York when receiving iCalendar, even when the sender specifies the timezone as /Canada/Toronto. --Alan From owner-ietf-calendar@mail.imc.org Fri Apr 6 11:12:46 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11665 for ; Fri, 6 Apr 2001 11:12:46 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA02184 for ietf-calendar-bks; Fri, 6 Apr 2001 07:54:12 -0700 (PDT) Received: from amsmta06-svc.chello.nl (mail-out.chello.nl [213.46.240.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA02179 for ; Fri, 6 Apr 2001 07:54:11 -0700 (PDT) Received: from khazad-dum.copa.nl ([212.187.86.233]) by amsmta06-svc.chello.nl (InterMail vK.4.03.02.00 201-232-124 license f747fce8063b429e7fcd66ee14ce8c58) with ESMTP id <20010406145508.KBLY24449.amsmta06-svc@khazad-dum.copa.nl> for ; Fri, 6 Apr 2001 16:55:08 +0200 Received: from martijn by khazad-dum.copa.nl with local (Exim 3.22 #1 (Debian)) id 14lXem-0001ZE-00 for ; Fri, 06 Apr 2001 16:56:12 +0200 Date: Fri, 6 Apr 2001 16:56:12 +0200 From: Martijn van Beers To: ietf-calendar@imc.org Subject: CAP SQLmin Message-ID: <20010406165612.A5915@khazad-dum.copa.nl> Mail-Followup-To: Martijn van Beers , ietf-calendar@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I was looking at the query-min syntax for the VQUERY component, and I was wondering how to handle AND/OR. there's no parentheses in the syntax, so 'expr AND expr OR expr' seem ambiguous to me. Is it supposed to mean '(expr) AND (expr OR expr)' or '(expr AND expr) OR expr'? Or are things like that just not allowed? I think at least some clarification is in order. Martijn -- Martijn van Beers From owner-ietf-calendar@mail.imc.org Fri Apr 6 11:54:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12836 for ; Fri, 6 Apr 2001 11:54:20 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA08095 for ietf-calendar-bks; Fri, 6 Apr 2001 08:41:03 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA08090 for ; Fri, 6 Apr 2001 08:41:02 -0700 (PDT) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36FdeS28741; Fri, 6 Apr 2001 08:39:42 -0700 (PDT) Received: from netscape.com (h-198-93-95-109.mcom.com [198.93.95.109]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id IAA27238863; Fri, 6 Apr 2001 08:44:26 -0700 (PDT) Message-ID: <3ACDE3CB.6F59D381@netscape.com> Date: Fri, 06 Apr 2001 08:42:03 -0700 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Martijn van Beers CC: ietf-calendar@imc.org, George Babics Subject: Re: CAP SQLmin References: <20010406165612.A5915@khazad-dum.copa.nl> Content-Type: multipart/mixed; boundary="------------779E1655DC8D948A907C771E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------779E1655DC8D948A907C771E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martijn van Beers wrote: > Hi, > > I was looking at the query-min syntax for the VQUERY component, and > I was wondering how to handle AND/OR. there's no parentheses in the > syntax, so 'expr AND expr OR expr' seem ambiguous to me. Is it > supposed to mean '(expr) AND (expr OR expr)' or > '(expr AND expr) OR expr'? Or are things like that just not > allowed? I think at least some clarification is in order. Thanks for pointing this out. I think you're right, we need some clarification. We'll propose something. -Steve --------------779E1655DC8D948A907C771E Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------779E1655DC8D948A907C771E-- From owner-ietf-calendar@mail.imc.org Fri Apr 6 11:58:34 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12987 for ; Fri, 6 Apr 2001 11:58:32 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA07389 for ietf-calendar-bks; Fri, 6 Apr 2001 08:38:29 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA07370 for ; Fri, 6 Apr 2001 08:38:27 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f36Fj9606673 for ; Fri, 6 Apr 2001 11:45:09 -0400 Message-ID: <3ACDE483.27A3FB45@ecal.com> Date: Fri, 06 Apr 2001 11:45:07 -0400 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: Omit VTIMEZONE when using global identifiers? References: <3ACC7487.7B72D56D@steltor.com> <5.0.0.25.0.20010406101607.025628b0@apollo> 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 Alan Davies wrote: > At 10:17 2001-04-06 -0400, John Stracke wrote: > >I think we have to keep the VTIMEZONE in, no matter what. > > So what's the point of using the unique name? In iCalendar--not much. In the UI, it might be vaguely useful for people to be able to carry their knowledge from CUA to CUA. -- /=================================================================\ |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 Apr 6 14:41:16 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16897 for ; Fri, 6 Apr 2001 14:41:12 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA17391 for ietf-calendar-bks; Fri, 6 Apr 2001 11:09:49 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17386 for ; Fri, 6 Apr 2001 11:09:47 -0700 (PDT) From: Bruce_Kahn@iris.com To: George Babics Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04042001 April 04, 2001 Message-ID: Date: Fri, 6 Apr 2001 14:14:45 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/06/2001 02:14:54 PM, Serialize complete at 04/06/2001 02:14:54 PM Content-Type: multipart/alternative; boundary="=_alternative 0063C52B85256A26_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063C52B85256A26_= Content-Type: text/plain; charset="us-ascii" George replied: > > Also, if we define the global TZ registry, can we remove the requirement > > to include a VTIMEZONE in a component when the TZID parameters reference > > global names? > > Good idea. > > What happens when an application encounters a timezone from the > the global TZ registry that was recently added, and that the application > is not aware about? Should it assume that it came from the global registry > and print a message saying something like: "your timezone registry may be out > of date, please update." Whew, got lots of group backlog in just 4 days. Good thing its possible to see a threaded view to keep up on it all... Im not sure that not sending global definitions is that good an idea just yet. Besides the case that a client may not have easy access to the absolute latest defintions (via some TBD mechanism that we haven't even thought about building yet) there is the problem that defintions may change and get updated. For example, between 1973 and 1976 the US changed their DST shift rules every year. France and Brazil set theirs on some regular basis as well. As such, a client that uses the absolutely latest defintion may send a request to a client that has an earlier definition of the exact same TZID. As such, misscheduling can occur. The only solid way to prevent this from happening is to require that the VTIMEZONE information is always sent by the sender. That way the receiving clients can tell if their definition of the 'standard' TZID is the same or not. Otherwise we could have an issue with latency in timezone definition updates causing scheduling problems. Unless an entry has some really really funky repeat set, the VTIMEZONE info that covers it should not be prohibitively large to include. Of course for those .0001% of the end users out there who use a C&S system that allows for truely infinitely repeating events this could eventually become a bandwidth issue but I expect a newer protocol (or at least a newer revision) to deal with this kind of fringe use case later on... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0063C52B85256A26_= Content-Type: text/html; charset="us-ascii"
George replied:
> > Also, if we define the global TZ registry, can we remove the requirement
> > to include a VTIMEZONE in a component when the TZID parameters reference
> > global names?
>
>   Good idea.
>  
>   What happens when an application encounters a timezone from the
> the global TZ registry that was recently added, and that the application
> is not aware about? Should it assume that it came from the global registry
> and print a message saying something like: "your timezone registry may be out
> of date, please update."

Whew, got lots of group backlog in just 4 days.  Good thing its possible to see a threaded view to keep up on it all...

Im not sure that not sending global definitions is that good an idea just yet.  Besides the case that a client may not have easy access to the absolute latest defintions (via some TBD mechanism that we haven't even thought about building yet) there is the problem that defintions may change and get updated.  For example, between 1973 and 1976 the US changed their DST shift rules every year.  France and Brazil set theirs on some regular basis as well.  As such, a client that uses the absolutely latest defintion may send a request to a client that has an earlier definition of the exact same TZID.  As such, misscheduling can occur.

The only solid way to prevent this from happening is to require that the VTIMEZONE information is always sent by the sender.  That way the receiving clients can tell if their definition of the 'standard' TZID is the same or not.  Otherwise we could have an issue with latency in timezone definition updates causing scheduling problems.

Unless an entry has some really really funky repeat set, the VTIMEZONE info that covers it should not be prohibitively large to include.  Of course for those .0001% of the end users out there who use a C&S system that allows for truely infinitely repeating events this could eventually become a bandwidth issue but I expect a newer protocol (or at least a newer revision) to deal with this kind of fringe use case later on...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0063C52B85256A26_=-- From owner-ietf-calendar@mail.imc.org Fri Apr 6 14:45:05 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17027 for ; Fri, 6 Apr 2001 14:45:00 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA17705 for ietf-calendar-bks; Fri, 6 Apr 2001 11:16:34 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17700 for ; Fri, 6 Apr 2001 11:16:33 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04042001 April 04, 2001 Message-ID: Date: Fri, 6 Apr 2001 14:21:31 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/06/2001 02:21:39 PM, Serialize complete at 04/06/2001 02:21:39 PM Content-Type: multipart/alternative; boundary="=_alternative 006463C185256A26_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006463C185256A26_= Content-Type: text/plain; charset="us-ascii" Alan asked: > So what's the point of using the unique name? Hmm, how about more than 1 VEVENT in the VCALENDAR that uses a different TZID?? How about having an RDATE with a different TZID because its repeating in a different timezone (ie: think TV or satelite rebroadcasts, "on the road" presentations, etc)?? Given that at least these 2 cases could require > 1 TZID I think I can see why its necessary. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006463C185256A26_= Content-Type: text/html; charset="us-ascii"
Alan asked:
> So what's the point of using the unique name?

Hmm, how about more than 1 VEVENT in the VCALENDAR that uses a different TZID??

How about having an RDATE with a different TZID because its repeating in a different timezone (ie: think TV or satelite rebroadcasts, "on the road" presentations, etc)??

Given that at least these 2 cases could require > 1 TZID I think I can see why its necessary.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006463C185256A26_=-- From owner-ietf-calendar@mail.imc.org Fri Apr 6 14:50:31 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17221 for ; Fri, 6 Apr 2001 14:50:28 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA18148 for ietf-calendar-bks; Fri, 6 Apr 2001 11:23:24 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA18141 for ; Fri, 6 Apr 2001 11:23:20 -0700 (PDT) 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 OAA24181 for ; Fri, 6 Apr 2001 14:22:50 -0400 Received: from c-1244.steltor.com (C-1244 [101.1.46.10]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2M0X444S; Fri, 6 Apr 2001 14:21:10 -0400 Message-Id: <5.0.0.25.0.20010406142033.00af07c0@apollo> X-Sender: aland@apollo X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Apr 2001 14:22:35 -0400 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: Omit VTIMEZONE when using global identifiers? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:21 2001-04-06 -0400, Bruce_Kahn@iris.com wrote: >Alan asked: > > So what's the point of using the unique name? > >Hmm, how about more than 1 VEVENT in the VCALENDAR that uses a different >TZID?? > >How about having an RDATE with a different TZID because its repeating in a >different timezone (ie: think TV or satelite rebroadcasts, "on the road" >presentations, etc)?? > >Given that at least these 2 cases could require > 1 TZID I think I can see >why its necessary. You don't need a globally unique TZID to do that, just an ID that's unique within the VCALENDAR, for which you can choose any text string that you like. RFC2445 4.2.19 The presence of the SOLIDUS character (US-ASCII decimal 47) as a prefix, indicates that this TZID represents a unique ID in a globally defined time zone registry (when such registry is defined). Note: This document does not define a naming convention for time zone identifiers. Implementers may want to use the naming conventions defined in existing time zone specifications such as the public-domain Olson database [TZ]. The specification of globally unique time zone identifiers is not addressed by this document and is left for future study. --Alan From owner-ietf-calendar@mail.imc.org Fri Apr 6 15:12:26 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17784 for ; Fri, 6 Apr 2001 15:12:25 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA19631 for ietf-calendar-bks; Fri, 6 Apr 2001 11:53:54 -0700 (PDT) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19626 for ; Fri, 6 Apr 2001 11:53:50 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f36J0Y607755 for ; Fri, 6 Apr 2001 15:00:34 -0400 Message-ID: <3ACE1251.50E3666D@ecal.com> Date: Fri, 06 Apr 2001 15:00:33 -0400 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: Omit VTIMEZONE when using global identifiers? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > Alan asked: > > So what's the point of using the unique name? > > Hmm, how about more than 1 VEVENT in the VCALENDAR that uses a > different TZID?? No, I think he means globally unique. Two different timezones in the same iCalendar could be solved by on-the-fly TZIDs. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |I'm not a bibliophile, I'm a bibliophiliac. Put| |francis@ecal.com|me in a bookstore, & my wallet bleeds. | \================================================================/ From owner-ietf-calendar@mail.imc.org Sun Apr 8 03:27:01 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 DAA02955 for ; Sun, 8 Apr 2001 03:27:00 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA21929 for ietf-calendar-bks; Sun, 8 Apr 2001 00:00:21 -0700 (PDT) Received: from royer.com ([206.162.94.80]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA21909 for ; Sun, 8 Apr 2001 00:00:16 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA07658 for ietf-calendar@imc.org; Sun, 8 Apr 2001 00:00:04 -0700 (PDT) Date: Sun, 8 Apr 2001 00:00:04 -0700 (PDT) From: Doug Royer Message-Id: <200104080700.AAA07658@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 Apr 9 14:33:12 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 OAA13782 for ; Mon, 9 Apr 2001 14:33:12 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA19072 for ietf-calendar-bks; Mon, 9 Apr 2001 11:12:49 -0700 (PDT) Received: from strauss.udel.edu (trevor@strauss.udel.edu [128.175.13.74]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19064 for ; Mon, 9 Apr 2001 11:12:47 -0700 (PDT) Received: from localhost (trevor@localhost) by strauss.udel.edu (8.9.3/8.9.3) with ESMTP id OAA09024 for ; Mon, 9 Apr 2001 14:12:46 -0400 (EDT) Date: Mon, 9 Apr 2001 14:12:46 -0400 (EDT) From: Trevor Moore To: Subject: Talking with Netscape 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'm trying to set up a calendar server to talk with Netscape calendar. I've got Netscape connecting to my server (for a short time) but it's sending me things that I'm unsure as to what they mean. Here is what it prints: 0 0 64 0 java.net.SocketException: Connection reset by peer: JVM_recv in socket input stream read Process completed successfully Now, I'm assuming those 0's and 64 are ASCII characters, which would be, Null char, and the @ symbol. I can't get Netscape to send me anything other than this. What does this mean? Do I have to send Netscape some sort of hello to connect properly, and if so, how do I do that? I'm hoping someone here can help, me out with this, because I've gotten stuck at every other turn. Trevor Moore trevor@udel.edu From owner-ietf-calendar@mail.imc.org Tue Apr 10 07:35: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 HAA11689 for ; Tue, 10 Apr 2001 07:35:09 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA14199 for ietf-calendar-bks; Tue, 10 Apr 2001 04:19:38 -0700 (PDT) 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 EAA14186 for ; Tue, 10 Apr 2001 04:19:34 -0700 (PDT) Received: from metamatrix.se (IDENT:pbb@dublin.metamatrix.se [213.88.195.121]) by smtp.wineasy.se with ESMTP id f3ABJvT08474 for ; Tue, 10 Apr 2001 13:19:57 +0200 Message-ID: <3AD2EC68.53055535@metamatrix.se> Date: Tue, 10 Apr 2001 13:20:08 +0200 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: SKiCal component property extensions - WHURL 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 4.4 What URL Property Name: WHURL Purpose: This property defines a Uniform Resource Locator (URL) associated with the SKiSource the SKICal object is describing. Value Type: URI Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: This property may be used in a SKiCal object to convey a URL for information about the SKiSource. The difference between WHURL and the iCal Property URL as defined in RFC2445 section 4.8.4.6 is that while URL points to some place "where a more dynamic rendition of the calendar information associated with the calendar component can be found", WHURL points to the "home page" of the SKiSource itself. This memo does not attempt to standardize the form of the URI, nor the format of the resource pointed to by the property value. Format Definition: The property is defined by the following notation: whurl = "WHURL" whurlparam ":" uri CRLF whurlparam = *( ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following is an example of this property: WHURL:http://www.superbowl.com/ From owner-ietf-calendar@mail.imc.org Tue Apr 10 08:03: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 IAA12338 for ; Tue, 10 Apr 2001 08:03:16 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA16838 for ietf-calendar-bks; Tue, 10 Apr 2001 04:51:24 -0700 (PDT) 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 EAA16822 for ; Tue, 10 Apr 2001 04:51:21 -0700 (PDT) Received: from metaacer (unknown [213.88.195.108]) by ljudo.shortlist.se (Postfix) with SMTP id 6B73EB3572; Tue, 10 Apr 2001 13:51:20 +0200 (CEST) From: "Greg FitzPatrick" To: "Eric Busboom" , Subject: SkiCal property parameter extensions Date: Tue, 10 Apr 2001 13:50:00 +0200 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.50.4522.1200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit SKiCal has defined a group of general parameters, they can be found in our draft in the following section: 4.2 Property Parameters: TERM, OPTIME, OPRULES, ITEM, SKIROLE The first four are all used for qualifying Properties with time, the fifth is the result of discussions on this list; where the issue was: a1) Can SKiCal use ROLE in a wider scope than originally designed into 2445 or a2) The scope of ROLE in 2445 is actually wider than it appears to be. Originally SKiCal had defined a unique ROLE parameter for each property; DIPROLE, DITROLE, DITHROLE, but after comments primarily from Bruce we have reduced these to one ROLE parameter. So the issue was then ; ROLE or SKIROLE and we opted for SKIROLE I will now, in accordance with the agreed on submission methods, submit these property parameters using one mail for each. From owner-ietf-calendar@mail.imc.org Tue Apr 10 08:07: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 IAA12537 for ; Tue, 10 Apr 2001 08:07:14 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA16862 for ietf-calendar-bks; Tue, 10 Apr 2001 04:51:32 -0700 (PDT) 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 EAA16824 for ; Tue, 10 Apr 2001 04:51:21 -0700 (PDT) Received: from metaacer (unknown [213.88.195.108]) by ljudo.shortlist.se (Postfix) with SMTP id 5FD58B3570; Tue, 10 Apr 2001 13:51:21 +0200 (CEST) From: "Greg FitzPatrick" To: "Eric Busboom" , Subject: SkiCal property parameter extensions -TERM Date: Tue, 10 Apr 2001 13:50:01 +0200 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.50.4522.1200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Parameter Name: TERM Purpose: This parameter is used to qualify properties using date and date-time values as defined in RFC 2445 - 4.3.4 Date and 4.3.5 Date-Time. Term declares a DATETIME period during which a set of access rules will be valid. Format Definition: The property parameter is defined by the following notation: termparam = "term" "=" (date-time / date) "/" ((date-time / date) / ( "THISANDPRIOR" / "THISANDFUTURE)) Description: Facilitates date-time values as qualifiers for auxiliary features of a SkiSource. The TERM parameter indicates a period for the property it is qualifying . This period might be constructed by two date-time values separated by a "/" or one date-time value separated by a "/" from one of two value types; THISANDPRIOR and THISANDFUTURE. By the use of THISANDPRIOR the date-time value is used to signify the end of a TERM whose start time is either not relevant or unknown. By the use of THISANDFUTURE the date-time value is used to signify the start of a TERM whose conclusion is either not relevant or unknown. Example: BOOKINGS;TERM=20010313T140000Z/THISANDFUTURE:Tickets2go BOOKINGS;TERM=20001128T143000Z EVENT-LANGUAGE;TERM=20021002/20021009:no EVENT-LANGUAGE;TERM=20021010/20021014:fr From owner-ietf-calendar@mail.imc.org Tue Apr 10 08:10: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 IAA12616 for ; Tue, 10 Apr 2001 08:10:23 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA17480 for ietf-calendar-bks; Tue, 10 Apr 2001 04:55:01 -0700 (PDT) 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 EAA17472 for ; Tue, 10 Apr 2001 04:54:59 -0700 (PDT) Received: from metamatrix.se (IDENT:pbb@dublin.metamatrix.se [213.88.195.121]) by smtp.wineasy.se with ESMTP id f3ABtJo27895 for ; Tue, 10 Apr 2001 13:55:19 +0200 Message-ID: <3AD2F4B6.74768C77@metamatrix.se> Date: Tue, 10 Apr 2001 13:55:34 +0200 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: SKiCal component property extensions - ORIENTATION 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 4.3 Orientation Property Name: ORIENTATION Purpose: This property specifies the target audience for the SKiSource. Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: This property can facilitate SKiSource discovery. It can indicate that a SKiSource has a specific target audience, or that it is somehow related to a specific cause, faith, professional group, gender, ethnic group etc. This property has a different purpose than the CATEGORIES property used in iCal. A soccer match organized by a car manufacturer for teambuilding among employees and subcontractors could still be categorized as "sport" while the orientation could be "Mercedes car producers". Infomediaries can use this property to define their own specific customer orientation types without altering the values in CATEGORIES. Format Definition: The property is defined by the following notation: orientation = "ORIENTATION" orientationparam ":" text CRLF ; It is RECOMMENDED that the text value be ; chosen from a list, as described in Section 5 ; of the SKICal specification. orientationparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" orienttypeparam ) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) orienttypeparam = *(";" "ORIENTTYPE" "=" text) ; It is RECOMMENDED that the text value be ; chosen from a list, as described in Section 5 ; of the SKICal specification. Value Type: TEXT. Example: The following are examples of this property: ORIENTATION;ORIENTTYPE=Religious:Methodist ORIENTATION;ORIENTTYPE=DemographicsRus:Soccer Moms ORIENTATION;ORIENTTYPE=DemographicsRus:Champagne Set ORIENTATION;ORIENTTYPE=AgeGroup:Senior Citizens ORIENTATION;ORIENTTYPE=Gender:Female ORIENTATION;ORIENTTYPE=Sexual:Gay ORIENTATION;ORIENTTYPE=Occupation:Medical From owner-ietf-calendar@mail.imc.org Tue Apr 10 09:12: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 JAA14003 for ; Tue, 10 Apr 2001 09:12:23 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA21926 for ietf-calendar-bks; Tue, 10 Apr 2001 05:55:39 -0700 (PDT) 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 FAA21922 for ; Tue, 10 Apr 2001 05:55:37 -0700 (PDT) Received: from metaacer (unknown [213.88.195.108]) by ljudo.shortlist.se (Postfix) with SMTP id CCEDCB3572; Tue, 10 Apr 2001 14:55:36 +0200 (CEST) From: "Greg FitzPatrick" To: , "Eric Busboom" Subject: SV: SkiCal property parameter extensions - OPTIME Date: Tue, 10 Apr 2001 14:53:50 +0200 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.50.4522.1200 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 FAA21926 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA14003 2.3 Opening Times Parameter Name: OPTIME Purpose: This parameter is used to qualify properties using time values as defined in RFC 2445 - 4.3.12 Time. OPTIME declares a period of time when a set of access rules will be valid. Format Definition: The property parameter is defined by the following notation: optimeparam = "OPTIME" "=" (period-explicit / period-start) period-explicit = time "/" time period-start = time "/" dur-value Description: Facilitates time values as qualifiers for particular aspects of a SkiSource. The OPTIME parameter indicates a period of time when the property value is accessible or in a state of being "open" . If the property permits, multiple "period" values are specified by a COMMA character (US-ASCII decimal 44) separated list. There are two forms of a period of time. First, a period of time is identified by its start and its end. This format is expressed as the [ISO 8601] complete representation, basic format for "TIME" start of the period, followed by a SOLIDUS character (US- ASCII decimal 47), followed by the "TIME" of the end of the period. If the start of the period is of a greater value than the end of the period, 24 hours will be added to the end value in order to calculate the correct time period (a so called "Midnight crossing"). For example 180000Z/030000Z would be calculated as starting at 18:00:00 UTC and ending at 03:00:00 UTC on the following day. 200000Z/195959Z would be calculated as a 24 hour period (- 1 second) A period of time can also be defined by a start time and a positive duration of time. The format is expressed as the [ISO 8601] complete representation, basic format for the "TIME" start of the period, followed by a SOLIDUS character (US-ASCII decimal 47), followed by the [ISO 8601] basic format for "DURATION" of the period. Example: The period starting at 18:00:00 UTC and ending at 23:30:00 UTC would be: 180000Z/2330000Z which is the equivalent to 180000Z/PT5H30M. The later method is the preferred syntax for OPTIME since it allows the declarations of times exceeding 24 hours. Examples: BOOKINGS;TERM=20011214/THISANDPRIOR;OPTIME=130000Z/170000Z:The front Box Office RESOURCES;OPTIME=120000Z/220000Z:Hot food RECOMMENDED;OPTIME=130000Z/150000Z,220000Z/230000Z:Avoid the crowds for good seats LOCATION;OPTIME=110000Z/023000Z:Palais de Congrès BEGIN:VEVENT SUMMARY:The schedule for demonstrations in our booth at the trade show, shorter sessions in the afternoon. PERSONS;SKIROLE="demonstrator";OPTIME=short110000Z/111500Z,120000Z,140000Z/1 41000Z,150000Z/151000Z,160000Z/161000Z:Eva PERSONS;SKIROLE="demonstrator";OPTIME=103000Z/104500Z,123000Z/124500Z,143000 Z/144000Z,153000Z/154000Z,163000Z/164000Z:Lisa END:VEVENT From owner-ietf-calendar@mail.imc.org Tue Apr 10 09:40: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 JAA14823 for ; Tue, 10 Apr 2001 09:40:36 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA22680 for ietf-calendar-bks; Tue, 10 Apr 2001 06:20:37 -0700 (PDT) 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 GAA22674 for ; Tue, 10 Apr 2001 06:20:28 -0700 (PDT) Received: from metaacer (unknown [213.88.195.108]) by ljudo.shortlist.se (Postfix) with SMTP id B3A3AB3573; Tue, 10 Apr 2001 15:19:37 +0200 (CEST) From: "Greg FitzPatrick" To: , "Eric Busboom" Subject: SV: SkiCal property parameter extensions -OPRULES Date: Tue, 10 Apr 2001 15:17:41 +0200 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.50.4522.1200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 2.4 Opening Time Rules Parameter Name: OPRULES Purpose: This parameter is used to qualify properties by the "BYxxx" values as defined in RFC 2445 - 4.3.10 Recurrence Rule. OPRULES define the recurrence rules for when a particular set of OpTimes will be valid. Format Definition: The property parameter is defined by the following notation: oprulesparam = (";" "BYDAY" "=" bywdaylist )/( ";" "BYMONTHDAY" "= bymodaylist )/( ";" "BYYEARDAY" "=" byyrdaylist ) Description: Facilitates time values as qualifiers for particular aspects of a SkiSource. The OPRULES parameter works similarly to the Recurrence rules of RFC 2445 4.3.10 with the following distinctions. Frequency is limited to DAYS. The COUNT and UNTIL rules are not used. Multiple "recur" values are not allowed. Both are replaced by the SkiCal parameter TERM. With this set of rules the vast majority of "Opening Times" and "Operating Times" can be stated. RESOURCES;BYDAY=MO,WE,FR;OPTIME=120000/220000:The Astoria Bar RESOURCES;BYDAY=TU,TH;OPTIME=160000/240000:The Astoria Bar Example: BOOKINGS;TERM=20011214/THISANDPRIOR;OPTIME=130000Z/170000Z;BYDAY=MO,TU,WE,TH ,FR:The front Box-Office REQUIRED;OPTIME=180000Z/020000Z;BYDAY=SA:Evening Dress RECOMMENDED;BYMONTHDAY=24:Avoid using our ATMs on national paydays LOCATION;BYYEARDAY=1:Pasadena Rose Bowl BEGIN:VEVENT SUMMARY: This is where you will find the Good Humor Ice Cream truck LOCATION:BYDAY=MO:Down Town LOCATION:BYDAY=TU:Up Town LOCATION:BYDAY=WE:North Town LOCATION:BYDAY=TH:South Town LOCATION:BYDAY=FR:East Town LOCATION:BYDAY=SA:West Town Warning: The above multiples of LOCATION is not allowed in 2445 From owner-ietf-calendar@mail.imc.org Tue Apr 10 11:58: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 LAA19208 for ; Tue, 10 Apr 2001 11:58:42 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA05180 for ietf-calendar-bks; Tue, 10 Apr 2001 08:40:21 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA05173 for ; Tue, 10 Apr 2001 08:40:20 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3AFdov00334 for ; Tue, 10 Apr 2001 08:39:50 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GBL26E00.FFQ; Tue, 10 Apr 2001 08:39:50 -0700 Message-ID: <3AD32933.90736870@netscape.com> Date: Tue, 10 Apr 2001 08:39:31 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Trevor Moore CC: ietf-calendar@imc.org Subject: Re: Talking with Netscape References: Content-Type: multipart/mixed; boundary="------------2E526EC19C1578A1FBED8B73" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2E526EC19C1578A1FBED8B73 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Trevor, Are you talking about the NCS product or the iPlanet Calendar Server (2.x or 5.x)? If you're working with the iPlanet product, I can nelp you. The iPlanet Calendar Server has an open, well-documented protocol. See http://docs.iplanet.com/docs/manuals/calendar.html . But I suspect you may be referring to an older product we OEM'd. If so, I may not be able to get help. We stopped shipping that product about 18 months ago -Steve Trevor Moore wrote: > I'm trying to set up a calendar server to talk with Netscape calendar. > I've got Netscape connecting to my server (for a short time) but it's > sending me things that I'm unsure as to what they mean. > > Here is what it prints: > > 0 > 0 > 64 > 0 > java.net.SocketException: Connection reset by peer: JVM_recv in socket > input stream read > Process completed successfully > > Now, I'm assuming those 0's and 64 are ASCII characters, which would be, > Null char, and the @ symbol. I can't get Netscape to send me anything > other than this. What does this mean? Do I have to send Netscape some sort > of hello to connect properly, and if so, how do I do that? > > I'm hoping someone here can help, me out with this, because I've gotten > stuck at every other turn. > > Trevor Moore > trevor@udel.edu --------------2E526EC19C1578A1FBED8B73 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------2E526EC19C1578A1FBED8B73-- From owner-ietf-calendar@mail.imc.org Tue Apr 10 14:28:04 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 OAA23075 for ; Tue, 10 Apr 2001 14:28:03 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA15283 for ietf-calendar-bks; Tue, 10 Apr 2001 11:04:59 -0700 (PDT) Received: from strauss.udel.edu (trevor@strauss.udel.edu [128.175.13.74]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15275 for ; Tue, 10 Apr 2001 11:04:58 -0700 (PDT) Received: from localhost (trevor@localhost) by strauss.udel.edu (8.9.3/8.9.3) with ESMTP id OAA12404; Tue, 10 Apr 2001 14:04:54 -0400 (EDT) Date: Tue, 10 Apr 2001 14:04:53 -0400 (EDT) From: Trevor Moore To: Steve Mansour cc: Subject: Re: Talking with Netscape In-Reply-To: <3AD32933.90736870@netscape.com> 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: The Calendar application of Netscape Communicator 4.08 w/ Calendar. I'm a student at the University of Delaware, and for my Internet Applications concentration I've taken an Independant Study where I've been told I need to develop some sort of server so that the secretaries can synchronize scheduling using Outlook and NS calendar. I've been told to start with Netscape. I've read through all of the RFCs and Protocols at http://www.imc.org/ietf-calendar/ , and have been stuck meddling with these things for a while now. It took me a while to even find out what port Netscape wanted to talk on (for some reason I couldn't find that documented anywhere). I'll check out your link, and hopefully that will shed some insight, but anything else useful you think I might need, I will be MORE than grateful if you could tell me =) Trevor Moore trevor@udel.edu On Tue, 10 Apr 2001, Steve Mansour wrote: > Trevor, > > Are you talking about the NCS product or the iPlanet Calendar Server (2.x or > 5.x)? If you're working with the iPlanet product, I can nelp you. The iPlanet > Calendar Server has an open, well-documented protocol. See > http://docs.iplanet.com/docs/manuals/calendar.html . > > But I suspect you may be referring to an older product we OEM'd. If so, I may > not be able to get help. We stopped shipping that product about 18 months ago > > -Steve > > Trevor Moore wrote: > > > I'm trying to set up a calendar server to talk with Netscape calendar. > > I've got Netscape connecting to my server (for a short time) but it's > > sending me things that I'm unsure as to what they mean. > > > > Here is what it prints: > > > > 0 > > 0 > > 64 > > 0 > > java.net.SocketException: Connection reset by peer: JVM_recv in socket > > input stream read > > Process completed successfully > > > > Now, I'm assuming those 0's and 64 are ASCII characters, which would be, > > Null char, and the @ symbol. I can't get Netscape to send me anything > > other than this. What does this mean? Do I have to send Netscape some sort > > of hello to connect properly, and if so, how do I do that? > > > > I'm hoping someone here can help, me out with this, because I've gotten > > stuck at every other turn. > > > > Trevor Moore > > trevor@udel.edu > From owner-ietf-calendar@mail.imc.org Wed Apr 11 09:44:30 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 JAA24033 for ; Wed, 11 Apr 2001 09:44:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA09979 for ietf-calendar-bks; Wed, 11 Apr 2001 06:22:02 -0700 (PDT) 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 GAA09970 for ; Wed, 11 Apr 2001 06:21:58 -0700 (PDT) Received: from metaacer (unknown [213.88.195.108]) by ljudo.shortlist.se (Postfix) with SMTP id 32C8FB3570; Wed, 11 Apr 2001 15:21:58 +0200 (CEST) From: "Greg FitzPatrick" To: Cc: "'Ietf-Calendar@Imc. Org'" Subject: Re: announce: www-rdf-calendar mailing list Date: Wed, 11 Apr 2001 15:19:13 +0200 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.50.4522.1200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan has cautioned us against cross-posting. And I will have to break faith with that on my very first mail:-) Hopefully many of us from the IETF CALSCH list will be joining in here and I hope that we can develop a method for signaling issues to those who are not subscribed to both lists. For the CALSCH list John Stracke has created a little bot that lurks over all IETF lists and lights up when anybody on any list names our RFC number or uses some other relevant term. This came about as the result of the IPTEL group using the RFC2445 recurrence rules without the knowledge of the CALSCH WG. Not that you have to ask permission of course, but the CALSCH WG had plenty of good suggestions that might have been overlooked. Greg From owner-ietf-calendar@mail.imc.org Wed Apr 11 11:22: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 LAA26035 for ; Wed, 11 Apr 2001 11:22:10 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA17816 for ietf-calendar-bks; Wed, 11 Apr 2001 08:03:24 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17811 for ; Wed, 11 Apr 2001 08:03:22 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3BFAT502505; Wed, 11 Apr 2001 11:10:29 -0400 Message-ID: <3AD473E3.7D4D655E@ecal.com> Date: Wed, 11 Apr 2001 11:10:27 -0400 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: Greg FitzPatrick CC: www-rdf-calendar@w3.org, "'Ietf-Calendar@Imc. Org'" Subject: Re: announce: www-rdf-calendar mailing list 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: > For the CALSCH list John Stracke has created a little bot that lurks over > all IETF lists and lights up when anybody on any list names our RFC number > or uses some other relevant term. Not lists, it just monitors Internet-Drafts. -- /================================================================\ |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 Apr 11 11:56:09 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 LAA26882 for ; Wed, 11 Apr 2001 11:56:09 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA19536 for ietf-calendar-bks; Wed, 11 Apr 2001 08:26:13 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA19531 for ; Wed, 11 Apr 2001 08:26:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3BFPfv21980 for ; Wed, 11 Apr 2001 08:25:41 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GBMW6U00.J3L; Wed, 11 Apr 2001 08:25:42 -0700 Message-ID: <3AD47760.57CD8123@netscape.com> Date: Wed, 11 Apr 2001 08:25:20 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Greg FitzPatrick CC: www-rdf-calendar@w3.org, "'Ietf-Calendar@Imc. Org'" Subject: Re: announce: www-rdf-calendar mailing list References: Content-Type: multipart/mixed; boundary="------------245F2BA384286822B3D523D8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------245F2BA384286822B3D523D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit this bot sounds pretty cool. So, John, can you make the information your little bot finds available to the rest of us? -Steve Greg FitzPatrick wrote: > Dan has cautioned us against cross-posting. > > And I will have to break faith with that on my very first mail:-) > > Hopefully many of us from the IETF CALSCH list will be joining in here and I > hope that we can develop a method for signaling issues to those who are not > subscribed to both lists. > > For the CALSCH list John Stracke has created a little bot that lurks over > all IETF lists and lights up when anybody on any list names our RFC number > or uses some other relevant term. This came about as the result of the > IPTEL group using the RFC2445 recurrence rules without the knowledge of the > CALSCH WG. Not that you have to ask permission of course, but the CALSCH WG > had plenty of good suggestions that might have been overlooked. > > Greg --------------245F2BA384286822B3D523D8 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------245F2BA384286822B3D523D8-- From owner-ietf-calendar@mail.imc.org Wed Apr 11 12:45:45 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 MAA28469 for ; Wed, 11 Apr 2001 12:45:44 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA28046 for ietf-calendar-bks; Wed, 11 Apr 2001 09:28:02 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA28041 for ; Wed, 11 Apr 2001 09:28:00 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3BGZI502820; Wed, 11 Apr 2001 12:35:19 -0400 Message-ID: <3AD487C5.51B388EC@ecal.com> Date: Wed, 11 Apr 2001 12:35:17 -0400 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: www-rdf-calendar@w3.org Subject: Re: announce: www-rdf-calendar mailing list References: <3AD47760.57CD8123@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: > this bot sounds pretty cool. So, John, can you make the information your little > bot finds available to the rest of us? Oh, yeah--if it finds any calsch-related Draft, it sends a message to the list. (Unfortunately, the one time it found anything, I found that it was misconfigured, and the message bounced...but it was a false alarm anyway. :-) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"If there's anything The Flintstones have taught| |francis@ecal.com|us, it's that pelicans can be used to mix | | |cement." -- Homer Simpson | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 11 13:28: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 NAA29400 for ; Wed, 11 Apr 2001 13:28:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA29994 for ietf-calendar-bks; Wed, 11 Apr 2001 10:10:07 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29990 for ; Wed, 11 Apr 2001 10:10:05 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA25034; Wed, 11 Apr 2001 12:07:20 -0500 From: "Shannon J. Clark" To: "'Ietf-Calendar@Imc. Org'" Cc: Subject: RE: announce: www-rdf-calendar mailing list Date: Wed, 11 Apr 2001 12:09:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <3AD487C5.51B388EC@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, If it is working - have you offered it as a tool to the rest of the IETF working groups? That is each working group has a very similar set of problems (some encounter it much more frequently than we do). From what I have observed in my participation over this last year - anything that can be done to make the various standards bodies communicate with each other better, avoid duplicating efforts, and keep up on what other groups are working on is fundamentally a very good thing and a major step forward. Just my two cents. Shannon (it would also be interesting if the same software could be modified to monitor other lists that may be going back and forth about a particular topic prior to submitting it - could help head off issues before they even get submitted formally.) -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Wednesday, April 11, 2001 11:35 AM To: 'Ietf-Calendar@Imc. Org' Cc: www-rdf-calendar@w3.org Subject: Re: announce: www-rdf-calendar mailing list Steve Mansour wrote: > this bot sounds pretty cool. So, John, can you make the information your little > bot finds available to the rest of us? Oh, yeah--if it finds any calsch-related Draft, it sends a message to the list. (Unfortunately, the one time it found anything, I found that it was misconfigured, and the message bounced...but it was a false alarm anyway. :-) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"If there's anything The Flintstones have taught| |francis@ecal.com|us, it's that pelicans can be used to mix | | |cement." -- Homer Simpson | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 11 14:11:09 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 OAA00272 for ; Wed, 11 Apr 2001 14:11:08 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA02639 for ietf-calendar-bks; Wed, 11 Apr 2001 10:53:11 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA02632 for ; Wed, 11 Apr 2001 10:53:10 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3BI0T503230; Wed, 11 Apr 2001 14:00:29 -0400 Message-ID: <3AD49BBC.1F99BF9A@ecal.com> Date: Wed, 11 Apr 2001 14:00:28 -0400 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: www-rdf-calendar@w3.org Subject: Re: announce: www-rdf-calendar mailing list 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: > If it is working - have you offered it as a tool to the rest of the IETF > working groups? Yes...or......no. I thought I posted about it on ietf@ietf.org when I put it out, but nope. I'll post now. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"How quietly do you think we can nail these back| |francis@ecal.com|in?" --Calvin | \=================================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 11 23:05:33 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 XAA08577 for ; Wed, 11 Apr 2001 23:05:32 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA06673 for ietf-calendar-bks; Wed, 11 Apr 2001 19:47:22 -0700 (PDT) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA06664 for ; Wed, 11 Apr 2001 19:47:20 -0700 (PDT) From: pregen@egenconsulting.com To: John Stracke Cc: "'Ietf-Calendar@Imc. Org'" , owner-ietf-calendar@mail.imc.org, www-rdf-calendar@w3.org Subject: Re: announce: www-rdf-calendar mailing list X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 11 Apr 2001 22:47:08 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 04/11/2001 10:47:13 PM, Serialize complete at 04/11/2001 10:47:13 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000F48D585256A2C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000F48D585256A2C_= Content-Type: text/plain; charset="us-ascii" Great idea John. Spread the wealth. This is really good what you have done. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 John Stracke Sent by: owner-ietf-calendar@mail.imc.org 04/11/01 02:00 PM To: "'Ietf-Calendar@Imc. Org'" cc: www-rdf-calendar@w3.org Subject: Re: announce: www-rdf-calendar mailing list "Shannon J. Clark" wrote: > If it is working - have you offered it as a tool to the rest of the IETF > working groups? Yes...or......no. I thought I posted about it on ietf@ietf.org when I put it out, but nope. I'll post now. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"How quietly do you think we can nail these back| |francis@ecal.com|in?" --Calvin | \=================================================================/ --=_alternative 000F48D585256A2C_= Content-Type: text/html; charset="us-ascii"
Great idea John.  Spread the wealth.  This is really good what you have done.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

04/11/01 02:00 PM

       
        To:        "'Ietf-Calendar@Imc. Org'" <ietf-calendar@imc.org>
        cc:        www-rdf-calendar@w3.org
        Subject:        Re: announce: www-rdf-calendar mailing list



"Shannon J. Clark" wrote:

> If it is working - have you offered it as a tool to the rest of the IETF
> working groups?

Yes...or...<dig, dig>...no.  I thought I posted about it on ietf@ietf.org
when I put it out, but nope.  I'll post now.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"How quietly do you think we can nail these back|
|francis@ecal.com|in?" --Calvin                                   |
\=================================================================/

--=_alternative 000F48D585256A2C_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 12 05:30:53 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 FAA25160 for ; Thu, 12 Apr 2001 05:30:51 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id CAA15353 for ietf-calendar-bks; Thu, 12 Apr 2001 02:10:27 -0700 (PDT) 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 CAA15330 for ; Thu, 12 Apr 2001 02:10:23 -0700 (PDT) Received: from metaacer (unknown [213.88.195.108]) by ljudo.shortlist.se (Postfix) with SMTP id 4EF1AB3572; Thu, 12 Apr 2001 11:10:16 +0200 (CEST) From: "Greg FitzPatrick" To: "'Ietf-Calendar@Imc. Org'" , , Subject: announce: www-rdf-calendar mailing list Date: Thu, 12 Apr 2001 11:09:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit As several CALSCH activists have kindly pointed out to me off-list, I have referred to a list; the existence of which, the purpose of which and the subscription procedures of which - are as unknown as the Christian nickname for this particular Thursday (*answer to that below). So... The RDF Calendaring and Scheduling mailing list scope as defined by Dan Brickley: Use www-rdf-calendar for detailed technical discussion of systems, vocabulary and scenarios relating to the use of RDF and XML with calendaring and scheduling tools on the Web. Please try to avoid crossposts with the other RDF lists. The focus of the list is on practical implementation work (testbeds, prototypes, collaborative development), although theoretical work (eg. on representations for events, time-periods etc) in RDF, XML, DAML etc. is in scope. The archives are here: http://lists.w3.org/Archives/Public/www-rdf-calendar/ Subscription rules are: to subscribe to the mailing list, send a message: To: www-rdf-calendar-request@w3.org Subject: subscribe (or 'unsubscribe' if it all proves too much) The list is public, archived, and like www-rdf-logic and the RDF IG IRC channel (http://www.w3.org/RDF/Interest/#irc) falls under the Semantic Web Activity within W3C (http://www.w3.org/2001/sw/). *Maundy Thursday From owner-ietf-calendar@mail.imc.org Sun Apr 15 17:18:07 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 RAA11779 for ; Sun, 15 Apr 2001 17:18:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA19476 for ietf-calendar-bks; Sun, 15 Apr 2001 14:02:13 -0700 (PDT) Received: from akamai.com (akafire-exodus.akamai.com [64.14.77.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA19469 for ; Sun, 15 Apr 2001 14:02:12 -0700 (PDT) Received: from akamai.com (vwall1.kendall.akamai.com [172.24.40.125]) by akamai.com (8.11.1/8.11.1) with ESMTP id f3FL1wn05037 for ; Sun, 15 Apr 2001 17:01:58 -0400 (EDT) Received: from ssh-gw.sanmateo.akamai.com (ssh-gw.sanmateo.akamai.com [172.23.1.53]) by akamai.com (8.11.1/8.11.1) with ESMTP id f3FL1pg26260 for ; Sun, 15 Apr 2001 17:02:01 -0400 (EDT) Received: (from mnot@localhost) by ssh-gw.sanmateo.akamai.com (8.9.3/8.9.3) id OAA13572 for ietf-calendar@imc.org; Sun, 15 Apr 2001 14:01:49 -0700 Date: Sun, 15 Apr 2001 14:01:49 -0700 From: Mark Nottingham To: ietf-calendar@imc.org Subject: representing scheduled events Message-ID: <20010415140144.B13375@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Just a quick question. I've seen several fields where it's desireable to model a scheduled event and then represent it in some form (XML or a simple string, usually). For example, I'd want to model and express: - "Every Tueday at 6pm" - "The first Monday of the month at noon" - "Every other day at midnight" Possible uses include for HTTP cache freshness, recurring events in RSS news feeds, and policy updates for things like P3P. In general, I'm talking about representing a publication schedule. Does calsch have a solution for this, or any thoughts that would point an effort to develop such a thing in the right direction? Cheers, -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA) From owner-ietf-calendar@mail.imc.org Mon Apr 16 01:03: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 BAA17156 for ; Mon, 16 Apr 2001 01:03:13 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id VAA10071 for ietf-calendar-bks; Sun, 15 Apr 2001 21:50:01 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA10067 for ; Sun, 15 Apr 2001 21:49:59 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id XAA30569 for ; Sun, 15 Apr 2001 23:45:13 -0500 From: "Shannon J. Clark" To: Subject: RE: representing scheduled events Date: Sun, 15 Apr 2001 23:49:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <20010415140144.B13375@akamai.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This seems to me to be a case which supports my suggestion of breaking out the reoccurrence rules (limited to timed events) into a separately defined standard, they would them be easily available for use in cases such as Mark suggested. Certainly the whole category of repeating in TIME events which are cases of software talking to software (as in HTTP cache freshness) is a case that does not require most of the iCalendar spec (attendees, etc) but is clearly related to Calendaring. By using a common standard syntax to indicate repeating events, and by using a common conceptual framework for how to describe timed occurrences, we would be helping move applications and the Internet in a direction that will facilitate the use and adoption of calendaring & scheduling software. Anyway, just my two 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 Mark Nottingham Sent: Sunday, April 15, 2001 4:02 PM To: ietf-calendar@imc.org Subject: representing scheduled events Hello, Just a quick question. I've seen several fields where it's desireable to model a scheduled event and then represent it in some form (XML or a simple string, usually). For example, I'd want to model and express: - "Every Tueday at 6pm" - "The first Monday of the month at noon" - "Every other day at midnight" Possible uses include for HTTP cache freshness, recurring events in RSS news feeds, and policy updates for things like P3P. In general, I'm talking about representing a publication schedule. Does calsch have a solution for this, or any thoughts that would point an effort to develop such a thing in the right direction? Cheers, -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA) From owner-ietf-calendar@mail.imc.org Tue Apr 17 17:25: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 RAA16808 for ; Tue, 17 Apr 2001 17:25:40 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA17489 for ietf-calendar-bks; Tue, 17 Apr 2001 13:55:32 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17485 for ; Tue, 17 Apr 2001 13:55:30 -0700 (PDT) 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 QAA22764; Tue, 17 Apr 2001 16:55:02 -0400 Received: from pc152 (PC-152 [101.1.46.9]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JDT9FNQW; Tue, 17 Apr 2001 16:53:11 -0400 Message-ID: <096601c0c780$904ed280$092e0165@cst.ca> From: "Graham Gilmore" To: , References: Subject: Re: representing scheduled events Date: Tue, 17 Apr 2001 16:54:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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" To: Sent: 16 April, 2001 00:49 Subject: RE: representing scheduled events > This seems to me to be a case which supports my suggestion of breaking out > the reoccurrence rules (limited to timed events) into a separately defined > standard, they would them be easily available for use in cases such as Mark > suggested. > > Certainly the whole category of repeating in TIME events which are cases of > software talking to software (as in HTTP cache freshness) is a case that > does not require most of the iCalendar spec (attendees, etc) but is clearly > related to Calendaring. > > By using a common standard syntax to indicate repeating events, and by using > a common conceptual framework for how to describe timed occurrences, we > would be helping move applications and the Internet in a direction that will > facilitate the use and adoption of calendaring & scheduling software. Splitting off the concept of recurrence rules into a separate document (which could be used for much more than simply scheduling) makes a lot of sense to me - in fact, there are a number of seemingly independent concepts mixed together in RFC 2445 which might be more clearly expressed (and more easily used) if they were separate documents. For example, I can't imagine any reasonable case where one might want to have an event which has both a recurrence rule specifying a repetition in seconds, and ATTENDEE information. Should they really be part of the same document? Obviously if we want to continue moving the iTIP/CAP stuff towards standard status it would be silly to tear apart iCalendar v2.0 at this point, but might we not consider a newer, more modular version in the future? Graham From owner-ietf-calendar@mail.imc.org Tue Apr 17 18:24:07 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 SAA17307 for ; Tue, 17 Apr 2001 18:24:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA22603 for ietf-calendar-bks; Tue, 17 Apr 2001 15:02:12 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA22599 for ; Tue, 17 Apr 2001 15:02:11 -0700 (PDT) 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 SAA24283 for ; Tue, 17 Apr 2001 18:01:43 -0400 Received: from pc152 (PC-152 [101.1.46.9]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JDT9FN6D; Tue, 17 Apr 2001 17:59:52 -0400 Message-ID: <097701c0c789$e1221c90$092e0165@cst.ca> From: "Graham Gilmore" To: Subject: Interpretation of VALARM TRIGGERs in recurring components Date: Tue, 17 Apr 2001 18:00:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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 I'm looking at the information given in RFC 2445 about the TRIGGER property of a VALARM component (section 4.8.6.3). While the default value type of the property is DURATION, a DATE-TIME value type can also be specified by means of a VALUE parameter. I'm wondering what the interpretation of this would be in the case of a VEVENT or VTODO that has a recurrence rule: a) A single alarm is triggered at the given DATE-TIME for all instances of the recurrence b) One alarm is triggered for every instance of the recurrence, at the given DATE-TIME, i.e. multiple alarms at the same time (how would this work for infinite recurrences?) c) The offset between the given DATE-TIME and the DTSTART of the first instance is calculated as a duration (in hours/minutes/seconds), and the duration is used to determine when each alarm is triggered for each recurrence. (The duration between an alarm trigger and its recurrence instance would remain constant, even across DST changes.) d) Almost like (c), except the duration is not constant across DST changes. I can't even figure out how to express this one properly in words, so I'm not sure how useful or straightforward it could be as an interpretation :) I would lean towards (c), but it's certainly not as clear as it could be. Any other opinions or interpretations? Graham From owner-ietf-calendar@mail.imc.org Wed Apr 18 10:44: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 KAA12101 for ; Wed, 18 Apr 2001 10:44:25 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA11753 for ietf-calendar-bks; Wed, 18 Apr 2001 07:24:51 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11749 for ; Wed, 18 Apr 2001 07:24:49 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3IEWJw07638 for ; Wed, 18 Apr 2001 10:32:19 -0400 Message-ID: <3ADDA572.2332043C@ecal.com> Date: Wed, 18 Apr 2001 10:32:18 -0400 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: Interpretation of VALARM TRIGGERs in recurring components References: <097701c0c789$e1221c90$092e0165@cst.ca> 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 Graham Gilmore wrote: > I'm wondering what the > interpretation of this would be in the case of a VEVENT or VTODO that > has a recurrence rule: I think the only interpretation that meshes with 2445 is (a), a single alarm at a given time that has nothing to do with the recurrence. Your (c) (infer a duration given a date-time) is counter to the text ("The 'TRIGGER' property value type can alternatively be set to an absolute calendar date and time of day value") in two ways. First, the text says "an", which implies exactly one. Second, the text says "absolute", which is counter to your inferred-duration approach. Your (b) (one alarm per instance, but all at the same time) is, as you say, not workable. Granted, an absolute-time alarm in a recurring event is *strange*; but it's not utterly useless. Maybe I've got a procedural alarm that needs to go off sometime before the first email alarm, but doesn't need to go off on every one. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Illiterate? Write today for free help! | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Apr 18 12:42: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 MAA14106 for ; Wed, 18 Apr 2001 12:42:21 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA24780 for ietf-calendar-bks; Wed, 18 Apr 2001 09:24:07 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA24772 for ; Wed, 18 Apr 2001 09:24:05 -0700 (PDT) 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 MAA02025 for ; Wed, 18 Apr 2001 12:23:36 -0400 Received: from pc152 (PC-152 [101.1.46.9]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JDT9FP98; Wed, 18 Apr 2001 12:21:42 -0400 Message-ID: <09ae01c0c823$cd07e0b0$092e0165@cst.ca> From: "Graham Gilmore" To: References: <097701c0c789$e1221c90$092e0165@cst.ca> <3ADDA572.2332043C@ecal.com> Subject: Re: Interpretation of VALARM TRIGGERs in recurring components Date: Wed, 18 Apr 2001 12:22:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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: "John Stracke" To: Sent: 18 April, 2001 10:32 Subject: Re: Interpretation of VALARM TRIGGERs in recurring components > Graham Gilmore wrote: > > > I'm wondering what the > > interpretation of this would be in the case of a VEVENT or VTODO that > > has a recurrence rule: > > I think the only interpretation that meshes with 2445 is (a), a single > alarm at a given time that has nothing to do with the recurrence. Your > (c) (infer a duration given a date-time) is counter to the text ("The > 'TRIGGER' property value type can alternatively be set to an absolute > calendar date and time of day value") in two ways. First, the text says > "an", which implies exactly one. Second, the text says "absolute", which > is counter to your inferred-duration approach. The text refers to the value of the property, not the interpretation of that value. It's fairly straightforward on reading the text that there be only a single property value, and that value be an 'absolute calendar date and time of day value'. It's the interpretation of the value that I'm wondering about :) I would agree that (a) seems to be the simplest interpretation, but somehow it doesn't feel like that would be the intent of someone who would include it in an iCalendar, if they were working only from the RFC. Perhaps the (c) option I detailed would be reading too much into it. In any case, as long as there's a single interpretation that's generally agreed upon, I don't care all that much which one it is, as long as it's not overly complex. The real problem is that the text isn't clear on what the meaning of the DATE-TIME form is, in combination with recurrence rules. Graham From owner-ietf-calendar@mail.imc.org Thu Apr 19 11:05: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 LAA12267 for ; Thu, 19 Apr 2001 11:05:36 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA00939 for ietf-calendar-bks; Thu, 19 Apr 2001 07:29:34 -0700 (PDT) Received: from Arista.iris.com ([198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00931 for ; Thu, 19 Apr 2001 07:29:25 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04122001 April 12, 2001 Message-ID: Date: Thu, 19 Apr 2001 10:29:28 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/19/2001 10:30:26 AM, Serialize complete at 04/19/2001 10:30:26 AM Content-Type: multipart/alternative; boundary="=_alternative 004F68B085256A33_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004F68B085256A33_= Content-Type: text/plain; charset="us-ascii" John replied: >Two different timezones in >the same iCalendar could be solved by on-the-fly TZIDs. I appologize for the timeout, Ive been heads down on some critical work in-house to the detriment of the WG list... Actually, I would hope that the 'globally defined' TZIDs would be used over the "I think Ill name them Fred and Barney" TZID approach once we actually get the TZIDs registered. Otherwise whats the use of globally registering them?? Lets just have chaos all around... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 004F68B085256A33_= Content-Type: text/html; charset="us-ascii"
John replied:
>Two different timezones in
>the same iCalendar could be solved by on-the-fly TZIDs.

I appologize for the timeout, Ive been heads down on some critical work in-house to the detriment of the WG list...

Actually, I would hope that the 'globally defined' TZIDs would be used over the "I think Ill name them Fred and Barney" TZID approach once we actually get the TZIDs registered.  Otherwise whats the use of globally registering them??  Lets just have chaos all around...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 004F68B085256A33_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 19 11:13: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 LAA12456 for ; Thu, 19 Apr 2001 11:13:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA01206 for ietf-calendar-bks; Thu, 19 Apr 2001 07:36:01 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA01201 for ; Thu, 19 Apr 2001 07:35:59 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04122001 April 12, 2001 Message-ID: Date: Thu, 19 Apr 2001 10:35:59 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/19/2001 10:36:52 AM, Serialize complete at 04/19/2001 10:36:52 AM Content-Type: multipart/alternative; boundary="=_alternative 005001E985256A33_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005001E985256A33_= Content-Type: text/plain; charset="us-ascii" Alan noted: > The presence of the SOLIDUS character (US-ASCII decimal 47) as a > prefix, indicates that this TZID represents a unique ID in a globally > defined time zone registry (when such registry is defined). > > Note: This document does not define a naming convention for time > zone identifiers. Implementers may want to use the naming > conventions defined in existing time zone specifications such as > the public-domain Olson database [TZ]. The specification of > globally unique time zone identifiers is not addressed by this > document and is left for future study. Ok, this may be hair splitting but the _only_ place that "globally unique" and TZIDs are mentioned is in the Note part of the text. Its not actually called for in the normalative text. The phrase in the Note is talking about any TZID that is created with a '/' prefix and making them globally unique. This is good (once it begins) even if it does not directly address the issue of changes to a unique entry. That is out of scope for iCalendar right now. If you reread the ABNF for TZID you will see it is simply defined as: tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF tzidprefix = "/" The paramtext is NOT defined as globally unqiue so it is perfectly reasonable to have my iCal engine and Johns generating the same TZID=We_rule_TZID values in separate iCalendar streams... The globally uniquenes only applys to any future IANA (or other body) registered values, not to ones that anyone else generates. Now I may have come full circle on this argument but Im just now swapping back in so appologies now just in case... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005001E985256A33_= Content-Type: text/html; charset="us-ascii"
Alan noted:
>    The presence of the SOLIDUS character (US-ASCII decimal 47) as a
>    prefix, indicates that this TZID represents a unique ID in a globally
>    defined time zone registry (when such registry is defined).
>
>         Note: This document does not define a naming convention for time
>         zone identifiers. Implementers may want to use the naming
>         conventions defined in existing time zone specifications such as
>         the public-domain Olson database [TZ]. The specification of
>         globally unique time zone identifiers is not addressed by this
>         document and is left for future study.

Ok, this may be hair splitting but the _only_ place that "globally unique" and TZIDs are mentioned is in the Note part of the text.  Its not actually called for in the normalative text.  The phrase in the Note is talking about any TZID that is created with a '/' prefix and making them globally unique.  This is good (once it begins) even if it does not directly address the issue of changes to a unique entry.  That is out of scope for iCalendar right now.

If you reread the ABNF for TZID you will see it is simply defined as:

     tzidparam  = "TZID" "=" [tzidprefix] paramtext CRLF

    tzidprefix = "/"
The paramtext is NOT defined as globally unqiue so it is perfectly reasonable to have my iCal engine and Johns generating the same TZID=We_rule_TZID values in separate iCalendar streams...  The globally uniquenes only applys to any future IANA (or other body) registered values, not to ones that anyone else generates.  Now I may have come full circle on this argument but Im just now swapping back in so appologies now just in case...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 005001E985256A33_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 19 11:32: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 LAA12822 for ; Thu, 19 Apr 2001 11:32:05 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA03411 for ietf-calendar-bks; Thu, 19 Apr 2001 08:11:00 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA03404 for ; Thu, 19 Apr 2001 08:10:58 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3JFITc10736 for ; Thu, 19 Apr 2001 11:18:29 -0400 Message-ID: <3ADF01C5.AFDAE79A@ecal.com> Date: Thu, 19 Apr 2001 11:18:29 -0400 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: Interpretation of VALARM TRIGGERs in recurring components References: <097701c0c789$e1221c90$092e0165@cst.ca> <3ADDA572.2332043C@ecal.com> <09ae01c0c823$cd07e0b0$092e0165@cst.ca> 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 Graham Gilmore wrote: > The text refers to the value of the property, not the interpretation > of that value. Since RFC-2445 doesn't specify an interpretation, we have to take the obvious one: an "absolute calendar date and time of day value" implies an absolute calendar date and time of day. There'd be no point in supporting DATE-TIME if it gives you the same semantics as DURATION. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Piscatorice non aristotelice. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Apr 20 01:55: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 BAA00375 for ; Fri, 20 Apr 2001 01:55:38 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA22257 for ietf-calendar-bks; Thu, 19 Apr 2001 22:38:17 -0700 (PDT) Received: from server (ni-5-67.cytanet.com.cy [195.14.128.67]) by above.proper.com (8.9.3/8.9.3) with SMTP id WAA22252; Thu, 19 Apr 2001 22:38:14 -0700 (PDT) From: internationalcommodity@tr.com Message-Id: <200104200538.WAA22252@above.proper.com> Date: Đáñ, 20 Áđñ 2001 05:01:18 Subject: EMPLOYMENTS Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: WE OFFER JOBS TO FOLLOWING: MASONS CARPENTERS ELECTRICIANS PAINTERS CIVIL/MECHANICAL/ELECTRICAL ENGINEERS ADMINISTRATORS HOUSE CLEANERS GARDENERS NURSES WE PROVIDE: 2 YEAR CONTRACTS HIGH SALLARY ACCOMODATION VISA/RESIDENCE PERMIT FOR CANADA PLEASE CALL OR/AND SEND YOUR C/V FOR ARRANGING FURTHER. YOURS FAITHFULLY JOHN ATHERTON INTERNATIONAL COMMODITY TRADERS TEL.NO.0015149400141 OO14162166827 FAX NO 0015149400142 From owner-ietf-calendar@mail.imc.org Fri Apr 20 13:06:02 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 NAA14620 for ; Fri, 20 Apr 2001 13:06:01 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA23454 for ietf-calendar-bks; Fri, 20 Apr 2001 09:33:55 -0700 (PDT) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA23448 for ; Fri, 20 Apr 2001 09:33:50 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f3KGXf827910 for ; Fri, 20 Apr 2001 09:33:46 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Fri, 20 Apr 2001 09:33:40 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Recap: Does 1 day == 24 hours? 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: This is recap of the thread we had a few weeks ago regarding "Does 1 day == 24 hours" To review, the problem is that RFC2445 does not specify what 1D really means when used in a DURATION. During the discussion, there were three camps: 1) 1D means 24H. In this case, 1D is a synonym for 24H. This means that DURATION values can always be expressed as a number of seconds, but you may get unexpected behavior when a DURATION crosses a timezone boundary: an event of DURATION:1D may start at 10:00 on one day and finish at 9:00, 10:00 or 11:00 the next. 2) 1D means "the remainder of today". In this case the W and D parts of the DURATION are an entirely separate scale from the time parts. The date parts always end on date boundaries. So a duration of 2D will end at 24:00 tomorrow, and a duration of 1D on an event that starts at 23:50 will mean that the event lasts only 10 minutes. 3) 1D means "the same time tomorrow" In this case, a meeting with a duration of 1D that begins at 10:00 will end at 10:00 tomorrow, regardless of any intervening time shifts. So, for the America/Los-Angeles timezone, the meeting could be 23,24 or 25 hours long, depending if the next day includes a time shift on to or off of daylight savings time. Now, honestly, none of these options are very good. (1) implies that the end time of a 1D event can move around depending on daylight savings time shifts, and it makes the W and D specifiers redundant, since they can always be expressed in H, M or S. (2) is logical, self consistent and non-redundant. It is the RFC authors original intent, but I'd suspect that end users will find it very strange. Are there use cases that require this behavior? (3) may be more expected from the end-users perspective, but is complex to implement, since you have to look for timezone shifts every time you convert a DURATION of 1D into an end time. Personally, I'd reject (1). It is the easiest to understand and is logical, but it doesn't add anything to the behavior of DURATION. If we are going to define 1W = 7D and 1D = 24H, then we could just condense the entire DURATION down to seconds. ( BTW, this condensation to seconds in an implementation is what triggered the entire discussion. ) I prefer (2), but could live with (3). Both add useful behavior to DURATION that cannot be accomplished easily with H,M and S. (3) is nice because I think it best matches users expectations. I would naturally expect that a 1D event that starts today at 10:00 will end tomorrow at 10:00, and (3) ensures this behavior. However (2) makes more sense when the value of DTSTART is DATE. In fact, it is probably sensible to restrict DURATION to only using W and D when DTSTART:VALUE=DATE. This would eliminate any questions about what it means to at 2H to a DATE. This points to strengthing the concept of time scale vs date scale in RFC2445, and (2) would be an important part of that concept. (2) is easy to implement, adds additinoal functionality, and although it has unusual behavior for DTSTART;VALUE-DATE-TIME, it is a perfect match for DTSTART;VALUE=DATE. Which option do you prefer? eric. From owner-ietf-calendar@mail.imc.org Mon Apr 23 10:24:09 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04776 for ; Mon, 23 Apr 2001 10:24:08 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA18784 for ietf-calendar-bks; Mon, 23 Apr 2001 06:59:30 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA18776 for ; Mon, 23 Apr 2001 06:59:27 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id JAA26005; Mon, 23 Apr 2001 09:58:58 -0400 Received: from c-1244.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3NDwsP01442; Mon, 23 Apr 2001 09:58:58 -0400 (EDT) Message-Id: <5.0.0.25.0.20010423094809.02f66290@apollo> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Apr 2001 09:57:33 -0400 To: Bruce_Kahn@iris.com From: Alan Davies Subject: Re: Omit VTIMEZONE when using global identifiers? Cc: ietf-calendar@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To resplit some more hairs- if you reread the first passage, (which was quoted from the RFC) you'll see that the words "unique" and "globally" do appear in the normalative text, in the phrase "represents a unique ID in a globally defined time zone registry" All taking part in the discussion realised that the paramtext for TZIDs does not _have_ to be globally unique, we were discussing cases where the '/' prefix is used to imply a globally unique ID. --Alan At 10:35 2001-04-19 -0400, Bruce_Kahn@iris.com wrote: >Alan noted: > > The presence of the SOLIDUS character (US-ASCII decimal 47) as a > > prefix, indicates that this TZID represents a unique ID in a globally > > defined time zone registry (when such registry is defined). > > > > Note: This document does not define a naming convention for time > > zone identifiers. Implementers may want to use the naming > > conventions defined in existing time zone specifications such as > > the public-domain Olson database [TZ]. The specification of > > globally unique time zone identifiers is not addressed by this > > document and is left for future study. > >Ok, this may be hair splitting but the _only_ place that "globally unique" >and TZIDs are mentioned is in the Note part of the text. Its not actually >called for in the normalative text. The phrase in the Note is talking >about any TZID that is created with a '/' prefix and making them globally >unique. This is good (once it begins) even if it does not directly >address the issue of changes to a unique entry. That is out of scope for >iCalendar right now. > >If you reread the ABNF for TZID you will see it is simply defined as: > > tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF > > tzidprefix = "/" > >The paramtext is NOT defined as globally unqiue so it is perfectly >reasonable to have my iCal engine and Johns generating the same >TZID=We_rule_TZID values in separate iCalendar streams... The globally >uniquenes only applys to any future IANA (or other body) registered >values, not to ones that anyone else generates. Now I may have come full >circle on this argument but Im just now swapping back in so appologies now >just in case... > >Bruce >=========================================================================== >Bruce Kahn INet: Bruce_Kahn@iris.com >Iris Associates Phone: 978.392.5335 >Westford, MA, USA 01886 FAX: and nothing but the FAX... >Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Mon Apr 23 11:40:40 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05746 for ; Mon, 23 Apr 2001 11:40:38 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA25591 for ietf-calendar-bks; Mon, 23 Apr 2001 08:23:49 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA25554 for ; Mon, 23 Apr 2001 08:23:34 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA27926; Mon, 23 Apr 2001 11:22:46 -0400 Received: from c-1244.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3NFMgP08720; Mon, 23 Apr 2001 11:22:46 -0400 (EDT) Message-Id: <5.0.0.25.0.20010423101429.02f29da0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Apr 2001 11:21:22 -0400 To: Eric Busboom , ietf-calendar@imc.org From: Alan Davies Subject: Re: Recap: Does 1 day == 24 hours? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >However (2) makes more sense when the value of DTSTART is DATE. In fact, >it is probably sensible to restrict DURATION to only using W and D when >DTSTART:VALUE=DATE. This would eliminate any questions about what it means >to at 2H to a DATE. This points to strengthing the concept of time scale >vs date scale in RFC2445, and (2) would be an important part of that >concept. This seems like a sensible suggestion- there should be a clear link between the scale used for DTSTART and the scale used for DURATION. All 3 interpretations that you summarised have their good points, but suffer because they're either ambiguous or too complex when used with mismatched calendar scales. I like the idea of strengthening the time scale vs date scale concept. Date scale DURATIONs would in D(ays), time scale DURATIONs in (S)econds. Weeks could still be used to represent 7 days, and Hours and Minutes the corresponding number of seconds, although how much value do they add? Two reasons I can think of for W, H, and M are that they increase human-readability of the object (it's not immediately obvious to me that 43200 seconds is actually 12 hours), and possibly give some implication about the precision (in a mathematical sense) of the value- although this could be stated if it is true. (As a side note: it's not clear in RFC2445 whether durations such as PT70S, PT60M etc. are allowed - i.e. with second/minute components greater than 59. I can't see any text to disallow them though.) In a spec like this, should we be trying to avoid redundancy, ambiguousity, and unnecessary complexity wherever possible? One of the reasons for the rise in popularity of RISC processors was that their smaller instruction sets were easy to prototype and test. iCalendar implementations are not easy to prototype and test. --Alan From owner-ietf-calendar@mail.imc.org Mon Apr 23 13:06:54 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07042 for ; Mon, 23 Apr 2001 13:06:53 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA05685 for ietf-calendar-bks; Mon, 23 Apr 2001 09:46:40 -0700 (PDT) Received: from hqvsbh1.ms.com (hqvsbh1-x0.ms.com [205.228.12.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05668 for ; Mon, 23 Apr 2001 09:46:38 -0700 (PDT) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.11.3/8.11.3) id f3NGket11882 for ; Mon, 23 Apr 2001 12:46:40 -0400 (EDT) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9880443981.011770; Mon, 23 Apr 01 12:46:38 -0400 Received: (from uucp@localhost) by hqvsbh1.ms.com (8.11.3/8.11.3) id f3NGkcZ11719 for ; Mon, 23 Apr 2001 12:46:38 -0400 (EDT) Received: from unknown(144.14.206.187) by hqvsbh1 via smap (4.1) id sma.9880443961.011630; Mon, 23 Apr 01 12:46:36 -0400 Received: from morganstanley.com (openmadeo.morgan.com [144.14.42.219]) by pismh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id MAA27559 for ; Mon, 23 Apr 2001 12:46:36 -0400 (EDT) Message-ID: <3AE45C6D.6999C69D@morganstanley.com> Date: Mon, 23 Apr 2001 12:46:37 -0400 From: David Madeo Reply-To: David.Madeo@morganstanley.com Organization: Morgan Stanley X-Mailer: Mozilla 4.75 [en]C-CCK-MCD MS4.75 V20001029.1 (Windows NT 5.0; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Reefknot discussion in Boston Content-Type: multipart/mixed; boundary="------------C5BE97B59786EC0EFEAB4A92" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C5BE97B59786EC0EFEAB4A92 Content-Type: multipart/alternative; boundary="------------A6F342DD523FC1BBEDD03E16" --------------A6F342DD523FC1BBEDD03E16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I noticed that reefknot's (an open source perl iCalendar toolkit leading to an open source implementation) two main people (Shane Landrum and Kirrily Skud Robert) are giving a presentation on May 1st for Boston.pm. I'm thinking of flying up there to hear more about this, and I know several members of this list reside in the area and might be interested as well. I haven't been able to find more details on the web, but if you're up for it, let's coordinate off-list. dmadeo --------------A6F342DD523FC1BBEDD03E16 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I noticed that reefknot's (an open source perl iCalendar toolkit leading to an open source implementation) two main people (Shane Landrum and Kirrily Skud Robert) are giving a presentation on May 1st for Boston.pm.  I'm thinking of flying up there to hear more about this, and I know several members of this list reside in the area and might be interested as well.  I haven't been able to find more details on the web, but if you're up for it, let's coordinate off-list.

dmadeo --------------A6F342DD523FC1BBEDD03E16-- --------------C5BE97B59786EC0EFEAB4A92 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;pager:dmadeo@skytel.com or 888-354-8513 tel;cell:917-295-9893 tel;fax:877-545-8846 tel;work:212-762-2348 x-mozilla-html:TRUE url:http://www.morganstanley.com org:Morgan Stanley;Information Technology adr:;;750 Seventh Ave;New York;NY;10019;United States version:2.1 email;internet:David.Madeo@morganstanley.com title:Vice President fn:David Madeo end:vcard --------------C5BE97B59786EC0EFEAB4A92-- From owner-ietf-calendar@mail.imc.org Mon Apr 23 13:18:29 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07392 for ; Mon, 23 Apr 2001 13:18:29 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA06541 for ietf-calendar-bks; Mon, 23 Apr 2001 09:53:45 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA06536 for ; Mon, 23 Apr 2001 09:53:44 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA30039 for ; Mon, 23 Apr 2001 12:53:15 -0400 Received: from c-1244.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3NGrFP16605 for ; Mon, 23 Apr 2001 12:53:15 -0400 (EDT) Message-Id: <5.0.0.25.0.20010423114402.02f148c0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Apr 2001 12:26:06 -0400 To: ietf-calendar@imc.org From: Alan Davies Subject: REQUEST sent to non-ATTENDEE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A recent discussion brought to light the fact that iCalendar implementations may wish to achieve an effect similar to an email Bcc (or even Cc). Here are three possible ways that it could be achieved (I'll call the CU who receives the Bcc 'User B'): 1) Add User B as an ATTENDEE with ROLE=NON-PARTICIPANT. User B would be visible to all other ATTENDEEs though, which might not be the required effect. 2) PUBLISH the event to the User B. The PUBLISHed object would, of course, contain no ATTENDEEs, which may not leave much value in the Bcc. 3) Send User B the same REQUEST that was sent to all ATTENDEEs, (i.e. just Bcc User B on the iMIP REQUEST that is sent). This solves the first two problems, but what would User B's CUA be expected to do with this object? User B is not an ATTENDEE, and it seems logical to me that all recipients of a REQUEST should be ATTENDEEs, but I couldn't find a statement about this anywhere in RFC2246. So, what do other implementors think- can a REQUEST be sent to a non-ATTENDEE? --Alan From owner-ietf-calendar@mail.imc.org Mon Apr 23 13:58:18 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08304 for ; Mon, 23 Apr 2001 13:58:17 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA11446 for ietf-calendar-bks; Mon, 23 Apr 2001 10:45:51 -0700 (PDT) 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 KAA11436 for ; Mon, 23 Apr 2001 10:45:47 -0700 (PDT) Received: from localhost (slandrum@localhost) by grendel.csc.smith.edu (8.9.3/8.9.3) with ESMTP id NAA03876; Mon, 23 Apr 2001 13:44:25 -0400 Date: Mon, 23 Apr 2001 13:44:25 -0400 (EDT) From: srl To: David Madeo cc: ietf-calendar@imc.org Subject: Re: Reefknot discussion in Boston In-Reply-To: <3AE45C6D.6999C69D@morganstanley.com> 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 Mon, 23 Apr 2001, David Madeo wrote: > I noticed that reefknot's (an open source perl iCalendar toolkit leading > to an open source implementation) two main people (Shane Landrum and > Kirrily Skud Robert) are giving a presentation on May 1st for > Boston.pm. I'm thinking of flying up there to hear more about this, and > I know several members of this list reside in the area and might be > interested as well. I haven't been able to find more details on the > web, but if you're up for it, let's coordinate off-list. The talk will be at 7pm (or maybe 7:30, I don't recall) on May 1. Please RSVP to rjk@linguist.dartmouth.edu, the Boston.pm coordinator, who can provide you with directions and a precise time. The talk is a regular technical meeting of the Boston Perl Mongers, and food is usually provided. The Boston.pm talk will be partially a discussion of our overall strategy and partially a work-in-progress demo. We're still in early alpha stages, but we'd welcome comments. You can find out more about the project at http://reefknot.sourceforge.net. 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 Mon Apr 23 18:21:41 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14034 for ; Mon, 23 Apr 2001 18:21:41 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA01620 for ietf-calendar-bks; Mon, 23 Apr 2001 15:10:53 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA01613 for ; Mon, 23 Apr 2001 15:10:51 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Recap: Does 1 day == 24 hours? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04172001 April 17, 2001 Message-ID: Date: Mon, 23 Apr 2001 18:19:25 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/23/2001 06:11:59 PM, Serialize complete at 04/23/2001 06:11:59 PM Content-Type: multipart/alternative; boundary="=_alternative 0079D74485256A37_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079D74485256A37_= Content-Type: text/plain; charset="us-ascii" Alan wrote: > (As a side note: it's not clear in RFC2445 whether durations > such as PT70S, PT60M etc. are allowed - i.e. with second/minute > components greater than 59. I can't see any text to disallow > them though.) From RFC 2445, Section 4.3.6: 4.3.6 Duration Value Name: DURATION Purpose: This value type is used to identify properties that contain a duration of time. [Snip] dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) dur-date = dur-day [dur-time] dur-time = "T" (dur-hour / dur-minute / dur-second) dur-week = 1*DIGIT "W" dur-hour = 1*DIGIT "H" [dur-minute] dur-minute = 1*DIGIT "M" [dur-second] dur-second = 1*DIGIT "S" dur-day = 1*DIGIT "D" As noted, there is nothing precluding the use of DURATION:PT90M over DURATION:PT1H30M. Both are equally valid and legal. You could possibly even encode it as a whole lot of seconds if you wanted to. You may be thinking of the restrictions that were put on the Recurrence Rule values. Check out Section 4.3.10 for those restrictions (ie: BYHOUR=1,9,23) but they do not apply to this context. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0079D74485256A37_= Content-Type: text/html; charset="us-ascii"
Alan wrote:
> (As a side note: it's not clear in RFC2445 whether durations
> such as PT70S, PT60M etc. are allowed - i.e. with second/minute
> components greater than 59. I can't see any text to disallow
> them though.)

From RFC 2445, Section 4.3.6:

4.3.6   Duration

  Value Name: DURATION

  Purpose: This value type is used to identify properties that contain
  a duration of time.
[Snip]

    dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)

    dur-date   = dur-day [dur-time]
    dur-time   = "T" (dur-hour / dur-minute / dur-second)
    dur-week   = 1*DIGIT "W"
    dur-hour   = 1*DIGIT "H" [dur-minute]
    dur-minute = 1*DIGIT "M" [dur-second]
    dur-second = 1*DIGIT "S"
    dur-day    = 1*DIGIT "D"

As noted, there is nothing precluding the use of DURATION:PT90M over DURATION:PT1H30M.  Both are equally valid and legal.  You could possibly even encode it as a whole lot of seconds if you wanted to.

You may be thinking of the restrictions that were put on the Recurrence Rule values.  Check out Section 4.3.10 for those restrictions (ie: BYHOUR=1,9,23) but they do not apply to this context.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0079D74485256A37_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 23 18:28:35 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14090 for ; Mon, 23 Apr 2001 18:28:35 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA02799 for ietf-calendar-bks; Mon, 23 Apr 2001 15:19:37 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02792 for ; Mon, 23 Apr 2001 15:19:35 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04172001 April 17, 2001 Message-ID: Date: Mon, 23 Apr 2001 18:28:08 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/23/2001 06:20:43 PM, Serialize complete at 04/23/2001 06:20:43 PM Content-Type: multipart/alternative; boundary="=_alternative 007AA3C385256A37_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007AA3C385256A37_= Content-Type: text/plain; charset="us-ascii" Alan replied: > To resplit some more hairs- if you reread the first passage, > (which was quoted from the RFC) you'll see that the words "unique" > and "globally" do appear in the normalative text, in the phrase > > "represents a unique ID in a globally defined time zone registry" Thats taken out of context a bit. The entire line is: The presence of the SOLIDUS character (US-ASCII decimal 47) as a prefix, indicates that this TZID represents a unique ID in a globally defined time zone registry (when such registry is defined). The original intent was that for non-solidus'd TZIDs the value is not a guid but rather luid (locally unique in the iCalendar stream). For solidus'd values, the value MUST be a guid. That does not address the issue of revisions to a standardized TZID (ie: France or David's Brazil calls) but it does provide a means for a CUA to find and possibly match a TZID that is not necessarily in the iCalendar stream (and even find the latest definition, etc). There is no mention of non-solidus'd values being globally unique, that is just some inplicit extension of the cited text by some folks. Frank can correct me if Im wrong about all this though. Im not sure Derik is still even lurking on this list to confirm / deny this. You can also search the archives for any thread on this topic going back to ~Day 1 if that would help. Enough digression and hairs though. I think we all agree that a TZID that is not solidus prefixed is NOT a guid and that we have an issue w/dealing with revision to standardized values which is separate from any RFC 2445 update (since we have no registration system in place yet). Any dissent on this at least? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007AA3C385256A37_= Content-Type: text/html; charset="us-ascii"
Alan replied:
> To resplit some more hairs- if you reread the first passage,
> (which was quoted from the RFC) you'll see that the words "unique"
> and "globally" do appear in the normalative text, in the phrase
>
>      "represents a unique ID in a globally defined time zone registry"
Thats taken out of context a bit.  The entire line is:

   The presence of the SOLIDUS character (US-ASCII decimal 47) as a
  prefix, indicates that this TZID represents a unique ID in a globally
  defined time zone registry (when such registry is defined).

The original intent was that for non-solidus'd TZIDs the value is not a guid but rather luid (locally unique in the iCalendar stream).  For solidus'd values, the value MUST be a guid.  That does not address the issue of revisions to a standardized TZID (ie: France or David's Brazil calls) but it does provide a means for a CUA to find and possibly match a TZID that is not necessarily in the iCalendar stream (and even find the latest definition, etc).  There is no mention of non-solidus'd values being globally unique, that is just some inplicit extension of the cited text by some folks.

Frank can correct me if Im wrong about all this though.  Im not sure Derik is still even lurking on this list to confirm / deny this.  You can also search the archives for any thread on this topic going back to ~Day 1 if that would help.

Enough digression and hairs though.  I think we all agree that a TZID that is not solidus prefixed is NOT a guid and that we have an issue w/dealing with revision to standardized values which is separate from any RFC 2445 update (since we have no registration system in place yet).  Any dissent on this at least?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007AA3C385256A37_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 23 18:43:45 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14228 for ; Mon, 23 Apr 2001 18:43:44 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA03937 for ietf-calendar-bks; Mon, 23 Apr 2001 15:34:24 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03927 for ; Mon, 23 Apr 2001 15:34:22 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04172001 April 17, 2001 Message-ID: Date: Mon, 23 Apr 2001 18:42:54 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/23/2001 06:35:30 PM, Serialize complete at 04/23/2001 06:35:30 PM Content-Type: multipart/alternative; boundary="=_alternative 007BFDE585256A37_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007BFDE585256A37_= Content-Type: text/plain; charset="us-ascii" (Damn finger splint. I clicked on send instead of finishing my email...) Alan replied: > All taking part in the discussion realised that the paramtext for TZIDs > does not _have_ to be globally unique, we were discussing cases where > the '/' prefix is used to imply a globally unique ID. Ok, there are some compelling reasons FOR the inclusion of TZ information even when the TZID is a guid. The ones I can think of include: 1: The receiving CUA may not have access to any still TBD TZ registry mechanism. As such, they could not resolve any shifts properly! 2: The receiving CUA may have a slightly different TZ definition for the TZID (ie: it was hard coded at ship time and is not dynamically resolved at process time). As such, they would resolve any shifts possibly wrong. This would not make Dave Madeo very happy... 3: The receiving CUA may be an older CUA that does not know of any way to go and resolve/confirm the non-included TZID. Again, this is not very nice. I have yet to hear any good and strong reason NOT to include globally defined TZIDs (if and when we actually build a registration mechanism and get it up and running). Anyone at CalConnect I or II think they could have properly handled a "TZID=/US-New York" referenece w/o it being in the iCalendar stream?? I thought not... We do need to have some better means to convey 'revision of TZID' so that when we do get something going that we wont have to re-address issue #2. Thats probably best done by LAST-MODIFIED but that wont fit currently as a property parameter on DTSTART, etc... Anyone got a suggestion on how to address the revision issue? If not, Id say that not including the 'global' TZID is something that really should be avoided... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007BFDE585256A37_= Content-Type: text/html; charset="us-ascii"
(Damn finger splint.  I clicked on send instead of finishing my email...)

Alan replied:
> All taking part in the discussion realised that the paramtext for TZIDs
> does not _have_ to be globally unique, we were discussing cases where
> the '/' prefix is used to imply a globally unique ID.

Ok, there are some compelling reasons FOR the inclusion of TZ information even when the TZID is a guid.  The ones I can think of include:

1: The receiving CUA may not have access to any still TBD TZ registry mechanism.  As such, they could not resolve any shifts properly!  
2: The receiving CUA may have a slightly different TZ definition for the TZID (ie: it was hard coded at ship time and is not dynamically resolved at process time).  As such, they would resolve any shifts possibly wrong.  This would not make Dave Madeo very happy...
3: The receiving CUA may be an older CUA that does not know of any way to go and resolve/confirm the non-included TZID.  Again, this is not very nice.

I have yet to hear any good and strong reason NOT to include globally defined TZIDs (if and when we actually build a registration mechanism and get it up and running).  Anyone at CalConnect I or II think they could have properly handled a "TZID=/US-New York" referenece w/o it being in the iCalendar stream?? I thought not...

We do need to have some better means to convey 'revision of TZID' so that when we do get something going that we wont have to re-address issue #2.  Thats probably best done by LAST-MODIFIED but that wont fit currently as a property parameter on DTSTART, etc...  Anyone got a suggestion on how to address the revision issue?  If not, Id say that not including the 'global' TZID is something that really should be avoided...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007BFDE585256A37_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 23 18:57:49 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14342 for ; Mon, 23 Apr 2001 18:57:49 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA04561 for ietf-calendar-bks; Mon, 23 Apr 2001 15:45:05 -0700 (PDT) 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 PAA04556 for ; Mon, 23 Apr 2001 15:45:04 -0700 (PDT) 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 f3NMj3g03626 for ; Mon, 23 Apr 2001 17:45:13 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Apr 2001 17:44:35 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 23 Apr 2001 17:44:35 -0500 Message-ID: <30F2DED23724D311902D0008C7EABAFB03F348DD@daeis06nok> To: Bruce_Kahn@iris.com, aland@steltor.com Cc: ietf-calendar@imc.org Subject: RE: Omit VTIMEZONE when using global identifiers? Date: Mon, 23 Apr 2001 17:44:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC46.F6561EB0" 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_01C0CC46.F6561EB0 Content-Type: text/plain; charset="iso-8859-1" YES, Bruce. Local TZID has no SOLIDUS character and has a requirement to be unique only within the iCalendar object. If the TZID value has a SOLIDUS prefix, then it signals a registered value and MUST BE globally unique. YES, there could be an issue about updates to registered time zone definitions. Biggest problem right now is the lack of a registrar and process! -- Frank ------_=_NextPart_001_01C0CC46.F6561EB0 Content-Type: text/html; charset="iso-8859-1"

YES, Bruce. Local TZID has no SOLIDUS character and has a requirement to be unique only within the iCalendar object. If the TZID value has a SOLIDUS prefix, then it signals a registered value and MUST BE globally unique.
 
YES, there could be an issue about updates to registered time zone definitions. Biggest problem right now is the lack of a registrar and process!
 
-- Frank 
------_=_NextPart_001_01C0CC46.F6561EB0-- From owner-ietf-calendar@mail.imc.org Mon Apr 23 19:59:11 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14828 for ; Mon, 23 Apr 2001 19:59:10 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA08738 for ietf-calendar-bks; Mon, 23 Apr 2001 16:47:32 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA08731 for ; Mon, 23 Apr 2001 16:47:29 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Recap: Does 1 day == 24 hours? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04172001 April 17, 2001 Message-ID: Date: Mon, 23 Apr 2001 19:56:00 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/23/2001 07:48:39 PM, Serialize complete at 04/23/2001 07:48:39 PM Content-Type: multipart/alternative; boundary="=_alternative 0082AF2C85256A37_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0082AF2C85256A37_= Content-Type: text/plain; charset="us-ascii" Eric scribbed: > To review, the problem is that RFC2445 does not > specify what 1D really means when used in a DURATION. During the > discussion, there were three camps: Ive been too busy w/paying work to wade in on this until now but Ill jump right in and try to catch up... > 1) 1D means 24H. In this case, 1D is a synonym for 24H. [Snip] > > 2) 1D means "the remainder of today".[Snip] > > 3) 1D means "the same time tomorrow" [Snip] > > Now, honestly, none of these options are very good. I find one option right on and the other 2 off base by variying amounts (why else would I be responding?) Before progressing w/Erics analysis Id like to point out something from the ABNF (and I think that Patrick raised it at one point). From 4.3.6's ABNF: dur-date = dur-day [dur-time] dur-time = "T" (dur-hour / dur-minute / dur-second) [Snip] dur-day = 1*DIGIT "D" You will note that dur-day is NOT a time duration; its an implicit date unit and as such is not a time unit. There should be no consideration of time units when dealing with a date unit. Sure, you can do some mappings that work for nearly all cases (ie: 1 day = 24 hours except for possibly 2 dates a year which is somewhere around ~0.75% of the calendar days in a Gregorian calendar year; not a high percentage occurance case IMHO) but as already noted this could confuse some people. > (1) implies that the end time of a 1D event can move around depending on > daylight savings time shifts, and it makes the W and D specifiers > redundant, since they can always be expressed in H, M or S. This case would be an acceptable idea from a coding model but its possible that it could confuse human users, depending on how the CUAs display the information. Its also ambiguous enough that some confusion may exist (especially if the receiving CUA does not have the TZ definition of the sending CUA and they do not share TZ shift rules). > (2) is logical, self consistent and non-redundant. It is the RFC > authors original intent, but I'd suspect that end users will find it > very strange. Are there use cases that require this behavior? It may have been Franks intent but I do not recall it being expressed that way. I certainly would have argued against it had he done so in any earlier drafts. Perhaps its splitting hairs (ugh) between saying July 4th is 1 Day long (starting at midnight local time and ending at 23:59:59 local time) and my "day long" Scavenger Hunt that starts at July 4th @ 9AM (EST) and ends "1 day later" but I would claim its not. The former case has implicit time values involved (ie: DTSTART;VALUE=DATE:07042001) and the latter case has explicit time values. As noted above, day is NOT time unit based as such time units should not be used when 'adjusting' or calculating a date based shift. One cannot reliably use a implicit time case to argue the explicit time case; thats like using apples and oranges. (Well, actually one could try...) I would suggest that using DURATION:1D is an improper use of it if the user wanted to indicate "This event ends just before midnight no matter the start time". Thats more properly specified by a DTEND;VALUE=DATE:07042001 where the time is implicity assumed to be 23:59:59. > (3) may be more expected from the end-users perspective, but is > complex to implement, since you have to look for timezone shifts every > time you convert a DURATION of 1D into an end time. Not sure I follow that logic. Simply put for (3), all I have to do is (pardon this pseudo script): Dim Duration As New DateTime( DTStart.Value ) Call Duration.AdjustDay (+1) This simply moves the 'date' to the 'next day'. The time value of the DTSTART, given to the DURATION value, is unchanged. This is not rocket science nor complex to implement. It may be complex if your engine converts all date values to time values and you do not properly write your AdjustDay() to scale the adjust value to the same base units (ie: seconds since 01-Jan-2000, etc). Otherwise its trivial to shift dates. There is no end time to convert, you inherit the one from the DTSTART. If the DTSTART is of VALUE=DATE, the value is 00:00:00 and the calculated end time would use that. > Personally, I'd reject (1). It is the easiest to understand and is > logical, but it doesn't add anything to the behavior of DURATION. A KISS mantra could be that this is useful for the vast majority of cases (unless you really only work around a TZ shift and spend the entire rest of the year doing nothing) and as such could be used if we codified this behaviour. However I agree that its not the one Id describe as "the best". > I prefer (2), but could live with (3). Both add useful behavior to > DURATION that cannot be accomplished easily with H,M and S. (3) is nice > because I think it best matches users expectations. I would naturally > expect that a 1D event that starts today at 10:00 will end tomorrow at > 10:00, and (3) ensures this behavior. Thats partly why I like (3). The other part is that its not rocket science to code it. I very strongly dislike (2) since it involves unit conversion that is not safe or intuitive. > However (2) makes more sense when the value of DTSTART is DATE. In fact, > it is probably sensible to restrict DURATION to only using W and D when > DTSTART:VALUE=DATE. This would eliminate any questions about what it means > to at 2H to a DATE. This points to strengthing the concept of time scale > vs date scale in RFC2445, and (2) would be an important part of that > concept. I can see uses where I may want the implicit start time (which wont vary even w/a TZ shift) but have a duration of 1DT8H (which may end at 7AM, 8AM, or 9AM depending on if a TZ shift is involved). However these cases are not likely to be the norm for our C&S usage model (lets try to apply the 90/10 or 99/1 rule here shall we???). I would suggest that the restrictions on DURATION 'scale' be: Duration MUST be of VALUE=DATE if DTSTART is of VALUE=DATE. This does preclude a DURATION:1DT8H case but its an acceptable limitation to me. Duration MAY be of VALUE=DATE or VALUE=DATE-TIME if DTSTART is of VALUE=DATE-TIME Date units are NOT convertable to Time units. The time value for the calculated or effective DTEND is inherited from the DTSTART when no dur-time values are specified When time units are specified (in addition to date units) then they are based on the time inherited from the DTSTART property. I also think that this would allow us to at some point reintroduce week and month duration in a consistant manner (ie: P1W = "Add 1 to the week value of the start date" with 1 week = 7 days). We may have to do some tightening of what it means to have a duration of 1 month when the following month has fewer days than the current one (ie: DTSTART:01302001 and DURATION:P1M = what date?) but thats over the horizon now. I think it bears mentioning that a duration value of P1W suffers from the same 'vagueness' that P1D does (just think about it). May as well clean it all up at once... > (2) is easy to implement, adds additinoal functionality, and although it > has unusual behavior for DTSTART;VALUE-DATE-TIME, it is a perfect match > for DTSTART;VALUE=DATE. Its behaviour is non-intuitive and can more properly be modeled by a DTEND;VALUE=DATE. I see no problem w/(3) matching DTSTART;VALUE=DATE at all since times units are not involved. > Which option do you prefer? In case its not clear by now: (3) is by far my favorite option with (1) a somewhat distant second and (3) absolutely dead last. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0082AF2C85256A37_= Content-Type: text/html; charset="us-ascii"
Eric scribbed:
> To review, the problem is that RFC2445 does not
> specify what 1D really means when used in a DURATION. During the
> discussion, there were three camps:

Ive been too busy w/paying work to wade in on this until now but Ill jump right in and try to catch up...

>   1) 1D means 24H. In this case, 1D is a synonym for 24H. [Snip]
>
>   2) 1D means "the remainder of today".[Snip]
>
>   3) 1D means "the same time tomorrow" [Snip]
>
> Now, honestly, none of these options are very good.

I find one option right on and the other 2 off base by variying amounts (why else would I be responding?)  Before progressing w/Erics analysis Id like to point out something from the ABNF (and I think that Patrick raised it at one point).  From 4.3.6's ABNF:

     dur-date   = dur-day [dur-time]
    dur-time   = "T" (dur-hour / dur-minute / dur-second)
[Snip]
     dur-day    = 1*DIGIT "D"

You will note that dur-day is NOT a time duration; its an implicit date unit and as such is not a time unit. There should be no consideration of time units when dealing with a date unit.  Sure, you can do some mappings that work for nearly all cases (ie: 1 day = 24 hours except for possibly 2 dates a year which is somewhere around ~0.75% of the calendar days in a Gregorian calendar year; not a high percentage occurance case IMHO) but as already noted this could confuse some people.

> (1) implies that the end time of a 1D event can move around depending on
> daylight savings time shifts, and it makes the W and D specifiers
> redundant, since they can always be expressed in H, M or S.
This case would be an acceptable idea from a coding model but its possible that it could confuse human users, depending on how the CUAs display the information.  Its also ambiguous enough that some confusion may exist (especially if the receiving CUA does not have the TZ definition of the sending CUA and they do not share TZ shift rules).

> (2) is logical, self consistent and non-redundant. It is the RFC
> authors original intent, but I'd suspect that end users will find it
> very strange. Are there use cases that require this behavior?
It may have been Franks intent but I do not recall it being expressed that way.  I certainly would have argued against it had he done so in any earlier drafts.

Perhaps its splitting hairs (ugh) between saying July 4th is 1 Day long (starting at midnight local time and ending at 23:59:59 local time) and my "day long" Scavenger Hunt that starts at July 4th @ 9AM (EST) and ends "1 day later" but I would claim its not.  The former case has implicit time values involved (ie: DTSTART;VALUE=DATE:07042001) and the latter case has explicit time values.  As noted above, day is NOT time unit based as such time units should not be used when 'adjusting' or calculating a date based shift.

One cannot reliably use a implicit time case to argue the explicit time case; thats like using apples and oranges.  (Well, actually one could try...)

I would suggest that using DURATION:1D is an improper use of it if the user wanted to indicate "This event ends just before midnight no matter the start time".  Thats more properly specified by a DTEND;VALUE=DATE:07042001 where the time is implicity assumed to be 23:59:59.

> (3) may be more expected from the end-users perspective, but is
> complex to implement, since you have to look for timezone shifts every
> time you convert a DURATION of 1D into an end time.

Not sure I follow that logic.  Simply put for (3), all I have to do is (pardon this pseudo script):

        Dim Duration As New DateTime( DTStart.Value )
        Call Duration.AdjustDay (+1)        

This simply moves the 'date' to the 'next day'.  The time value of the DTSTART, given to the DURATION value, is unchanged.  This is not rocket science nor complex to implement.  It may be complex if your engine converts all date values to time values and you do not properly write your AdjustDay() to scale the adjust value to the same base units (ie: seconds since 01-Jan-2000, etc).  Otherwise its trivial to shift dates.

There is no end time to convert, you inherit the one from the DTSTART.  If the DTSTART is of VALUE=DATE, the value is 00:00:00 and the calculated end time would use that.

> Personally, I'd reject (1). It is the easiest to understand and is
> logical, but it doesn't add anything to the behavior of DURATION.

A KISS mantra could be that this is useful for the vast majority of cases (unless you really only work around a TZ shift and spend the entire rest of the year doing nothing) and as such could be used if we codified this behaviour.  However I agree that its not the one Id describe as "the best".

> I prefer (2), but could live with (3). Both add useful behavior to
> DURATION that cannot be accomplished easily with H,M and S. (3) is nice
> because I think it best matches users expectations. I would naturally
> expect that a 1D event that starts today at 10:00 will end tomorrow at
> 10:00, and (3) ensures this behavior.

Thats partly why I like (3).  The other part is that its not rocket science to code it.  I very strongly dislike (2) since it involves unit conversion that is not safe or intuitive.

> However (2) makes more sense when the value of DTSTART is DATE. In fact,
> it is probably sensible to restrict DURATION to only using W and D when
> DTSTART:VALUE=DATE. This would eliminate any questions about what it means
> to at 2H to a DATE. This points to strengthing the concept of time scale
> vs date scale in RFC2445, and (2) would be an important part of that
> concept.

I can see uses where I may want the implicit start time (which wont vary even w/a TZ shift) but have a duration of 1DT8H (which may end at 7AM, 8AM, or 9AM depending on if a TZ shift is involved).  However these cases are not likely to be the norm for our C&S usage model (lets try to apply the 90/10 or 99/1 rule here shall we???).

I would suggest that the restrictions on DURATION 'scale' be:
  1. Duration MUST be of VALUE=DATE if DTSTART is of VALUE=DATE.  This does preclude a DURATION:1DT8H case but its an acceptable limitation to me.
  2. Duration MAY be of VALUE=DATE or VALUE=DATE-TIME if DTSTART is of VALUE=DATE-TIME
  1. Date units are NOT convertable to Time units.  The time value for the calculated or effective DTEND is inherited from the DTSTART when no dur-time values are specified
  2. When time units are specified (in addition to date units) then they are based on the time inherited from the DTSTART property.

    I also think that this would allow us to at some point reintroduce week and month duration in a consistant manner (ie: P1W = "Add 1 to the week value of the start date" with 1 week = 7 days).  We may have to do some tightening of what it means to have a duration of 1 month when the following month has fewer days than the current one (ie: DTSTART:01302001 and DURATION:P1M = what date?) but thats over the horizon now.

    I think it bears mentioning that a duration value of P1W suffers from the same 'vagueness' that P1D does (just think about it).  May as well clean it all up at once...

    > (2) is easy to implement, adds additinoal functionality, and although it
    > has unusual behavior for DTSTART;VALUE-DATE-TIME, it is a perfect match
    > for DTSTART;VALUE=DATE.
    Its behaviour is non-intuitive and can more properly be modeled by a DTEND;VALUE=DATE.   I see no problem w/(3) matching DTSTART;VALUE=DATE at all since times units are not involved.

    > Which option do you prefer?
    In case its not clear by now: (3) is by far my favorite option with (1) a somewhat distant second and (3) absolutely dead last.

    Bruce
    ===========================================================================
    Bruce Kahn                                INet: Bruce_Kahn@iris.com
    Iris Associates                          Phone: 978.392.5335
    Westford, MA, USA 01886                    FAX: and nothing but the FAX...
    Standard disclaimers apply, even where prohibited by law...
--=_alternative 0082AF2C85256A37_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 23 20:26:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15224 for ; Mon, 23 Apr 2001 20:26:19 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA09781 for ietf-calendar-bks; Mon, 23 Apr 2001 17:15:01 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA09774 for ; Mon, 23 Apr 2001 17:14:59 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Shannon J. Clark" Cc: "CalSched IETF" Subject: Re: Questions from RFC2445 - Member, Range, "group schedule" and periods MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04172001 April 17, 2001 Message-ID: Date: Mon, 23 Apr 2001 20:23:29 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/23/2001 08:16:08 PM, Serialize complete at 04/23/2001 08:16:08 PM Content-Type: multipart/alternative; boundary="=_alternative 00015D2485256A38_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00015D2485256A38_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shannon asked: >1. Why is there a "Member" parameter? The examples that are shown do not >seem to clearly identify a useful role for this parameter. So that a user can easily convey what group or groups they are a member=20 of. That way a CUA can use the information for either presentation or=20 possibly for data/response organization. Imagine you invite=20 ATTENDEE;TYPE=3DUNKNOWN:mailto:ietf-calendar@imc.org and you later want to = see what the attendee responses are. Your CUA may use that info to match=20 my reply up (ATTENDEE;MEMBER=3D"mailto:ietf-calendar@imc.org";CN=3D"Bruce K= ahn":mailto:Bruce=5FKahn@iris.con)=20 to possible groups in your invite. It also allows a CUA to possibly=20 detect that an ATTENDEE is not a "person" but rather a "group". The other = uses are left to the CUA implementors imagination (or the product=20 marketing types to dream up). >2. Why is there a RANGE parameter ? it also does not seem to clearly have = a >useful role? Certainly the examples do not show why this is there or how=20 it >will be used in "real" world applications. Some simple "real" world uses: 1: You want to reschedule all instances of an existing repeating meeting=20 to be at a new location, day or time. You may only want to reschedule=20 "our weekly team meetings" to be in a new LOCATION if you changed=20 buildings, etc. 2: You need to add an ATTENDEE (or other details) to an existing repeating = entry set but only for a particular period of time (ie: "Dont forget to=20 add the new guy to the team mailing list"). 3: Propagating any other kinds of changes to a range of entries in a=20 repeating set. This functionality already exists in some shipping=20 products. >3. p26. uses a reference to a "group schedule calendar component" which=20 is >not, I think, ever defined anywhere else in the standards document. Thats the same as the "group scheduled event or to-do " mentioned on pp21 (= twice) & 30, the "group scheduled "VEVENT", "VTODO" or "VJOURNAL"" on p26, = the "group scheduled calendar entity" on p102 and the "group scheduled meet= ing" on p137. You'll also find that exact phrase on p88. I think there is= a typo and=20 it should be "group scheduled calendar component"... >4. p36 ? Says only that for periods the start time must be before the end >time. Hmm, I think you mean p39. The snippet of ABNF that I think you are referr= ing=20 to is: period-explicit =3D date-time "/" date-time ; [ISO 8601] complete representation basic format for a period of ; time consisting of a start and end. The start MUST be before the ; end. This is a correct restriction. The period cannot end before it begins... >i.e. the time values MUST be in the same format (you can?t have a >floating time and a UTC or TZID formatted time and get a sensible=20 result.) >This probably should be clarified and specified. Actually you may (although not 100% of the time) but I think that this is=20 a good suggestion in order to avoid some pain later on.=20 Bruce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Kahn INet: Bruce=5FKahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00015D2485256A38_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Shannon asked:
>1. Why is there a "Member&= quot; parameter? The examples that are shown do not
>seem to clearly identify a useful role for this parameter.
So that a user can easily convey wha= t group or groups they are a member of.  That way a CUA can use the in= formation for either presentation or possibly for data/response organizatio= n.  Imagine you invite ATTENDEE;TYPE=3DUNKNOWN:mailto:ietf-calendar@im= c.org and you later want to see what the attendee responses are.  Your= CUA may use that info to match my reply up (ATTENDEE;MEMBER=3D"mailto= :ietf-calendar@imc.org";CN=3D"Bruce Kahn":mailto:Bruce=5FKah= n@iris.con) to possible groups in your invite.  It also allows a CUA t= o possibly detect that an ATTENDEE is not a "person" but rather a= "group".  The other uses are left to the CUA implementors i= magination (or the product marketing types to dream up).

>2. Why is there a RANGE paramet= er – it also does not seem to clearly have a
>useful role? Certainly the examples do not show why this is there or ho= w it
>will be used in "real" world applications.

Some simple "real" world u= ses:

1: You want to reschedule all instan= ces of an existing repeating meeting to be at a new location, day or time. =  You may only want to reschedule "our weekly team meetings" = to be in a new LOCATION if you changed buildings, etc.
2: You need to add an ATTENDEE (or o= ther details) to an existing repeating entry set but only for a particular = period of time (ie: "Dont forget to add the new guy to the team mailin= g list").
3: Propagating any other kinds of ch= anges to a range of entries in a repeating set.  This functionality al= ready exists in some shipping products.

>3. p26. uses a reference to a &= quot;group schedule calendar component" which is
>not, I think, ever defined anywhere else in the standards document.

Thats the same as the "group sc= heduled event or to-do " mentioned on pp21 (twice) & 30, the "= ;group scheduled "VEVENT", "VTODO" or "VJOURNAL&qu= ot;" on p26, the "group scheduled calendar entity" on p102 a= nd the "group scheduled meeting" on p137.  You'll also find = that exact phrase on p88.  I think there is a typo and it should be &q= uot;group scheduled calendar component"...

>4. p36 – Says only that f= or periods the start time must be before the end
>time.

Hmm, I think you mean p39.  The= snippet of ABNF that I think you are referring to is:

     period-explicit= =3D date-time "/" date-time
    ; [ISO 8601] complete representation basic format for a peri= od of
    ; time consisting of a start and end. The start MUST be befo= re the
    ; end.
This is a correct restriction.  = ;The period cannot end before it begins...

>i.e. the time values MUST be in= the same format (you can’t have a
>floating time and a UTC or TZID formatted time and get a sensible resul= t.)
>This probably should be clarified and specified.

Actually you may (although not 100% = of the time) but I think that this is a good suggestion in order to avoid s= ome pain later on.  

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                   &= nbsp;            INet: Bruce=5FKahn@iris.com<= br> Iris Associates                 &nb= sp;        Phone: 978.392.5335
Westford, MA, USA 01886               &n= bsp;    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00015D2485256A38_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 23 21:25:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15855 for ; Mon, 23 Apr 2001 21:25:42 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA13344 for ietf-calendar-bks; Mon, 23 Apr 2001 18:14:52 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA13339 for ; Mon, 23 Apr 2001 18:14:50 -0700 (PDT) Received: from ximian.com (IDENT:damon@karuna.ximian.com [141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id VAA26214; Mon, 23 Apr 2001 21:14:37 -0400 Message-ID: <3AE4D2D5.F4C60AA7@ximian.com> Date: Mon, 23 Apr 2001 21:11:49 -0400 From: Damon Chaplin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Busboom CC: ietf-calendar@imc.org Subject: Re: Recap: Does 1 day == 24 hours? 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: > 1) 1D means 24H. > 2) 1D means "the remainder of today". > 3) 1D means "the same time tomorrow" I'd say use (3) as it is the most intuitive. Surely most iCalendar apps out there already assume (3) anyway. I can't see much use for (2), and if an app really wants that kind of functionality it can convert it to a 'normal' duration or use an end time instead or something. Damon From owner-ietf-calendar@mail.imc.org Mon Apr 23 21:46:54 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16977 for ; Mon, 23 Apr 2001 21:46:53 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA14768 for ietf-calendar-bks; Mon, 23 Apr 2001 18:36:57 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA14758 for ; Mon, 23 Apr 2001 18:36:54 -0700 (PDT) Received: from ximian.com (IDENT:damon@karuna.ximian.com [141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id VAA27960; Mon, 23 Apr 2001 21:36:42 -0400 Message-ID: <3AE4D802.95498F7E@ximian.com> Date: Mon, 23 Apr 2001 21:33:54 -0400 From: Damon Chaplin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: Omit VTIMEZONE when using global identifiers? References: <3ACC7487.7B72D56D@steltor.com> <5.0.0.25.0.20010406101607.025628b0@apollo> <3ACDE483.27A3FB45@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > Alan Davies wrote: > > > At 10:17 2001-04-06 -0400, John Stracke wrote: > > >I think we have to keep the VTIMEZONE in, no matter what. > > > > So what's the point of using the unique name? > > In iCalendar--not much. In the UI, it might be vaguely useful for people to > be able to carry their knowledge from CUA to CUA. I agree with John here. I don't see much use at present for the globally unique identifiers, except for the GUI. Possible version updates mean you can't rely on the VTIMEZONE being the same. (But one important benefit would be for CUAs to store translations of the standard timezone names, so they are of more use to non-English speakers.) Damon From owner-ietf-calendar@mail.imc.org Mon Apr 23 23:18:28 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18477 for ; Mon, 23 Apr 2001 23:18:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id UAA17670 for ietf-calendar-bks; Mon, 23 Apr 2001 20:06:19 -0700 (PDT) Received: from agony.busboom.org (dt011n61.san.rr.com [204.210.13.97]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA17661 for ; Mon, 23 Apr 2001 20:06:17 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f3O36A814189 for ; Mon, 23 Apr 2001 20:06:10 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 23 Apr 2001 20:06:09 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Where to put VTIMEZONE and VALARM? 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: Currently, the CAP draft (-04) has a storage model that says: Calendar Store | +-- VCARs +-- Properties +-- VCARs +-- VTIMEZONEs +-- VCALENDARs | +--VEVENTs +--VALARMs +--VTODOs +--VALARMs +--VJOURNALs +--VCARs +--Properties +--VTIMEZONEs +--VSCHEDULE +--Calendar -- that is, that VALARMS can be stored in VEVENTs and VTODOS, but VTIMEZONE are stored in the VCALENDAR. Putting VALARMS in the VEVENT makes sense, since it is there is no other way to associate the VALARM with the VEVENT. Unfortunately, this seems to be disallowed in iTIP by RFC 2446. It would be nice if the CAP storage model and the iTIP model agreed So request #1 for this mail is: Can we change RFC2446 to allow the VALARM to be a child of a VEVENT or VTODO? That is, make RFC2446 agree with the storage model in the CAP draft. Currently, a similar problem exists with VTIMEZONE. If you try to put a bunch of components that you got from remote users into a single VCALENDAR, the VTIMEZONES are children of the VCALENDAR, not the VEVENTS. This means that if you have two VTIMEZONES with the same TZID, but different RRULES ( presumably from two different users working with different version of a timezone database ) then you will have a conflict when the VTIMEZONES go into the VCALENDAR. So, the second request is: Can we change the storage model to allow VTIMEZONES to be children of VEVENT, VTODO and VJOURNAL? That is, make RFC2446 agree with this model: Calendar Store | +-- VCARs +-- Properties +-- VCARs +-- VTIMEZONEs +-- VCALENDARs | +--VEVENTs +--VALARMs +--VTIMEZONEs +--VTODOs +--VALARMs +--VTIMEZONEs +--VJOURNALs Then, the conflicting VTIMEZONES could be associated with their events, and ones that are known to be global can be put at the VCALENDAR level. eric. From owner-ietf-calendar@mail.imc.org Tue Apr 24 10:03:12 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08003 for ; Tue, 24 Apr 2001 10:03:11 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA13788 for ietf-calendar-bks; Tue, 24 Apr 2001 06:51:01 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA13775 for ; Tue, 24 Apr 2001 06:50:54 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3ODwWA30209 for ; Tue, 24 Apr 2001 09:58:32 -0400 Message-ID: <3AE57CAB.E0931635@ecal.com> Date: Tue, 24 Apr 2001 09:16:28 -0400 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: REQUEST sent to non-ATTENDEE References: <5.0.0.25.0.20010423114402.02f148c0@imap1.in.steltor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alan Davies wrote: > So, what do other implementors think- can a REQUEST be sent > to a non-ATTENDEE? I'd think so. 2446/3.2.2 lists uses for REQUEST, including: Forward a "VEVENT" to another uninvited CU. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"There will be no more there. We will all be | |francis@ecal.com|here."--networkMCI ad | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 24 10:03:49 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08017 for ; Tue, 24 Apr 2001 10:03:47 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA13783 for ietf-calendar-bks; Tue, 24 Apr 2001 06:50:56 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA13776 for ; Tue, 24 Apr 2001 06:50:54 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3ODwXA30213 for ; Tue, 24 Apr 2001 09:58:33 -0400 Message-ID: <3AE57CE2.3BE19275@ecal.com> Date: Tue, 24 Apr 2001 09:17:22 -0400 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: Recap: Does 1 day == 24 hours? 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: > Personally, I'd reject (1). It is the easiest to understand and is > logical, but it doesn't add anything to the behavior of DURATION. If > we are going to define 1W = 7D and 1D = 24H, then we could just > condense the entire DURATION down to seconds. By this argument, W, H, and M should all be eliminated in favor of D and S. > Which option do you prefer? (1). -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"There will be no more there. We will all be | |francis@ecal.com|here."--networkMCI ad | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 24 10:10:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08091 for ; Tue, 24 Apr 2001 10:10:20 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA14166 for ietf-calendar-bks; Tue, 24 Apr 2001 06:56:55 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA14160 for ; Tue, 24 Apr 2001 06:56:53 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3OE4WA30236 for ; Tue, 24 Apr 2001 10:04:32 -0400 Message-ID: <3AE587EF.9F9ADD43@ecal.com> Date: Tue, 24 Apr 2001 10:04:31 -0400 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: Recap: Does 1 day == 24 hours? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > (1) [...] > Its also ambiguous enough that some confusion may exist > (especially if the receiving CUA does not have the TZ > definition of the sending CUA and they do not share TZ shift > rules). This is a strawman, since every VEVENT must contain a VTIMEZONE for every TZ it uses -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |We must be devious, cunning, inventive... too| |francis@ecal.com|bad we're us. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 24 10:19:47 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08176 for ; Tue, 24 Apr 2001 10:19:47 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA14883 for ietf-calendar-bks; Tue, 24 Apr 2001 07:04:18 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA14876 for ; Tue, 24 Apr 2001 07:04:16 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3OEBtA30250 for ; Tue, 24 Apr 2001 10:11:55 -0400 Message-ID: <3AE589AA.B70F7007@ecal.com> Date: Tue, 24 Apr 2001 10:11:55 -0400 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: Omit VTIMEZONE when using global identifiers? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > 1: The receiving CUA may not have access to any still TBD TZ > registry mechanism. As such, they could not resolve any shifts > properly! [...] > 3: The receiving CUA may be an older CUA that does not know of > any way to go and resolve/confirm the non-included TZID. > Again, this is not very nice. In any event, we don't want CUAs to go out and hit a global registry every time they need a timezone definition, since that would require a truly massive server. Embedding the VTIMEZONE in the event is a step toward reducing the registry's load. (I believe the IESG tends to look skeptically on any proposal that requires automatically consulting a global registry. I remember that WebDAV had some pushback on their use of URIs as identifiers until they put in text that these URIs were never to be resolved.) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Chris is the most self-effacing guy I know."| |francis@ecal.com|"Well, I'm not *that* good at it." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 24 10:20:31 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08195 for ; Tue, 24 Apr 2001 10:20:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA15034 for ietf-calendar-bks; Tue, 24 Apr 2001 07:06:44 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA15029 for ; Tue, 24 Apr 2001 07:06:42 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f3OEEKA30268 for ; Tue, 24 Apr 2001 10:14:20 -0400 Message-ID: <3AE58A3B.2FF5EAB1@ecal.com> Date: Tue, 24 Apr 2001 10:14:19 -0400 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: Omit VTIMEZONE when using global identifiers? References: <3ACC7487.7B72D56D@steltor.com> <5.0.0.25.0.20010406101607.025628b0@apollo> <3ACDE483.27A3FB45@ecal.com> <3AE4D802.95498F7E@ximian.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 Damon Chaplin wrote: > (But one important benefit would be for CUAs to store translations of > the standard > timezone names, so they are of more use to non-English speakers.) Yes, that would be nice. Of course, a VTIMEZONE can have multiple TZNAMEs; but that works only if the sender's CUA knows the translation for the receiver's language. If I'm, say, Estonian (~1 million speakers), and I'm trying to schedule a meeting with someone in Japan, a translation table in my CUA would be very useful. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Fly Heisenberg Airlines! We may not know where| |francis@ecal.com|we are, but we're making real good time." -- | | |_Synners_ by Pat Cadigan | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Apr 24 10:42:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08599 for ; Tue, 24 Apr 2001 10:42:34 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA16226 for ietf-calendar-bks; Tue, 24 Apr 2001 07:30:34 -0700 (PDT) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA16218 for ; Tue, 24 Apr 2001 07:30:30 -0700 (PDT) Received: from dhcp-64-103-48-193.cisco.com (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA14181; Tue, 24 Apr 2001 16:30:00 +0200 (MET DST) Date: Tue, 24 Apr 2001 16:30:01 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: John Stracke , ietf-calendar@imc.org Subject: Re: Recap: Does 1 day == 24 hours? Message-ID: <296620.988129801@dhcp-64-103-48-193.cisco.com> In-Reply-To: <3AE57CE2.3BE19275@ecal.com> References: <3AE57CE2.3BE19275@ecal.com> X-Mailer: Mulberry/2.1.0a4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On 01-04-24 09.17 -0400 John Stracke wrote: > If > we are going to define 1W = 7D and 1D = 24H, then we could just > condense the entire DURATION down to seconds. I have not read the whole thread (too much mail, and I always trust the wg to do a correct job). But, these things will _NOT_ pass the IESG. One week is not the same thing as 7*24*3600 seconds. You have leap seconds and changes to/from daylight savings. If one say duration of one day, with start 12.32AM, the end is 12.32AM next day, regardless of whether there have been a leap second, change in daylight savings or whatever. If the duration is not one day but 24*3600 seconds, the end time might be something else than 12.32AM the next day. paf From owner-ietf-calendar@mail.imc.org Tue Apr 24 11:59:25 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09787 for ; Tue, 24 Apr 2001 11:59:23 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA24335 for ietf-calendar-bks; Tue, 24 Apr 2001 08:44:17 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA24322 for ; Tue, 24 Apr 2001 08:44:14 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: REQUEST sent to non-ATTENDEE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Tue, 24 Apr 2001 11:44:41 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/24/2001 11:44:52 AM, Serialize complete at 04/24/2001 11:44:52 AM Content-Type: multipart/alternative; boundary="=_alternative 00566BEB85256A38_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00566BEB85256A38_= Content-Type: text/plain; charset="us-ascii" Alan wrote: > User B would be visible to all other ATTENDEEs though, > which might not be the required effect. Id like to make sure that folks realize something thats implicit in the RFCs. _Nowhere_ in the RFCs does it state each ATTENDEE gets the exact same copy of the iCalendar stream that the other ATTENDEEs do. Most (all?) of our examples show A, B and C all getting the same invitation, etc but it is perfectly legal to NOT send the same stream to each ATTENDEE. That is, Users A, B and C all get iCalendar invites that just look as if they are the sole invitee. Or just User C could get one with all the ATTENDEEs and the other two see just themselves... Examples for this include being able to build your Bcc style functionality or just plain adding an ATTENDEE after the fact (dont tell me that everyone always gets the invitee list perfect on the first attempt 100% of the time). Another example is inviting a 'local group' (local to my computer) and having the SMTP system explode it into separate iMIP recipients so that I can digitally sign and encrypt each message. Sure, most CUAs will create the iCalendar w/all the ATTENDEEs in it and send out 1 copy since that is the easiest approach. Perhaps 2+ may be sent if the CUA wants to 'roll' alternate copies for each BCC invitee and a single all inclusive one to the room reservation system so that it can properly decide if the room can handle all the invitees. However it is dangerous to code a CUA to expect that all invitees are listed in your REQUEST since the sender may not have put them all in it for whatever reason. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00566BEB85256A38_= Content-Type: text/html; charset="us-ascii"
Alan wrote:
>        User B would be visible to all other ATTENDEEs though,
>        which might not be the required effect.

Id like to make sure that folks realize something thats implicit in the RFCs.  _Nowhere_ in the RFCs does it state each ATTENDEE gets the exact same copy of the iCalendar stream that the other ATTENDEEs do.  Most (all?) of our examples show A, B and C all getting the same invitation, etc but it is perfectly legal to NOT send the same stream to each ATTENDEE.  That is, Users A, B and C all get iCalendar invites that just look as if they are the sole invitee.  Or just User C could get one with all the ATTENDEEs and the other two see just themselves...

Examples for this include being able to build your Bcc style functionality or just plain adding an ATTENDEE after the fact (dont tell me that everyone always gets the invitee list perfect on the first attempt 100% of the time).  Another example is inviting a 'local group' (local to my computer) and having the SMTP system explode it into separate iMIP recipients so that I can digitally sign and encrypt each message.

Sure, most CUAs will create the iCalendar w/all the ATTENDEEs in it and send out 1 copy since that is the easiest approach.  Perhaps 2+ may be sent if the CUA wants to 'roll' alternate copies for each BCC invitee and a single all inclusive one to the room reservation system so that it can properly decide if the room can handle all the invitees.  However it is dangerous to code a CUA to expect that all invitees are listed in your REQUEST since the sender may not have put them all in it for whatever reason.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00566BEB85256A38_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 24 13:04:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10615 for ; Tue, 24 Apr 2001 13:04:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA29506 for ietf-calendar-bks; Tue, 24 Apr 2001 09:48:27 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA29501 for ; Tue, 24 Apr 2001 09:48:25 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA14420 for ; Tue, 24 Apr 2001 12:47:57 -0400 Received: from c-1244.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3OGluP14822 for ; Tue, 24 Apr 2001 12:47:57 -0400 (EDT) Message-Id: <5.0.0.25.0.20010424122958.00af0bc0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 24 Apr 2001 12:46:31 -0400 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: REQUEST sent to non-ATTENDEE In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Bruce_Kahn@iris.com wrote: >Alan wrote: > > User B would be visible to all other ATTENDEEs though, > > which might not be the required effect. > >Id like to make sure that folks realize something thats implicit in the >RFCs. _Nowhere_ in the RFCs does it state each ATTENDEE gets the exact >same copy of the iCalendar stream that the other ATTENDEEs do. Most >(all?) of our examples show A, B and C all getting the same invitation, >etc but it is perfectly legal to NOT send the same stream to each ATTENDEE. That's a good point- so The Bcc'd user would see themselves as a NON-PARTICIPANT, but the other ATTENDEEs would get an object that didn't include them. This way the receiving CU would always see themselves as an attendee. John suggested that RFC2446 3.2.2.6 "Forwarding to An Uninvited CU" showed that a REQUEST could be forwarded to a CU without them being an ATTENDEE: An "Attendee" invited to an event may invite another uninvited CU to the event. The invited "Attendee" accomplishes this by forwarding the original "REQUEST" method to the uninvited CU. The "Organizer" decides whether or not the uninvited CU is added to the attendee list. This section didn't tell us how the "Organizer" gets the information about the uninvited CU though, does the invited "Attendee" send a COUNTER to the "Organizer"? --Alan From owner-ietf-calendar@mail.imc.org Tue Apr 24 15:16:09 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13099 for ; Tue, 24 Apr 2001 15:16:08 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA08921 for ietf-calendar-bks; Tue, 24 Apr 2001 12:00:47 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA08917 for ; Tue, 24 Apr 2001 12:00:45 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Tue, 24 Apr 2001 15:01:11 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/24/2001 03:01:23 PM, Serialize complete at 04/24/2001 03:01:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0068696485256A38_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068696485256A38_= Content-Type: text/plain; charset="us-ascii" Eric wrote: >So request #1 for this mail is: > > Can we change RFC2446 to allow the VALARM to be a child of a > VEVENT or VTODO? > >That is, make RFC2446 agree with the storage model in the CAP draft. That also makes it agree w/the implicit model from 2445. Its another restriction table bug I think. I dont think that the iTIP editors ever meant to imply that VALARMs were at the same containment level as VEVENTs, VTODOs, etc. >So, the second request is: > > Can we change the storage model to allow VTIMEZONES to be children > of VEVENT, VTODO and VJOURNAL? This would put the storage model at odds with containment model specified in 2445. Since more than 1 VEVENT can share the same TZID then you just get bad data bloat. Besides that kind of containment change is not as intuitive as the EVENT/ALARM model we already know and love... I would like to see the root of the problem resolved in a more model friendly way. >This means that if you have two VTIMEZONES with the same TZID, >but different RRULES ( presumably from two different users working with >different version of a timezone database ) then you will have a conflict >when the VTIMEZONES go into the VCALENDAR. I think you mean that the VTIMEZONE has > 1 VDAYLIGHT or VSTANDARD that have different RRULEs. Thats fine. The one with the most recent "effective date" superceedes the one with the earlier "effective date", just check out the text under Section 4.6.5 Time Zone Component and the example on p65. Perhaps you mean that 2 different streams have 2 VTIMEZONEs with the same TZID but different rules (but _identical_ effective dates)? That could be a problem. If the TZID is a standardized one (ugh) then we have a versioning problem and thats not in scope for this thread. If its a non-standardized TZID then Id suggest some other behaviour is necessary (like rewriting one TZID to be different or matching the newer TZID to an existing one that has the same/similar defintion, etc). However I dont think this probelm calls for reworking the containment rules in iCalendar/iTIP just yet... Bruce PS: You had 2 VCARs at under "Calendar Store"; you only need 1. =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0068696485256A38_= Content-Type: text/html; charset="us-ascii"
Eric wrote:

>So request #1 for this mail is:
>
>                 Can we change RFC2446 to allow the VALARM to be a child of a
>                 VEVENT or VTODO?
>
>That is, make RFC2446 agree with the storage model in the CAP draft.

That also makes it agree w/the implicit model from 2445.  Its another restriction table bug I think.  I dont think that the iTIP editors ever meant to imply that VALARMs were at the same containment level as VEVENTs, VTODOs, etc.

>So, the second request is:
>
>                 Can we change the storage model to allow VTIMEZONES to be children
>                 of VEVENT, VTODO and VJOURNAL?

This would put the storage model at odds with containment model specified in 2445.  Since more than 1 VEVENT can share the same TZID then you just get bad data bloat.  Besides that kind of containment change is not as intuitive as the EVENT/ALARM model we already know and love...

I would like to see the root of the problem resolved in a more model friendly way.  

>This means that if you have two VTIMEZONES with the same TZID,
>but different RRULES ( presumably from two different users working with
>different version of a timezone database ) then you will have a conflict
>when the VTIMEZONES go into the VCALENDAR.

I think you mean that the VTIMEZONE has > 1 VDAYLIGHT or VSTANDARD that have different RRULEs.  Thats fine.  The one with the most recent "effective date" superceedes the one with the earlier "effective date", just check out the text under Section 4.6.5 Time Zone Component and the example on p65.

Perhaps you mean that 2 different streams have 2 VTIMEZONEs with the same TZID but different rules (but _identical_ effective dates)?  That could be a problem.  If the TZID is a standardized one (ugh) then we have a versioning problem and thats not in scope for this thread.  If its a non-standardized TZID then Id suggest some other behaviour is necessary (like rewriting one TZID to be different or matching the newer TZID to an existing one that has the same/similar defintion, etc).  However I dont think this probelm calls for reworking the containment rules in iCalendar/iTIP just yet...  

Bruce
PS: You had 2 VCARs at under "Calendar Store"; you only need 1.
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0068696485256A38_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 24 15:57:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14020 for ; Tue, 24 Apr 2001 15:57:20 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA12502 for ietf-calendar-bks; Tue, 24 Apr 2001 12:40:34 -0700 (PDT) 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 MAA12497 for ; Tue, 24 Apr 2001 12:40:32 -0700 (PDT) Received: from localhost (slandrum@localhost) by grendel.csc.smith.edu (8.9.3/8.9.3) with ESMTP id PAA05699 for ; Tue, 24 Apr 2001 15:39:21 -0400 Date: Tue, 24 Apr 2001 15:39:21 -0400 (EDT) From: srl To: ietf-calendar@imc.org Subject: Reefknot talk at Boston.pm May 1 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: For those of you who were wondering about the Reefknot talk in Boston on May 1, here's the official notice. This will be an *informal* work-in-progress talk and brainstorming session. 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 ---------- Forwarded message ---------- Date: Tue, 24 Apr 2001 11:26:53 -0400 From: Ronald J Kimball To: Boston Perl Mongers Subject: [Boston.pm] Tech Meeting Tues May 1 Boston.pm will be having a Technical Meeting on Tuesday, May 1 (one week from today), at the offices of Boston.com. The meeting will begin at 7:30pm. See below for directions. Kirrily "Skud" Robert and Shane Landrum will be presenting Reefknot, a shared calendaring project. An abstract of this talk is included below. Also, Chris Nandor will tell us about the current state of MacPerl. With the recent releases of both perl5.6.1 and Mac OS X, there's a lot going on! Boston.com will be providing pizza and beverages. All members and friends of Boston.pm are welcome. Please RSVP to me if you plan on attending this meeting. thanks, Ronald rjk@linguist.dartmouth.edu ------------------------------------------------------------- Reefknot: shared calendaring in Perl Kirrily "Skud" Robert and Shane Landrum Have you ever wished your enterprise could do without MS Exchange? Ever wanted to schedule events with other members of your club, family, or organization? Do you use Perl? If so, you want to know about Reefknot. Reefknot is a project to build standards-compliant shared calendaring tools in Perl. We want to make it easy for Perl programmers to build calendaring clients and servers that speak iCalendar (RFC2445) and other standard protocols. The Reefknot project's major work to date is a major revision of Net::ICal; release 0.14 will be available soon on CPAN. We'll talk about the project's goals, show some of our recent work, and discuss what we're working on next. Bring your ideas for how you want to use calendaring tools. See http://reefknot.sourceforge.net for more information. -------------------------------------------------------------- Boston.com 320 Congress Street Boston, MA 02210 http://go.boston.com/scripts/map.dll?mad=320+Congress+St&mwt=350&mht=280&mct=Boston&mst=MA&YpOp=map&type=gis&method=mapaddr&Search=View+Map&ck=&ver=2.11 Driving directions: Directions From the South Shore: Drive north on the expressway (Rt 93.) take exit 20 (the Downtown Boston/Chinatown/Mass Pike exit) and stay towards the left when on the exit ramp. At the bottom of the exit ramp, take a left onto Kneeland Street and then your first right onto Surface Road. Drive straight past South Station, and past the Federal Reserve building, take a right Congress St. (At the Congress Street turn there will be a shop Lannan Ship Model Gallery on your right.) On Congress Street, drive straight over the bridge, (passing by the Boston Tea Party replica exhibit), past the Milk Bottle, and the Children's Museum. 320 Congress Street is on the left, the next building after the Children's Museum. Directions From the North Shore: Drive south on the expressway (Rt. 93) and take exit 23, (the High Street/Congress St exit.) The exit ramp puts you on Oliver Street. Take the first left onto High Street, and then after a few streets take a left onto Congress St. (it looks like two streets on the map I'm looking at, but I don't think that it is counting a couple of very wide looking alleys) Once on Congress, do your best to keep to the right, since the intersection at Surface Rd has two left turn only lanes. Drive straight past Lannan Ship Model Gallery, straight over the bridge, past the Tea Party replica, and past the Children's Museum. Boston.com is in the next building on the left. 320 Congress St. Parking info: The cheapest for-pay parking in the evenings is the lot across the street from Boston.com (I think it is a Kinney lot, evenings are a $6 flat rate.) The next least expensive parking lots are the $7 lots on either Service Rd (a few blocks down from Boston.com on the left) or the Northern Ave lots (Instead of the above driving directions, drive to the Federal Courthouse and walk up Sleeper Street, Boston.com will be at the corner of Sleeper and Congress on the left.) The parking lot at the corner of Congress and Farnsworth is outrageously expensive at any hour, as is the Farnsworth St Garage. For street parking, I think there are a few non-resident parking spaces still on the block Boston.com is on, but it seems that they convert more non-resident to resident spaces every week. More street parking is available on Summer Street (the street parallel to Congress on the south) and Dorchester Ave. (not to be confused with the well known Dot Ave. This one is just the short stretch of road that connects the Fort Point Post Office to Three Cheers). There is also parking on East Service Road and West Service Road. If you are looking for street parking I'd suggest driving circles around Congress/Service/Summer/Dorchester or driving down to E Service Rd/W Service Rd (around Anthony's Pier 4) If you park on Summer St, walk towards Downtown Boston and look for the small downward stairway on the last building before the bridge. That stairway will lead to Congress St and help you avoid having to cross the bridge twice. Public Transportation Directions: If you take the commuter rail into South Station, exit from the doors on the right (near the ticket counter) cross the street to the Federal Reserve Building (the large white building with the metal sliding panels which hide the gun turrets) take a right and walk along Summer St. down the sidewalk towards South Boston. At the set of lights with the the Post Office towards your right, take a left on Dorchester Ave and walk one block towards Congress St. Once you hit Congress St. cross the bridge and pass the Tea Party Museam, the Milk Bottle and the Children's Museum. Boston.com is in the next building after the Children's Museum. Directions from the Red Line: Try to navigate through the underground labyrinth to the "Museum Warf/Federal Reserve" exit. Go up the stairs and stand so you are facing South Boston and your back is against the Downtown Crossing area. Once above ground, find the subway entrance that I meant for you to leave from and walk towards that one. (Unless you wind up at the one that exits right into South Station itself, if so follow the commuter rail directions above.) Walk down Summer with the Federal Reserve building on your left and South Station on your right. /Federal Reserve" exit. Go up the stairs and stand so you are facing South Boston and your back is against the Downtown Crossing area. Once above ground, find the subway entrance that I meant for you to leave from and walk towards that one. Walk down Summer with the Federal Reserve building on your left and South Station on your right. When you get to the set of lights at the corner of Summer and Dorchester, (the Post Office is on your right) take a left and walk one block towards Congress St. Once on Congress St, take a right, walk over the bridge and pass the Tea Party Museum, The Milk Bottle, and the Children's Museum. Boston.com is in the next building after the Children's Museum. Food info: If you are planning on heading to around the Boston.com office first and then picking up dinner or coffee (maybe a small snack to tide you over until the tech meeting's pizzas are served), you will be serverly disappointed. Everthing on Congress and Summer Street closes by 5PM. Your best bet is either the South Station food court (which is open until about 8PM), or along Summer Street heading toward Downtown Crossing. (If you choose South Station, I recommend the Bourbon Chicken.) From owner-ietf-calendar@mail.imc.org Tue Apr 24 16:00:27 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14090 for ; Tue, 24 Apr 2001 16:00:26 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA13260 for ietf-calendar-bks; Tue, 24 Apr 2001 12:46:06 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA13254 for ; Tue, 24 Apr 2001 12:46:04 -0700 (PDT) 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 PAA18787 for ; Tue, 24 Apr 2001 15:45:36 -0400 Received: from pc152 (PC-152 [101.1.46.9]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JDT9GBNL; Tue, 24 Apr 2001 15:43:39 -0400 Message-ID: <0bff01c0ccf6$fd02bc90$092e0165@cst.ca> From: "Graham Gilmore" To: References: Subject: Re: Where to put VTIMEZONE and VALARM? Date: Tue, 24 Apr 2001 15:44:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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: To: "Eric Busboom" Cc: Sent: 24 April, 2001 15:01 Subject: Re: Where to put VTIMEZONE and VALARM? > > Can we change the storage model to allow VTIMEZONES to > be children > > of VEVENT, VTODO and VJOURNAL? > > This would put the storage model at odds with containment model > specified in 2445. Since more than 1 VEVENT can share the same TZID > then you just get bad data bloat. At first glance, I saw it this way too; but looking at Eric's proposed model: Calendar Store | +-- VCARs +-- Properties +-- VCARs +-- VTIMEZONEs +-- VCALENDARs | +--VEVENTs +--VALARMs +--VTIMEZONEs +--VTODOs +--VALARMs +--VTIMEZONEs +--VJOURNALs VTIMEZONEs are still present where they were before, they've just been added (optionally) under the VEVENT and VTODO (etc.) components. This would allow the majority of your VEVENTs to share a single VTIMEZONE, with any strange ones that use conflicting VTIMEZONEs (as Eric describes*) would 'internalize' their own VTIMEZONE (which would override the one in the 'outer scope', I assume). However, I agree that this isn't necessarily the way to go :) *Eric describes: "This means that if you have two VTIMEZONES with the same TZID, but different RRULES ( presumably from two different users working with different version of a timezone database ) then you will have a conflict when the VTIMEZONES go into the VCALENDAR. " > Perhaps you mean that 2 different streams have 2 VTIMEZONEs with the > same TZID but different rules (but _identical_ effective dates)? That > could be a problem. I believe this is the case Eric was referring to. > If the TZID is a standardized one (ugh) then we > have a versioning problem and thats not in scope for this thread. If > its a non-standardized TZID then Id suggest some other behaviour is > necessary (like rewriting one TZID to be different or matching the newer > TZID to an existing one that has the same/similar defintion, etc). I would suggest in both cases that one of the TZIDs could be modified. Even if the VTIMEZONEs refer to (hypothetically) some entry in a global database, then one of the entries supersedes the other, and this can be verified by examining the LAST-MODIFIED property in the VTIMEZONEs (I would suggest making this field a MUST in RFC 2445 if the TZID refers to a global database of some kind; it is currently optional). The older one in that case no longer refers to an up-to-date timezone entity, and could safely be renamed. Graham From owner-ietf-calendar@mail.imc.org Tue Apr 24 16:06:14 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14191 for ; Tue, 24 Apr 2001 16:06:13 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA14008 for ietf-calendar-bks; Tue, 24 Apr 2001 12:52:23 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14004 for ; Tue, 24 Apr 2001 12:52:21 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: REQUEST sent to non-ATTENDEE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Tue, 24 Apr 2001 15:52:50 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/24/2001 03:52:59 PM, Serialize complete at 04/24/2001 03:52:59 PM Content-Type: multipart/alternative; boundary="=_alternative 006D23F385256A38_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D23F385256A38_= Content-Type: text/plain; charset="us-ascii" Alan replied on 04/24/2001 12:46:31 PM: > John suggested that RFC2446 3.2.2.6 "Forwarding to An Uninvited CU" > showed that a REQUEST could be forwarded to a CU without them > being an ATTENDEE: > > An "Attendee" invited to an event may invite another uninvited CU to > the event. The invited "Attendee" accomplishes this by forwarding the > original "REQUEST" method to the uninvited CU. The "Organizer" > decides whether or not the uninvited CU is added to the attendee list. > > This section didn't tell us how the "Organizer" gets the information > about the uninvited CU though, does the invited "Attendee" send > a COUNTER to the "Organizer"? The RFCs fail to address this. I recall seeing 2 different assumptions about this in our sordid WG history. One assumption is that the REQUEST is forwarded as an Content-Type: message/rfc822 (that contains the Content-Type: text/calendar) to indicate that it was forwarded. Another assumption is that if the uninvited CU cannot 'find' themselves in the ATTENDEE list then they are a 'party crasher' (or possibly a group member!!). In general I thought (need to scan the archives to confirm) that 'party crashers' (aka uninvited CUs) do NOT participate in the workflow process so they do not ACCEPT, DECLINE, DELEGATE, etc to other CUs or otherwise respond back to the Organizer. I did see that in Section 3.2.3 Reply of 2446 we claimed: The "Organizer" of an event may receive the "REPLY" method from a CU not in the original "REQUEST". [Snip] In addition, the "REPLY" method may be received from an unknown CU (a "Party Crasher"). This uninvited "Attendee" may be accepted, or the "Organizer" may cancel the event for the uninvited "Attendee" by sending a "CANCEL" method to the uninvited "Attendee". This somewhat contradicts one of the assumptions above but it could have been left in by accident. Frank would have to codify this for us. I suspect that the proper behaviour for adding a new invitee would be to have the forwarding CU COUNTER with the previously uninvited CU added as a new ATTENDEE rather than just forwarding the invitation and causing the Organizer grief. I also hope that a CUA would be somewhat lenient in that a reply could be from a delegatee or from a member of a group and as such may not be in the original/current invitation. "Unknown" CUs should not just be rejected outright or automagically... I think that the text in Section 4.2.8 Forwarding an Event Request of 2446 could probably use some tightening up: Implementations are not required to add the "Party Crasher" to the "Attendee" list and hence there is no guarantee that a "Party Crasher" will receive additional updates to the Event. The forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the attendee list. The "Organizer" MAY add the forwarded "Calendar User" to the attendee list. I think that the SHOULD NOT for the forwarding CU really should be a MAY NOT or MUST NOT since they are NOT delegating it to the crasher nor are they COUNTERing to the Organizer to have the new CU added. Only the Organizer should be adding non-delegatee ATTENDEEs. Anyone else agree/disagree?? (As if I need to ask for disagreement on this list... ;^} ) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D23F385256A38_= Content-Type: text/html; charset="us-ascii"
Alan replied on 04/24/2001 12:46:31 PM:
> John suggested that RFC2446 3.2.2.6 "Forwarding to An Uninvited CU"
> showed that a REQUEST could be forwarded to a CU without them
> being an ATTENDEE:
>
>     An "Attendee" invited to an event may invite another uninvited CU to
>     the event. The invited "Attendee" accomplishes this by forwarding the
>     original "REQUEST" method to the uninvited CU. The "Organizer"
>     decides whether or not the uninvited CU is added to the attendee list.
>
> This section didn't tell us how the "Organizer" gets the information
> about the uninvited CU though, does the invited "Attendee" send
> a COUNTER to the "Organizer"?
The RFCs fail to address this.  I recall seeing 2 different assumptions about this in our sordid WG history.  One assumption is that the REQUEST is forwarded as an Content-Type: message/rfc822 (that contains the Content-Type: text/calendar) to indicate that it was forwarded.  Another assumption is that if the uninvited CU cannot 'find' themselves in the ATTENDEE list then they are a 'party crasher' (or possibly a group member!!).

In general I thought (need to scan the archives to confirm) that 'party crashers' (aka uninvited CUs) do NOT participate in the workflow process so they do not ACCEPT, DECLINE, DELEGATE, etc to other CUs or otherwise respond back to the Organizer.   I did see that in Section 3.2.3 Reply of 2446 we claimed:

   The "Organizer" of an event may receive the "REPLY" method from a CU
  not in the original "REQUEST". [Snip] In addition, the "REPLY" method may be
  received from an unknown CU (a "Party Crasher"). This uninvited
  "Attendee" may be accepted, or the "Organizer" may cancel the event
  for the uninvited "Attendee" by sending a "CANCEL" method to the
  uninvited "Attendee".

This somewhat contradicts one of the assumptions above but it could have been left in by accident.  Frank would have to codify this for us.  

I suspect that the proper behaviour for adding a new invitee would be to have the forwarding CU COUNTER with the previously uninvited CU added as a new ATTENDEE rather than just forwarding the invitation and causing the Organizer grief.  

I also hope that a CUA would be somewhat lenient in that a reply could be from a delegatee or from a member of a group and as such may not be in the original/current invitation.  "Unknown" CUs should not just be rejected outright or automagically...

I think that the text in Section 4.2.8 Forwarding an Event Request of 2446 could probably use some tightening up:

                    Implementations are not required to add the "Party
  Crasher" to the "Attendee" list and hence there is no guarantee that
  a "Party Crasher" will receive additional updates to the Event. The
  forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
  attendee list. The "Organizer" MAY add the forwarded "Calendar User"
  to the attendee list.

I think that the SHOULD NOT for the forwarding CU really should be a MAY NOT or MUST NOT since they are NOT delegating it to the crasher nor are they COUNTERing to the Organizer to have the new CU added.  Only the Organizer should be adding non-delegatee ATTENDEEs.  Anyone else agree/disagree??  (As if I need to ask for disagreement on this list... ;^} )

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006D23F385256A38_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 24 16:42:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14860 for ; Tue, 24 Apr 2001 16:42:36 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA16271 for ietf-calendar-bks; Tue, 24 Apr 2001 13:25:46 -0700 (PDT) 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 NAA16266 for ; Tue, 24 Apr 2001 13:25:45 -0700 (PDT) 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 f3OKPgg10928 for ; Tue, 24 Apr 2001 15:25:52 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 24 Apr 2001 15:24:45 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 24 Apr 2001 15:24:45 -0500 Message-ID: <30F2DED23724D311902D0008C7EABAFB03F34921@daeis06nok> To: Bruce_Kahn@iris.com, aland@steltor.com Cc: ietf-calendar@imc.org Subject: RE: REQUEST sent to non-ATTENDEE Date: Tue, 24 Apr 2001 15:24:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCFC.98B900E0" 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_01C0CCFC.98B900E0 Content-Type: text/plain; charset="iso-8859-1" Bruce: Intended "Attendee" (AKA, party crasher) sends a REPLY to the Organizer, of course. This is stated in the section you quote from RFC2446. I agree with your restatement of the RFCs that only the Organizer should be adding/deleting CUs. -- Frank ------_=_NextPart_001_01C0CCFC.98B900E0 Content-Type: text/html; charset="iso-8859-1"
Bruce:
 
Intended "Attendee" (AKA, party crasher) sends a REPLY to the Organizer, of course. This is stated in the section you quote from RFC2446.
 
I agree with your restatement of the RFCs that only the Organizer should be adding/deleting CUs.
 
-- Frank
------_=_NextPart_001_01C0CCFC.98B900E0-- From owner-ietf-calendar@mail.imc.org Tue Apr 24 16:51:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15046 for ; Tue, 24 Apr 2001 16:51:20 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA17349 for ietf-calendar-bks; Tue, 24 Apr 2001 13:39:28 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17345 for ; Tue, 24 Apr 2001 13:39:26 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Graham Gilmore" Cc: ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Tue, 24 Apr 2001 16:39:54 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/24/2001 04:40:04 PM, Serialize complete at 04/24/2001 04:40:04 PM Content-Type: multipart/alternative; boundary="=_alternative 007172DC85256A38_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007172DC85256A38_= Content-Type: text/plain; charset="us-ascii" Graham wrote on 04/24/2001 03:44:34 PM: > At first glance, I saw it this way too; but looking at Eric's > proposed model: [Snip] > However, I agree that this isn't necessarily the way to go :) Whew! I get very nervous when a proposed change impacts the overall model (and no matter how ya view it, it does propose changing the containment model and thats non-trivial.) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007172DC85256A38_= Content-Type: text/html; charset="us-ascii"
Graham wrote on 04/24/2001 03:44:34 PM:
>     At first glance, I saw it this way too; but looking at Eric's
> proposed model:
[Snip]
>     However, I agree that this isn't necessarily the way to go :)
Whew!  I get very nervous when a proposed change impacts the overall model (and no matter how ya view it, it does propose changing the containment model and thats non-trivial.)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007172DC85256A38_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 24 17:04:53 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15324 for ; Tue, 24 Apr 2001 17:04:52 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA17502 for ietf-calendar-bks; Tue, 24 Apr 2001 13:45:09 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17498 for ; Tue, 24 Apr 2001 13:45:08 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Graham Gilmore" Cc: ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Tue, 24 Apr 2001 16:45:37 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/24/2001 04:45:45 PM, Serialize complete at 04/24/2001 04:45:45 PM Content-Type: multipart/alternative; boundary="=_alternative 0071F8CB85256A38_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071F8CB85256A38_= Content-Type: text/plain; charset="us-ascii" Graham wrote: >The older one in that case no longer refers to an up-to-date >timezone entity, and could safely be renamed. Are you suggesting it be renamed to a non-standardized name and then put into the VEVENT then?? Or are you renaming the standardized TZID to something else and keeping it at the Calendar level? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0071F8CB85256A38_= Content-Type: text/html; charset="us-ascii"
Graham wrote:
>The older one in that case no longer refers to an up-to-date
>timezone entity, and could safely be renamed.

Are you suggesting it be renamed to a non-standardized name and then put into the VEVENT then??  Or are you renaming the standardized TZID to something else and keeping it at the Calendar level?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0071F8CB85256A38_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 24 17:08:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15380 for ; Tue, 24 Apr 2001 17:08:19 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA19055 for ietf-calendar-bks; Tue, 24 Apr 2001 13:53:40 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19049 for ; Tue, 24 Apr 2001 13:53:39 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Graham Gilmore" Cc: ietf-calendar@imc.org Subject: Re: Interpretation of VALARM TRIGGERs in recurring components MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Tue, 24 Apr 2001 16:54:06 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/24/2001 04:54:17 PM, Serialize complete at 04/24/2001 04:54:17 PM Content-Type: multipart/alternative; boundary="=_alternative 0072BFE385256A38_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072BFE385256A38_= Content-Type: text/plain; charset="us-ascii" Graham asked: >While the default >value type of the property is DURATION, a DATE-TIME value type can also >be specified by means of a VALUE parameter. I'm wondering what the >interpretation of this would be in the case of a VEVENT or VTODO that >has a recurrence rule: The intent and only really logical interpreation of a VALUE=DATE-TIME is that the alarm triggers only 1 time, at the specified date and time. It is non-sensical to have a TRIGGER;VALUE=DATE-TIME on a repeating entry really since they would in effect all trigger at the same instance in time. Perhaps someone will write a CUA that will play some .WAV Audio alarm 500 times for that 500 instance repeating meeting (want to drive your cubicle neighbors up a wall??) but the generally accepted intent is that its only for use on non-repeating entries. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072BFE385256A38_= Content-Type: text/html; charset="us-ascii"
Graham asked:
>While the default
>value type of the property is DURATION, a DATE-TIME value type can also
>be specified by means of a VALUE parameter.  I'm wondering what the
>interpretation of this would be in the case of a VEVENT or VTODO that
>has a recurrence rule:

The intent and only really logical interpreation of a VALUE=DATE-TIME is that the alarm triggers only 1 time, at the specified date and time.  It is non-sensical to have a TRIGGER;VALUE=DATE-TIME on a repeating entry really since they would in effect all trigger at the same instance in time.  Perhaps someone will write a CUA that will play some .WAV Audio alarm 500 times for that 500 instance repeating meeting (want to drive your cubicle neighbors up a wall??) but the generally accepted intent is that its only for use on non-repeating entries.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0072BFE385256A38_=-- From owner-ietf-calendar@mail.imc.org Tue Apr 24 17:18:32 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15515 for ; Tue, 24 Apr 2001 17:18:31 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA20583 for ietf-calendar-bks; Tue, 24 Apr 2001 14:06:03 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20578 for ; Tue, 24 Apr 2001 14:06:02 -0700 (PDT) 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 RAA23469 for ; Tue, 24 Apr 2001 17:05:34 -0400 Received: from pc152 (PC-152 [101.1.46.9]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JDT9GCW6; Tue, 24 Apr 2001 17:03:36 -0400 Message-ID: <0c3f01c0cd02$28a05a00$092e0165@cst.ca> From: "Graham Gilmore" To: References: Subject: Re: Where to put VTIMEZONE and VALARM? Date: Tue, 24 Apr 2001 17:04:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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: To: "Graham Gilmore" Cc: Sent: 24 April, 2001 16:45 Subject: Re: Where to put VTIMEZONE and VALARM? > > Graham wrote: > >The older one in that case no longer refers to an up-to-date > >timezone entity, and could safely be renamed. > > Are you suggesting it be renamed to a non-standardized name and then put > into the VEVENT then?? Or are you renaming the standardized TZID to > something else and keeping it at the Calendar level? > > Bruce I am suggesting renaming the older one(s) to a non-standardized name(s), and keeping both (all) of the VTIMEZONEs at the VCALENDAR level. Graham From owner-ietf-calendar@mail.imc.org Tue Apr 24 17:57:27 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16234 for ; Tue, 24 Apr 2001 17:57:26 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA24075 for ietf-calendar-bks; Tue, 24 Apr 2001 14:44:41 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA24061 for ; Tue, 24 Apr 2001 14:44:40 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Graham Gilmore" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Where to put VTIMEZONE and VALARM? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Tue, 24 Apr 2001 17:45:14 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/24/2001 05:45:18 PM, Serialize complete at 04/24/2001 05:45:18 PM Content-Type: multipart/alternative; boundary="=_alternative 00776C0285256A38_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00776C0285256A38_= Content-Type: text/plain; charset="us-ascii" Graham wrote on 04/24/2001 05:04:32 PM: > I am suggesting renaming the older one(s) to a non-standardized > name(s), and keeping both (all) of the VTIMEZONEs at the VCALENDAR > level. That would work for me. Anyone want to code up the matching of the original TZIDs from the Organzier on later updates/invites w/the changed one?? Id love to hear from Damon or Eric about how they approached this since one of them raised it recently... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00776C0285256A38_= Content-Type: text/html; charset="us-ascii"
Graham wrote on 04/24/2001 05:04:32 PM:
>     I am suggesting renaming the older one(s) to a non-standardized
> name(s), and keeping both (all) of the VTIMEZONEs at the VCALENDAR
> level.
That would work for me.  

Anyone want to code up the matching of the original TZIDs from the Organzier on later updates/invites w/the changed one??  Id love to hear from Damon or Eric about how they approached this since one of them raised it recently...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00776C0285256A38_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 25 15:13:08 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27505 for ; Wed, 25 Apr 2001 15:13:07 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA13200 for ietf-calendar-bks; Wed, 25 Apr 2001 11:38:28 -0700 (PDT) Received: from agony.busboom.org (dt011n61.san.rr.com [204.210.13.97]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA13196 for ; Wed, 25 Apr 2001 11:38:27 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f3PIbr818161; Wed, 25 Apr 2001 11:37:53 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Wed, 25 Apr 2001 11:37:53 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Bruce_Kahn@iris.com cc: ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? 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, 24 Apr 2001 Bruce_Kahn@iris.com wrote: > Graham wrote on 04/24/2001 05:04:32 PM: > > I am suggesting renaming the older one(s) to a non-standardized > > name(s), and keeping both (all) of the VTIMEZONEs at the VCALENDAR > > level. > > That would work for me. I really don't like the idea of requiring the receiver to rename the TZIDs. It is just mandating a hack, and the problem should be solved rather than hacked. > Anyone want to code up the matching of the original TZIDs from the > Organzier on later updates/invites w/the changed one?? Given that there are no requirements for the time span that a VTIMEZONE covers -- outside of covering the event it relates to -- I don't think trying to match incoming VTIMEZONES with existing ones is a good idea either. A CUA could send out any number of VTIMEZONEs with different time spans, and the receiver would have to be smart enough to correlate these, or risk having a potential enormous tmezone database. Besides, I think that is an abuse of the RRULEs. If we need a way to match up two timezone definitions, let's make it explicit, rather than hoping that the sender doesn't play odd games when constructing timezone definitions. How about having the sender do the re-write rather than the client? That is, the sender would use a TZID that is unique to the sender, basically attaching a UID to every TZID that it uses? The sender should guarantee that every TZID name that it sends out is associated with only one timezone definition, and that that name is unique to it. I imagine that this would result in TZIDs that are correlated to: A Timezone A Vendor A Product A version of the timezone So, suppose, for instance, that a TZNAME was: //Gnome/Evolution/1/America/Los_Angeles The recipient can be assured that whenever it gets this name, the name applies to a single version of a particular timezone, as it is defined by the sender. If the sender makes any changes to the definition, it should use a new TZNAME. Of course, there should be some signal to indicate that these names are special -- perhaps the "//" as above? This would also allow groups of vendors to create timezone databases on their own. For instance the first version of the translation of the Olsen database could use: //Olsen/1/America/Los_Angeles To refer to version 1 of America/Los_Angeles in the Olsen database. A CUA that also used this version of the Olsen database would not have to store the VTIMEZONE of other products that used the same datbase. If a CUA had version 1 of America/Los_Angeles and got version 2, then it would just store it. If a CUA did get a conflict, it may resort to renaming, but in general that would not be required. This would solve most of the problems that we have been discussing, such as how to create a global registry and how to avoid conflicts with TZIDs, without changing the storage model or requiring the recipient to muck with the TZIDs. eric. From owner-ietf-calendar@mail.imc.org Wed Apr 25 16:02:01 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29350 for ; Wed, 25 Apr 2001 16:02:00 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA14355 for ietf-calendar-bks; Wed, 25 Apr 2001 12:36:12 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14351 for ; Wed, 25 Apr 2001 12:36:11 -0700 (PDT) From: Bruce_Kahn@iris.com To: Jonathan Lennox Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Changes to RECUR MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Wed, 25 Apr 2001 15:36:44 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/25/2001 03:41:22 PM, Serialize complete at 04/25/2001 03:41:22 PM Content-Type: multipart/alternative; boundary="=_alternative 006BA31785256A39_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006BA31785256A39_= Content-Type: text/plain; charset="us-ascii" Jonathan suggested: >Also note that self-contradictory rules are still possible with your >restrictions, and I don't think they can in general be eliminated. Consider >the obvious >RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=31 From 2445, Section 4.3.10 Recurrence Rule, p44 precludes the obvious cases but does not 'invalidate' the entire rule: If BYxxx rule part values are found which are beyond the available scope (ie, BYMONTHDAY=30 in February), they are simply ignored. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006BA31785256A39_= Content-Type: text/html; charset="us-ascii"
Jonathan suggested:

>Also note that self-contradictory rules are still possible with your
>restrictions, and I don't think they can in general be eliminated.  Consider
>the obvious
>RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=31

From 2445, Section 4.3.10 Recurrence Rule, p44 precludes the obvious cases but does not 'invalidate' the entire rule:

   If BYxxx rule part values are found which are beyond the available
  scope (ie, BYMONTHDAY=30 in February), they are simply ignored.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006BA31785256A39_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 25 16:02:37 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29363 for ; Wed, 25 Apr 2001 16:02:36 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA14305 for ietf-calendar-bks; Wed, 25 Apr 2001 12:32:28 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14301 for ; Wed, 25 Apr 2001 12:32:26 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Are date ranges half-open? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Wed, 25 Apr 2001 15:32:58 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/25/2001 03:37:37 PM, Serialize complete at 04/25/2001 03:37:37 PM Content-Type: multipart/alternative; boundary="=_alternative 006B4AED85256A39_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B4AED85256A39_= Content-Type: text/plain; charset="us-ascii" Eric asked: >I've always though of the span of time of an event as a half-open >interval. That is, the event includes the start time but does not include >the end time -- it ends some infintesimal moment before. I think we all agree it is... >In fact, I don't think the spec has anything to say about time >spans either. Perhaps we should include some text the defines the end date >or time to not be part of the interval? From 2445, Section 4.6.1 Event Component, p 53 says: The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE data type but no "DTEND" property, the events non-inclusive end is the end of the calendar date specified by the "DTSTART" property. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME data type but no "DTEND" property, the event ends on the same calendar date and time of day specified by the "DTSTART" property. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B4AED85256A39_= Content-Type: text/html; charset="us-ascii"
Eric asked:
>I've always though of the span of time of an event as a half-open
>interval. That is, the event includes the start time but does not include
>the end time -- it ends some infintesimal moment before.

I think we all agree it is...

>In fact, I don't think the spec has anything to say about time
>spans either. Perhaps we should include some text the defines the end date
>or time to not be part of the interval?

From 2445, Section 4.6.1 Event Component, p 53 says:

   The "DTSTART" property for a "VEVENT" specifies the inclusive start
  of the event. For recurring events, it also specifies the very first
  instance in the recurrence set. The "DTEND" property for a "VEVENT"
  calendar component specifies the non-inclusive end of the event. For
  cases where a "VEVENT" calendar component specifies a "DTSTART"
  property with a DATE data type but no "DTEND" property, the events
  non-inclusive end is the end of the calendar date specified by the
  "DTSTART" property. For cases where a "VEVENT" calendar component
  specifies a "DTSTART" property with a DATE-TIME data type but no
  "DTEND" property, the event ends on the same calendar date and time
  of day specified by the "DTSTART" property.
Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006B4AED85256A39_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 25 16:24:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00016 for ; Wed, 25 Apr 2001 16:24:20 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA14996 for ietf-calendar-bks; Wed, 25 Apr 2001 12:54:39 -0700 (PDT) Received: from agony.busboom.org (dt011n61.san.rr.com [204.210.13.97]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14992 for ; Wed, 25 Apr 2001 12:54:37 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f3PJsTB18336; Wed, 25 Apr 2001 12:54:29 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Wed, 25 Apr 2001 12:54:28 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Bruce_Kahn@iris.com cc: ietf-calendar@imc.org Subject: Re: Recap: Does 1 day == 24 hours? 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 Mon, 23 Apr 2001 Bruce_Kahn@iris.com wrote: > I would suggest that the restrictions on DURATION 'scale' be: > Duration MUST be of VALUE=DATE if DTSTART is of VALUE=DATE. This does > preclude a DURATION:1DT8H case but its an acceptable limitation to me. It's not really a limitation, since if your times are in the date scale then the end time should be disregarded -- you couldn't do anything with the 8H anyway. And, in this case, 1D, really means "until the end of the day specified in DTSTART" -- essentiall my option (2). > Duration MAY be of VALUE=DATE or VALUE=DATE-TIME if DTSTART is of > VALUE=DATE-TIME And, in this case, we are really in the time scale, so 1D means "same time tomorrow" > Date units are NOT convertable to Time units. The time value for the > calculated or effective DTEND is inherited from the DTSTART when no > dur-time values are specified OK. > When time units are specified (in addition to date units) then they are > based on the time inherited from the DTSTART property. As usual. ( BTW, RFC2445 does not permit a VALUE parameter for DURATION, so I will suppose that VALUE=DATE implies that the DURATION value has no H, M or S ) So, perhaps what we really have is: option (2) -- 1D means "until the end of today" -- when the DURATION is in the date scale option (3) -- 1D means "same time tomorrow" when the DURATION is in the time scale with the scale coming from the value type of DTSTART. Here is some proposed text, to be added to the section for the DURATION property: -------------------------------------------------------------------------- For the purpose of calculating an end time based on a start time and a duration. The dur-week ("W") and dur-day ("D") parts of DURATION can vary their meaning depending on wether the DTSTART is a value of DATE or DATE-TIME. If the DTSTART value time is a DATE-TIME, a day (dur-day) MUST be interpreted as the period spanning between the same times on sucessive days, not as a period of 24 hours. So, An event of DURATION:P1D that starts at 10:00 will end the following day at 10:00, regardless of any intervening shifts between Standard Time and Daylight Savings Time. Similarly, if the value of DTSTART is DATE-TIME, a week ( dur-week) MUST be interpreted as a period of seven days (DURATION:7D) , not as 168 hours. If the value of DTSTART is DATE, then dur-week and dur-day are interpreted on an integer day scale. Because DATE values time work off of the start and end of days, there is no consideration for daylight savings time shifts. Thus, these two specifications for a time period are always identical: DTSTART;VALUE=DATE:19971103 DURATION:P1D and: DTSTART;VALUE=DATE:19971103 DTEND:19971104 If the DTSTART of an event has a value of DATE, then the DURATION MUST NOT include dur-hour, dur-minute or dur-second parts. --------------------------------------------------------------------------- eric. From owner-ietf-calendar@mail.imc.org Wed Apr 25 16:51:26 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00779 for ; Wed, 25 Apr 2001 16:51:26 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA15333 for ietf-calendar-bks; Wed, 25 Apr 2001 13:18:59 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA15329 for ; Wed, 25 Apr 2001 13:18:58 -0700 (PDT) From: Bruce_Kahn@iris.com To: Jonathan Lennox Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Changes to RECUR MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Wed, 25 Apr 2001 16:19:31 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/25/2001 04:24:09 PM, Serialize complete at 04/25/2001 04:24:09 PM Content-Type: multipart/alternative; boundary="=_alternative 006F8DA885256A39_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F8DA885256A39_= Content-Type: text/plain; charset="us-ascii" Jonathan suggested: >It's not clear to me that that's really necessary. A self-contradictory >rule isn't *ambiguous* -- it's clear that it means "no recurrence at all, >except for the DTSTART." The attempt to make a very flexible and powerful recurrence grammar created cases that are sometimes workable and sometimes not. This is part of an ongoing attempt by implementors to codify what cases are allowed and which are not. By codifying allowed and disallowed cases and the proper actions we reduce the margin of error that various CUAs may have to deal with. My quick head calcs show that we can generate LOTS of combinations that are just illogical and that just makes my coding job that much harder. Eric is attempting to simplify and codify the boundaries for the grammar parts and its not just an exercise in keeping the revision editor busy. >or the somewhat less obvious >DTSTART;TZID=America/New_York:20010329T0230 >DURATION:T20M >RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU Ugh, my split mucked me up again, sorry... That case is not bad either. Its a case where the 1st instance of the repeat set is NOT the same as the following instances. That is, the 1st instance is 29-Mar-2001 @ 02:30:00 and lasts for 20 minutes. The next (and all subsequent instances are on 01-Apr at the same time and for the same duration (ie: 01-Apr-2001, 02-Apr-2002, etc). >(This is the reason I dropped bysetpos from CPL...) That means you will have a ver hard time supporting Outlook users. They use BYSETPOS to convey simple stuff like "The 4th Thrusday every month"... Bruce PS: Thats duration should have been "PT20M" I think... =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F8DA885256A39_= Content-Type: text/html; charset="us-ascii"
Jonathan suggested:
>It's not clear to me that that's really necessary.  A self-contradictory
>rule isn't *ambiguous* -- it's clear that it means "no recurrence at all,
>except for the DTSTART."  

The attempt to make a very flexible and powerful recurrence grammar created cases that are sometimes workable and sometimes not.  This is part of an ongoing attempt by implementors to codify what cases are allowed and which are not.  By codifying allowed and disallowed cases and the proper actions we reduce the margin of error that various CUAs may have to deal with.  My quick head calcs show that we can generate LOTS of combinations that are just illogical and that just makes my coding job that much harder.

Eric is attempting to simplify and codify the boundaries for the grammar parts and its not just an exercise in keeping the revision editor busy.

>or the somewhat less obvious
>DTSTART;TZID=America/New_York:20010329T0230
>DURATION:T20M
>RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU

Ugh, my split mucked me up again, sorry...

That case is not bad either.  Its a case where the 1st instance of the repeat set is NOT the same as the following instances.  That is, the 1st instance is 29-Mar-2001 @ 02:30:00 and lasts for 20 minutes.  The next (and all subsequent instances are on 01-Apr at the same time and for the same duration (ie: 01-Apr-2001, 02-Apr-2002, etc).  

>(This is the reason I dropped bysetpos from CPL...)

That means you will have a ver hard time supporting Outlook users.  They use BYSETPOS to convey simple stuff like "The 4th Thrusday every month"...

Bruce
PS: Thats duration should have been "PT20M" I think...
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006F8DA885256A39_=-- From owner-ietf-calendar@mail.imc.org Wed Apr 25 17:47:11 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02202 for ; Wed, 25 Apr 2001 17:47:10 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA16131 for ietf-calendar-bks; Wed, 25 Apr 2001 14:07:40 -0700 (PDT) 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 OAA16127 for ; Wed, 25 Apr 2001 14:07:38 -0700 (PDT) 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 RAA04277; Wed, 25 Apr 2001 17:07:39 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id RAA38907; Wed, 25 Apr 2001 17:07:39 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15079.15514.995726.950492@conrail.cs.columbia.edu> Date: Wed, 25 Apr 2001 17:07:38 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Changes to RECUR In-Reply-To: References: 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 Wednesday, April 25 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: > Jonathan suggested: > >It's not clear to me that that's really necessary. A self-contradictory > >rule isn't *ambiguous* -- it's clear that it means "no recurrence at all, > >except for the DTSTART." > > The attempt to make a very flexible and powerful recurrence grammar > created cases that are sometimes workable and sometimes not. This is part > of an ongoing attempt by implementors to codify what cases are allowed and > which are not. By codifying allowed and disallowed cases and the proper > actions we reduce the margin of error that various CUAs may have to deal > with. My quick head calcs show that we can generate LOTS of combinations > that are just illogical and that just makes my coding job that much > harder. > > Eric is attempting to simplify and codify the boundaries for the grammar > parts and its not just an exercise in keeping the revision editor busy. Well, it depends on how your code works. If you have to have separate code for each of the 2^N combinations of rules, eliminating combinations makes things simpler. If you have independent code for each of the N orthogonal rule restrictions (as I believe is possible -- I did it for the CPL subset), forbidding combinations makes things more *complicated*. And forbidding combinations doesn't make the grammar (if by that you mean syntactic-level rules) any simpler. > >or the somewhat less obvious > >DTSTART;TZID=America/New_York:20010329T0230 > >DURATION:T20M > >RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU > > Ugh, my split mucked me up again, sorry... > > That case is not bad either. Its a case where the 1st instance of the > repeat set is NOT the same as the following instances. That is, the 1st > instance is 29-Mar-2001 @ 02:30:00 and lasts for 20 minutes. The next > (and all subsequent instances are on 01-Apr at the same time and for the > same duration (ie: 01-Apr-2001, 02-Apr-2002, etc). Yes, there's one initial occurence on March 29. After that, though, I contend that there are no subsequent recurences, because in America/New_York (under current DST rules) 2:30 - 2:50 AM doesn't occur on the first Sunday in April. (Clocks jump from 1:59:59 AM EST to 3:00:00 AM EDT.) If you disagree, what time and duration do you think the subsequent recurrences should have? > >(This is the reason I dropped bysetpos from CPL...) > > That means you will have a ver hard time supporting Outlook users. They > use BYSETPOS to convey simple stuff like "The 4th Thrusday every month"... They use BYSETPOS rather than BYDAY=4TH? That's odd. Are you sure? > Bruce > PS: Thats duration should have been "PT20M" I think... Yes, you're right. I assume the "P" is a ISO compatibility thing? It seems gratuitous otherwise. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Apr 25 17:47:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02213 for ; Wed, 25 Apr 2001 17:47:19 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA16266 for ietf-calendar-bks; Wed, 25 Apr 2001 14:14:27 -0700 (PDT) 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 OAA16262 for ; Wed, 25 Apr 2001 14:14:25 -0700 (PDT) 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 RAA04770; Wed, 25 Apr 2001 17:14:26 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id RAA38913; Wed, 25 Apr 2001 17:14:26 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15079.15921.368365.304372@conrail.cs.columbia.edu> Date: Wed, 25 Apr 2001 17:14:25 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Changes to RECUR In-Reply-To: References: 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 Wednesday, April 25 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: > Jonathan suggested: > > >Also note that self-contradictory rules are still possible with your > >restrictions, and I don't think they can in general be eliminated. > Consider > >the obvious > >RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=31 > > >From 2445, Section 4.3.10 Recurrence Rule, p44 precludes the obvious cases but does not 'invalidate' the entire > rule: > > If BYxxx rule part values are found which are beyond the available > scope (ie, BYMONTHDAY=30 in February), they are simply ignored. Should this be read to mean "treat it as though there were no RRULE present", or "treat it as though it were RRULE:FREQ=YEARLY;BYMONTH=2"? If the latter, what's the definition of "Available scope"? For instance, does this mean that DTSTART:20000220T0900 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=2;BYDAY=29 means "February 20, 2000, plus February 29, every leap year" but DTSTART:20010220T0900 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=2;BYDAY=29 means "February 20, 2001, plus Feburary 20, every year which which is 1 mod 4" since Feburary 29 is outside of the "available scope" in this case? I would certainly find this to be terribly surprising. A much simpler interpretation would that "February 29, in a year which is 1 mod 4, never occurs. Therefore, the recurrence has no subsequent occurences." By the same token, for a rule with "BYMONTH=2;BYMONTHDAY=30" I would say that "Feburary 30 never occurs. Therefore, thus recurrence has no subsequent occurences." -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Apr 25 18:36:51 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03051 for ; Wed, 25 Apr 2001 18:36:50 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA17554 for ietf-calendar-bks; Wed, 25 Apr 2001 15:04:59 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA17550 for ; Wed, 25 Apr 2001 15:04:58 -0700 (PDT) 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 SAA10787 for ; Wed, 25 Apr 2001 18:04:31 -0400 Received: from pc152 (PC-152 [101.1.46.9]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JDT9GH5N; Wed, 25 Apr 2001 18:02:32 -0400 Message-ID: <0cc001c0cdd3$8dfaeec0$092e0165@cst.ca> From: "Graham Gilmore" To: References: <15079.15921.368365.304372@conrail.cs.columbia.edu> Subject: Re: Changes to RECUR Date: Wed, 25 Apr 2001 18:03:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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: "Jonathan Lennox" To: Cc: "Eric Busboom" ; Sent: 25 April, 2001 17:14 Subject: Re: Changes to RECUR > On Wednesday, April 25 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: > > > Jonathan suggested: > > > > >Also note that self-contradictory rules are still possible with your > > >restrictions, and I don't think they can in general be eliminated. > > Consider > > >the obvious > > >RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=31 > > > > >From 2445, Section 4.3.10 Recurrence Rule, p44 precludes the obvious cases but does not 'invalidate' the entire > > rule: > > > > If BYxxx rule part values are found which are beyond the available > > scope (ie, BYMONTHDAY=30 in February), they are simply ignored. > > Should this be read to mean "treat it as though there were no RRULE > present", or "treat it as though it were RRULE:FREQ=YEARLY;BYMONTH=2"? I think it should be read to mean, "ignore any individual recurrences that are non-existant dates/times". For example: DTSTART:20010220T0900 RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=28,29 The 29th of February is not always a valid date, but it still makes sense to include those dates that are valid. I would read this example as "February 20, 2001, February 28th every year, and February 29th every leap year." If the recurrence rule generates NO valid dates, as in your example: > DTSTART:20010220T0900 > RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=2;BYDAY=29 Then yes, it would be equivalent to "treat it as though there were no RRULE present", because all generated recurrences are ignored. But we need not reject the entire rule outright, otherwise you'd have to reject something like this example (paraphrased from your other mesage), simply because on 1 day of the year it happens not to exist: DTSTART;TZID=America/New_York:20010329T0230 DURATION:T20M RRULE:FREQ=DAILY;UNTIL=20020328T0730Z Graham From owner-ietf-calendar@mail.imc.org Wed Apr 25 18:37:10 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03070 for ; Wed, 25 Apr 2001 18:37:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA17426 for ietf-calendar-bks; Wed, 25 Apr 2001 14:58:53 -0700 (PDT) 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 OAA17421 for ; Wed, 25 Apr 2001 14:58:52 -0700 (PDT) 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 RAA08329; Wed, 25 Apr 2001 17:58:53 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id RAA38970; Wed, 25 Apr 2001 17:58:52 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15079.18587.828348.238281@conrail.cs.columbia.edu> Date: Wed, 25 Apr 2001 17:58:51 -0400 (EDT) To: ietf-calendar@imc.org Cc: jdrosen@dynamicsoft.com, hgs@cs.columbia.edu Subject: RECUR Subset and IPTel's CPL: Need Resolution 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 The IPTel group's Call Processing Language specification is currently stalled on the question of its specification of recurrence subsets. This issue was raised here in the CalSch group, but consensus was never reached. To review: A fundamental requirement of the IPTel's CPL work is that it be possible to process scripts in constant time. (Technically, linear time in the textual length of the script, and constant time in the values of all the script's parameters.) This allows user-created scripts to be placed on high-volume call servers, without providers having to worry about malicious or mis-designed scripts overloading the server. CPL adopts RFC 2445's method of describing recurrences, with minor syntactic transformations, to define recurring intervals in which a person might want specialized call handling. However, the full RFC 2445 RECUR syntax does not satisfy the fundamental requirement I stated above. Thus, for CPL I removed several features, which I considered to be of only relatively specialized applicability, from recurrences, and showed (with running code) that the rest of the features could be implemented in constant time. However, there were significant objections from the IESG and the CalSch community that this subset was not actually compatible with all of RFC 2445. As I mentioned, this was discussed at the Minnesota IETF and on the mailing list, but no consensus was ever reached. One significant point was raised, though, that the computational complexity of RECUR can be a significant issue for calendaring applications as well, for example for a centralized calendaring server for a large organization; and that RECUR is sufficiently complicated that it presents significant interoperability problems for RFC 2445 implementations. As I see it, therefore, there are several ways we could proceed: 1. Somehow demonstrate that the full RFC 2445 recurrences actually do satisfy the requirement I listed above after all. I don't believe this is possible. 2. Re-define RECUR in a successor to RFC 2445, eliminating the computationally-intensive parts. Since there is currently some effort to limit RECUR in some other ways to be more tractable, this may be feasible. However, this clearly isn't going to happen quickly. 3. Issue a document describing the recurrence subset, along with advice describing ways to transform full RFC2445 recurrences into the subset with minimal information loss. 4. Do (3) short term, with the intention of doing (2) and folding it into a future rfc2445bis long-term. 5. Allow CPL to go its own way, and eliminate its text claiming iCalendar compatibility. I personally would prefer option (4), unless (2) is going to happen a lot more quickly that it would currently appear. However, failing this, I'm afraid that it might be necessary to go with (5). What is the feeling of the working group on this issue? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Thu Apr 26 00:45:55 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10081 for ; Thu, 26 Apr 2001 00:45:55 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id VAA24372 for ietf-calendar-bks; Wed, 25 Apr 2001 21:30:04 -0700 (PDT) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA24362 for ; Wed, 25 Apr 2001 21:30:02 -0700 (PDT) From: pregen@egenconsulting.com To: Jonathan Lennox Cc: hgs@cs.columbia.edu, ietf-calendar@imc.org, jdrosen@dynamicsoft.com, owner-ietf-calendar@mail.imc.org Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 26 Apr 2001 00:29:53 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 04/26/2001 12:29:54 AM, Serialize complete at 04/26/2001 12:29:54 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0018F58485256A3A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0018F58485256A3A_= Content-Type: text/plain; charset="us-ascii" Not being in Minnesota, I can not be sure of all that was discussed. However, I really am reluctant to see us "step back" a draft in order to make it fit a smaller model such as telephony. I don't believe that is the best thing to do here. There are already vendors implementing or attempting to implement iCalendar and making what appears to be such a big change could potentially throw a monkey wrench in a process that is finally starting to move - i.e. interoperability. Those of you on the list need to speak up on this comment about reducing the complexity of recurrence rules. If anything happens it needs to be a new RFC. There will always be new technology that comes along after a draft has been produced. What happens in those situations? They don't rewrite the draft - they build new drafts that add on to or enhance the draft. I don't think they step the drafts backwards. I may be wrong - some one step up and throw rocks at me if I'm reading this incorrectly. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0018F58485256A3A_= Content-Type: text/html; charset="us-ascii"
Not being in Minnesota, I can not be sure of all that was discussed.  However, I really am reluctant to see us "step back" a draft in order to make it fit a smaller model such as telephony.  I don't believe that is the best thing to do here.  There are already vendors implementing or attempting to implement iCalendar and making what appears to be such a big change could potentially throw a monkey wrench in a process that is finally starting to move - i.e. interoperability.  Those of you on the list need to speak up on this comment about reducing the complexity of recurrence rules.  If anything happens it needs to be a new RFC.  There will always be new technology that comes along after a draft has been produced.  What happens in those situations?  They don't rewrite the draft - they build new drafts that add on to or enhance the draft. I don't think they step the drafts backwards.  I may ! be wrong - some one step up and throw rocks at me if I'm reading this incorrectly.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0018F58485256A3A_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 26 09:06:15 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02217 for ; Thu, 26 Apr 2001 09:06:14 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA07284 for ietf-calendar-bks; Thu, 26 Apr 2001 05:42:40 -0700 (PDT) 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 FAA07279 for ; Thu, 26 Apr 2001 05:42:39 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA09993; Thu, 26 Apr 2001 08:42:39 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id IAA17968; Thu, 26 Apr 2001 08:42:39 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15080.6078.294979.729466@grandcentral.cs.columbia.edu> Date: Thu, 26 Apr 2001 08:42:37 -0400 (EDT) To: "Graham Gilmore" Cc: Subject: Re: Changes to RECUR In-Reply-To: <0cc001c0cdd3$8dfaeec0$092e0165@cst.ca> References: <15079.15921.368365.304372@conrail.cs.columbia.edu> <0cc001c0cdd3$8dfaeec0$092e0165@cst.ca> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, April 25 2001, "Graham Gilmore" wrote to "" saying: > > > From 2445, Section 4.3.10 Recurrence Rule, p44 precludes the > > > obvious cases but does not 'invalidate' the entire rule: > > > > > > If BYxxx rule part values are found which are beyond the available > > > scope (ie, BYMONTHDAY=30 in February), they are simply ignored. > > > > Should this be read to mean "treat it as though there were no RRULE > > present", or "treat it as though it were RRULE:FREQ=YEARLY;BYMONTH=2"? > > I think it should be read to mean, "ignore any individual > recurrences that are non-existant dates/times". [Examples elided] Yes, that's the interpretation I'd favor as well; I think it's by far the least surprising result, and the simplest to implement. However, it sounded like some people on this list didn't interpret that sentence this way. And a close reading of the sentence from RFC2445 quoted above would have the referent of "they" being "BYxxx rule part values", not "recurrences". Is there consensus that this is a wording flaw in RFC 2445, and the spec should be changed to make Graham's interpretation explicit? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Thu Apr 26 11:50:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09183 for ; Thu, 26 Apr 2001 11:50:49 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA20321 for ietf-calendar-bks; Thu, 26 Apr 2001 08:28:25 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA20313 for ; Thu, 26 Apr 2001 08:28:23 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA18741; Thu, 26 Apr 2001 11:27:54 -0400 Received: from c-1244.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3QFRsP12838; Thu, 26 Apr 2001 11:27:54 -0400 (EDT) Message-Id: <5.0.0.25.0.20010426105519.02f0b3e0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 26 Apr 2001 11:26:18 -0400 To: Jonathan Lennox , Bruce_Kahn@iris.com From: Alan Davies Subject: Re: Changes to RECUR Cc: Eric Busboom , ietf-calendar@imc.org In-Reply-To: <15079.15514.995726.950492@conrail.cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 17:07 2001-04-25 -0400, Jonathan Lennox wrote: > > >(This is the reason I dropped bysetpos from CPL...) > > > > That means you will have a ver hard time supporting Outlook users. They > > use BYSETPOS to convey simple stuff like "The 4th Thrusday every month"... > >They use BYSETPOS rather than BYDAY=4TH? That's odd. Are you sure? They do use BYSETPOS, but leaving it in the spec doesn't really help Outlook compatibility; This is the RRULE Outlook 2000 just generated for me, when I specified "The Fourth Thursday of every 1 Month(s), repeating forever" in it's 'Appointment Recurrence' Dialog: RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=TH;BYSETPOS=4;WKST=SU The BYDAY=TH;BYSETPOS=4; should surely be BYDAY=4TH; as you said (so that we take the fourth Thursday of _every_ month, not just the fourth occurrence from the set generated by the rest of the rule). This rule clearly generates just one recurrence. There doesn't seem to be a way in the Outlook UI to generate an RRULE that would use BYSETPOS correctly. Hmmmm. Does anyone actually use BYSETPOS as defined by RFC2445? --Alan From owner-ietf-calendar@mail.imc.org Thu Apr 26 12:15:12 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10333 for ; Thu, 26 Apr 2001 12:15:11 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA25879 for ietf-calendar-bks; Thu, 26 Apr 2001 08:53:58 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA25863 for ; Thu, 26 Apr 2001 08:53:53 -0700 (PDT) From: Bruce_Kahn@iris.com MIME-Version: 1.0 To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Recap: Does 1 day == 24 hours? X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Thu, 26 Apr 2001 11:54:23 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/26/2001 11:54:35 AM, Serialize complete at 04/26/2001 11:54:35 AM Content-Type: multipart/alternative; boundary="=_alternative 0057435B85256A3A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057435B85256A3A_= Content-Type: text/plain; charset="us-ascii" eric wrote on 04/25/2001 03:54:28 PM: > > Duration MUST be of VALUE=DATE if DTSTART is of VALUE=DATE. This does > > preclude a DURATION:1DT8H case but its an acceptable limitation to me. > > It's not really a limitation, since if your times are in the date scale > then the end time should be disregarded -- you couldn't do anything with > the 8H anyway. Sure you can. Well, I didnt scan the RFCs for the exact text (too many scans frying my brain) but if I have a DTSTART;VALUE=DATE:20010427 then there is an implicit start time of 00:00:00 local time so a duration of 8H is fine. It would begin at midnight local time and end at 8AM local time... > And, in this case, 1D, really means "until the end of the day specified in > DTSTART" -- essentiall my option (2). If you want that behaviour then reread 2445 where it talks about DTSTART;VALUE=DATE and no DTEND where it says that its implied 23:59:59 local time... No need for a DURATION:P1D. > ( BTW, RFC2445 does not permit a VALUE parameter for DURATION, so I will > suppose that VALUE=DATE implies that the DURATION value has no H, M or S ) Thats because its encoded in the value of sorts in the dur-value data type. It can contain both. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0057435B85256A3A_= Content-Type: text/html; charset="us-ascii"
eric wrote on 04/25/2001 03:54:28 PM:

> > Duration MUST be of VALUE=DATE if DTSTART is of VALUE=DATE.  This does
> > preclude a DURATION:1DT8H case but its an acceptable limitation to me.
>
> It's not really a limitation, since if your times are in the date scale
> then the end time should be disregarded -- you couldn't do anything with
> the 8H anyway.

Sure you can.  Well, I didnt scan the RFCs for the exact text (too many scans frying my brain) but if I have a DTSTART;VALUE=DATE:20010427 then there is an implicit start time of 00:00:00 local time so a duration of 8H is fine.  It would begin at midnight local time and end at 8AM local time...

> And, in this case, 1D, really means "until the end of the day specified in
> DTSTART" -- essentiall my option (2).
If you want that behaviour then reread 2445 where it talks about DTSTART;VALUE=DATE and no DTEND where it says that its implied 23:59:59 local time...    No need for a DURATION:P1D.

> ( BTW, RFC2445 does not permit a VALUE parameter for DURATION, so I will
> suppose that VALUE=DATE implies that the DURATION value has no H, M or S )

Thats because its encoded in the value of sorts in the dur-value data type.  It can contain both.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0057435B85256A3A_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 26 13:28:52 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13379 for ; Thu, 26 Apr 2001 13:28:51 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA01507 for ietf-calendar-bks; Thu, 26 Apr 2001 10:15:00 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA01496 for ; Thu, 26 Apr 2001 10:14:56 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id NAA21355 for ; Thu, 26 Apr 2001 13:14:28 -0400 Received: from c-1244.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3QHERP22387 for ; Thu, 26 Apr 2001 13:14:28 -0400 (EDT) Message-Id: <5.0.0.25.0.20010426125918.02fa28c0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 26 Apr 2001 13:12:52 -0400 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: Changes to RECUR In-Reply-To: <5.0.0.25.0.20010426105519.02f0b3e0@imap1.in.steltor.com> References: <15079.15514.995726.950492@conrail.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It's been pointed out to me that I'd misinterpreted the meaning of BYSETPOS- the wording in 2445 doesn't seem to specify which 'set' BYSETPOS refers to, but the example given implies it must be the period of FREQ * INTERVAL, rather than the entire set generated by the rest of the rule: RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 This example shows that BYSETPOS does indeed have some value, as there would be no way to represent this other than with RDATEs. So, my penultimate paragraph should have read: Outlook only uses BYSETPOS in cases where an ordinal value could have been used instead (e.g. BYDAY=4TH, etc.). --Alan At 11:26 2001-04-26 -0400, Alan Davies wrote: >At 17:07 2001-04-25 -0400, Jonathan Lennox wrote: >> > >(This is the reason I dropped bysetpos from CPL...) >> > >> > That means you will have a ver hard time supporting Outlook users. They >> > use BYSETPOS to convey simple stuff like "The 4th Thrusday every month"... >> >>They use BYSETPOS rather than BYDAY=4TH? That's odd. Are you sure? > >They do use BYSETPOS, but leaving it in the spec doesn't really help >Outlook compatibility; This is the RRULE Outlook 2000 just generated >for me, when I specified "The Fourth Thursday of every 1 Month(s), >repeating forever" in it's 'Appointment Recurrence' Dialog: > >RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=TH;BYSETPOS=4;WKST=SU > >The BYDAY=TH;BYSETPOS=4; should surely be BYDAY=4TH; as you said >(so that we take the fourth Thursday of _every_ month, not just >the fourth occurrence from the set generated by the rest of the rule). >This rule clearly generates just one recurrence. > >There doesn't seem to be a way in the Outlook UI to generate an >RRULE that would use BYSETPOS correctly. > >Hmmmm. Does anyone actually use BYSETPOS as defined by RFC2445? > > >--Alan > From owner-ietf-calendar@mail.imc.org Thu Apr 26 15:17:46 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16673 for ; Thu, 26 Apr 2001 15:17:45 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA06964 for ietf-calendar-bks; Thu, 26 Apr 2001 11:59:54 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA06958 for ; Thu, 26 Apr 2001 11:59:50 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Thu, 26 Apr 2001 15:00:25 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/26/2001 03:00:33 PM, Serialize complete at 04/26/2001 03:00:33 PM Content-Type: multipart/alternative; boundary="=_alternative 006848EE85256A3A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006848EE85256A3A_= Content-Type: text/plain; charset="us-ascii" eric wrote on 04/25/2001 02:37:53 PM: > How about having the sender do the re-write rather than the client? That > is, the sender would use a TZID that is unique to the sender, basically > attaching a UID to every TZID that it uses? The sender should guarantee > that every TZID name that it sends out is associated with only one > timezone definition, and that that name is unique to it. > > I imagine that this would result in TZIDs that are correlated to: > A Timezone > A Vendor > A Product > A version of the timezone > > So, suppose, for instance, that a TZNAME was: > > //Gnome/Evolution/1/America/Los_Angeles This is kinda like creating a PRODID for TZs but actually using it as a key of sorts (unlike our prohibition on relying on the PRODID value to impart extra meaning to items). It could work as stated. One question does come to mind though: do we want a structured format (ala URIs) or do we want to treat it like UID and just make it an opaque hashable/indexable value?? I lean towards the URI concept so that its simple and clear to detect different versions of a TZ def from different products but the overall usage is probably going to be more of the opaque type... > Of course, there should be some signal to indicate that these names are > special -- perhaps the "//" as above? Given that we already declared the soldue (aka '/') character the prefix character for a 'globally registered' name (that follows it), do we want to use a different character to indicate our 'change of design' (ie: "~" or some other character)? Since we are basically inventing a namespace mechanism (but not truely registering it anywhere) I just want to avoid any possible problems that may occur for those already implenting some form of "is it global or local" mechanism in their current engines. Hmm, just a crazy thought that popped in my head: do we need to have any prefix marker at all?? We may but maybe not. In 2445 we say that '/' prefixes some global (TBD) ID and all other values are just local ID. Is there a downside to treating "Gnome/Evolution/1/America/Los_Angeles" as a local ID? I can see a use for a special prefix marker of some kind too, depending on how I hold up the spec and twist it around but I can see a KISS answer of "just make all of them 'local' and let the CUAs match them w/their own table of 'local' IDs..." Someone nudge me off the fence... > To refer to version 1 of America/Los_Angeles in the Olsen database. A CUA > that also used this version of the Olsen database would not have to store > the VTIMEZONE of other products that used the same datbase. > > If a CUA had version 1 of America/Los_Angeles and got version 2, then it > would just store it. A good incentive for a structured URI format. > If a CUA did get a conflict, it may resort to renaming, but in general > that would not be required. Im not sure that a conflict should really happen if each vendor is responsible for versioning their TZ information. How could, say, Evolution put out 2 defintions for the "Gnome/Evolution/1/America/Los_Angeles" TZID that were different? Wouldn't that violate the intent/use of versioning?? > This would solve most of the problems that we have been discussing, such > as how to create a global registry and how to avoid conflicts with TZIDs, > without changing the storage model or requiring the recipient to muck with > the TZIDs. It resolves some issues but make some others come up (like dealing with various CUAs building caches of other CUAs IDs and getting "metadata bloat", 'compacting' down obsoleted or redudnant cached definitions, etc). This does help solve some stuff but Ill bet it raises some other issues elsewhere. A good suggestion to mull over though... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006848EE85256A3A_= Content-Type: text/html; charset="us-ascii"
eric wrote on 04/25/2001 02:37:53 PM:
> How about having the sender do the re-write rather than the client? That
> is, the sender would use a TZID that is unique to the sender, basically
> attaching a UID to every TZID that it uses? The sender should guarantee
> that every TZID name that it sends out is associated with only one
> timezone definition, and that that name is unique to it.
>
> I imagine that this would result in TZIDs that are correlated to:
>    A Timezone
>    A Vendor
>    A Product
>    A version of the timezone
>
> So, suppose, for instance, that a TZNAME was:
>
>    //Gnome/Evolution/1/America/Los_Angeles
This is kinda like creating a PRODID for TZs but actually using it as a key of sorts (unlike our prohibition on relying on the PRODID value to impart extra meaning to items).  It could work as stated.  One question does come to mind though: do we want a structured format (ala URIs) or do we want to treat it like UID and just make it an opaque hashable/indexable value??  I lean towards the URI concept so that its simple and clear to detect different versions of a TZ def from different products but the overall usage is probably going to be more of the opaque type...

> Of course, there should be some signal to indicate that these names are
> special -- perhaps the "//" as above?
Given that we already declared the soldue (aka '/') character the prefix character for a 'globally registered' name (that follows it), do we want to use a different character to indicate our 'change of design' (ie: "~" or some other character)?  Since we are basically inventing a namespace mechanism (but not truely registering it anywhere) I just want to avoid any possible problems that may occur for those already implenting some form of "is it global or local" mechanism in their current engines.  

Hmm, just a crazy thought that popped in my head: do we need to have any prefix marker at all??  We may but maybe not.  In 2445 we say that '/' prefixes some global (TBD) ID and  all other values are just local ID.  Is there a downside to treating "Gnome/Evolution/1/America/Los_Angeles"  as a local ID?  I can see a use for a special prefix marker of some kind too, depending on how I hold up the spec and twist it around but I can see a KISS answer of "just make all of them 'local' and let the CUAs match them w/their own table of 'local' IDs..."  Someone nudge me off the fence...

> To refer to version 1 of America/Los_Angeles in the Olsen database. A CUA
> that also used this version of the Olsen database would not have to store
> the VTIMEZONE of other products that used the same datbase.
>
> If a CUA had version 1 of America/Los_Angeles and got version 2, then it
> would just store it.

A good incentive for a structured URI format.

> If a CUA did get a conflict, it may resort to renaming, but in general
> that would not be required.

Im not sure that a conflict should really happen if each vendor is responsible for versioning their TZ information.  How could, say, Evolution put out 2 defintions for the "Gnome/Evolution/1/America/Los_Angeles" TZID that were different?  Wouldn't that violate the intent/use of versioning??

> This would solve most of the problems that we have been discussing, such
> as how to create a global registry and how to avoid conflicts with TZIDs,
> without changing the storage model or requiring the recipient to muck with
> the TZIDs.
It resolves some issues but make some others come up (like dealing with various CUAs building caches of other CUAs IDs and getting "metadata bloat", 'compacting' down obsoleted or redudnant cached definitions, etc).  This does help solve some stuff but Ill bet it raises some other issues elsewhere.  A good suggestion to mull over though...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006848EE85256A3A_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 26 15:41:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17309 for ; Thu, 26 Apr 2001 15:41:24 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA07459 for ietf-calendar-bks; Thu, 26 Apr 2001 12:24:17 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA07454 for ; Thu, 26 Apr 2001 12:24:16 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Antonio Ortega" Cc: ietf-calendar@imc.org Subject: Re: A beginner needs help MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Thu, 26 Apr 2001 15:24:47 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/26/2001 03:24:57 PM, Serialize complete at 04/26/2001 03:24:57 PM Content-Type: multipart/alternative; boundary="=_alternative 006A84C785256A3A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A84C785256A3A_= Content-Type: text/plain; charset="us-ascii" Antonio asked: > Well ... the subject of this message is if somebody could advise me >some place to begin. If I can, would prefer not to have to read the RFC ;) > >1 - Can someone refer me about any simply and clear summary about ICalendar. Hmmm, if you dont want to bite that bullet, you could try the Reefknot Bootstrap guide at http://reefknot.sourceforge.net/bootstrap-guide/t1.html as a basic starting point. However if you are going to have to do any coding to fix the app you found, you will have to read the RFCs. >2 - Has someone a Java example on how does it function. I havent seen any Java implementations yet but that doesnt mean there aren't any. Since noone else sent a reply to the WG I suspect there may not be any (or at least any that want their existance public). Since you did not mention what the app was its hard to tell if the person/group working on it still is active or if it was just a project that is now dead. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006A84C785256A3A_= Content-Type: text/html; charset="us-ascii"
Antonio asked:
>    Well ... the subject of this message is if somebody could advise me
>some place to begin. If I can, would prefer not to have to read the RFC ;)
>
>1 - Can someone refer me about any simply and clear summary about ICalendar.

Hmmm, if you dont want to bite that bullet, you could try the Reefknot Bootstrap guide at http://reefknot.sourceforge.net/bootstrap-guide/t1.html as a basic starting point.  However if you are going to have to do any coding to fix the app you found, you will have to read the RFCs.

>2 - Has someone a Java example on how does it function.

I havent seen any Java implementations yet but that doesnt mean there aren't any.  Since noone else sent a reply to the WG I suspect there may not be any (or at least any that want their existance public).

Since you did not mention what the app was its hard to tell if the person/group working on it still is active or if it was just a project that is now dead.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006A84C785256A3A_=-- From owner-ietf-calendar@mail.imc.org Thu Apr 26 23:45:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01157 for ; Thu, 26 Apr 2001 23:45:42 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id UAA04814 for ietf-calendar-bks; Thu, 26 Apr 2001 20:34:44 -0700 (PDT) Received: from elysium.uwa.edu.au (root@elysium.uwa.edu.au [130.95.128.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA04810 for ; Thu, 26 Apr 2001 20:34:40 -0700 (PDT) Received: from tartarus.uwa.edu.au (mtearle@tartarus.uwa.edu.au [130.95.128.3]) by elysium.uwa.edu.au (8.11.1/8.10.2) with ESMTP id f3R3Ygm17123 for ; Fri, 27 Apr 2001 11:34:42 +0800 (WST) Date: Fri, 27 Apr 2001 11:34:42 +0800 (WST) From: Mark Tearle X-X-Sender: To: Subject: Re: A beginner needs help 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 Thu, 26 Apr 2001 Bruce_Kahn@iris.com wrote: > >2 - Has someone a Java example on how does it function. > > I havent seen any Java implementations yet but that doesnt mean there > aren't any. Since noone else sent a reply to the WG I suspect there may > not be any (or at least any that want their existance public). There is the Jetspeed iCalendar implementation by Jeff Prickett http://jakarta.apache.org/jetspeed/site/icalendar.html However, I have no idea of it's current status or functionality. Yours Mark -- Mark Tearle - mark@tearle.com "He who fights monsters should be careful lest he thereby become a monster. And when you gaze long into the abyss, the abyss also gazes into you." -- Friedrich Nietzsche From owner-ietf-calendar@mail.imc.org Fri Apr 27 11:55:04 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06439 for ; Fri, 27 Apr 2001 11:55:03 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA01632 for ietf-calendar-bks; Fri, 27 Apr 2001 08:40:22 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01603 for ; Fri, 27 Apr 2001 08:40:12 -0700 (PDT) From: Bruce_Kahn@iris.com To: Mark Tearle Cc: ietf-calendar@imc.org Subject: Re: A beginner needs help MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Fri, 27 Apr 2001 11:41:20 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/27/2001 11:41:00 AM, Serialize complete at 04/27/2001 11:41:00 AM Content-Type: multipart/alternative; boundary="=_alternative 0055FCB185256A3B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0055FCB185256A3B_= Content-Type: text/plain; charset="us-ascii" Mark wrote on 04/26/2001 11:34:42 PM: > There is the Jetspeed iCalendar implementation by Jeff Prickett > http://jakarta.apache.org/jetspeed/site/icalendar.html > > However, I have no idea of it's current status or functionality. A quick scan of that site shows: Jetspeed (as of 1.2b1) implements a subset of RFC 2445 or iCalendar. [Snip] iCalendar was made a separate module from Jetspeed, since it is a general utility. Unfortunately, currently it has lost visibility in the jakarta project. If you are interested in contributing to a portable implementation of RFC2445, please contact Jeff Prickett. So it sounds as if its not under much active development now. However it is nice to know that someone at least began something. Thanks for the pointer Mark. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0055FCB185256A3B_= Content-Type: text/html; charset="us-ascii"
Mark wrote on 04/26/2001 11:34:42 PM:

> There is the Jetspeed iCalendar implementation by Jeff Prickett
>    http://jakarta.apache.org/jetspeed/site/icalendar.html
>
> However, I have no idea of it's current status or functionality.
A quick scan of that site shows:

    Jetspeed (as of 1.2b1) implements a subset of RFC 2445 or iCalendar.
  [Snip]
    iCalendar was made a separate module from Jetspeed, since it is a general utility.
   Unfortunately, currently it has lost visibility in the jakarta project. If you are interested in contributing to a portable implementation of RFC2445, please contact Jeff Prickett.

So it sounds as if its not under much active development now.  However it is nice to know that someone at least began something.  Thanks for the pointer Mark.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0055FCB185256A3B_=-- From owner-ietf-calendar@mail.imc.org Sun Apr 29 19:09:10 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12308 for ; Sun, 29 Apr 2001 19:09:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA08650 for ietf-calendar-bks; Sun, 29 Apr 2001 15:51:21 -0700 (PDT) Received: from agony.busboom.org (dt011n61.san.rr.com [204.210.13.97]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA08644 for ; Sun, 29 Apr 2001 15:51:20 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f3TMp3310085; Sun, 29 Apr 2001 15:51:03 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Sun, 29 Apr 2001 15:51:02 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Bruce_Kahn@iris.com cc: ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? 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 Thu, 26 Apr 2001 Bruce_Kahn@iris.com wrote: > Hmm, just a crazy thought that popped in my head: do we need to have any > prefix marker at all?? We may but maybe not. In 2445 we say that '/' > prefixes some global (TBD) ID and all other values are just local ID. Is > there a downside to treating "Gnome/Evolution/1/America/Los_Angeles" as a > local ID? The reason that I suggested a marker was that when a vendor does not use the "product-global" TZID, then the receiving CUA may have to resort to the renaming trick suggested earlier. It seems that the CUA could use a hint as to wether the sender of the VTIME is guaranteeing that the TZID will not have to be renamed, and the marker is that hint. Considering your suggestions that the TZID could be a URI, I am equally equivocal. The main advantage of using a URI, I'd suppose, is that the receiver could fetch the object referenced by the URI through the net or a filesystem. But, the sender is required to send the VTIMEZONE, and what would the receiver want to fetch that would not already be in the VTIMEZONE? And, unless we defined how the URI would be used, both the sender and receiver would have to agree on what to do with it. This would most likely result in a proprietary use of the TZID URI. Well, it is already OK for a vendor to make the TZID a URI and define some proprietary use for it between the vendor's own CUAs, so adding text to RFC would not really change anything. So, here is my proposal: ------------------------------------------------------------------------------ Additions to 4.8.3.1 Time Zone Identifier ;tzidprefix = "/" / "~" ; Defined previously. Just listed here for reader convenience. [ Add another character to tzidprefix: '~' ( TILDE, US-ASCII 126). ] This presence of the TILDE character ( US-ASCII 126) as a prefix indicates that all distinct usages of the TZID will refer to functionally equivalent timezone data. Two VTIMEZONE are "functionally equivalent" when the set of time shifts generated by one VTIMEZONE is equivalent to the set generated by the other. The generator of a TZID MUST ensure that the TZID with a TILDE prefix uniquely references a single set of timezone shifts. The generator of such a TZID SHOULD include in the TZID the name of the database where the timezone information is stored, the name of the timezone, and the version of the data. For example: TZID:=~TimezoneEmporium/America/New_York/1 ----------------------------------------------------------------------------- Another idea: since there is no global tinezone database, the "/" prefiz reaaly does not mean anything ueful, and after the addition above, it will still not really mean anything. Instead of adding a new prefix character, could we skip it and commandeer the "/"? That is, make the "/" serve the purpose of "~" in the above proposal? In that case, remove this text: ------------------------------------------------------------------------------ The presence of the SOLIDUS character (US-ASCII decimal 47) as a prefix, indicates that this TZID represents a unique ID in a globally defined time zone registry (when such registry is defined). Note: This document does not define a naming convention for time zone identifier s. Implementers may want to use the naming conventions defined in existing time zone specifications such as the public-domain Olson database [TZ]. The specification of globally unique time zone identifiers is no ------------------------------------------------------------------------------ and replace it with: ------------------------------------------------------------------------------ This presence of the SOLIDUS character ( US-ASCII 47) as a prefix indicates that all distinct usages of the TZID will refer to functionally equivalent timezone data. Two VTIMEZONE are "functionally equivalent" when the set of time shifts generated by one VTIMEZONE is equivalent to the set generated by the other. The generator of a TZID MUST ensure that the TZID with a SOLIDUS prefix uniquely references a single set of timezone shifts. The generator of such a TZID SHOULD include in the TZID the name of the database where the timezone information is stored, the name of the timezone, and the version of the data. For example: TZID:=/TimezoneEmporium/America/New_York/1 ------------------------------------------------------------------------------ I like the second proposal better, since the TZID looks cleaner and it does not leave the cruft of the previous "/" prefix text laying around. And I think that it fits with the original idea of a global database, except that we are allowing for multiple, unregisters databases. eric. From owner-ietf-calendar@mail.imc.org Sun Apr 29 19:32:06 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12504 for ; Sun, 29 Apr 2001 19:32:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA11265 for ietf-calendar-bks; Sun, 29 Apr 2001 16:21:05 -0700 (PDT) Received: from agony.busboom.org (dt011n61.san.rr.com [204.210.13.97]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA11259 for ; Sun, 29 Apr 2001 16:21:04 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f3TNL6b10132 for ; Sun, 29 Apr 2001 16:21:07 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Sun, 29 Apr 2001 16:21:06 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Proposed Text for "Does 1day == 24 Hours" 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: This is proposed text for RFC2445 issue #52 Please review the text and comment. ----------------------------------------------------------------------- Addition to 4.3.6 Duration When calculating an end time from a DTSTART and a DURATION, the dur-day ("D") and dur-week ("W") MUST only be added to the date parts of the DTSTART; dur-day and dur-week MUST NOT be assumed to be generally convertable to hours, minutes or seconds. If the value of DTSTART is a DATE, then the DURATION MUST NOT include dur-hour, dur-minute or dur-second parts. ----------------------------------------------------------------------- eric. From owner-ietf-calendar@mail.imc.org Sun Apr 29 20:02:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12646 for ; Sun, 29 Apr 2001 20:02:18 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA12805 for ietf-calendar-bks; Sun, 29 Apr 2001 16:45:58 -0700 (PDT) Received: from trna.ximian.com ([141.154.95.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA12799 for ; Sun, 29 Apr 2001 16:45:56 -0700 (PDT) Received: from ximian.com (IDENT:damon@karuna.ximian.com [141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id TAA05784; Sun, 29 Apr 2001 19:45:19 -0400 Message-ID: <3AECA6CF.CA0B6CD@ximian.com> Date: Sun, 29 Apr 2001 19:42:07 -0400 From: Damon Chaplin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Busboom CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? 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: > How about having the sender do the re-write rather than the client? That > is, the sender would use a TZID that is unique to the sender, basically > attaching a UID to every TZID that it uses? The sender should guarantee > that every TZID name that it sends out is associated with only one > timezone definition, and that that name is unique to it. > > I imagine that this would result in TZIDs that are correlated to: > A Timezone > A Vendor > A Product > A version of the timezone > > So, suppose, for instance, that a TZNAME was: > > //Gnome/Evolution/1/America/Los_Angeles > > The recipient can be assured that whenever it gets this name, the name > applies to a single version of a particular timezone, as it is defined by > the sender. If the sender makes any changes to the definition, it > should use a new TZNAME. But what happens if a malicious app sends out VTIMEZONEs with the same TZIDs as a proper client app? It could mess up your timezone database. I still think the simplest thing to do is just rename clashing TZIDs, so you get "America/Los_Angeles", "America/Los_Angeles(2)", "America/Los_Angeles(3)", etc. Its fairly easy to do and works with existing iCalendar apps. And it should only happen when you import iCalendar data or get an iTIP request. Damon From owner-ietf-calendar@mail.imc.org Mon Apr 30 02:04:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00436 for ; Mon, 30 Apr 2001 02:04:42 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA25373 for ietf-calendar-bks; Sun, 29 Apr 2001 22:53:50 -0700 (PDT) Received: from agony.busboom.org (dt011n61.san.rr.com [204.210.13.97]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA25369 for ; Sun, 29 Apr 2001 22:53:48 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f3U5rX010677; Sun, 29 Apr 2001 22:53:33 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Sun, 29 Apr 2001 22:53:32 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Damon Chaplin cc: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? In-Reply-To: <3AECA6CF.CA0B6CD@ximian.com> 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 Sun, 29 Apr 2001, Damon Chaplin wrote: > But what happens if a malicious app sends out VTIMEZONEs with the > same TZIDs as a proper client app? It could mess up your timezone > database. Don't overwrite existing TZID entries with new ones. Not only would the attacker have to guess the right TZID, including zone name and database name, and be the first to send you a meeting with that TZID, but you would also have to book the meeting on the calendar. That is very remote, and even if it succedes, it is not very exciting for the attacker. > I still think the simplest thing to do is just rename clashing > TZIDs, so you get "America/Los_Angeles", "America/Los_Angeles(2)", > "America/Los_Angeles(3)", etc. But in this case you are certain to have one copy of every VTIMEZONE that you have every recieved, and a CS will have to store a copy for every VTIMEZONE that every user has ever recieved. With the current proposal, there is no renaming for the client to do, and the VTIMEZONES can be shared. That is even easier that the renaming; all you have to do is set the names in the timezone database to follow the poposed form, and use them as they come out of the database --- there is no renaming to do anywhere. eric. From owner-ietf-calendar@mail.imc.org Mon Apr 30 15:53:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24128 for ; Mon, 30 Apr 2001 15:53:43 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA08573 for ietf-calendar-bks; Mon, 30 Apr 2001 12:31:29 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA08569 for ; Mon, 30 Apr 2001 12:31:28 -0700 (PDT) Received: from ximian.com (IDENT:damon@karuna.ximian.com [141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id PAA13804; Mon, 30 Apr 2001 15:30:59 -0400 Message-ID: <3AEDBCB0.3D96568C@ximian.com> Date: Mon, 30 Apr 2001 15:27:44 -0400 From: Damon Chaplin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Busboom CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? 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: > > On Sun, 29 Apr 2001, Damon Chaplin wrote: > > > But what happens if a malicious app sends out VTIMEZONEs with the > > same TZIDs as a proper client app? It could mess up your timezone > > database. > > Don't overwrite existing TZID entries with new ones. Not only would the > attacker have to guess the right TZID, including zone name and database > name, and be the first to send you a meeting with that TZID, but you would > also have to book the meeting on the calendar. That is very remote, and > even if it succedes, it is not very exciting for the attacker. They don't have to guess the TZIDs - they can just read them in iMIP requests. Admittedly it is remote, but iCalendar shouldn't leave the slightest possibility of someone else interfering with your calendar. > > I still think the simplest thing to do is just rename clashing > > TZIDs, so you get "America/Los_Angeles", "America/Los_Angeles(2)", > > "America/Los_Angeles(3)", etc. > > But in this case you are certain to have one copy of every VTIMEZONE that > you have every recieved, and a CS will have to store a copy for every > VTIMEZONE that every user has ever recieved. You can compare VTIMEZONEs so you don't have duplicates. > With the current proposal, there is no renaming for the client to do, and > the VTIMEZONES can be shared. That is even easier that the renaming; all > you have to do is set the names in the timezone database to follow the > poposed form, and use them as they come out of the database --- there is > no renaming to do anywhere. I agree that it would be nicer to do it that way. (I think I even suggested something like that a while back.) But I think it is insecure so we can't. Damon From owner-ietf-calendar@mail.imc.org Mon Apr 30 15:59:55 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24300 for ; Mon, 30 Apr 2001 15:59:54 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA09455 for ietf-calendar-bks; Mon, 30 Apr 2001 12:44:28 -0700 (PDT) Received: from agony.busboom.org (dt011n61.san.rr.com [204.210.13.97]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA09451 for ; Mon, 30 Apr 2001 12:44:27 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f3UJiSU12132 for ; Mon, 30 Apr 2001 12:44:29 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 30 Apr 2001 12:44:28 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: RFC 2445 Issues and Proposed Text 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: Today I updated the RFC2445 issues list and proposed text. See both online at: http://softwarestudio.org/iCal/index.html eric. From owner-ietf-calendar@mail.imc.org Mon Apr 30 22:07:53 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01260 for ; Mon, 30 Apr 2001 22:07:53 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA04741 for ietf-calendar-bks; Mon, 30 Apr 2001 18:46:57 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA04734 for ; Mon, 30 Apr 2001 18:46:56 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Mon, 30 Apr 2001 21:48:16 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/30/2001 09:52:10 PM, Serialize complete at 04/30/2001 09:52:10 PM Content-Type: multipart/alternative; boundary="=_alternative 0009C81685256A3F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0009C81685256A3F_= Content-Type: text/plain; charset="us-ascii" eric wrote on 04/29/2001 06:51:02 PM: > Considering your suggestions that the TZID could be a URI, I am equally > equivocal. Actually I didnt suggest that it be a URI. I suggested it have a parsable structure like a URI (unlike PROID that has structure but CUAs should not use it to impart any meaning to the data). Not quite the same suggestion. Having a format thats parsable and extensible is an appealing way to fix some of the bubbles under the wallpaper (and to push others to different places). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0009C81685256A3F_= Content-Type: text/html; charset="us-ascii"
eric wrote on 04/29/2001 06:51:02 PM:
> Considering your suggestions that the TZID could be a URI, I am equally
> equivocal.
Actually I didnt suggest that it be a URI.  I suggested it have a parsable structure like a URI (unlike PROID that has structure but CUAs should not use it to impart any meaning to the data).  Not quite the same suggestion.  Having a format thats parsable and extensible is an appealing way to fix some of the bubbles under the wallpaper (and to push others to different places).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0009C81685256A3F_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 30 22:08:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01291 for ; Mon, 30 Apr 2001 22:08:35 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA05317 for ietf-calendar-bks; Mon, 30 Apr 2001 18:54:20 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA05312 for ; Mon, 30 Apr 2001 18:54:19 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Proposed Text for "Does 1day == 24 Hours" MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Mon, 30 Apr 2001 21:55:41 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/30/2001 09:59:33 PM, Serialize complete at 04/30/2001 09:59:33 PM Content-Type: multipart/alternative; boundary="=_alternative 000A75F785256A3F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000A75F785256A3F_= Content-Type: text/plain; charset="us-ascii" eric wrote on 04/29/2001 07:21:06 PM: > When calculating an end time from a DTSTART and a DURATION, the dur-day > ("D") and dur-week ("W") MUST only be added to the date parts of the > DTSTART; dur-day and dur-week MUST NOT be assumed to be generally > convertable to hours, minutes or seconds. I like. > If the value of DTSTART is a DATE, then the DURATION MUST NOT include > dur-hour, dur-minute or dur-second parts. I dont see a strong need for this restriction. The DTSTART;VALUE=DATE has an implicit 00:00:00 local starting time so time durations can still be easily and accuratly used. It _could_ get messy if a TZID that was not the same as the recipients was used AND a DST shift was involved in 1 case but not the other but for those VERY tiny cases Id say that the 95/05 rule (or is that 99/01?) would apply. Then again Im not _that_ strongly against it (I just want to keep the text perturbations down). Bruce "Mr. KISS" =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 000A75F785256A3F_= Content-Type: text/html; charset="us-ascii"
eric wrote on 04/29/2001 07:21:06 PM:
> When calculating an end time from a DTSTART and a DURATION, the dur-day
> ("D") and dur-week ("W") MUST only be added to the date parts of the
> DTSTART; dur-day and dur-week MUST NOT be assumed to be generally
> convertable to hours, minutes or seconds.
I like.

> If the value of DTSTART is a DATE, then the DURATION MUST NOT include
> dur-hour, dur-minute or dur-second parts.

I dont see a strong need for this restriction.  The DTSTART;VALUE=DATE has an implicit 00:00:00 local starting time so time durations can still be easily and accuratly used.

It _could_ get messy if a TZID that was not the same as the recipients was used AND a DST shift was involved in 1 case but not the other but for those VERY tiny cases Id say that the 95/05 rule (or is that 99/01?) would apply.  Then again Im not _that_ strongly against it (I just want to keep the text perturbations down).

Bruce
"Mr. KISS"
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 000A75F785256A3F_=-- From owner-ietf-calendar@mail.imc.org Mon Apr 30 22:15:13 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01394 for ; Mon, 30 Apr 2001 22:15:12 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA05580 for ietf-calendar-bks; Mon, 30 Apr 2001 18:59:50 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA05576 for ; Mon, 30 Apr 2001 18:59:49 -0700 (PDT) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Mon, 30 Apr 2001 22:01:10 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 04/30/2001 10:05:03 PM, Serialize complete at 04/30/2001 10:05:03 PM Content-Type: multipart/alternative; boundary="=_alternative 000AF68B85256A3F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000AF68B85256A3F_= Content-Type: text/plain; charset="us-ascii" Damon replied on 04/29/2001 07:42:07 PM: > But what happens if a malicious app sends out VTIMEZONEs with the > same TZIDs as a proper client app? It could mess up your timezone > database. Sounds like you are thinking of some spam or C&S bomb attack. Ill group all bogus C&S into the "spam" cateogry for this reply. Well, if I trash the spam then my CUA wont have to store the faked out data and no harm is done. If it is not C&S spam and I actually want to do some C&S w/the sender then the odds are pretty good that they wont be using some malicious app that wants to hose my local TZ cache. So I don't yet see that this is a big problem w/Erics suggestion but perhaps Bob or Paul can slap me up side the head and set me right (on this guys!) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 000AF68B85256A3F_= Content-Type: text/html; charset="us-ascii"
Damon replied on 04/29/2001 07:42:07 PM:
> But what happens if a malicious app sends out VTIMEZONEs with the
> same TZIDs as a proper client app? It could mess up your timezone
> database.
Sounds like you are thinking of some spam or C&S bomb attack.  Ill group all bogus C&S into the "spam" cateogry for this reply.

Well, if I trash the spam then my CUA wont have to store the faked out data and no harm is done.  If it is not C&S spam and I actually want to do some C&S w/the sender then the odds are pretty good that they wont be using some malicious app that wants to hose my local TZ cache.

So I don't yet see that this is a big problem w/Erics suggestion but perhaps Bob or Paul can slap me up side the head and set me right (on this guys!)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 000AF68B85256A3F_=--