From owner-ietf-calendar@mail.imc.org Tue May 1 11:30:42 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01281 for ; Tue, 1 May 2001 11:30:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA07637 for ietf-calendar-bks; Tue, 1 May 2001 08:04: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 IAA07631 for ; Tue, 1 May 2001 08:03:58 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA07385; Tue, 1 May 2001 11:03:29 -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 f41F3SP14227; Tue, 1 May 2001 11:03:29 -0400 (EDT) Message-Id: <5.0.0.25.0.20010501104349.021f13a0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 01 May 2001 11:02:02 -0400 To: Bruce_Kahn@iris.com From: Alan Davies Subject: Re: Where to put VTIMEZONE and VALARM? 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: You're assuming that an average CU is capable of recognising a bogus VTIMEZONE, which might be expecting a bit too much. Remember it's not always easy to tell spam/malicious email from real email- just look at how email viruses manage to spread. I wouldn't even expect an average CU to be able to look at the source of a VTIMEZONE and decide if it's valid or not. If all CUAs accepted buggy timezones that were presented to them, those VTIMEZONEs could spread quickly, in a similar manner to viruses- imagine if my EST5EDT timezone was messed up, but only in the 'standard' portion; I wouldn't realise until October. It would also be kind of annoying though to be in the position where another vendor's bugs can mess up my TZ database- "Every time I get an iCalendar object from John Doe's buggy Development Beta CUA my Timezone seems to mess up and I have to restart/reboot/redownload/reinstall/whatever"- it wouldn't feel like my own CUA was very robust. --Alan At 22:01 2001-04-30 -0400, Bruce_Kahn@iris.com wrote: >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... From owner-ietf-calendar@mail.imc.org Tue May 1 13:31:11 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05001 for ; Tue, 1 May 2001 13:31:10 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA21734 for ietf-calendar-bks; Tue, 1 May 2001 10:15:55 -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 KAA21722 for ; Tue, 1 May 2001 10:15:53 -0700 (PDT) From: Bruce_Kahn@iris.com MIME-Version: 1.0 To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Where to put VTIMEZONE and VALARM? X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Tue, 1 May 2001 13:17:15 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/01/2001 01:21:07 PM, Serialize complete at 05/01/2001 01:21:07 PM Content-Type: multipart/alternative; boundary="=_alternative 005ED0FF85256A3F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005ED0FF85256A3F_= Content-Type: text/plain; charset="us-ascii" Alan wrote on 05/01/2001 11:02:02 AM: > You're assuming that an average CU is capable of recognising > a bogus VTIMEZONE, which might be expecting a bit too much. > > Remember it's not always easy to tell spam/malicious email > from real email- just look at how email viruses manage to > spread. Sure, anyone can build a CUA that is not well designed and CUs are more than welcome to use it and pay the price ("Ya get what you pay for" and "What goes around, comes around" come to mind for both CU and vendor in this case). However, Id hope that a CUA that offers autoprocessing would have some kind of smarts in it (ie: "I only want requests from my boss to be autoprocessed", "Only process signed iMIP requests from domains X, Y or Z", etc) so that this is not an issue. After all, if I dont accept the spam then why would my CUA need or want to store the bogus defintions? The bogus definitions are only useful in the context of the iTIP/iMIP message that my CUA is processing to start with and if I toss it, I can safely toss the cruft too. > I wouldn't even expect an average CU to be able to look > at the source of a VTIMEZONE and decide if it's valid or not. Whoa Hoss. The CU is not very likely at all to even see the TZ defintions. They see the decoded iTIP request and will generally toss it (unless of course they love adding spam to their calendar). If they for some reason accept the spam then Id expect the CUA to require some CU involvement before "updating" or 'overwriting" its own TZ definitions. > If > all CUAs accepted buggy timezones that were presented to them, those > VTIMEZONEs could spread quickly, in a similar manner to viruses- > imagine if my EST5EDT timezone was messed up, but only in the > 'standard' portion; I wouldn't realise until October. I think that Erics current proposal is NOT that the bogus defintions would be propigated but rather that each app would encode the TZ information from its own internal table of TZ definitions. That is, I may get (and for some reason) accept your spam that adds a new North_America/Los_Angeles to my system but it will have a different product and/or version info in it. As such my CUA would not be resending it out in any of my requests, it would use its own internal table w/its own product name and version on it. If the offending spam came in w/the same TZID as my own CUAs then my CUA could safely ignore it (ie: "I already know what ~Lotus/Notes/1/North_America/Los_Angeles/ is so I dont need to use the senders TZ info") If for some reason my CUA wanted keep the spam TZ info and it was forged so that it appeared to be a 'newer' version of the TZ definition then the CUA should have some reasonable behaviour like prompt the CU that a 'newer' TZ definition is (or "may be") available and what do they want to do w/it. If it came in on some spam then I would expect the CUs to do nothing! Afterall you can only protect a CU from themselves for so long before its just 10 lines of code and 10,000 lines of safety netting. Better that the CUA make it something that takes cogntive action on the part of the CU _before_ the suspect (or real) TZ defs are added to the system!! > It would also be kind of annoying though to be in the position > where another vendor's bugs can mess up my TZ database- Please reread Erics proposal. His proposal does not say that your CUA would absorb and reuse the bogus TZ info. I believe that his intent is still that your CUA would continue to use its own tables for all outbound stuff w/possibly the exception of delegations or "party crashing". Eric can confirm or deny this though. As such, the bogus data wont be mucking up your normal workflow process since it is only applied to the entry(s) that it came in on. > It would also be kind of annoying though to be in the position > where another vendor's bugs can mess up my TZ database- > [Snip, snip] it wouldn't feel > like my own CUA was very robust. Given the format of Erics TZID, your vendor and product ID wont match the crufty CUAs vendor and product ID so a poor CUAs defintions wont be messing up your CUAs (unless your CUA is poorly designed too and reuses someone elses TZ info as their own). 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 005ED0FF85256A3F_= Content-Type: text/html; charset="us-ascii"
Alan wrote on 05/01/2001 11:02:02 AM:
> You're assuming that an average CU is capable of recognising
> a bogus VTIMEZONE, which might be expecting a bit too much.
>
> Remember it's not always easy to tell spam/malicious email
> from real email- just look at how email viruses manage to
> spread.

Sure, anyone can build a CUA that is not well designed and CUs are more than welcome to use it and pay the price ("Ya get what you pay for" and "What goes around, comes around" come to mind for both CU and vendor in this case).  However, Id hope that a CUA that offers autoprocessing would have some kind of smarts in it (ie: "I only want requests from my boss to be autoprocessed", "Only process signed iMIP requests from domains X, Y or Z", etc) so that this is not an issue.  

After all, if I dont accept the spam then why would my CUA need or want to store the bogus defintions?  The bogus definitions are only useful in the context of the iTIP/iMIP message that my CUA is processing to start with and if I toss it, I can safely toss the cruft too.

>         I wouldn't even expect an average CU to be able to look
> at the source of a VTIMEZONE and decide if it's valid or not.

Whoa Hoss.  The CU is not very likely at all to even see the TZ defintions.  They see the decoded iTIP request and will generally toss it (unless of course they love adding spam to their calendar).  If they for some reason accept the spam then Id expect the CUA to require some CU involvement before "updating" or 'overwriting" its own TZ definitions.

> If
> all CUAs accepted buggy timezones that were presented to them, those
> VTIMEZONEs could spread quickly, in a similar manner to viruses-
> imagine if my EST5EDT timezone was messed up, but only in the
> 'standard' portion; I wouldn't realise until October.
I think that Erics current proposal is NOT that the bogus defintions would be propigated but rather that each app would encode the TZ information from its own internal table of TZ definitions.  That is, I may get (and for some reason) accept your spam that adds a new North_America/Los_Angeles to my system but it will have a different product and/or version info in it.  As such my CUA would not be resending it out in any of my requests, it would use its own internal table w/its own product name and version on it.  If the offending spam came in w/the same TZID as my own CUAs then my CUA could safely ignore it (ie: "I already know what ~Lotus/Notes/1/North_America/Los_Angeles/ is so I dont need to use the senders TZ info")

If for some reason my CUA wanted keep the spam TZ info and it was forged so that it appeared to be a 'newer' version of the TZ definition then the CUA should have some reasonable behaviour like prompt the CU that a 'newer' TZ definition is (or "may be") available and what do they want to do w/it.  If it came in on some spam then I would expect the CUs to do nothing!   Afterall you can only protect a CU from themselves for so long before its just 10 lines of code and 10,000 lines of safety netting.  Better that the CUA make it something that takes cogntive action on the part of the CU _before_ the suspect (or real) TZ defs are added to the system!!

> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database-

Please reread Erics proposal.  His proposal does not say that your CUA would absorb and reuse the bogus TZ info.  I believe that his intent is still that your CUA would continue to use its own tables for all outbound stuff w/possibly the exception of delegations or "party crashing".  Eric can confirm or deny this though.    As such, the bogus data wont be mucking up your normal workflow process since it is only applied to the entry(s) that it came in on.

> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database-
> [Snip, snip]                    it wouldn't feel
> like my own CUA was very robust.

Given the format of Erics TZID, your vendor and product ID wont match the crufty CUAs vendor and product ID so a poor CUAs defintions wont be messing up your CUAs (unless your CUA is poorly designed too and reuses someone elses TZ info as their own).  

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 005ED0FF85256A3F_=-- From owner-ietf-calendar@mail.imc.org Tue May 1 13:35:37 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05105 for ; Tue, 1 May 2001 13:35:36 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA21732 for ietf-calendar-bks; Tue, 1 May 2001 10:15:55 -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 KAA21716 for ; Tue, 1 May 2001 10:15:52 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies 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, 1 May 2001 13:17:13 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/01/2001 01:21:06 PM, Serialize complete at 05/01/2001 01:21:06 PM Content-Type: multipart/alternative; boundary="=_alternative 005ECFEC85256A3F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005ECFEC85256A3F_= Content-Type: text/plain; charset="us-ascii" Alan wrote on 05/01/2001 11:02:02 AM: > You're assuming that an average CU is capable of recognising > a bogus VTIMEZONE, which might be expecting a bit too much. > > Remember it's not always easy to tell spam/malicious email > from real email- just look at how email viruses manage to > spread. Sure, anyone can build a CUA that is not well designed and CUs are more than welcome to use it and pay the price ("Ya get what you pay for" and "What goes around, comes around" come to mind for both CU and vendor in this case). However, Id hope that a CUA that offers autoprocessing would have some kind of smarts in it (ie: "I only want requests from my boss to be autoprocessed", "Only process signed iMIP requests from domains X, Y or Z", etc) so that this is not an issue. After all, if I dont accept the spam then why would my CUA need or want to store the bogus defintions? The bogus definitions are only useful in the context of the iTIP/iMIP message that my CUA is processing to start with and if I toss it, I can safely toss the cruft too. > I wouldn't even expect an average CU to be able to look > at the source of a VTIMEZONE and decide if it's valid or not. Whoa Hoss. The CU is not very likely at all to even see the TZ defintions. They see the decoded iTIP request and will generally toss it (unless of course they love adding spam to their calendar). If they for some reason accept the spam then Id expect the CUA to require some CU involvement before "updating" or 'overwriting" its own TZ definitions. > If > all CUAs accepted buggy timezones that were presented to them, those > VTIMEZONEs could spread quickly, in a similar manner to viruses- > imagine if my EST5EDT timezone was messed up, but only in the > 'standard' portion; I wouldn't realise until October. I think that Erics current proposal is NOT that the bogus defintions would be propigated but rather that each app would encode the TZ information from its own internal table of TZ definitions. That is, I may get (and for some reason) accept your spam that adds a new North_America/Los_Angeles to my system but it will have a different product and/or version info in it. As such my CUA would not be resending it out in any of my requests, it would use its own internal table w/its own product name and version on it. If the offending spam came in w/the same TZID as my own CUAs then my CUA could safely ignore it (ie: "I already know what ~Lotus/Notes/1/North_America/Los_Angeles/ is so I dont need to use the senders TZ info") If for some reason my CUA wanted keep the spam TZ info and it was forged so that it appeared to be a 'newer' version of the TZ definition then the CUA should have some reasonable behaviour like prompt the CU that a 'newer' TZ definition is (or "may be") available and what do they want to do w/it. If it came in on some spam then I would expect the CUs to do nothing! Afterall you can only protect a CU from themselves for so long before its just 10 lines of code and 10,000 lines of safety netting. Better that the CUA make it something that takes cogntive action on the part of the CU _before_ the suspect (or real) TZ defs are added to the system!! > It would also be kind of annoying though to be in the position > where another vendor's bugs can mess up my TZ database- Please reread Erics proposal. His proposal does not say that your CUA would absorb and reuse the bogus TZ info. I believe that his intent is still that your CUA would continue to use its own tables for all outbound stuff w/possibly the exception of delegations or "party crashing". Eric can confirm or deny this though. As such, the bogus data wont be mucking up your normal workflow process since it is only applied to the entry(s) that it came in on. > It would also be kind of annoying though to be in the position > where another vendor's bugs can mess up my TZ database- > [Snip, snip] it wouldn't feel > like my own CUA was very robust. Given the format of Erics TZID, your vendor and product ID wont match the crufty CUAs vendor and product ID so a poor CUAs defintions wont be messing up your CUAs (unless your CUA is poorly designed too and reuses someone elses TZ info as their own). 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 005ECFEC85256A3F_= Content-Type: text/html; charset="us-ascii"
Alan wrote on 05/01/2001 11:02:02 AM:
> You're assuming that an average CU is capable of recognising
> a bogus VTIMEZONE, which might be expecting a bit too much.
>
> Remember it's not always easy to tell spam/malicious email
> from real email- just look at how email viruses manage to
> spread.

Sure, anyone can build a CUA that is not well designed and CUs are more than welcome to use it and pay the price ("Ya get what you pay for" and "What goes around, comes around" come to mind for both CU and vendor in this case).  However, Id hope that a CUA that offers autoprocessing would have some kind of smarts in it (ie: "I only want requests from my boss to be autoprocessed", "Only process signed iMIP requests from domains X, Y or Z", etc) so that this is not an issue.  

After all, if I dont accept the spam then why would my CUA need or want to store the bogus defintions?  The bogus definitions are only useful in the context of the iTIP/iMIP message that my CUA is processing to start with and if I toss it, I can safely toss the cruft too.

>         I wouldn't even expect an average CU to be able to look
> at the source of a VTIMEZONE and decide if it's valid or not.

Whoa Hoss.  The CU is not very likely at all to even see the TZ defintions.  They see the decoded iTIP request and will generally toss it (unless of course they love adding spam to their calendar).  If they for some reason accept the spam then Id expect the CUA to require some CU involvement before "updating" or 'overwriting" its own TZ definitions.

> If
> all CUAs accepted buggy timezones that were presented to them, those
> VTIMEZONEs could spread quickly, in a similar manner to viruses-
> imagine if my EST5EDT timezone was messed up, but only in the
> 'standard' portion; I wouldn't realise until October.
I think that Erics current proposal is NOT that the bogus defintions would be propigated but rather that each app would encode the TZ information from its own internal table of TZ definitions.  That is, I may get (and for some reason) accept your spam that adds a new North_America/Los_Angeles to my system but it will have a different product and/or version info in it.  As such my CUA would not be resending it out in any of my requests, it would use its own internal table w/its own product name and version on it.  If the offending spam came in w/the same TZID as my own CUAs then my CUA could safely ignore it (ie: "I already know what ~Lotus/Notes/1/North_America/Los_Angeles/ is so I dont need to use the senders TZ info")

If for some reason my CUA wanted keep the spam TZ info and it was forged so that it appeared to be a 'newer' version of the TZ definition then the CUA should have some reasonable behaviour like prompt the CU that a 'newer' TZ definition is (or "may be") available and what do they want to do w/it.  If it came in on some spam then I would expect the CUs to do nothing!   Afterall you can only protect a CU from themselves for so long before its just 10 lines of code and 10,000 lines of safety netting.  Better that the CUA make it something that takes cogntive action on the part of the CU _before_ the suspect (or real) TZ defs are added to the system!!

> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database-

Please reread Erics proposal.  His proposal does not say that your CUA would absorb and reuse the bogus TZ info.  I believe that his intent is still that your CUA would continue to use its own tables for all outbound stuff w/possibly the exception of delegations or "party crashing".  Eric can confirm or deny this though.    As such, the bogus data wont be mucking up your normal workflow process since it is only applied to the entry(s) that it came in on.

> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database-
> [Snip, snip]                    it wouldn't feel
> like my own CUA was very robust.

Given the format of Erics TZID, your vendor and product ID wont match the crufty CUAs vendor and product ID so a poor CUAs defintions wont be messing up your CUAs (unless your CUA is poorly designed too and reuses someone elses TZ info as their own).  

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 005ECFEC85256A3F_=-- From owner-ietf-calendar@mail.imc.org Tue May 1 16:16:27 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09375 for ; Tue, 1 May 2001 16:16:26 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA29025 for ietf-calendar-bks; Tue, 1 May 2001 12:59:34 -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 MAA29021 for ; Tue, 1 May 2001 12:59:33 -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 PAA32496 for ; Tue, 1 May 2001 15:59:21 -0400 Message-ID: <3AEF14D2.4C574DE7@ximian.com> Date: Tue, 01 May 2001 15:56:02 -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: "ietf-calendar@imc.org" Subject: RDATEs in VTIMEZONEs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm still unsure of which type of time is supposed to be used for RDATEs in VTIMEZONEs. In RFC2445, pg 64 it says: Alternatively, the "RDATE" property can be used to define the onset of the observance by giving the individual onset date and times. "RDATE" in this usage MUST be specified as a local DATE-TIME value in UTC time. Yet the example just below has: DTSTART:19971026T020000 RDATE:19971026T020000 Here the RDATE is not a UTC time - it doesn't have a 'Z'. It looks like a local 'wall clock' time, like DTSTART. So which is it - local time or UTC? I'd prefer local time, as that keeps it the same as the DTSTART and RRULE times. (What does Outlook use?) Damon From owner-ietf-calendar@mail.imc.org Tue May 1 16:22:57 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09488 for ; Tue, 1 May 2001 16:22:57 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA29571 for ietf-calendar-bks; Tue, 1 May 2001 13:06:01 -0700 (PDT) Received: from biz1.mailsrvcs.net (biz1.gte.net [207.115.153.50]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA29561 for ; Tue, 1 May 2001 13:05:59 -0700 (PDT) Received: from [4.3.146.172] by biz1.mailsrvcs.net (Post.Office MTA v3.5.3 release 223 ID# 0-64117L5000S0V35) with ESMTP id net; Tue, 1 May 2001 14:57:26 -0500 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Tue, 01 May 2001 12:49:23 -0800 Subject: Re: Time on Jan Mayen From: Rives McDow To: Steffen Thorsen , ietf Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id NAA29567 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 NAA29571 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA09488 All, I have communicated with the Norwegian Polar Institute since 1994, at which time they said that Jan Mayen used the same time as Norway, including daylight saving time. I'll write them to see if they have any historical data. Sincerely, Rives McDow >> The question is if Whitman's observation for Jan Mayen Island was >> correct earlier, in that case we will have to reuse parts of the first >> definition. Although EGT is a bit misleading perhaps because East >> Greenland (Scoresbysund) is using EU rules with DST, which might not >> coincide with what Jan Mayen had. I suggest that this needs to be >> investigated a bit further (hint, hint, I will probably not do it :) > > I've tried to research this a bit further, using a public available law > resource for Norway, http://www.lovdata.no (links are in Norwegian) > > Although I could not find it explicitly, it seems that Jan Mayen and > Svalbard have been using the same time as Norway at least since the time > they were declared as parts of Norway: > > Svalbard was declared as a part of Norway by law of 1925-07-17 no 11, § 4 > and Jan Mayen by law of 1930-02-27 no 2, § 2. > (From http://www.lovdata.no/all/nl-19250717-011.html and > http://www.lovdata.no/all/nl-19300227-002.html ) > > The law/regulation for normal/standard time in Norway is from 1894-06-29 > no 1 (came into operation on 1895-01-01) and Svalbard/Jan Mayen > seem to be a part of this law since 1925/1930. > (From http://www.lovdata.no/all/nl-18940629-001.html ) > > I have not been able to find if Jan Mayen used a different time zone (e.g.. > -0100) before 1930. Jan Mayen has only been "inhabitated" since 1921 > by Norwegian meteorologists and maybe used the same time as Norway ever > since 1921... > > Svalbard (Arctic/Longyearbyen) has been inhabited since before 1895, and > therefore probably changed the local time somewhere between 1895 and 1925 > (inclusive). > > Best regards, > Steffen > > -- > Steffen Thorsen > http://www.thorsen.priv.no > From owner-ietf-calendar@mail.imc.org Wed May 2 08:17:01 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07390 for ; Wed, 2 May 2001 08:17:00 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA15230 for ietf-calendar-bks; Wed, 2 May 2001 04:55:34 -0700 (PDT) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA15224 for ; Wed, 2 May 2001 04:55:32 -0700 (PDT) Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.136.193.32]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 1C6681ED for ; Wed, 2 May 2001 13:55:20 +0200 (METDST) Received: from isar.bbn.hp.com (isar.bbn.hp.com [15.140.168.13]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id NAA08220 for ; Wed, 2 May 2001 13:55:31 +0200 (METDST) Received: from 15.140.168.13 by isar.bbn.hp.com (InterScan E-Mail VirusWall NT); Wed, 02 May 2001 13:55:30 +0200 (W. Europe Daylight Time) Received: by isar.bbn.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 13:55:30 +0200 Message-ID: From: "NITSCH,FRANK (HP-Germany,ex1)" To: "Ietf-Calendar (E-mail)" Subject: Overview for a Beginner... ;-) Date: Wed, 2 May 2001 13:55:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi calendar friends, first I'd like to introduce myself: my Name is Frank Nitsch and I'm working as a software engineer for Hewlett Packard in Germany. In one of our current projects we need to provide scheduling and calendaring capabilities. Our aim is to use a standardized data format and standardized protocols where possible. Fortunately it wasn't too hard to find the effort of IETF's calsch working group in the web and so I started reading the drafts and I had a look at some messages from this mailing list. After some documents and various information I found about calendaring and scheduling I'm now a bit confused. There are many different terms and topics that refuse to build a clear picture in my head... So could you please help me forming a good understanding about the connections of all this? 1. iCalendar vs. vCalendar ~~~~~~~~~~~~~~~~~~~~~~~~~~ iCalendar is the data format proposed by the submitted drafts if calsch, right? So why is a iCalendar object enclosed in vCalendar tags? I thought vCalendar was an effort of some companies in the past; aiming for kind of a standard in calendaring. Well, I guess iCalendar bases on vCalendar in several areas. Is this the reason for this "inheritance"? Is vCalendar "dead" resp. replaced by iCalendar? And when I read in this mailing list that Outlook would at least support to import vCalendar objects: does this really mean vCalendar objects or rather iCalendar objects (which do have this vCalendar tag)? 2. iCal vs. SKICal ~~~~~~~~~~~~~~~~~~ When I first found the web page about SKICal I thought it would be a proprietary implementation based on iCal. Then I've seen some discussions on this list about SKICal as an extension to iCal. What's SKICal's role in the game? As far as I understand SKICal is not a part or the submitted drafts at all, right? Are there any plans to incorporate SKICal into iCal? Could anybody give me an overview please? 3. iRIP vs. CAP ~~~~~~~~~~~~~~~ I didn't really get the difference between these both. I read on this list that the interest in iRIP was lowered during the past month. Does this mean that CAP will be the successor of iRIP? How do iRIP and CAP differ and what is similar? What will happen to both the future? 4. CAP vs. WCAP (iPlanet) ~~~~~~~~~~~~~~~~~~~~~~~~~ I found iPlanet's calendaring product and I noticed that they used a proprietary format/protocol named WCAP. Does anybody have knowledge about the main differences, enhancements and about future plans? Will it still be a proprietary thing or are there any efforts to derive CAP enhancement from WCAP? 5. iCalendar/CAP and XML ~~~~~~~~~~~~~~~~~~~~~~~~ I've seen that somebody has created a DTD for using iCalendar with XML. I've also seen that people here argued that not changing the format to XML would be better because it would possibly waeken iCal's chance to become a standard. We'd be extremely interested in an XML format for iCalendar. There are so many advantages in terms of parsing (many XML parser tools available etc.), communication (tools and busses which talk XML) etc. Does anybody in the working group or in this list use XML for iCalendar objects? Is there any new implementation of a DTD for iCalendar? Who would be interested in discussing this (again...)? 6. Applications and Implementations of iCalendar so far... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Is there a document maintaining a list of applications supporting iCalendar/CAP and maybe embedded implementations, commercial and free solutions/tools? In our case we'd be happy to have the chance to take/buy a solution we could embed in our implementation. Probably it wouldn't hurt if only a limited set of features would work. Not each complex recurrence rule is always required... (but I like the flexibility of 'em very much! How to express otherwise things like "3rd to last work day of a quarter"?) I found the "libical" project on the web but my first impression is that it mainly deals with handling calendar objects (formatting, parsing etc.). It's not at all a calendar store, right? That's all for today. I appreciate any help and explanation. Thank you for your effort! Frank -- ==================================================================== Frank Nitsch mailto:frank_nitsch@hp.com -------------------------------------------------------------------- Hewlett-Packard GmbH | http://www.hewlett-packard.de Mailstop ASM-NGP, Building B32/3M17 | HP-Telnet 777-2135 Herrenberger Strasse 110-140 | Phone (+49) 07031/14-2135 D-71034 Boeblingen | Fax (+49) 07031/14-8253 ==================================================================== Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus, Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081 ==================================================================== From owner-ietf-calendar@mail.imc.org Wed May 2 10:41:17 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13123 for ; Wed, 2 May 2001 10:41:16 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA25837 for ietf-calendar-bks; Wed, 2 May 2001 07:24:12 -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 HAA25831 for ; Wed, 2 May 2001 07:24: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 f42ENfv05893 for ; Wed, 2 May 2001 07:23:41 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GCPPBH00.K51 for ; Wed, 2 May 2001 07:23:41 -0700 Message-ID: <3AF01851.43C21C69@netscape.com> Date: Wed, 02 May 2001 07:23:13 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Attendee clarification Content-Type: multipart/mixed; boundary="------------5C405DC9D0580A7E7D6C2B57" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------5C405DC9D0580A7E7D6C2B57 Content-Type: multipart/alternative; boundary="------------8EA7D92F392295002953E0AE" --------------8EA7D92F392295002953E0AE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All, One point of confusion that came up at Calconnect 2 had to do with some parameters on ATTENDEE. In particular. Because it was an interop issue, I want to add something to iTIP to clarify how a reconfirmation is formatted under several circumstances. When an Organizer sends out an updated event and wants the Attendees to reconfirm, the ATTENDEE property looks like this (I'm only listing the relevant parameters, in general there will be more): ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@example.com When the Organizer sends out an updated version of the event and does not require the Attendees to confirm, it looks like this: ATTENDEE;RSVP=FALSE;ROLE=REQ-PARTICIPANT:mailto:b@example.com When sending an event to a non-participant (like the 'cc' recipients of an email message), it looks like this: ATTENDEE;RSVP=FALSE;ROLE=NON-PARTICIPANT:mailto:b@example.com Does this look correct? -Steve --------------8EA7D92F392295002953E0AE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All,

One point of confusion that came up at Calconnect 2 had to do with some parameters on ATTENDEE. In particular. Because it was an interop issue, I want to add something to iTIP to clarify how a reconfirmation is formatted under several circumstances.

When an Organizer sends out an updated event and wants the Attendees to reconfirm, the ATTENDEE property looks like this (I'm only listing the relevant parameters, in general there will be more):

ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@example.com
When the Organizer sends out an updated version of the event and does not require the Attendees to confirm, it looks like this:
ATTENDEE;RSVP=FALSE;ROLE=REQ-PARTICIPANT:mailto:b@example.com
When sending an event to a non-participant (like the 'cc' recipients of an email message), it looks like this:
ATTENDEE;RSVP=FALSE;ROLE=NON-PARTICIPANT:mailto:b@example.com
Does this look correct?

-Steve --------------8EA7D92F392295002953E0AE-- --------------5C405DC9D0580A7E7D6C2B57 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;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 --------------5C405DC9D0580A7E7D6C2B57-- From owner-ietf-calendar@mail.imc.org Wed May 2 12:54:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17080 for ; Wed, 2 May 2001 12:54:02 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA07333 for ietf-calendar-bks; Wed, 2 May 2001 09:26: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 JAA07327 for ; Wed, 2 May 2001 09:26:26 -0700 (PDT) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: "ietf-calendar@imc.org" Subject: Re: RDATEs in VTIMEZONEs MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Wed, 2 May 2001 12:35:40 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/02/2001 12:27:15 PM, Serialize complete at 05/02/2001 12:27:15 PM Content-Type: multipart/alternative; boundary="=_alternative 005A48EC85256A40_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A48EC85256A40_= Content-Type: text/plain; charset="us-ascii" Damon wrote on 05/01/2001 03:56:02 PM: > In RFC2445, pg 64 it says: > > Alternatively, the "RDATE" property can be used to define the onset > of the observance by giving the individual onset date and times. > "RDATE" in this usage MUST be specified as a local DATE-TIME value in > UTC time. > > Yet the example just below has: > > DTSTART:19971026T020000 > RDATE:19971026T020000 > > Here the RDATE is not a UTC time - it doesn't have a 'Z'. > It looks like a local 'wall clock' time, like DTSTART. > > > So which is it - local time or UTC? I'd prefer local time, as that > keeps it the same as the DTSTART and RRULE times. You are correct to note that this is indeed contradictory text and the answer is that the last part of the text is wrong. It should say "local time" and not "UTC time". Wait a minute... Hmm, now that I mull it over I can see why UTC actually may be a better answer though. I dont want, say, Los Angeles to incorrectly use 2AM PST/PDT as the shift time for New York who actually shifted at 2AM EST/EDT! The shift for New York occurs at 11PM PST/PDT the day before!!! So by using UTC it makes compensating for shifts in other TZs correct... I think the examples are wrong in that case... Damn, I need to get some caffine! Bruce PS: Are you sure thats p64? Its on p65 in my copy and the one in the offical RFC editors site... =========================================================================== 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 005A48EC85256A40_= Content-Type: text/html; charset="us-ascii"
Damon wrote on 05/01/2001 03:56:02 PM:
> In RFC2445, pg 64 it says:
>
>    Alternatively, the "RDATE" property can be used to define the onset
>    of the observance by giving the individual onset date and times.
>    "RDATE" in this usage MUST be specified as a local DATE-TIME value in
>    UTC time.
>
> Yet the example just below has:
>
>      DTSTART:19971026T020000
>      RDATE:19971026T020000
>
> Here the RDATE is not a UTC time - it doesn't have a 'Z'.
> It looks like a local 'wall clock' time, like DTSTART.
>
>
> So which is it - local time or UTC? I'd prefer local time, as that
> keeps it the same as the DTSTART and RRULE times.
You are correct to note that this is indeed contradictory text and the answer is that the last part of the text is wrong.  It should say "local time" and not "UTC time".

Wait a minute... Hmm, now that I mull it over I can see why UTC actually may be a better answer though.  I dont want, say, Los Angeles to incorrectly use 2AM PST/PDT as the shift time for New York who actually shifted at 2AM EST/EDT!  The shift for New York occurs at 11PM PST/PDT the day before!!!  So by using UTC it makes compensating for shifts in other TZs correct...

I think the examples are wrong in that case...  Damn, I need to get some caffine!

Bruce
PS: Are you sure thats p64?  Its on p65 in my copy and the one in the offical RFC editors site...
===========================================================================
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 005A48EC85256A40_=-- From owner-ietf-calendar@mail.imc.org Wed May 2 14:54:05 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20019 for ; Wed, 2 May 2001 14:54:04 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA16740 for ietf-calendar-bks; Wed, 2 May 2001 11:31:33 -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 LAA16734 for ; Wed, 2 May 2001 11:31:30 -0700 (PDT) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: CalSched IETF Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Wed, 2 May 2001 14:40:42 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/02/2001 02:32:20 PM, Serialize complete at 05/02/2001 02:32:20 PM Content-Type: multipart/alternative; boundary="=_alternative 0065BB6885256A40_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065BB6885256A40_= Content-Type: text/plain; charset="us-ascii" sman wrote on 05/02/2001 10:23:13 AM: > One point of confusion that came up at Calconnect 2 had to do with > some parameters on ATTENDEE. In particular. Because it was an > interop issue, I want to add something to iTIP to clarify how a > reconfirmation is formatted under several circumstances. The intent of RSVP is to convey the Organizers desire for a response to the Invitees. Since not all C&S systems support a mechanism of selectively asking for RSVPs (or do not support 'em at all) we could not say "If RSVP=TRUE then the ATTTENDEE MUST send back a reply of some kind. If RSVP=FALSE then the ATTENDEE MUST NOT send back a reply of some kind." This lack of a feature was also why FALSE was selected as the default (so that less robust systems did not have to add it for every msg). So, the way that TRUE and FALSE should be interpreted is this: TRUE: The Organizer wants some kind of a response back (eventually) so the ATTENDEE SHOULD send back a reply when their PART-STAT changes (or they want to COUNTER) or if their ATTENDEE info/settings are not the same as the ones the Organzier sent; assuming they support the workflow model of REPLY, etc. Obviously this cannot be a MUST since those recipients w/non RSVP supporting systems cannot. Perhaps we need to make it a MUST feature for those that support the concept and a SHOULD for those that do not but Im not sure if that is Kosher to do in an RFC... FALSE: The Organizer does not want any kind of response back in response to the message so the ATTENDEE SHOULD NOT send back any kind of reply. WRT to Steves examples I think they are close but not quite correct. It is not possible to distinguish between "I never want to hear a response back from you" and "I do not want a response from you _for this message only_". That is, the Organizer does not care to really hear from you on a minor update (ie: a typo fix somewhere) but they DO want to hear back if you plan to attend or not. Since the Organizer sent an RSVP=FALSE on the typo change, the ATTENDEE has no way to know if that is a permanent change or not to their RSVP setting. As such, the ATTENDEE would (MUST) not send back any further replys. This means that if the ATTENDEE later decides to ACCEPT or DECLINE, they MUST not send a REPLY back to the Organizer. I do not think that this was Steves intent. This is also why the interpretation of TRUE includes the bit about differing ATTENDEE info/parameters. It could be that the Organizer never got my REPLY where I accepted so this provides me a hint that I may need to resend my acceptance notice. It may be that the Organizer did not (yet) get the delegation notice I sent 3 days ago so I need to resend it. I think you see the motivation why. Guess we need some better wordsmithing to codify this intent in the next update. Anyone have concerns/questions about this clarifcation? Oh yes, one extra tidbit we can include here. For ROLE=NON-PARTICIPANT the RSVP setting SHOULD be ignored (or really should be set to FALSE always) since by definition they are not part of the scheduling process. Its a logical thing but I wanted to express it outright to make sure we agree on that too... 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 0065BB6885256A40_= Content-Type: text/html; charset="us-ascii"
sman wrote on 05/02/2001 10:23:13 AM:
> One point of confusion that came up at Calconnect 2 had to do with
> some parameters on ATTENDEE. In particular. Because it was an
> interop issue, I want to add something to iTIP to clarify how a
> reconfirmation is formatted under several circumstances.

The intent of RSVP is to convey the Organizers desire for a response to the Invitees.  Since not all C&S systems support a mechanism of selectively asking for RSVPs (or do not support 'em at all) we could not say "If RSVP=TRUE then the ATTTENDEE MUST send back a reply of some kind.  If RSVP=FALSE then the ATTENDEE MUST NOT send back a reply of some kind."  This lack of a feature was also why FALSE was selected as the default (so that less robust systems did not have to add it for every msg).

So, the way that TRUE and FALSE should be interpreted is this:

TRUE: The Organizer wants some kind of a response back (eventually) so the ATTENDEE SHOULD send back a reply when their PART-STAT changes (or they want to COUNTER) or if their ATTENDEE info/settings are not the same as the ones the Organzier sent; assuming they support the workflow model of REPLY, etc.  Obviously this cannot be a MUST since those recipients w/non RSVP supporting systems cannot.  Perhaps we need to make it a MUST feature for those that support the concept and a SHOULD for those that do not but Im not sure if that is Kosher to do in an RFC...

FALSE: The Organizer does not want any kind of response back in response to the message so the ATTENDEE SHOULD NOT send back any kind of reply.  

WRT to Steves examples I think they are close but not quite correct.  It is not possible to distinguish between "I never want to hear a response back from you" and "I do not want a response from you _for this message only_".  That is, the Organizer does not care to really hear from you on a minor update (ie: a typo fix somewhere) but they DO want to hear back if you plan to attend or not.  Since the Organizer sent an RSVP=FALSE on the typo change, the ATTENDEE has no way to know if that is a permanent change or not to their RSVP setting.  As such, the ATTENDEE would (MUST) not send back any further replys.  This means that if the ATTENDEE later decides to ACCEPT or DECLINE, they MUST not send a REPLY back to the Organizer.  I do not think that this was Steves intent.

This is also why the interpretation of TRUE includes the bit about differing ATTENDEE info/parameters.  It could be that the Organizer never got my REPLY where I accepted so this provides me a hint that I may need to resend my acceptance notice.  It may be that the Organizer did not (yet) get the delegation notice I sent 3 days ago so I need to resend it.  I think you see the motivation why.

Guess we need some better wordsmithing to codify this intent in the next update.  Anyone have concerns/questions about this clarifcation?

Oh yes, one extra tidbit we can include here.  For ROLE=NON-PARTICIPANT the RSVP setting SHOULD be ignored (or really should be set to FALSE always) since by definition they are not part of the scheduling process.  Its a logical thing but I wanted to express it outright to make sure we agree on that too...

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 0065BB6885256A40_=-- From owner-ietf-calendar@mail.imc.org Wed May 2 15:26:07 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20831 for ; Wed, 2 May 2001 15:26:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA17860 for ietf-calendar-bks; Wed, 2 May 2001 12:05:24 -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 MAA17855 for ; Wed, 2 May 2001 12:05:21 -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 PAA14659; Wed, 2 May 2001 15:04:52 -0400 Message-ID: <3AF05989.A641F6E1@ximian.com> Date: Wed, 02 May 2001 15:01:29 -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: Bruce_Kahn@iris.com CC: "ietf-calendar@imc.org" Subject: Re: RDATEs in VTIMEZONEs 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: > Wait a minute... Hmm, now that I mull it over I can see why UTC > actually may be a better answer though. I dont want, say, Los Angeles > to incorrectly use 2AM PST/PDT as the shift time for New York who > actually shifted at 2AM EST/EDT! The shift for New York occurs at > 11PM PST/PDT the day before!!! So by using UTC it makes compensating > for shifts in other TZs correct... I'm not sure I understand the problem. I don't think the VTIMEZONE should be interpreted in any other timezone. A local RDATE would mean using the UTC offset that is in effect before the time change (i.e. from the other components in the VTIMEZONE). DTSTART values must be local times in VTIMEZONES as well. Damon > PS: Are you sure thats p64? Its on p65 in my copy and the one in the > offical RFC editors site... My fault. I was assuming the page numbers were at the top of the pages. Maybe a separator '---------' between pages would be handy. From owner-ietf-calendar@mail.imc.org Wed May 2 15:26:46 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20855 for ; Wed, 2 May 2001 15:26:45 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA18053 for ietf-calendar-bks; Wed, 2 May 2001 12:14: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 MAA18049 for ; Wed, 2 May 2001 12:14:57 -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 PAA28559 for ; Wed, 2 May 2001 15:14:29 -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 f42JESP04719 for ; Wed, 2 May 2001 15:14:28 -0400 (EDT) Message-Id: <5.0.0.25.0.20010502151147.02216aa0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 02 May 2001 15:12:55 -0400 To: CalSched IETF From: Alan Davies Subject: Re: Attendee clarification In-Reply-To: <3AF01851.43C21C69@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Looks correct to me. This seems to me to be the correct use of RSVP and ROLE. There was some discussion though about the intention of RSVP=FALSE, RFC2445 4.2.17 defines the purpose of RSVP as Purpose: To specify whether there is an expectation of a favor of a reply from the calendar user specified by the property value. I take this to mean that RSVP=TRUE implies that a REPLY should be sent by the ATTENDEE straight away, whereas RSVP=FALSE leaves the decision up to the ATTENDEE- they are still allowed to REPLY (e.g. if they change their attendance status), but are not required to. Does anyone disagree with this? --Alan At 07:23 2001-05-02 -0700, Steve Mansour wrote: >Hey All, > >One point of confusion that came up at Calconnect 2 had to do with some >parameters on ATTENDEE. In particular. Because it was an interop issue, I >want to add something to iTIP to clarify how a reconfirmation is formatted >under several circumstances. > >When an Organizer sends out an updated event and wants the Attendees to >reconfirm, the ATTENDEE property looks like this (I'm only listing the >relevant parameters, in general there will be more): >ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@example.com > >When the Organizer sends out an updated version of the event and does not >require the Attendees to confirm, it looks like this: >ATTENDEE;RSVP=FALSE;ROLE=REQ-PARTICIPANT:mailto:b@example.com > >When sending an event to a non-participant (like the 'cc' recipients of an >email message), it looks like this: >ATTENDEE;RSVP=FALSE;ROLE=NON-PARTICIPANT:mailto:b@example.com > >Does this look correct? > >-Steve From owner-ietf-calendar@mail.imc.org Wed May 2 18:34:53 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25477 for ; Wed, 2 May 2001 18:34:52 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA00600 for ietf-calendar-bks; Wed, 2 May 2001 15:22:03 -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 PAA00596 for ; Wed, 2 May 2001 15:22:01 -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 f42MLWv13526 for ; Wed, 2 May 2001 15:21:32 -0700 (PDT) Received: from netscape.com ([192.18.125.198]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GCQBFW00.207; Wed, 2 May 2001 15:21:32 -0700 Message-ID: <3AF0890B.B139BA02@netscape.com> Date: Wed, 02 May 2001 15:24:11 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: CalSched IETF Subject: Re: Attendee clarification References: Content-Type: multipart/mixed; boundary="------------168F0D740D78B62FA5890E48" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------168F0D740D78B62FA5890E48 Content-Type: multipart/alternative; boundary="------------158090A3842858DB48F13845" --------------158090A3842858DB48F13845 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > WRT to Steves examples I think they are close but not quite correct. > It is not possible to distinguish between "I never want to hear a > response back from you" and "I do not want a response from you _for > this message only_". That is, the Organizer does not care to really > hear from you on a minor update (ie: a typo fix somewhere) but they DO > want to hear back if you plan to attend or not. Since the Organizer > sent an RSVP=FALSE on the typo change, the ATTENDEE has no way to know > if that is a permanent change or not to their RSVP setting. As such, > the ATTENDEE would (MUST) not send back any further replys. This > means that if the ATTENDEE later decides to ACCEPT or DECLINE, they > MUST not send a REPLY back to the Organizer. I do not think that this > was Steves intent. actually, this was exactly the issue I was going to bring up. But I wanted to see everyone's response. If you invite me to a meeting, my ATTENDEE line for that request looks like this: ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:sman@netscape.com Then you send out a fix to a typo and you don't want me to reply, my Attendee line looks something like this: ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE:mailto:sman@netscape.com But if I want to decline the invitation at some point after I receive the typo fix, I should be able to do so. So, how can I do it? If RSVP is FALSE, it seems to me that the attendee must not send a reply. Yet that was not the Organizer's intent. So, when an attendee stores this info in their calendar, do they change RSVP to TRUE? Or leave it at FALSE? Does anyone see a good way to deal with this? Is there another parameter that helps? > Guess we need some better wordsmithing to codify this intent in the > next update. Anyone have concerns/questions about this clarifcation? I'm not sure I saw a clarification. Did you clarify a solution to this issue? > Oh yes, one extra tidbit we can include here. For > ROLE=NON-PARTICIPANT the RSVP setting SHOULD be ignored (or really > should be set to FALSE always) since by definition they are not part > of the scheduling process. Its a logical thing but I wanted to > express it outright to make sure we agree on that too... agreed. Initially I was thinking that ROLE might play a part in clarifying things. I don't believe it does. -Steve --------------158090A3842858DB48F13845 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

WRT to Steves examples I think they are close but not quite correct.  It is not possible to distinguish between "I never want to hear a response back from you" and "I do not want a response from you _for this message only_".  That is, the Organizer does not care to really hear from you on a minor update (ie: a typo fix somewhere) but they DO want to hear back if you plan to attend or not.  Since the Organizer sent an RSVP=FALSE on the typo change, the ATTENDEE has no way to know if that is a permanent change or not to their RSVP setting.  As such, the ATTENDEE would (MUST) not send back any further replys.  This means that if the ATTENDEE later decides to ACCEPT or DECLINE, they MUST not send a REPLY back to the Organizer.  I do not think that this was Steves intent.
actually, this was exactly the issue I was going to bring up.  But I wanted to see everyone's response.

If you invite me to a meeting, my ATTENDEE line for that request looks like this:

ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:sman@netscape.com
Then you send out a fix to a typo and you don't want me to reply, my Attendee line looks something like this:
ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE:mailto:sman@netscape.com
But if I want to decline the invitation at some point after I receive the typo fix, I should be able to do so.
So, how can I do it?  If RSVP is FALSE, it seems to me that the attendee must not send a reply. Yet that was not the Organizer's intent.  So, when an attendee stores this info in their calendar, do they change RSVP to TRUE?  Or leave it at FALSE?

Does anyone see a good way to deal with this?  Is there another parameter that helps?

Guess we need some better wordsmithing to codify this intent in the next update.  Anyone have concerns/questions about this clarifcation?
I'm not sure I saw a clarification.  Did you clarify a solution to this issue?
Oh yes, one extra tidbit we can include here.  For ROLE=NON-PARTICIPANT the RSVP setting SHOULD be ignored (or really should be set to FALSE always) since by definition they are not part of the scheduling process.  Its a logical thing but I wanted to express it outright to make sure we agree on that too...
agreed.  Initially I was thinking that ROLE might play a part in clarifying things. I don't believe it does.

-Steve --------------158090A3842858DB48F13845-- --------------168F0D740D78B62FA5890E48 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------168F0D740D78B62FA5890E48-- From owner-ietf-calendar@mail.imc.org Wed May 2 20:06:48 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26794 for ; Wed, 2 May 2001 20:06:47 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA05231 for ietf-calendar-bks; Wed, 2 May 2001 16:28:36 -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 QAA05225 for ; Wed, 2 May 2001 16:28:34 -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 TAA16795 for ; Wed, 2 May 2001 19:28:22 -0400 Message-ID: <3AF0974B.8B7D0886@ximian.com> Date: Wed, 02 May 2001 19:24:59 -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: "ietf-calendar@imc.org" Subject: VTIMEZONE conflicts - possible solution 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 Here's my best idea yet for solving the VTIMEZONE TZID conflicts issue: o All the events that a CUA creates itself are placed inside one VCALENDAR component, together with all the VTIMEZONES that are used. o Events that come in externally, either via iTIP or from importing iCalendar data, are placed in separate VCALENDAR components, so they can simply keep whatever VTIMEZONEs they come with. o The CUA uses a property of some kind on the VCALENDAR, e.g. "X-EVOLUTION-VTIMEZONES-VERSION:1.2" to identify the version of the builtin VTIMEZONES used within that VCALENDAR. So when it wants to create more events it knows which VCALENDAR to add them to. This would totally avoid the clashing TZID issue, even when the VTIMEZONEs in the CUA get updated. (It would simply create a new VCALENDAR with a different X-EVOLUTION-VTIMEZONES-VERSION.) It also means we don't need to define some new URL-like syntax for TZIDs (which I still think is a bad idea by the way!) Damon From owner-ietf-calendar@mail.imc.org Thu May 3 13:32:48 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01166 for ; Thu, 3 May 2001 13:32:47 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA23294 for ietf-calendar-bks; Thu, 3 May 2001 10:16:11 -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 KAA23289 for ; Thu, 3 May 2001 10:16:10 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f43HFqN20400; Thu, 3 May 2001 10:15:53 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 3 May 2001 10:15:52 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Damon Chaplin cc: "ietf-calendar@imc.org" Subject: Re: VTIMEZONE conflicts - possible solution In-Reply-To: <3AF0974B.8B7D0886@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 Wed, 2 May 2001, Damon Chaplin wrote: > > Here's my best idea yet for solving the VTIMEZONE TZID conflicts issue: > > o All the events that a CUA creates itself are placed inside one... > o Events that come in externally, either via iTIP or from importing... > o The CUA uses a property of some kind on the VCALENDAR,... OK, you can certainly do this. These are implementation choices, and an implementation can store data any way it wants to. But, since these proposals affect the storage model, they wouldn't be something we could add to the RFC, and we still should have a specification level solution. > It also means we don't need to define some new URL-like syntax for > TZIDs (which I still think is a bad idea by the way!) I am not fond of the URI-like syntax either -- I think that either it should be a URI or it shouldn't be. I just want to require that TZIDs that begin with a "/" are globally unique, like in a UID or a PRODID. Here is my proposal again: ------------------------------------------------------------------------------ The presence of the SOLIDUS character ( US-ASCII 47) as a prefix indicates that 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 ------------------------------------------------------------------------------ Note that if the sender does not use a TZID with a '/', then the recipient may have to tackle the problem of timezone conflicts itself. In that case, I'd suggest that the CUA uses a variant of your re-naming scheme as a fallback. Maybe it would rename the tmezone to include the organizer's name, the PRODID of the EVENT that the organizer sent, and a version number that it determined from comparing the timezone data. Thus you might change: /America/Los_Angeles to /bob@example.com/ABC Corp/1/America/Los_Angeles Now you have a result similar to if the sender had used the global form -- the TZID is unique and you don't have to store multiple copies of them if they are all the same. So, our two ideas are not exclusive; I'm proposing a spec-level solution, and you are proposing implementation-level solutions. Both can be implemented with no loss to either. eric. From owner-ietf-calendar@mail.imc.org Thu May 3 14:03:11 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02083 for ; Thu, 3 May 2001 14:03:09 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA25776 for ietf-calendar-bks; Thu, 3 May 2001 10:46:37 -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 KAA25771 for ; Thu, 3 May 2001 10:46:36 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f43HkGn20451; Thu, 3 May 2001 10:46:17 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 3 May 2001 10:46:15 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Bruce_Kahn@iris.com cc: Alan Davies , 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, 1 May 2001 Bruce_Kahn@iris.com wrote: > I think that Erics current proposal is NOT that the bogus defintions would > be propigated but rather that each app would encode the TZ information > from its own internal table of TZ definitions. Exactly. A CUA will use its own TZ database for outgoing messages, not the VTIMEZONES that is collects in its calendar. To do otherwise would result in a nasty Internet-wide bootstrapping problem. The only VTIMEZONES that should get into the victim's calendar are those that have TZIDs that are not already in the calendar -- if the CUA expects all TZIDs of the same value to map to the same VTIMEZONE, then it should choose to keep only the first one it receives, not the last. Recap of the problem we are discussing, as I understand it: Maillicious CUA sends an event with a VTIMEZONE that contains a TZID that conflicts with ( or will conflict with ) another TZID in the victim's calendar In order for this attack to work: 1) The attacker has to guess what timezones the recipient will receive and from what timezone database the VTIMEZONES will be created. For each attack message, the attacker would have to choose a TZID with a vendor name, a timezone name, a timezone version, and possibly a vendor database name, and all of those must map to at TZID that the victim will eventually use in the future. 2) The attacker must be the first to send the victim such a VTIMEZONE 3) The victim has to book the incoming attack event in the calendar. What is the payoff for the attacker? The victim might show up late for a few meetings. That's not going to get the crackers, script kiddies and disgruntled IT techs excited. If a CUA implementer does want to tackle to problem, they just need to compare incoming VTIMEZONES to ones with the same TZID in the calendar and issue a notice if there is a difference. So, we've got an extremely unlikely attack that has a small payoff and a simple fix. I really don't think we need to worry about this. eric. From owner-ietf-calendar@mail.imc.org Thu May 3 15:09:45 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04351 for ; Thu, 3 May 2001 15:09:44 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA00307 for ietf-calendar-bks; Thu, 3 May 2001 11:57:27 -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 LAA00301 for ; Thu, 3 May 2001 11:57:25 -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 OAA11209; Thu, 3 May 2001 14:57:08 -0400 Message-ID: <3AF1A935.9FE6D19A@ximian.com> Date: Thu, 03 May 2001 14:53:41 -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: VTIMEZONE conflicts - possible solution 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 Wed, 2 May 2001, Damon Chaplin wrote: > > > > > Here's my best idea yet for solving the VTIMEZONE TZID conflicts issue: > > > > o All the events that a CUA creates itself are placed inside one... > > o Events that come in externally, either via iTIP or from importing... > > o The CUA uses a property of some kind on the VCALENDAR,... > > OK, you can certainly do this. These are implementation choices, and an > implementation can store data any way it wants to. But, since these > proposals affect the storage model, they wouldn't be something we could > add to the RFC, and we still should have a specification level solution. My proposed solution can easily be turned into a spec-level solution. Just say that a VCALENDAR is a way to group components which share a set of VTIMEZONEs. And give guidelines for handling data from external sources. I think if we can avoid the possibility of security problems we should. Damon From owner-ietf-calendar@mail.imc.org Thu May 3 15:56:28 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06613 for ; Thu, 3 May 2001 15:56:27 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA01373 for ietf-calendar-bks; Thu, 3 May 2001 12:38: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 MAA01369 for ; Thu, 3 May 2001 12:38:48 -0700 (PDT) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: ietf-calendar@imc.org Subject: Re: RDATEs in VTIMEZONEs MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Thu, 3 May 2001 15:39:33 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/03/2001 03:47:59 PM, Serialize complete at 05/03/2001 03:47:59 PM Content-Type: multipart/alternative; boundary="=_alternative 006BE7EB85256A41_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006BE7EB85256A41_= Content-Type: text/plain; charset="us-ascii" damon@ximian.com wrote on 05/02/2001 03:01:29 PM: > > Wait a minute... Hmm, now that I mull it over I can see why UTC > > actually may be a better answer though. I dont want, say, Los Angeles > > to incorrectly use 2AM PST/PDT as the shift time for New York who > > actually shifted at 2AM EST/EDT! The shift for New York occurs at > > 11PM PST/PDT the day before!!! So by using UTC it makes compensating > > for shifts in other TZs correct... > > I'm not sure I understand the problem. > Ok, Ill go for the graphical explaination to see if that helps. I have a VTIMEZONE that is: BEGIN:VTIMEZONE TZID:US-Eastern LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:20001026T020000 RDATE:20011026T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD BEGIN:DAYLIGHT DTSTART:20001026T020000 RDATE:20010401T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT END:VTIMEZONE The times are in local since the changes are relative to that TZ, not to any other TZ. That is to say, New York City shifts at 2AM on 01-Apr-2001 WRT NYC's local time; NOT at 2AM LA time. Yes? As such an LA CUA would have to be able to look at a local DTSTART;TZID=US-Eastern and map it (using the VTIMEZONES) to LAs time. If both the LA and NYC VTIMEZONES were in local time then the CUA has to do extra work to match the LA shifted date/times with the NYC shift before it can finally decide what the actual LA occurance time actually is. In concrete terms: a 01:59 01-Apr-01 NYC event begins at 22:59 30-Mar-01 LA time but a 03:01 01-Apr-01 NCY event begins at 23:01 30-Mar-01. In LA only 2 minutes have passed but in NYC 62 have. If the VTIMEZONE info was in UTC then it becomes a quicker action for the CUA to detect this. The CUA in LA will have to convert the NYC relative TZ info to UTC and then use that to convert the actual entry date/time to UTC and then convert again to LA relative time (or just keep it at UTC so that it can apply its own TZ shifts accordingly too). So, since all CUAs will have to do the "convert XYZ relative TZ info to UTC", why not simplify their load and just have the TZ info in UTC already?... > I don't think the VTIMEZONE should be interpreted in any other timezone. > A local RDATE would mean using the UTC offset that is in effect before > the time change (i.e. from the other components in the VTIMEZONE). > > DTSTART values must be local times in VTIMEZONES as well. A VTIMEZONE must be interpretable in other time zones otherwise it would not be feasible to use them to schedule, say, a conference call between myself, Frank (in Dallas) and Steve (in San Jose) since we are all in different TZs. Conveying the TZ information just w/in the zone is not that useful since all the CUAs in that TZ probably have the same settings (unless you are scheduling between, say, Arizona and Nevada). From 2445, p62: Interoperability between two calendaring and scheduling applications, especially for recurring events, to-dos or journal entries, is dependent on the ability to capture and convey date and time information in an unambiguous format. Which is less ambiguous: UTC or a relative date/time? Id say UTC is the least amiguous since relative date/times require knowledge of their source TZ. Having to swap back and forth between deep issues like this and real work is more than a bit distracting so if Im way off on some rationale I expect Frank or Steve to whack me up-side the head and say "You forgot the case of..." and all will be better. Ya know, it all seemed logical before that Reefknot talk on Tuesday... ;^) 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 006BE7EB85256A41_= Content-Type: text/html; charset="us-ascii"
damon@ximian.com wrote on 05/02/2001 03:01:29 PM:
> > Wait a minute... Hmm, now that I mull it over I can see why UTC
> > actually may be a better answer though.  I dont want, say, Los Angeles
> > to incorrectly use 2AM PST/PDT as the shift time for New York who
> > actually shifted at 2AM EST/EDT!  The shift for New York occurs at
> > 11PM PST/PDT the day before!!!  So by using UTC it makes compensating
> > for shifts in other TZs correct...
>
> I'm not sure I understand the problem.
>

Ok, Ill go for the graphical explaination to see if that helps.  I have a VTIMEZONE that is:

BEGIN:VTIMEZONE
TZID:US-Eastern
LAST-MODIFIED:19870101T000000Z
BEGIN:STANDARD
DTSTART:20001026T020000
RDATE:20011026T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20001026T020000
RDATE:20010401T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE

The times are in local since the changes are relative to that TZ, not to any other TZ.  That is to say, New York City shifts at 2AM on 01-Apr-2001 WRT NYC's local time; NOT at 2AM LA time.  Yes?  As such an LA CUA would have to be able to look at a local DTSTART;TZID=US-Eastern and map it (using the VTIMEZONES) to LAs time.  If both the LA and NYC VTIMEZONES were in local time then the CUA has to do extra work to match the LA shifted date/times with the NYC shift before it can finally decide what the actual LA occurance time actually is.

In concrete terms: a 01:59 01-Apr-01 NYC event begins at 22:59 30-Mar-01 LA time but a 03:01 01-Apr-01 NCY event begins at 23:01 30-Mar-01.  In LA only 2 minutes have passed but in NYC 62 have.  If the VTIMEZONE info was in UTC then it becomes a quicker action for the CUA to detect this.  The CUA in LA will have to convert the NYC relative TZ info to UTC and then use that to convert the actual entry date/time to UTC and then convert again to LA relative time (or just keep it at UTC so that it can apply its own TZ shifts accordingly too).  So, since all CUAs will have to do the "convert XYZ relative TZ info to UTC", why not simplify their load and just have the TZ info in UTC already?...

> I don't think the VTIMEZONE should be interpreted in any other timezone.
> A local RDATE would mean using the UTC offset that is in effect before
> the time change (i.e. from the other components in the VTIMEZONE).
>
> DTSTART values must be local times in VTIMEZONES as well.
A VTIMEZONE must be interpretable in other time zones otherwise it would not be feasible to use them to schedule, say, a conference call between myself, Frank (in Dallas) and Steve (in San Jose) since we are all in different TZs.  Conveying the TZ information just w/in the zone is not that useful since all the CUAs in that TZ probably have the same settings (unless you are scheduling between, say, Arizona and Nevada).  From 2445, p62:

   Interoperability between two calendaring and scheduling applications,
  especially for recurring events, to-dos or journal entries, is
  dependent on the ability to capture and convey date and time
  information in an unambiguous format.

Which is less ambiguous: UTC or a relative date/time?  Id say UTC is the least amiguous since relative date/times require knowledge of their source TZ.

Having to swap back and forth between deep issues like this and real work is more than a bit distracting so if Im way off on some rationale I expect Frank or Steve to whack me up-side the head and say "You forgot the case of..." and all will be better.  Ya know, it all seemed logical before that Reefknot talk on Tuesday... ;^)

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 006BE7EB85256A41_=-- From owner-ietf-calendar@mail.imc.org Thu May 3 16:04:34 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07256 for ; Thu, 3 May 2001 16:04:34 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA01945 for ietf-calendar-bks; Thu, 3 May 2001 12:52: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 MAA01941 for ; Thu, 3 May 2001 12:52:38 -0700 (PDT) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: CalSched IETF Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Thu, 3 May 2001 15:53:23 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/03/2001 04:01:49 PM, Serialize complete at 05/03/2001 04:01:49 PM Content-Type: multipart/alternative; boundary="=_alternative 006D2C0F85256A41_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D2C0F85256A41_= Content-Type: text/plain; charset="us-ascii" Steve wrote on 05/02/2001 06:24:11 PM: > But if I want to decline the invitation at some point after I > receive the typo fix, I should be able to do so. Hang on. How do you know that the Organizer still wants any kind of reply from you since they told you RSVP=FALSE? You assuming that the FALSE only applied to the 'update'?? Can't do that since every REQUEST is a full snapshot of the event so any settings in the 'older' copies are no longer applicable; only the settings in the 'newest' copy should be used. (Sure, any CUA can violate the concept of the most recent copy is the only one to act on but A) thats not good form and B) its not what the CUs would expect of a CUA.) > So, how can I do it? If RSVP is FALSE, it seems to me that the > attendee must not send a reply. Yet that was not the Organizer's > intent. Again, are you psychic? Can you truely devine the Organizers intent from a simple "Yes/No" setting that was changed? The Organzier may have decided that they really do not want to hear back from you... > So, when an attendee stores this info in their calendar, do > they change RSVP to TRUE? Or leave it at FALSE? Since the latest REQUEST is a full snapshot of the invitation, the setting gets saved w/the latest value: FALSE. > Does anyone see a good way to deal with this? See my codifying text as to when a reply should be sent from the ATTENDEE in my original reply. In a nutshell: It is not automagically sent upon receipt of the REQUEST, it is sent on change of status (ie: accepting, declining, etc) or upon delegation (or if the REQUEST has ATTENDEE specific values/properties that differ from the ATTENDEEs copy as in they passed in the mail or the Organizer never got it). > Is there another > parameter that helps? Nope. > I'm not sure I saw a clarification. Did you clarify a solution to > this issue? Reread my posting beginning at "So, the way that TRUE and FALSE should be interpreted is this: " Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D2C0F85256A41_= Content-Type: text/html; charset="us-ascii"
Steve wrote on 05/02/2001 06:24:11 PM:
> But if I want to decline the invitation at some point after I
> receive the typo fix, I should be able to do so.

Hang on.  How do you know that the Organizer still wants any kind of reply from you since they told you RSVP=FALSE?  

You assuming that the FALSE only applied to the 'update'??  Can't do that since every REQUEST is a full snapshot of the event so any settings in the 'older' copies are no longer applicable; only the settings in the 'newest' copy should be used.  (Sure, any CUA can violate the concept of the most recent copy is the only one to act on but A) thats not good form and B) its not what the CUs would expect of a CUA.)

> So, how can I do it?  If RSVP is FALSE, it seems to me that the
> attendee must not send a reply. Yet that was not the Organizer's
> intent.

Again, are you psychic?  Can you truely devine the Organizers intent from a simple "Yes/No" setting that was changed?  The Organzier may have decided that they really do not want to hear back from you...

>      So, when an attendee stores this info in their calendar, do
> they change RSVP to TRUE?  Or leave it at FALSE?

Since the latest REQUEST is a full snapshot of the invitation, the setting gets saved w/the latest value: FALSE.

> Does anyone see a good way to deal with this?  

See my codifying text as to when a reply should be sent from the ATTENDEE in my original reply.  In a nutshell: It is not automagically sent upon receipt of the REQUEST, it is sent on change of status (ie: accepting, declining, etc) or upon delegation (or if the REQUEST has ATTENDEE specific values/properties that differ from the ATTENDEEs copy as in they passed in the mail or the Organizer never got it).

>                            Is there another
> parameter that helps?

Nope.

> I'm not sure I saw a clarification.  Did you clarify a solution to
> this issue?

Reread my posting beginning at "So, the way that TRUE and FALSE should be interpreted is this: "

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

--=_alternative 006D2C0F85256A41_=-- From owner-ietf-calendar@mail.imc.org Thu May 3 16:35:28 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09167 for ; Thu, 3 May 2001 16:35:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA04108 for ietf-calendar-bks; Thu, 3 May 2001 13:22:26 -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 NAA04103 for ; Thu, 3 May 2001 13:22:25 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f43KMKV20715; Thu, 3 May 2001 13:22:20 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 3 May 2001 13:22:19 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Damon Chaplin cc: "ietf-calendar@imc.org" Subject: Re: VTIMEZONE conflicts - possible solution In-Reply-To: <3AF1A935.9FE6D19A@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 Thu, 3 May 2001, Damon Chaplin wrote: > My proposed solution can easily be turned into a spec-level solution. > Just say that a VCALENDAR is a way to group components which share a > set of VTIMEZONEs. And give guidelines for handling data from external > sources. OK. Send some proposed text. eric. From owner-ietf-calendar@mail.imc.org Thu May 3 16:36:54 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09190 for ; Thu, 3 May 2001 16:36:53 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA03553 for ietf-calendar-bks; Thu, 3 May 2001 13:17:04 -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 NAA03539 for ; Thu, 3 May 2001 13:17:02 -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 QAA14388; Thu, 3 May 2001 16:16:40 -0400 Message-ID: <3AF1BBD9.88FC70ED@ximian.com> Date: Thu, 03 May 2001 16:13:13 -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: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: RDATEs in VTIMEZONEs 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: > The times are in local since the changes are relative to that TZ, not to any other TZ. That is to say, New York City shifts at 2AM on 01-Apr-2001 WRT NYC's local time; NOT at 2AM LA time. Yes? As such an LA CUA would have to be able to look at a local DTSTART;TZID=US-Eastern and map it (using the VTIMEZONES) to LAs time. If both the LA and NYC VTIMEZONES were in local time then the CUA has to do extra work to match the LA shifted date/times with the NYC shift before it can finally decide what the actual LA occurance time actually is. Oh, I see. You didn't really mean it would be incorrect to use local times. Just slower. I'm not sure if it makes enough difference to worry about. If you know what the UTC offset is it is pretty quick to switch back and forth from local to UTC time. I am more concerned with making sure we are compatable with Outlook (and maybe Notes). So I'd rather do whatever they do already. (Actually I'll probably add support for local and UTC times, to be sure.) Damon From owner-ietf-calendar@mail.imc.org Thu May 3 16:37:13 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09205 for ; Thu, 3 May 2001 16:37:12 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA03339 for ietf-calendar-bks; Thu, 3 May 2001 13:15: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 NAA03334 for ; Thu, 3 May 2001 13:15:35 -0700 (PDT) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: Eric Busboom , "ietf-calendar@imc.org" Subject: Re: VTIMEZONE conflicts - possible solution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_04222001 April 22, 2001 Message-ID: Date: Thu, 3 May 2001 16:16:04 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/03/2001 04:24:46 PM, Serialize complete at 05/03/2001 04:24:46 PM Content-Type: multipart/alternative; boundary="=_alternative 006F3FC185256A41_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F3FC185256A41_= Content-Type: text/plain; charset="us-ascii" Damon replied on 05/03/2001 02:53:41 PM: > My proposed solution can easily be turned into a spec-level solution. > Just say that a VCALENDAR is a way to group components which share a > set of VTIMEZONEs. Im not sure I like. If I want to include VEVENTs, VTODOs or VJOURNALs that are in UTC then I cannot also include them? It also smells like a model change and Ive very unkeen on that. It certainly wont be true of any currently shipping CUAs like Outlook, Lotus Organzier and possibly others... (That would mean possibly reving VERSION, ugh!!!) This proposal just sounds likes it pushing the version info from the TZID (Erics proposal) into a new property so where is the benefit of doing that? WRT: > o Events that come in externally, either via iTIP or from importing > iCalendar data, are placed in separate VCALENDAR components, so they > can simply keep whatever VTIMEZONEs they come with. I think this is really a messy CS/CUA storage issue that may not be something Id want to build. I (as a product) view a Calendar as a collection of entries no matter the vendor or TZ. W/this proposal I now have to segregate my entries into separate 'calendars' that are related simply by TZIDs. What does this buy me? Just lots of "which calendar is that #!^# UID in?!" agravation IMNHO. I dont think it makes interop any better/easier so what am I missing?? Bruce PS: Time to go get some food and raise my blood sugar levels so I can sound more coherent... =========================================================================== 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 006F3FC185256A41_= Content-Type: text/html; charset="us-ascii"
Damon replied on 05/03/2001 02:53:41 PM:
> My proposed solution can easily be turned into a spec-level solution.
> Just say that a VCALENDAR is a way to group components which share a
> set of VTIMEZONEs.

Im not sure I like.  If I want to include VEVENTs, VTODOs or VJOURNALs that are in UTC then I cannot also include them?  It also smells like a model change and Ive very unkeen on that.  It certainly wont be true of any currently shipping CUAs like Outlook, Lotus Organzier and possibly others... (That would mean possibly reving VERSION, ugh!!!)

This proposal just sounds likes it pushing the version info from the TZID (Erics proposal) into a new property so where is the benefit of doing that?  

WRT:
> o Events that come in externally, either via iTIP or from importing
>   iCalendar data, are placed in separate VCALENDAR components, so they
>   can simply keep whatever VTIMEZONEs they come with.

I think this is really a messy CS/CUA storage issue that may not be something Id want to build.  I (as a product) view a Calendar as a collection of entries no matter the vendor or TZ.  W/this proposal I now have to segregate my entries into separate 'calendars' that are related simply by TZIDs.  What does this buy me?   Just lots of "which calendar is that #!^# UID in?!" agravation IMNHO.  I dont think it makes interop any better/easier so what am I missing??

Bruce
PS: Time to go get some food and raise my blood sugar levels so I can sound more coherent...
===========================================================================
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 006F3FC185256A41_=-- From owner-ietf-calendar@mail.imc.org Fri May 4 10:39:33 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13458 for ; Fri, 4 May 2001 10:39:32 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA19333 for ietf-calendar-bks; Fri, 4 May 2001 07:25:15 -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 HAA19327 for ; Fri, 4 May 2001 07:25:13 -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 KAA23193 for ; Fri, 4 May 2001 10:24:44 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f44EOiP15379 for ; Fri, 4 May 2001 10:24:44 -0400 (EDT) Message-Id: <5.0.0.25.0.20010502182433.02205ba0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 04 May 2001 10:15:58 -0400 To: CalSched IETF From: Alan Davies Subject: Re: Attendee clarification In-Reply-To: <3AF0890B.B139BA02@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If Bruce's interpretation of RSVP is correct, there's not much difference between a REQ-PARTICIPANT with RSVP=FALSE and a NON-PARTICIPANT. The whole reason for REQUEST/REPLY/ROLE/RSVP/etc. is to allow interactive scheduling between CUAs, something that we're all working to achieve. We already have ways of scheduling without interaction (PUBLISH, NON-PARTICIPANT, etc.) RSVP should be able to strengthen the flow of information between Organiser and ATTENDEE, not weaken it. What Bruce is suggesting may be useful, but as far as I can see nothing in RFC2445 or RFC2446 implies that RSVP can be used to achieve this. Maybe RSVP should have 3 possible values- YES, NO, and DONT-CARE (DONT-CARE would leave the decision up to the ATTENDEE- the equivalent of Bruce's TRUE and Steve's FALSE.) --Alan At 15:24 2001-05-02 -0700, Steve Mansour wrote: >Bruce_Kahn@iris.com wrote: >>WRT to Steves examples I think they are close but not quite correct. It >>is not possible to distinguish between "I never want to hear a response >>back from you" and "I do not want a response from you _for this message >>only_". That is, the Organizer does not care to really hear from you on >>a minor update (ie: a typo fix somewhere) but they DO want to hear back >>if you plan to attend or not. Since the Organizer sent an RSVP=FALSE on >>the typo change, the ATTENDEE has no way to know if that is a permanent >>change or not to their RSVP setting. As such, the ATTENDEE would (MUST) >>not send back any further replys. This means that if the ATTENDEE later >>decides to ACCEPT or DECLINE, they MUST not send a REPLY back to the >>Organizer. I do not think that this was Steves intent. >actually, this was exactly the issue I was going to bring up. But I >wanted to see everyone's response. > >If you invite me to a meeting, my ATTENDEE line for that request looks >like this: >ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:sman@netscape.com > > >Then you send out a fix to a typo and you don't want me to reply, my >Attendee line looks something like this: >ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE:mailto:sman@netscape.com > > >But if I want to decline the invitation at some point after I receive the >typo fix, I should be able to do so. >So, how can I do it? If RSVP is FALSE, it seems to me that the attendee >must not send a reply. Yet that was not the Organizer's intent. So, when >an attendee stores this info in their calendar, do they change RSVP to >TRUE? Or leave it at FALSE? > >Does anyone see a good way to deal with this? Is there another parameter >that helps? From owner-ietf-calendar@mail.imc.org Fri May 4 15:16:28 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19449 for ; Fri, 4 May 2001 15:16:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA13245 for ietf-calendar-bks; Fri, 4 May 2001 11:52:45 -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 LAA13239 for ; Fri, 4 May 2001 11:52:44 -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 OAA07059; Fri, 4 May 2001 14:52:30 -0400 Message-ID: <3AF2F99B.250FCF3C@ximian.com> Date: Fri, 04 May 2001 14:48:59 -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: VTIMEZONE conflicts - possible solution 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: > For example: > TZID:=/TimezoneEmporium/America/New_York/1 If we do go with this, it would be useful to make it easy to separate out the actual timezone, e.g. 'America/New_York', so it can be displayed to the user. Remember that some Olson zones have 2 '/'s, e.g. 'America/Indiana/Marengo'. (Don't ask me why!) Damon From owner-ietf-calendar@mail.imc.org Sat May 5 00:05:34 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26811 for ; Sat, 5 May 2001 00:05:33 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id UAA23332 for ietf-calendar-bks; Fri, 4 May 2001 20:53:05 -0700 (PDT) Received: from mail.imc.org ([64.5.243.230]) by above.proper.com (8.9.3/8.9.3) with SMTP id UAA23220 for ; Fri, 4 May 2001 20:52:50 -0700 (PDT) Message-Id: <200105050352.UAA23220@above.proper.com> From: Paul.Risman@above.proper.com Date: Fri, 04 May 2001 23:51:34 To: ietf-calendar@imc.org Subject: Please read the following it could change your life MIME-Version: 1.0 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 If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. //////////////////////////////////////////////////////////// ONE TIME MAILING, NO NEED TO REMOVE //////////////////////////////////////////////////////////// This message is sent in compliance of the proposed bill SECTION 301. per Section 301, Paragraph (a)(2)(C) of S. 1618. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. Subject: Five Is The Key To My Freedom, It Could Be Yours Too. AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time THANK'S TO THE COMPUTER AGE AND THE INTERNET ! ================================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so gladI finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in." Pam Hedland, Fort Lee, New Jersey. =================================================== Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ====== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: =====Order all 5 reports shown on the list below ===== For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. Preferably use a word processor to type legibly these details and print on your printer. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work !!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ========================================================== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ========================================================== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4 .. $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGUREOUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ========================================================= REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ======================================================= Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and dd METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receivethe report. =========== AVAILABLE REPORTS ==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. Preferably use a word processor and your printer to do this. ================================================= PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================================ REPORT # 1: 'The Insider's Guide to Advertising for Free on the Net Order Report #1 from: Paul J. Risman P.O. Box 368 Tweed Ontario K0K 3J0 Canada _____________________________________________________________ REPORT # 2: The Insider's Guide to Sending Bulk e-mail on the Net Order Report # 2 from: PDP P.O. BOX 80572 185 10 PIRAEUS GREECE ____________________________________________________ REPORT # 3: Secret to Multilevel marketing on the net Order Report # 3 from: S.S. 32 Cross Street San Francisco, CA 94112 USA ________________________________________________________________ REPORT # 4: How to become a millionaire utilizing MLM& the Net Order Report # 4 from: Ada Ario 50 First Street, Suite I San Francisco, CA 94105 USA ________________________________________________________________ REPORT #5: How to send out 0ne Million emails for free Order Report # 5 From: Art Ano 146 McAllister Street,#103 San Francisco, CA 94102 USA ========================================================== ____________________________________________________________ $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ====================================================== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ============ MORE TESTIMONIALS ================ "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jodyaboutreceiving ''junk mail''. I made fun of the whole thing,spoutingmy knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ====================================================== ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ======================================================= ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, N.Y. ======================================================= ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thanx to internet.". Fred Dellaca, Westport, New Zealand ======================================================= ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR' ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. From owner-ietf-calendar@mail.imc.org Mon May 7 13:00:00 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16636 for ; Mon, 7 May 2001 12:59:59 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA13499 for ietf-calendar-bks; Mon, 7 May 2001 09:44:02 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13494 for ; Mon, 7 May 2001 09:44:00 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f47GiOH02683 for ; Mon, 7 May 2001 12:44:24 -0400 Message-ID: <3AF6D0E8.8FB6D721@ecal.com> Date: Mon, 07 May 2001 12:44:24 -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: CalSched IETF Subject: Re: Attendee clarification 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: > The intent of RSVP is to convey the Organizers desire for a > response to the Invitees. Since not all C&S systems support a > mechanism of selectively asking for RSVPs (or do not support > 'em at all) Those are not C&S systems; they're just C systems. If the invitee can't RSVP, you're not doing scheduling; you're just publishing an event. In my view, systems that can't do scheduling are out of scope for iTIP (or, at least, for the REQUEST method). -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Rope is rope, and string is string, and never| |francis@ecal.com|the twine shall meet. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon May 7 13:00:16 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16656 for ; Mon, 7 May 2001 13:00:15 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA13115 for ietf-calendar-bks; Mon, 7 May 2001 09:37:28 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13111 for ; Mon, 7 May 2001 09:37:27 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f47GbwH02669 for ; Mon, 7 May 2001 12:37:59 -0400 Message-ID: <3AF6CF66.41CB840D@ecal.com> Date: Mon, 07 May 2001 12:37:58 -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: VTIMEZONE conflicts - possible solution 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: > 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. What problem are you trying to solve, again? The VCALENDAR MUST contain the VTIMEZONE to which the TZID refers, so there's no great need for the TZID to be globally significant. -- /=================================================================\ |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 Mon May 7 13:01:17 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16682 for ; Mon, 7 May 2001 13:01:16 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA12968 for ietf-calendar-bks; Mon, 7 May 2001 09:33:36 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA12955 for ; Mon, 7 May 2001 09:33:34 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f47GY6H02661 for ; Mon, 7 May 2001 12:34:06 -0400 Message-ID: <3AF6CE7D.F131AD5C@ecal.com> Date: Mon, 07 May 2001 12:34:06 -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: VTIMEZONE conflicts - possible solution References: <3AF2F99B.250FCF3C@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: > Eric Busboom wrote: > > > For example: > > TZID:=/TimezoneEmporium/America/New_York/1 > > If we do go with this, it would be useful to make it easy to separate > out the actual timezone, e.g. 'America/New_York', so it can be > displayed to the user. That's what TZNAME is for. -- /=================================================================\ |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 Mon May 7 13:09:32 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16876 for ; Mon, 7 May 2001 13:09:31 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA13756 for ietf-calendar-bks; Mon, 7 May 2001 09:47:54 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13751 for ; Mon, 7 May 2001 09:47:52 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f47GmNH02698; Mon, 7 May 2001 12:48:24 -0400 Message-ID: <3AF6D1D5.8B1998B3@ecal.com> Date: Mon, 07 May 2001 12:48:21 -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: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > 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. Yeah, but RECUR is too big for calendaring, too. > 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. It can happen, I think; there's no law that says that the Draft Standard has to be a superset of the Proposed Standard. In fact, there's at least one case where RFC-2026 mandates that features be removed: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. (RFC-2026, 4.1.2, second paragraph.) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Brought to you by the letter Q. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon May 7 13:17:30 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17033 for ; Mon, 7 May 2001 13:17:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA14119 for ietf-calendar-bks; Mon, 7 May 2001 09:53:26 -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 JAA14114 for ; Mon, 7 May 2001 09:53:25 -0700 (PDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA02116; Mon, 7 May 2001 12:53:25 -0400 (EDT) Message-ID: <3AF6D305.DE45AA5@cs.columbia.edu> Date: Mon, 07 May 2001 12:53:25 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution References: <3AF6D1D5.8B1998B3@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: > > > 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. > > It can happen, I think; there's no law that says that the Draft > Standard has to be a superset of the Proposed Standard. In fact, > there's at least one case where RFC-2026 mandates that features > be removed: > > The requirement for at least two independent and > interoperable implementations applies to all of the > options and features of the specification. In cases in > which one or more options or features have not been > demonstrated in at least two interoperable > implementations, the specification may advance to the > Draft Standard level only if those options or features > are removed. > > (RFC-2026, 4.1.2, second paragraph.) This is actually quite common. Unless the WG con point to two interoperable implementations of a feature, that feature is history. (It might appear in a separate draft, to progress along the standards track independently.) The whole point of Proposed status is to ferret out the things that are truly useful in practice, rather than progressing grab-bags of ideas that seemed good at some point or another. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-ietf-calendar@mail.imc.org Mon May 7 17:04:17 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22333 for ; Mon, 7 May 2001 17:04:15 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA00957 for ietf-calendar-bks; Mon, 7 May 2001 13:33:33 -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 NAA00951 for ; Mon, 7 May 2001 13:33:31 -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 QAA17207; Mon, 7 May 2001 16:33:19 -0400 Message-ID: <3AF705AF.86C64BB7@ximian.com> Date: Mon, 07 May 2001 16:29:35 -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: VTIMEZONE conflicts - possible solution References: <3AF2F99B.250FCF3C@ximian.com> <3AF6CE7D.F131AD5C@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: > > Damon Chaplin wrote: > > > Eric Busboom wrote: > > > > > For example: > > > TZID:=/TimezoneEmporium/America/New_York/1 > > > > If we do go with this, it would be useful to make it easy to separate > > out the actual timezone, e.g. 'America/New_York', so it can be > > displayed to the user. > > That's what TZNAME is for. Yeah, maybe. But why isn't TZNAME a property of the VTIMEZONE component? It seems silly to duplicate it within each STANDARD and DAYLIGHT subcomponent. And if the TZNAMEs are actually different in some of the STANDARD and DAYLIGHT components, which one do we display? Damon From owner-ietf-calendar@mail.imc.org Tue May 8 11:08:59 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26536 for ; Tue, 8 May 2001 11:08:58 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA00217 for ietf-calendar-bks; Tue, 8 May 2001 07:29: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 HAA00206 for ; Tue, 8 May 2001 07:29:45 -0700 (PDT) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: John Stracke , "ietf-calendar@imc.org" Subject: Re: VTIMEZONE conflicts - possible solution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Tue, 8 May 2001 10:30:35 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/08/2001 10:30:42 AM, Serialize complete at 05/08/2001 10:30:42 AM Content-Type: multipart/alternative; boundary="=_alternative 004F80F385256A46_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004F80F385256A46_= Content-Type: text/plain; charset="us-ascii" Damon wrote on 05/07/2001 04:29:35 PM: > > That's what TZNAME is for. > > Yeah, maybe. But why isn't TZNAME a property of the VTIMEZONE component? > It seems silly to duplicate it within each STANDARD and DAYLIGHT subcomponent. Because humans dont just call it "Eastern" (not "New York"); we refer to "Eastern Standard Time" or "Eastern Daylight Time". Sometimes folks do not make a disctinction (ie: my mother who it TZ shift illiterate) and she just says "Eastern" but for scheduling purposes the disctinction is necessary. For places that do not observe Daylight Savings (ie: Arizona or Idaho in the US) we do not distinguish between "MST" or "MDT", its just "Mountain". For places like that you could argue that its logical to have a TZNAME on the VTIMEZONE but a VTIMEZONE is not really something that a CU is going to ever see. It is a container for TZ shift info and its subcomponents are really the ones that affect what name is shown to the CU when resolving across TZ shifts. Besides, I dont like model changes like this for the minority cases; too disruptive for the potential gain. > And if the TZNAMEs are actually different in some of the STANDARD and DAYLIGHT > components, which one do we display? You display the TZNAME that is used for a particular instance. So, for our 'weekly Monday 10AM conference calls starting in March and ending in May' your CUA would roll that out into some "EST" and some "EDT" values. They would both be 10AM but some would be labled "10:00 AM EST" and some BETTER be labeled "10:00 AM EDT" if I chose to see the TZ name. If you code your CUA to always resolve to the local TZ no matter the originating/reference TZ then you will probably have some form of UI setting that says "Show me TZ names" or possibly even "Show me in this and another TZ" (ie: I want to see it in my local TZ plus in Steve's local TZ so I can tell what time it is for him as a courtesy, etc). (See Lotus Organizer for this kind of feature in action) Here again is where you would want to have the right TZ tags. Sounds like you preferr to have an "Eastern" for all America/New_York entires instead of an "EST"/"EDT" distinction and would like it moved to the VTIMEZONE... Even so, the TZNAME is a 'friendly' name and cannot fully replace TZID (at least in the proposals on the table now). TZID is used for internal indexing for TZ shift finding. TZNAME is intended to be used in the actual UI. As such, nothing is really really gained. 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 004F80F385256A46_= Content-Type: text/html; charset="us-ascii"
Damon wrote on 05/07/2001 04:29:35 PM:
> > That's what TZNAME is for.
>
> Yeah, maybe. But why isn't TZNAME a property of the VTIMEZONE component?
> It seems silly to duplicate it within each STANDARD and DAYLIGHT subcomponent.
Because humans dont just call it "Eastern" (not "New York"); we refer to "Eastern Standard Time" or "Eastern Daylight Time".  Sometimes folks do not make a disctinction (ie: my mother who it TZ shift illiterate) and she just says "Eastern" but for scheduling purposes the disctinction is necessary.  For places that do not observe Daylight Savings (ie: Arizona or Idaho in the US) we do not distinguish between "MST" or "MDT", its just "Mountain".  For places like that you could argue that its logical to have a TZNAME on the VTIMEZONE but a VTIMEZONE is not really something that a CU is going to ever see.  It is a container for TZ shift info and its subcomponents are really the ones that affect what name is shown to the CU when resolving across TZ shifts.

Besides, I dont like model changes like this for the minority cases; too disruptive for the potential gain.

> And if the TZNAMEs are actually different in some of the STANDARD and DAYLIGHT
> components, which one do we display?
You display the TZNAME that is used for a particular instance.  So, for our 'weekly Monday 10AM conference calls starting in March and ending in May' your CUA would roll that out into some "EST" and some "EDT" values.  They would both be 10AM but some would be labled "10:00 AM EST" and some BETTER be labeled "10:00 AM EDT" if I chose to see the TZ name.  

If you code your CUA to always resolve to the local TZ no matter the originating/reference TZ then you will probably have some form of UI setting that says "Show me TZ names" or possibly even "Show me in this and another TZ" (ie: I want to see it in my local TZ plus in Steve's local TZ so I can tell what time it is for him as a courtesy, etc).  (See Lotus Organizer for this kind of feature in action)  Here again is where you would want to have the right TZ tags.

Sounds like you preferr to have an "Eastern" for all America/New_York entires instead of an "EST"/"EDT" distinction and would like it moved to the VTIMEZONE...  Even so, the TZNAME is a 'friendly' name and cannot fully replace TZID (at least in the proposals on the table now).  TZID is used for internal indexing for TZ shift finding.  TZNAME is intended to be used in the actual UI.  As such, nothing is really really gained.

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 004F80F385256A46_=-- From owner-ietf-calendar@mail.imc.org Tue May 8 11:22:51 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27085 for ; Tue, 8 May 2001 11:22:50 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA01318 for ietf-calendar-bks; Tue, 8 May 2001 07:46: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 HAA01314 for ; Tue, 8 May 2001 07:46:47 -0700 (PDT) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: Eric Busboom , "ietf-calendar@imc.org" Subject: Re: VTIMEZONE conflicts - possible solution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Tue, 8 May 2001 10:47:38 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/08/2001 10:47:44 AM, Serialize complete at 05/08/2001 10:47:44 AM Content-Type: multipart/alternative; boundary="=_alternative 005110C285256A46_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005110C285256A46_= Content-Type: text/plain; charset="us-ascii" Damon wrote on 05/04/2001 02:48:59 PM: > Remember that some Olson zones have 2 '/'s, e.g. 'America/Indiana/Marengo'. > (Don't ask me why!) That would suggest that we do not want to use '/' as our delimiter if we define a new URI like format that is easily decomposable. Unless we decide that it must be prefixed w/an escape character making it something like 'America/Indiana\/Marengo' or we encode it ala 'America/Indiana%2FMarengo' neither of which Im too fond to as it makes the TZID a pseudo URI. I think that an alternate delimiter is probably a safer and cleaner way to go (assuming we take this path entirely). 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 005110C285256A46_= Content-Type: text/html; charset="us-ascii"
Damon wrote on 05/04/2001 02:48:59 PM:
> Remember that some Olson zones have 2 '/'s, e.g. 'America/Indiana/Marengo'.
> (Don't ask me why!)
That would suggest that we do not want to use '/' as our delimiter if we define a new URI like format that is easily decomposable.  Unless we decide that it must be prefixed w/an escape character making it something like 'America/Indiana\/Marengo' or we encode it ala 'America/Indiana%2FMarengo' neither of which Im too fond to as it makes the TZID a pseudo URI.   I think that an alternate delimiter is probably a safer and cleaner way to go (assuming we take this path entirely).

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 005110C285256A46_=-- From owner-ietf-calendar@mail.imc.org Tue May 8 11:37:25 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27787 for ; Tue, 8 May 2001 11:37:24 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA02161 for ietf-calendar-bks; Tue, 8 May 2001 08:00:26 -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 IAA02157 for ; Tue, 8 May 2001 08:00:24 -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 KAA32627 for ; Tue, 8 May 2001 10:59:56 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f48ExtP02903 for ; Tue, 8 May 2001 10:59:55 -0400 (EDT) Message-Id: <5.0.0.25.0.20010508103827.00ad61f8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 08 May 2001 10:48:51 -0400 To: "ietf-calendar@imc.org" From: Alan Davies Subject: Re: VTIMEZONE conflicts - possible solution 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: In many User Interfaces, your mother's view is more sensible. When selecting a TimeZone I wouldn't expect a CUA to present me with the choice of "Eastern Standard Time", "Eastern Daylight Time", "Pacific Standard Time", etc... I would instead expect to choose between "Eastern Time" and "Pacific Time", and have the software make the appropriate Daylight/Standard adjustments. Perhaps there should be a TZNAME (or equivalent) in the VTIMEZONE as well as within the STANDARD and DAYLIGHT subcomponents. --Alan At 10:30 AM 08/05/2001 -0400, Bruce_Kahn@iris.com wrote: >Damon wrote on 05/07/2001 04:29:35 PM: > > > That's what TZNAME is for. > > > > Yeah, maybe. But why isn't TZNAME a property of the VTIMEZONE component? > > It seems silly to duplicate it within each STANDARD and DAYLIGHT > subcomponent. > >Because humans dont just call it "Eastern" (not "New York"); we refer to >"Eastern Standard Time" or "Eastern Daylight Time". Sometimes folks do >not make a disctinction (ie: my mother who it TZ shift illiterate) and she >just says "Eastern" but for scheduling purposes the disctinction is >necessary. For places that do not observe Daylight Savings (ie: Arizona >or Idaho in the US) we do not distinguish between "MST" or "MDT", its just >"Mountain". For places like that you could argue that its logical to have >a TZNAME on the VTIMEZONE but a VTIMEZONE is not really something that a >CU is going to ever see. It is a container for TZ shift info and its >subcomponents are really the ones that affect what name is shown to the CU >when resolving across TZ shifts. > >Besides, I dont like model changes like this for the minority cases; too >disruptive for the potential gain. > > > And if the TZNAMEs are actually different in some of the STANDARD and > DAYLIGHT > > components, which one do we display? > >You display the TZNAME that is used for a particular instance. So, for >our 'weekly Monday 10AM conference calls starting in March and ending in >May' your CUA would roll that out into some "EST" and some "EDT" >values. They would both be 10AM but some would be labled "10:00 AM EST" >and some BETTER be labeled "10:00 AM EDT" if I chose to see the TZ name. > >If you code your CUA to always resolve to the local TZ no matter the >originating/reference TZ then you will probably have some form of UI >setting that says "Show me TZ names" or possibly even "Show me in this and >another TZ" (ie: I want to see it in my local TZ plus in Steve's local TZ >so I can tell what time it is for him as a courtesy, etc). (See Lotus >Organizer for this kind of feature in action) Here again is where you >would want to have the right TZ tags. > >Sounds like you preferr to have an "Eastern" for all America/New_York >entires instead of an "EST"/"EDT" distinction and would like it moved to >the VTIMEZONE... Even so, the TZNAME is a 'friendly' name and cannot >fully replace TZID (at least in the proposals on the table now). TZID is >used for internal indexing for TZ shift finding. TZNAME is intended to be >used in the actual UI. As such, nothing is really really gained. > >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 Tue May 8 12:11:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29975 for ; Tue, 8 May 2001 12:11:03 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA09463 for ietf-calendar-bks; Tue, 8 May 2001 08:54:59 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA09451 for ; Tue, 8 May 2001 08:54:57 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id KAA10040 for ; Tue, 8 May 2001 10:53:13 -0500 From: "Shannon J. Clark" To: Subject: RE: VTIMEZONE conflicts - possible solution Date: Tue, 8 May 2001 10:54:08 -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) In-Reply-To: <5.0.0.25.0.20010508103827.00ad61f8@imap1.in.steltor.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit To continue with this example - most of the time people (end users that is) think in terms of where they live (or where they are going) to get to the timezone to use. So - if I am putting an event into my calendar for while I am in Paris - I want my application to present me with an option for "Paris, France" time - which will be adjusted correctly for Daylight savings time - and does not require me to know the name for Europe's timezone. If I am going to a non-major city, I'm comfortable looking for a city that I know is close by and which I assume is in the same timezone (i.e. if I am going to the Loire Valley in France - Paris time will work fine for me.) Others on this list have pointed out that users in Canada think of their timezones - even the ones that overlap with US timezones in terms of Canadian cities - not US cities. It does seem sensible to me that there should be mechanism for multiple TZNAME's to map to the same set of timezone rules - i.e. to map to the same TZID potentially. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Alan Davies Sent: Tuesday, May 08, 2001 9:49 AM To: ietf-calendar@imc.org Subject: Re: VTIMEZONE conflicts - possible solution In many User Interfaces, your mother's view is more sensible. When selecting a TimeZone I wouldn't expect a CUA to present me with the choice of "Eastern Standard Time", "Eastern Daylight Time", "Pacific Standard Time", etc... I would instead expect to choose between "Eastern Time" and "Pacific Time", and have the software make the appropriate Daylight/Standard adjustments. Perhaps there should be a TZNAME (or equivalent) in the VTIMEZONE as well as within the STANDARD and DAYLIGHT subcomponents. --Alan At 10:30 AM 08/05/2001 -0400, Bruce_Kahn@iris.com wrote: >Damon wrote on 05/07/2001 04:29:35 PM: > > > That's what TZNAME is for. > > > > Yeah, maybe. But why isn't TZNAME a property of the VTIMEZONE component? > > It seems silly to duplicate it within each STANDARD and DAYLIGHT > subcomponent. > >Because humans dont just call it "Eastern" (not "New York"); we refer to >"Eastern Standard Time" or "Eastern Daylight Time". Sometimes folks do >not make a disctinction (ie: my mother who it TZ shift illiterate) and she >just says "Eastern" but for scheduling purposes the disctinction is >necessary. For places that do not observe Daylight Savings (ie: Arizona >or Idaho in the US) we do not distinguish between "MST" or "MDT", its just >"Mountain". For places like that you could argue that its logical to have >a TZNAME on the VTIMEZONE but a VTIMEZONE is not really something that a >CU is going to ever see. It is a container for TZ shift info and its >subcomponents are really the ones that affect what name is shown to the CU >when resolving across TZ shifts. > >Besides, I dont like model changes like this for the minority cases; too >disruptive for the potential gain. > > > And if the TZNAMEs are actually different in some of the STANDARD and > DAYLIGHT > > components, which one do we display? > >You display the TZNAME that is used for a particular instance. So, for >our 'weekly Monday 10AM conference calls starting in March and ending in >May' your CUA would roll that out into some "EST" and some "EDT" >values. They would both be 10AM but some would be labled "10:00 AM EST" >and some BETTER be labeled "10:00 AM EDT" if I chose to see the TZ name. > >If you code your CUA to always resolve to the local TZ no matter the >originating/reference TZ then you will probably have some form of UI >setting that says "Show me TZ names" or possibly even "Show me in this and >another TZ" (ie: I want to see it in my local TZ plus in Steve's local TZ >so I can tell what time it is for him as a courtesy, etc). (See Lotus >Organizer for this kind of feature in action) Here again is where you >would want to have the right TZ tags. > >Sounds like you preferr to have an "Eastern" for all America/New_York >entires instead of an "EST"/"EDT" distinction and would like it moved to >the VTIMEZONE... Even so, the TZNAME is a 'friendly' name and cannot >fully replace TZID (at least in the proposals on the table now). TZID is >used for internal indexing for TZ shift finding. TZNAME is intended to be >used in the actual UI. As such, nothing is really really gained. > >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 Tue May 8 13:52:32 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03261 for ; Tue, 8 May 2001 13:52:32 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA16109 for ietf-calendar-bks; Tue, 8 May 2001 10:22:30 -0700 (PDT) Received: from intermezzo.ximian.com (intermezzo.ximian.com [141.154.95.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16104 for ; Tue, 8 May 2001 10:22:27 -0700 (PDT) Received: from localhost.localdomain (IDENT:jpr@localhost.localdomain [127.0.0.1]) by intermezzo.ximian.com (8.9.3/8.9.3) with ESMTP id NAA20404; Tue, 8 May 2001 13:22:16 -0400 Subject: Re: VTIMEZONE conflicts - possible solution From: JP Rosevear To: Eric Busboom Cc: "ietf-calendar@imc.org" Content-Type: text/plain X-Mailer: Evolution/0.10 (Preview Release) Date: 08 May 2001 13:22:14 -0400 Message-Id: <989342536.20269.0.camel@intermezzo.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 03 May 2001 10:15:52 -0700, Eric Busboom wrote: > The presence of the SOLIDUS character ( US-ASCII 47) as a prefix > indicates that 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. If this is going to be the case, then perhaps you should define the two vtimezones as functionally equivalent if, for the lifespan of the the appointment (ie from the first occurrence to the last) the set of time shifts generated is equivalent. This keeps timezones that contain extra historical data or know about future changes from automatically being not considered functionally equivalent. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Tue May 8 16:12:16 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06631 for ; Tue, 8 May 2001 16:12:16 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA20572 for ietf-calendar-bks; Tue, 8 May 2001 12:29:53 -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 MAA20567 for ; Tue, 8 May 2001 12:29:51 -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 PAA19994; Tue, 8 May 2001 15:29:38 -0400 Message-ID: <3AF8483E.F3ECED53@ximian.com> Date: Tue, 08 May 2001 15:25:50 -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: JP Rosevear CC: Eric Busboom , "ietf-calendar@imc.org" Subject: Re: VTIMEZONE conflicts - possible solution References: <989342536.20269.0.camel@intermezzo.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 JP Rosevear wrote: > > On 03 May 2001 10:15:52 -0700, Eric Busboom wrote: > > The presence of the SOLIDUS character ( US-ASCII 47) as a prefix > > indicates that 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. > > If this is going to be the case, then perhaps you should define the two > vtimezones as functionally equivalent if, for the lifespan of the the > appointment (ie from the first occurrence to the last) the set of time > shifts generated is equivalent. This keeps timezones that contain extra > historical data or know about future changes from automatically being > not considered functionally equivalent. But then you are back to having multiple VTIMEZONEs with the same TZID. So you either have to merge them together (a bit awkward, and not secure) or rename them or something. Damon From owner-ietf-calendar@mail.imc.org Wed May 9 00:46:15 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15767 for ; Wed, 9 May 2001 00:46:15 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id VAA16161 for ietf-calendar-bks; Tue, 8 May 2001 21:30:12 -0700 (PDT) Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA16156 for ; Tue, 8 May 2001 21:30:10 -0700 (PDT) Message-ID: <987120015394229790@pavilion> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: ietf-calendar@imc.org Subject: Business/Employment Opportunity Date: Tue, 8 May 2001 18:22:09 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id VAA16158 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Donaldson P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. From owner-ietf-calendar@mail.imc.org Wed May 9 20:01:48 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29577 for ; Wed, 9 May 2001 20:01:48 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA28512 for ietf-calendar-bks; Wed, 9 May 2001 16:47:23 -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 QAA28508 for ; Wed, 9 May 2001 16:47:21 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f49Nk1N01481; Wed, 9 May 2001 16:46:01 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Wed, 9 May 2001 16:46:01 -0700 (PDT) From: Eric Busboom X-X-Sender: To: "Shannon J. Clark" cc: Subject: RE: VTIMEZONE conflicts - possible solution 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, 8 May 2001, Shannon J. Clark wrote: > It does seem sensible to me that there should be mechanism for multiple > TZNAME's to map to the same set of timezone rules - i.e. to map to the same > TZID potentially. I think that the ideas behind this thread are generally sensible -- that humans need to understand timezone names as relating to a particular place or region -- but I think solution is outside of iCalendar. There are two problems to consider: (1) Given a common name of a region, how does a user select the timezone rules to apply to a meeting request? ((2) Given an incoming request, how does the user know what timezone rules apply? The answer to (1) is that the CUA creates its own list of Olsen place names, city names, or timezone region names and maps them into TZIDs in its own timezone database. The user picks a common name or place, and the CUA figures out what TZID to use. No need for a special solution here. For (2), the receiving user has LOCATION and TZNAME ( & sometimes GEO) in the incoming event request. If you get a message that has: Bob's Jazz Cafe, Manhattan July 10, 2001, 14:00 EST The "Manhattan" and "EST" are all you need to understand where the meeting is and what timezone applies. Even if the sender did not include "Manhattan", you are very unlikely to get an event request for a far-flung timezone without some out-of-band arrangements for the trip. You are not going to be looking through the Seattle street maps at 13:00 on the day of this meeting. TZNAME is defined at "customary designation for a time zone description" so timzone-database builders could pick whatever people best understand. They could call it "Eastern Standard Time" if they want. It is not our concern if the user does not understand the "customary designations" -- that is a problem for the user and the and the builders of the timezone databases. I don't think we should add any special structure to TZID, and I certainly don't think we should try to format it so parts of it can be displayed to the user. These are solutions for problems that are not in our realm. eric. From owner-ietf-calendar@mail.imc.org Thu May 10 17:50:56 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08824 for ; Thu, 10 May 2001 17:50:55 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA03889 for ietf-calendar-bks; Thu, 10 May 2001 14:36:34 -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 OAA03880 for ; Thu, 10 May 2001 14:36:33 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f4ALaXj09304 for ; Thu, 10 May 2001 14:36:33 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 10 May 2001 14:36:33 -0700 (PDT) From: Eric Busboom X-X-Sender: To: Subject: Draft update of RFC2445 online. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've poseted a draft update of RFC2445 to: http://softwarestudio.org/iCal/ The changes between this draft and the released RFC are listed in the introduction. There are not very many changes yet. eric. From owner-ietf-calendar@mail.imc.org Fri May 11 13:25:00 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16108 for ; Fri, 11 May 2001 13:24:59 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA03997 for ietf-calendar-bks; Fri, 11 May 2001 10:05:37 -0700 (PDT) Received: from dancing-bare.dsl-only.net (dancing-bare.dsl-only.net [63.105.16.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA03991 for ; Fri, 11 May 2001 10:05:32 -0700 (PDT) Received: from coral (unverified [63.105.21.104]) by dancing-bare.dsl-only.net (Rockliffe SMTPRA 4.5.4) with SMTP id ; Fri, 11 May 2001 10:12:42 -0700 From: "coral" To: Cc: "Rk-Devel" Subject: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) Date: Fri, 11 May 2001 10:06:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit There seems to be a point of confusion in 4.3.6 Duration. -- RFC2234 (ABNF) states: 3.6 Variable Repetition *Rule The operator "*" preceding an element indicates repetition. The full form is: *element where and are optional decimal values, indicating at least and at most occurrences of element. Default values are 0 and infinity so that * allows any number, including zero; 1* requires at least one; 3*3 allows exactly 3 and 1*2 allows one or two -- RFC2445 (iCal), Draft Update (May 10, 2001) states: 4.3.6 Duration Value Name: DURATION Purpose: This value type is used to identify properties that contain a duration of time. Formal Definition: The value type is defined by the following notation: 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" Description: If the property permits, multiple "duration" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. The format is expressed as the [3] basic format for the duration of time. The format can represent durations in terms of weeks, days, hours, minutes, and seconds. No additional content value encoding (i.e., BACKSLASH character encoding) are defined for this value type. Example: A duration of 15 days, 5 hours and 20 seconds would be: P15DT5H0M20S A duration of 7 weeks would be: P7W -- end Per the ABNF provided in 4.3.6, P7W as stated directly above is not valid - 1*DIGIT "W" is satisfied, but the "T", "H", "M", "S", and "D" are also required. I would propose changing the section to: 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 = *1DIGIT "W" dur-hour = *1DIGIT "H" [dur-minute] dur-minute = *1DIGIT "M" [dur-second] dur-second = *1DIGIT "S" dur-day = *1DIGIT "D" This allows P7W, P15DT5H0M20S, and P15DT4H10S as valid durations. Working on Net::ICal (a perl module implemented the iCal RFC), I've recently made a code change that allows us to reduce Duration values down to only what is necessary to express the duration, by removing zero-value elements. Example: P15DT0H10M0S would become P15DT10M P0DT0H0M1S would become PT1S However, this leads to further questions: Is it allowed to specify a time duration without providing the dur-day? How does one express a zero-value - "P0DT0H0M0S" would reduce to "P", which may or not be an acceptable duration. I'm not sure where to go from here. I prefer being able to specify time durations without requiring dur-week or dur-day. Net::ICal is using PT0S to express zero durations at this time, as it seemed the most reasonable choice. Also, there appears to be a thread on the Issues list that may be of some relevance to this topic: 45 01/19/2001 [Typo] Several examples with durations are missing T Thanks for your help and time. coral From owner-ietf-calendar@mail.imc.org Fri May 11 15:10:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18543 for ; Fri, 11 May 2001 15:10:20 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA07223 for ietf-calendar-bks; Fri, 11 May 2001 11:52:16 -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 LAA07219 for ; Fri, 11 May 2001 11:52:11 -0700 (PDT) From: Bruce_Kahn@iris.com To: "coral" Cc: ietf-calendar@imc.org, "Rk-Devel" Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 14:52:52 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 02:57:27 PM, Serialize complete at 05/11/2001 02:57:27 PM Content-Type: multipart/alternative; boundary="=_alternative 00678C5A85256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00678C5A85256A49_= Content-Type: text/plain; charset="us-ascii" coral wrote on 05/11/2001 01:06:58 PM: > -- RFC2445 (iCal), Draft Update (May 10, 2001) states: > > 4.3.6 Duration > > Value Name: DURATION > > Purpose: This value type is used to identify properties that contain > a duration of time. > > Formal Definition: The value type is defined by the following > notation: > > 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" [Snip] > Per the ABNF provided in 4.3.6, P7W as stated directly above is not > valid - 1*DIGIT "W" is satisfied, but the "T", "H", "M", "S", and "D" > are also required. I would propose changing the section to: Actually it is satisified by resolving this way: P7W = (["+"] / "-")"P" dur-week = "P" 1*DIGIT "W" The ABNF says "(dur-date / dur-time / dur-week)" which means only 1 of them is possible (hence the extra work in dur-date, etc). As such, P7W resolves in just 1 step. There is no ABNF requirement for the dur-time, dur-date, dur-hour, etc if resolving the value to dur-week. Now the ABNF does NOT allow for something like P2W3DT12H (ie: 2 Weeks, 3 Days and 12 Hours) but thats not the same case you seem to be looking for. > However, this leads to further questions: Is it allowed to specify > a time duration without providing the dur-day? How does one express > a zero-value - "P0DT0H0M0S" would reduce to "P", which may or not be > an acceptable duration. Sure, the ABNF is: dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) which for your question would be resolveable by resolving the ABNF down to dur-value = (["+"] / "-") "P" dur-time As for the 0 length duration, its legal to have PT0H0M0S (or just PT0H, etc) but the question is WHY have it? If the entry has no length, why use a DURATION at all?? Guess Im just not sure why you would even want to generate that... 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 00678C5A85256A49_= Content-Type: text/html; charset="us-ascii"
coral wrote on 05/11/2001 01:06:58 PM:
> -- RFC2445 (iCal), Draft Update (May 10, 2001) states:
>
> 4.3.6 Duration
>
>    Value Name: DURATION
>
>    Purpose: This value type is used to identify properties that contain
>    a duration of time.
>
>    Formal Definition: The value type is defined by the following
>    notation:
>
>         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"
[Snip]
> Per the ABNF provided in 4.3.6, P7W as stated directly above is not
> valid - 1*DIGIT "W" is satisfied, but the "T", "H", "M", "S", and "D"
> are also required.  I would propose changing the section to:
Actually it is satisified by resolving this way:

        P7W = (["+"] / "-")"P" dur-week = "P" 1*DIGIT "W"

The ABNF says "(dur-date / dur-time / dur-week)" which means only 1 of them is possible (hence the extra work in dur-date, etc).  As such, P7W resolves in just 1 step.  There is no ABNF requirement for the dur-time, dur-date, dur-hour, etc if resolving the value to dur-week.

Now the ABNF does NOT allow for something like P2W3DT12H (ie: 2 Weeks, 3 Days and 12 Hours) but thats not the same case you seem to be looking for.

> However, this leads to further questions:  Is it allowed to specify
> a time duration without providing the dur-day?  How does one express
> a zero-value - "P0DT0H0M0S" would reduce to "P", which may or not be
> an acceptable duration.
Sure, the ABNF is:

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

which for your question would be resolveable by resolving the ABNF down to

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

As for the 0 length duration, its legal to have PT0H0M0S (or just PT0H, etc) but the question is WHY have it?  If the entry has no length, why use a DURATION at all??  Guess Im just not sure why you would even want to generate that...

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 00678C5A85256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 15:25:44 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18661 for ; Fri, 11 May 2001 15:25:44 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA08021 for ietf-calendar-bks; Fri, 11 May 2001 12:12:19 -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 MAA08011 for ; Fri, 11 May 2001 12:12:10 -0700 (PDT) From: Bruce_Kahn@iris.com To: "coral" Cc: ietf-calendar@imc.org, "Rk-Devel" Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 15:13:06 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 03:17:26 PM, Serialize complete at 05/11/2001 03:17:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0069669685256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069669685256A49_= Content-Type: text/plain; charset="us-ascii" coral wrote on 05/11/2001 01:06:58 PM: > Per the ABNF provided in 4.3.6, P7W as stated directly above is not > valid - 1*DIGIT "W" is satisfied, but the "T", "H", "M", "S", and "D" > are also required. I would propose changing the section to: > > 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 = *1DIGIT "W" > dur-hour = *1DIGIT "H" [dur-minute] > dur-minute = *1DIGIT "M" [dur-second] > dur-second = *1DIGIT "S" > dur-day = *1DIGIT "D" > > This allows P7W, P15DT5H0M20S, and P15DT4H10S as valid durations. Actually your "1*" change to "*1" makes the last 2 examples illegal. They could ONLY have 0 or 1 digit so "15D" is bad since it has 2 digits. Same for all the other cases subcomponents. If you are trying to 'simplify' the ABNF so that you can have "PT10M" (ie: no "0H") then this proposal wont do it. You would eliminate the need for a "0" in front of the "H" but you would be left with "PTH10M" instead. Not too helpful and kinda confusing. If you intend to make it so that dur-hour is optional in a dur-time, thats not how it would parse out. Im not sure if this just a misunderstaning on how to parse the format or if there is a goal that is not being expressed so my simple mind can grok it... 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 0069669685256A49_= Content-Type: text/html; charset="us-ascii"
coral wrote on 05/11/2001 01:06:58 PM:
> Per the ABNF provided in 4.3.6, P7W as stated directly above is not
> valid - 1*DIGIT "W" is satisfied, but the "T", "H", "M", "S", and "D"
> are also required.  I would propose changing the section to:
>
>         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   = *1DIGIT "W"
>         dur-hour   = *1DIGIT "H" [dur-minute]
>         dur-minute = *1DIGIT "M" [dur-second]
>         dur-second = *1DIGIT "S"
>         dur-day    = *1DIGIT "D"
>
> This allows P7W, P15DT5H0M20S, and P15DT4H10S as valid durations.
Actually your "1*" change to "*1" makes the last 2 examples illegal.  They could ONLY have 0 or 1 digit so "15D" is bad since it has 2 digits.  Same for all the other cases subcomponents.

If you are trying to 'simplify' the ABNF so that you can have "PT10M" (ie: no "0H") then this proposal wont do it.  You would eliminate the need for a "0" in front of the "H" but you would be left with "PTH10M" instead.  Not too helpful and kinda confusing.   If you intend to make it so that dur-hour is optional in a dur-time, thats not how it would parse out.  Im not sure if this just a misunderstaning on how to parse the format or if there is a goal that is not being expressed so my simple mind can grok it...

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 0069669685256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 16:03:06 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19508 for ; Fri, 11 May 2001 16:03:04 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA09950 for ietf-calendar-bks; Fri, 11 May 2001 12:51:00 -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 MAA09943 for ; Fri, 11 May 2001 12:50:54 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: CalSched IETF Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 15:51:52 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 03:56:11 PM, Serialize complete at 05/11/2001 03:56:11 PM Content-Type: multipart/alternative; boundary="=_alternative 006CF32C85256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CF32C85256A49_= Content-Type: text/plain; charset="us-ascii" Alan suggested: >If Bruce's interpretation of RSVP is correct, there's >not much difference between a REQ-PARTICIPANT with RSVP=FALSE >and a NON-PARTICIPANT. First off, its not "my interpretation". I was expressly describing our original intent when we designed and added RSVP. Ask Frank or Derik to confirm this... The RSVP property parameter conveys 1 intent: does the Organizer want to get a response from the Invitee to this (overall) invitation. The ROLE conveys another. The ROLE=REQ-PARTICIPANT conveys to me that the Organizer really would like (or requires) me to attend. The ROLE=OPT-PARTICIPANT tells me that they prefer that I attend but can live w/o me being there. The METHOD property conveys the overall action that the Organizer is trying to do (ie: Invite me to a meeting, PUBLISH a calendar entry, etc). All the have distinct, separate and useful semantics. There are cases for when to use each one in different ways. The claim that RSVP=FALSE;ROLE=REQ-PARTICIPANT is akin to a METHOD:PUBLISH could be true if you do not see the use of each property/parameter and how they are intended to be used. Also, do not forget that _each_ REQUEST is a separate and complete snapshot of the event so that we do not have to worry about partial updates, "delta management", etc. in our workflow process. However it sounds as if Alan is proposing that we turn RSVP into a "1 time only" use parameter. If that were the case then it is possible that I would/could _never_ reply to a REQUEST from him if I only got the 'typo' correction and never got the original invitation. Or if I did get the original invite _after_ the update then my CUA would no longer just ignore it like we have agree'd on since nearly Day 1 ("That DTSTAMP is older than the one I already got for the same UID and SEQUENCE values so I can just toss it"). My CUA must try to figure out if I really should reply to the REQUEST or not based on info that is 'older' than the last 'snapshot'. Ugh. Another inherent part of this argument is that a ROLE=REQ-PARTICIAPNT (and possibly OPT-PARTICPANT) have some implicit "respond" actions. That is, if I see that Alan made me a REQ-PARTICIPANT then I must implicitly be mandated to send him some kind of reply. Sorry, Alan cannot make me reply if I dont want to nor is my role indicative of my abilty to respond/counter/etc. A simple scenario where a response is not necessary: I talk w/Steve to arrange lunch next Thursday. We both have it free and agree to the time, place, etc. I use my normal CUA to send him an invitation but I do not need to know if he is coming or not (we've already planned it) so I just fill in the normal request form and post it off to him w/the RSVP=FALSE. I could have made him a "Non-particiapnt" but as a CU, I do not view Steve as not particpating in lunch; its a lunch date! However by Alans view I would have to expressly make Steve a non-particpant (via a different entry line or some other GUI setup) instead of simply saying "Send w/o requesting response" (or your favorite GUI action). A non-particpant is someone like the AA who has to know about the meeting, the caterer who has to get an idea of the head count so they can plan the meals, etc. If someone is going to participate, Id say they are not a non-participant. >The whole reason for REQUEST/REPLY/ROLE/RSVP/etc. is to >allow interactive scheduling between CUAs, something that >we're all working to achieve. When the RSVP property was first put on the table, some vendor(s) said that they did not have the concept of all these kinds of msgs and would not be able to support them all (hence our easing of the MUST/MUST NOT text). How can you expect to mandate a particular behaviour if someone does not have an architecture/design that supports your implicit assumptions? You can't. >What Bruce is suggesting may be useful, but as far as I >can see nothing in RFC2445 or RFC2446 implies that RSVP >can be used to achieve this. Once again: Its not expressly in the text, thats why I posted the clarification as to the original intent. If you reread the text for TRUE I originally posted (sounds like some have not or just skimmed it) you will see that setting RSVP=TRUE on a 'typo' update is NOT mandating that the CU send back a "I got your typo fix" any more than it means "Send the Organizer a 'I got your REQUEST and will send a REPLY soon'" message. That sounds like a MIME delivery confirmation setting and we are not building that. The value of TRUE is used to tell the invitee that the Organizer wants to know of any PART-STATUS changes (ie: you accepted, declined, delegated, etc) or if they want me to be able to Counter with a new date/time. So _PLEASE_ explain to me why my CUA would automagically send a REPLY to your 'typo' fix when my ATTENDEE value and property parameters (ie: PART-STAT=Accepted) are the same? There is _NO_ need for it to so it shouldn't. So why would the Organizer need/want to set RSVP=FALSE for just that iTIP message?? They have none! If however, my CUA noticed that you think I have not yet accepted then it should either prompt me if I want to re-accept (ie: send a second acceptance just in case) or possibly do a DIFF against its snapshot first to see if just a typo fix was found (or other minor tidbits) and then do it for me as a feature. That is, "Hmm, Alan did not change the start time, end time, location, attendee list, ... but did change 1 word in SUMMARY AND he has not indicated that he got my acceptance notice from last week so I better re-accept so he knows." 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 006CF32C85256A49_= Content-Type: text/html; charset="us-ascii"
Alan suggested:
>If Bruce's interpretation of RSVP is correct, there's
>not much difference between a REQ-PARTICIPANT with RSVP=FALSE
>and a NON-PARTICIPANT.

First off, its not "my interpretation".  I was expressly describing our original intent when we designed and added RSVP.  Ask Frank or Derik to confirm this...

The RSVP property parameter conveys 1 intent: does the Organizer want to get a response from the Invitee to this (overall) invitation.  

The ROLE conveys another.  The ROLE=REQ-PARTICIPANT conveys to me that the Organizer really would like (or requires) me to attend.  The ROLE=OPT-PARTICIPANT tells me that they prefer that I attend but can live w/o me being there.  

The METHOD property conveys the overall action that the Organizer is trying to do (ie: Invite me to a meeting, PUBLISH a calendar entry, etc).  

All the have distinct, separate and useful semantics.  There are cases for when to use each one in different ways.  The claim that RSVP=FALSE;ROLE=REQ-PARTICIPANT is akin to a METHOD:PUBLISH could be true if you do not see the use of each property/parameter and how they are intended to be used.  

Also, do not forget that _each_ REQUEST is a separate and complete snapshot of the event so that we do not have to worry about partial updates, "delta management", etc. in our workflow process.  However it sounds as if Alan is proposing that we turn RSVP into a "1 time only" use parameter.  If that were the case then it is possible that I would/could _never_ reply to a REQUEST from him if I only got the 'typo' correction and never got the original invitation.  Or if I did get the original invite _after_ the update then my CUA would no longer just ignore it like we have agree'd on since nearly Day 1 ("That DTSTAMP is older than the one I already got for the same UID and SEQUENCE values so I can just toss it").  My CUA must try to figure out if I really should reply to the REQUEST or not based on info that is 'older' than the last 'snapshot'.  Ugh.

Another inherent part of this argument is that a ROLE=REQ-PARTICIAPNT (and possibly OPT-PARTICPANT) have some implicit "respond" actions.  That is, if I see that Alan made me a REQ-PARTICIPANT then I must implicitly be mandated to send him some kind of reply.  Sorry, Alan cannot make me reply if I dont want to nor is my role indicative of my abilty to respond/counter/etc.

A simple scenario where a response is not necessary: I talk w/Steve to arrange lunch next Thursday.  We both have it free and agree to the time, place, etc.  I use my normal CUA to send him an invitation but I do not need to know if he is coming or not (we've already planned it) so I just fill in the normal request form and post it off to him w/the RSVP=FALSE.  I could have made him a "Non-particiapnt" but as a CU, I do not view Steve as not particpating in lunch; its a lunch date!  However by Alans view I would have to expressly make Steve a non-particpant (via a different entry line or some other GUI setup) instead of simply saying "Send w/o requesting response" (or your favorite GUI action).

A non-particpant is someone like the AA who has to know about the meeting, the caterer who has to get an idea of the head count so they can plan the meals, etc.  If someone is going to participate, Id say they are not a non-participant.

>The whole reason for REQUEST/REPLY/ROLE/RSVP/etc. is to
>allow interactive scheduling between CUAs, something that
>we're all working to achieve.

When the RSVP property was first put on the table, some vendor(s) said that they did not have the concept of all these kinds of msgs and would not be able to support them all (hence our easing of the MUST/MUST NOT text).  How can you expect to mandate a particular behaviour if someone does not have an architecture/design that supports your implicit assumptions?   You can't.

>What Bruce is suggesting may be useful, but as far as I
>can see nothing in RFC2445 or RFC2446 implies that RSVP
>can be used to achieve this.

Once again: Its not expressly in the text, thats why I posted the clarification as to the original intent.  

If you reread the text for TRUE I originally posted (sounds like some have not or just skimmed it) you will see that setting RSVP=TRUE on a 'typo' update is NOT mandating that the CU send back a "I got your typo fix" any more than it means "Send the Organizer a 'I got your REQUEST and will send a REPLY soon'" message.  That sounds like a MIME delivery confirmation setting and we are not building that.  The value of TRUE is used to tell the invitee that the Organizer wants to know of any PART-STATUS changes (ie: you accepted, declined, delegated, etc) or if they want me to be able to Counter with a new date/time.

So _PLEASE_ explain to me why my CUA would automagically send a REPLY to your 'typo' fix when my ATTENDEE value and property parameters (ie: PART-STAT=Accepted) are the same?  There is _NO_ need for it to so it shouldn't.  So why would the Organizer need/want to set RSVP=FALSE for just that iTIP message??  They have none!

If however, my CUA noticed that you think I have not yet accepted then it should either prompt me if I want to re-accept (ie: send a second acceptance just in case) or possibly do a DIFF against its snapshot first to see if just a typo fix was found (or other minor tidbits) and then do it for me as a feature.  That is, "Hmm, Alan did not change the start time, end time, location, attendee list, ... but did change 1 word in SUMMARY AND he has not indicated that he got my acceptance notice from last week so I better re-accept so he knows."

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 006CF32C85256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 16:16:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19761 for ; Fri, 11 May 2001 16:16:20 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA10161 for ietf-calendar-bks; Fri, 11 May 2001 12:58:02 -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 MAA10154 for ; Fri, 11 May 2001 12:57:56 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: CalSched IETF Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 15:58:54 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 04:03:13 PM, Serialize complete at 05/11/2001 04:03:13 PM Content-Type: multipart/alternative; boundary="=_alternative 006D982E85256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D982E85256A49_= Content-Type: text/plain; charset="us-ascii" John wrote: >Those are not C&S systems; they're just C systems. If the >invitee can't RSVP, you're not doing scheduling; you're just >publishing an event. Id say that Data General would disagree that their award winning CEO product doesn't have C&S in it. (I used it for 7 years while @ DG and I arranged/participated in at least 1 meeting while there). I believe (but could be wrong) that Novell's GroupWise also has a restriction that did not allow it to support RSVP as well. Guess GroupWise isnt a C&S product then either... If a system has a design more like "direct book" or some different design than your they are not a valid possible implementation candidate for iCalendar... Sounds like John has the view that the RSVP is more like a Delivery Confirmation notice also. Thats not a valid use for it; that what your MIME settings are for on your iMIP message... 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 006D982E85256A49_= Content-Type: text/html; charset="us-ascii"
John wrote:
>Those are not C&S systems; they're just C systems.  If the
>invitee can't RSVP, you're not doing scheduling; you're just
>publishing an event.
Id say that Data General would disagree that their award winning CEO product doesn't have C&S in it.  (I used it for 7 years while @ DG and I arranged/participated in at least 1 meeting while there).  I believe (but could be wrong) that Novell's GroupWise also has a restriction that did not allow it to support RSVP as well.  Guess GroupWise isnt a C&S product then either...  If a system has a design more like "direct book" or some different design than your they are not a valid possible implementation candidate for iCalendar...

Sounds like John has the view that the RSVP is more like a Delivery Confirmation notice also.  Thats not a valid use for it; that what your MIME settings are for on your iMIP message...

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 006D982E85256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 16:27:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19981 for ; Fri, 11 May 2001 16:27:23 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA11085 for ietf-calendar-bks; Fri, 11 May 2001 13:17:01 -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 NAA11065 for ; Fri, 11 May 2001 13:16:55 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4BKHId13844 for ; Fri, 11 May 2001 16:17:18 -0400 Message-ID: <3AFC48CB.A306E142@ecal.com> Date: Fri, 11 May 2001 16:17:15 -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: CalSched IETF Subject: Re: Attendee clarification 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: > > John wrote: > >Those are not C&S systems; they're just C systems. If the > >invitee can't RSVP, you're not doing scheduling; you're just > >publishing an event. [...] > Sounds like John has the view that the RSVP is more like a > Delivery Confirmation notice also. No. My objection is this: if you want to do scheduling, you need feedback from the recipients, to find out whether or not they're going to attend the meeting. If you're using a system that doesn't support that feedback (or if you set RSVP to FALSE), then all you've done is publish an event into the recipients' calendars; you have no idea whether or not they'll be there. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |I have strong opinions about ambivalence. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri May 11 16:33:34 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20143 for ; Fri, 11 May 2001 16:33:33 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA12094 for ietf-calendar-bks; Fri, 11 May 2001 13:23:32 -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 NAA12079 for ; Fri, 11 May 2001 13:23:27 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4BKNcd13870 for ; Fri, 11 May 2001 16:23:38 -0400 Message-ID: <3AFC4A49.A7637B7A@ecal.com> Date: Fri, 11 May 2001 16:23:38 -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: VTIMEZONE conflicts - possible solution 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: > > Yeah, maybe. But why isn't TZNAME a property of the VTIMEZONE > component? > > It seems silly to duplicate it within each STANDARD and > DAYLIGHT subcomponent. > > Because humans dont just call it "Eastern" (not "New York"); we > refer to "Eastern Standard Time" or "Eastern Daylight Time". Not necessarily. Suppose you've got something that happens every day at 8:00 all year; you have to refer to "Eastern Time", because "8:00 Eastern Standard Time" is a fixed GMT offset. > Sometimes folks do not make a disctinction (ie: my mother who > it TZ shift illiterate) Or, for example, TV stations, which say things like "8/7 Central and Mountain" (when the transmitter is near the Central/Mountain border). This is common enough > > And if the TZNAMEs are actually different in some of the > STANDARD and DAYLIGHT > > components, which one do we display? > > You display the TZNAME that is used for a particular instance. And which one do you put in the menu for the user to choose from when they haven't chosen a date yet? I think Damon's right; we should be able to put a TZNAME in the VTIMEZONE. There would still be TZNAMEs in the STANDARD/DAYLIGHT components. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Stupid, adj.: Losing $25 on the game and $50 on| |francis@ecal.com|the instant replay. | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri May 11 16:34:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20181 for ; Fri, 11 May 2001 16:34:49 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA11502 for ietf-calendar-bks; Fri, 11 May 2001 13:19: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 NAA11485 for ; Fri, 11 May 2001 13:19: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 QAA02861 for ; Fri, 11 May 2001 16:19:06 -0400 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f4BKJ6v13629 for ; Fri, 11 May 2001 16:19:06 -0400 (EDT) Message-ID: <05dc01c0da57$690ec740$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3AF01851.43C21C69@netscape.com> Subject: Re: Attendee clarification Date: Fri, 11 May 2001 16:17: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 So, sifting through the clarifications & whatnot, it would seem that a correction to Steve's examples would look like this: > When an Organizer sends out an updated event and wants the Attendees to > reconfirm, the ATTENDEE property looks like this (I'm only listing the > relevant parameters, in general there will be more): > > ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@example.com > ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@e xample.com The PARTSTAT is "reset" to NEEDS-ACTION if the Organizer really wants attendees to re-confirm their statuses based on the new information. > When the Organizer sends out an updated version of the event and does > not require the Attendees to confirm, it looks like this: > > ATTENDEE;RSVP=FALSE;ROLE=REQ-PARTICIPANT:mailto:b@example.com > ATTENDEE;PARTSTAT=;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@example.com The PARTSTAT is left as-is, reflecting any replies (RSVP's) that the Organizer has received to date. So, Attendees who receive the update and agree with their currently listed PARTSTAT need not send a reply, whereas those who wish to change their PARTSTAT should send a reply. > When sending an event to a non-participant (like the 'cc' recipients of > an email message), it looks like this: > > ATTENDEE;RSVP=FALSE;ROLE=NON-PARTICIPANT:mailto:b@example.com > ATTENDEE;ROLE=NON-PARTICIPANT:mailto:b@example.com As Bruce mentioned, as the Attendee is not participating in the event, the Attendee has no meaningful PARTSTAT and thus there is no need to include the RSVP parameter. Does this make sense to everyone? Graham From owner-ietf-calendar@mail.imc.org Fri May 11 16:55:56 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20405 for ; Fri, 11 May 2001 16:55:56 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA14170 for ietf-calendar-bks; Fri, 11 May 2001 13:44: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 NAA14156 for ; Fri, 11 May 2001 13:44:54 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: CalSched IETF Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 16:45:48 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 04:50:10 PM, Serialize complete at 05/11/2001 04:50:10 PM Content-Type: multipart/alternative; boundary="=_alternative 0071E35385256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071E35385256A49_= Content-Type: text/plain; charset="us-ascii" John wrote on 05/11/2001 04:17:15 PM: > No. My objection is this: if you want to do scheduling, you need > feedback from the recipients, to find out whether or not they're > going to attend the meeting. Since an RSVP is not something that can coerce the CU to do anything, you wont get feedback from me anyway unless I want you to. However, for my lunch case where I do not need it, I do no like the thought of having to make my co-eater a NON-PARTICIPANT just because someone cannot answer my questions. So I will ask a 4th time (or is it 5th yet): So _PLEASE_ explain to me why my CUA would automagically send a REPLY to your 'typo' fix when my ATTENDEE value and property parameters (ie: PART-STAT=Accepted) are the same? There is _NO_ need for it to so it shouldn't. So why would the Organizer need/want to set RSVP=FALSE for just that iTIP message?? They have none! Or perhaps another way to ask is: Why should the Organizer put RSVP=FALSE on the typo update at all unless they had no need/desire to hear back at all? 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 0071E35385256A49_= Content-Type: text/html; charset="us-ascii"
John wrote on 05/11/2001 04:17:15 PM:
> No.  My objection is this: if you want to do scheduling, you need
> feedback from the recipients, to find out whether or not they're
> going to attend the meeting.  
Since an RSVP is not something that can coerce the CU to do anything, you wont get feedback from me anyway unless I want you to.  However, for my lunch case where I do not need it, I do no like the thought of having to make my co-eater a NON-PARTICIPANT just because someone cannot answer my questions.  So I will ask a 4th time (or is it 5th yet):

So _PLEASE_ explain to me why my CUA would automagically send a REPLY to your 'typo' fix when my ATTENDEE value and property parameters (ie: PART-STAT=Accepted) are the same?  There is _NO_ need for it to so it shouldn't.  So why would the Organizer need/want to set RSVP=FALSE for just that iTIP message??  They have none!  

Or perhaps another way to ask is: Why should the Organizer put RSVP=FALSE on the typo update at all unless they had no need/desire to hear back at all?

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 0071E35385256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 17:06:05 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20600 for ; Fri, 11 May 2001 17:06:05 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA14868 for ietf-calendar-bks; Fri, 11 May 2001 13:55:04 -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 NAA14864 for ; Fri, 11 May 2001 13:54:59 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Graham Gilmore" Cc: ietf-calendar@imc.org Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 16:55:55 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 05:00:16 PM, Serialize complete at 05/11/2001 05:00:16 PM Content-Type: multipart/alternative; boundary="=_alternative 0072D09785256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072D09785256A49_= Content-Type: text/plain; charset="us-ascii" Graham astutely noted on 05/11/2001 04:17:32 PM: > So, sifting through the clarifications & whatnot, it would seem that > a correction to Steve's examples would look like this: Your changes are all accurate. There is no (or yet to be postulated) reason for the Organizer to set RSVP=FALSE for a typo change (unless you view it as a Delivery Notification type flag)! > The PARTSTAT is "reset" to NEEDS-ACTION if the Organizer really > wants attendees to re-confirm their statuses based on the new > information. Assuming that their PARTSTAT value was not already NEEDS-ACTION then this is correct. Otherwise there is nothing really to 'reset' but essentilly yes. > ATTENDEE;PARTSTAT= this attendee>;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@example.com > > The PARTSTAT is left as-is, reflecting any replies (RSVP's) that the > Organizer has received to date. So, Attendees who receive the update > and agree with their currently listed PARTSTAT need not send a reply, > whereas those who wish to change their PARTSTAT should send a reply. And the crowd goes wild with excitement!! Its sinking in to some folks it seems. A hush settles over the crowd in eager anticiaption that the rest will soon follow... > As Bruce mentioned, as the Attendee is not participating in the > event, the Attendee has no meaningful PARTSTAT and thus there is no need > to include the RSVP parameter. And the excitement builds again... > Does this make sense to everyone? They hold their breath and wait... 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 0072D09785256A49_= Content-Type: text/html; charset="us-ascii"
Graham astutely noted on 05/11/2001 04:17:32 PM:
>     So, sifting through the clarifications & whatnot, it would seem that
> a correction to Steve's examples would look like this:
Your changes are all accurate.  There is no (or yet to be postulated) reason for the Organizer to set RSVP=FALSE for a typo change (unless you view it as a Delivery Notification type flag)!  

>     The PARTSTAT is "reset" to NEEDS-ACTION if the Organizer really
> wants attendees to re-confirm their statuses based on the new
> information.
Assuming that their PARTSTAT value was not already NEEDS-ACTION then this is correct.  Otherwise there is nothing really to 'reset' but essentilly yes.

>     ATTENDEE;PARTSTAT=<whatever status the organizer currently has for
> this attendee>;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@example.com
>
>     The PARTSTAT is left as-is, reflecting any replies (RSVP's) that the
> Organizer has received to date.  So, Attendees who receive the update
> and agree with their currently listed PARTSTAT need not send a reply,
> whereas those who wish to change their PARTSTAT should send a reply.
And the crowd goes wild with excitement!!  Its sinking in to some folks it seems.  A hush settles over the crowd in eager anticiaption that the rest will soon follow...

>     As Bruce mentioned, as the Attendee is not participating in the
> event, the Attendee has no meaningful PARTSTAT and thus there is no need
> to include the RSVP parameter.
And the excitement builds again...

>     Does this make sense to everyone?
They hold their breath and wait...

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 0072D09785256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 17:10:59 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20696 for ; Fri, 11 May 2001 17:10:59 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA15161 for ietf-calendar-bks; Fri, 11 May 2001 13:58: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 NAA15144 for ; Fri, 11 May 2001 13:58:49 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: "ietf-calendar@imc.org" Subject: Re: VTIMEZONE conflicts - possible solution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 16:59:40 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 05:04:06 PM, Serialize complete at 05/11/2001 05:04:06 PM Content-Type: multipart/alternative; boundary="=_alternative 0073284385256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073284385256A49_= Content-Type: text/plain; charset="us-ascii" John postualted on 05/11/2001 04:23:38 PM: > I think Damon's right; we should be able to put a TZNAME in the > VTIMEZONE. There would still be TZNAMEs in the STANDARD/DAYLIGHT > components. Can someone please tell me why we want it in both places when you and Damon just claimed that it is of no use in the VDAYLIGHT and VSTANDARD subcomponents? About the only logical reason I can think of is possibly so that some VERSION:2.0 engines wont choke and die w/o it but then again if they never use it as some claim, why would they choke and die?? 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 0073284385256A49_= Content-Type: text/html; charset="us-ascii"
John postualted on 05/11/2001 04:23:38 PM:
> I think Damon's right; we should be able to put a TZNAME in the
> VTIMEZONE.  There would still be TZNAMEs in the STANDARD/DAYLIGHT
> components.
Can someone please tell me why we want it in both places when you and Damon just claimed that it is of no use in the VDAYLIGHT and VSTANDARD subcomponents?  About the only logical reason I can think of is possibly so that some VERSION:2.0 engines wont choke and die w/o it but then again if they never use it as some claim, why would they choke and die??

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 0073284385256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 17:11:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20713 for ; Fri, 11 May 2001 17:11:24 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA15431 for ietf-calendar-bks; Fri, 11 May 2001 14:02:02 -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 OAA15421 for ; Fri, 11 May 2001 14:01:56 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4BL26d14041 for ; Fri, 11 May 2001 17:02:06 -0400 Message-ID: <3AFC534D.8C99D14@ecal.com> Date: Fri, 11 May 2001 17:02: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: CalSched IETF Subject: Re: Attendee clarification 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: > John wrote on 05/11/2001 04:17:15 PM: > > No. My objection is this: if you want to do scheduling, you > need > > feedback from the recipients, to find out whether or not > they're > > going to attend the meeting. > > Since an RSVP is not something that can coerce the CU to do > anything, you wont get feedback from me anyway unless I want > you to. Sure--and then I can't believe that the meeting is scheduled. But that wasn't the topic; we were discussing calendar systems which don't *allow* you to send that feedback. > So _PLEASE_ explain to me why my CUA would automagically send a > REPLY to your 'typo' fix when my ATTENDEE value and property > parameters (ie: PART-STAT=Accepted) are the same? You're changing the subject. You stated that the reasoning behind the design of RSVP included a desire to support systems that can't implement RSVP; I pointed out that such systems were not doing scheduling. The typo-fix is another thread. In addition, I'm not convinced that a typo fix shouldn't require new responses from the attendees. How is the protocol supposed to distinguish between typo fixes and other changes? You can leave it up to the ORGANIZER; but maybe the ORGANIZER didn't realize that the original typo changed the meaning of the message so much that the recipients' original decision to attend is invalid. (For example, suppose I accept an invitation saying "SUMMARY:Birthday Party for Joanie", and the typo is that it should have been "Janie"; I like Joanie but can't stand Janie. It's not up to the ORGANIZER to decide whether I still want to come.) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Collect call from reality, will you accept | |francis@ecal.com|the--" *click* | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri May 11 17:24:10 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20919 for ; Fri, 11 May 2001 17:24:10 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA15559 for ietf-calendar-bks; Fri, 11 May 2001 14:04:30 -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 OAA15554 for ; Fri, 11 May 2001 14:04:25 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4BL4ad14054 for ; Fri, 11 May 2001 17:04:36 -0400 Message-ID: <3AFC53E4.3963DB47@ecal.com> Date: Fri, 11 May 2001 17:04:36 -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: VTIMEZONE conflicts - possible solution 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: > > John postualted on 05/11/2001 04:23:38 PM: > > I think Damon's right; we should be able to put a TZNAME in > the > > VTIMEZONE. There would still be TZNAMEs in the > STANDARD/DAYLIGHT > > components. > > Can someone please tell me why we want it in both places when > you and Damon just claimed that it is of no use in the > VDAYLIGHT and VSTANDARD subcomponents? I did not say that. Having TZNAME in STANDARD & DAYLIGHT is useful for when you want to tell the user what timezone a non-recurring event is scheduled for. Having it in VTIMEZONE is useful for when you want to describe a recurring event, or when the user wants to pick a timezone from a list. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Where's your sense of adventure?" "In front of| |francis@ecal.com|a roaring fire with a cup of cocoa." | \================================================================/ From owner-ietf-calendar@mail.imc.org Fri May 11 17:46:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21291 for ; Fri, 11 May 2001 17:46:35 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA16271 for ietf-calendar-bks; Fri, 11 May 2001 14:33: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 OAA16266 for ; Fri, 11 May 2001 14:33:48 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: CalSched IETF Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 17:34:37 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 05:39:05 PM, Serialize complete at 05/11/2001 05:39:05 PM Content-Type: multipart/alternative; boundary="=_alternative 00765B3685256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00765B3685256A49_= Content-Type: text/plain; charset="us-ascii" John replied on 05/11/2001 05:02:05 PM: > > So _PLEASE_ explain to me why my CUA would automagically send a > > REPLY to your 'typo' fix when my ATTENDEE value and property > > parameters (ie: PART-STAT=Accepted) are the same? > > You're changing the subject. You stated that the reasoning > behind the design of RSVP included a desire to support systems > that can't implement RSVP; I pointed out that such systems were > not doing scheduling. The typo-fix is another thread. No I didnt. Doesnt anyone actually read the text that gets posted?? I said that the reason the terms MUST/MUST NOT etc were not in the text was that it would have been impossible for some vendors to implement and if it were mandated then a CUA that could support it would expect the non-supporting CUA to senda reply that it could NEVER generate. Im not changing the subject either. It was stipulated that the Organizer needed to set RSVP=FALSE on a typo update to avoid triggering the invitee's CUA from sending a reply (that smells a lot like...) Given my clarification text about TRUE vs FALSE (that some have yet to at least read it seems) then the question I ask is _DIRECTLY_ on the subject. Your argument was that a system that does not have the RSVP concept is not a C&S system, its a C system. Thats orthogonal to the intended meaning of RSVP... > In addition, I'm not convinced that a typo fix shouldn't require > new responses from the attendees. If nothing about the event has signficantly changed (ie: If the Organizer thinks Im going or not) but rather the change was simply trivail (ie: "SUMMARY: Confarence call" -> "SUMMARY:Confence call") then I dont need to respond. Even if the change was to fix the dial in information; my participation status has not changed and Im not going to counter w/a new time for that either. So, riddle me this Batman: Why would I need to response w/a new REPLY for this case? > How is the protocol supposed > to distinguish between typo fixes and other changes? I wont do an iCalendar 101/102 for you but I will use sarcasm since thats all I have left at 5PM on a Friday. The CUA has a full snapshot copy of the REQUEST from when it was first sent (or later updated). It also has the new REQUEST that is also a full snapshot. Presumably the CUA is going to be able to parse the REQUEST and will be able to detect changes, deletions and additions. Thats how we've talked about doing it for over 3 years now... > (For example, suppose I accept an invitation saying > "SUMMARY:Birthday Party for Joanie", and the typo is that it > should have been "Janie"; I like Joanie but can't stand Janie. > It's not up to the ORGANIZER to decide whether I still want to > come.) I have no clue where you pulled that last thought from. Id ask for enlightenment on it but I doubt it would help. Your CUA will have to process the "Janie" REQUEST and present it to you. Presumably it would be nice enough to show you the differences only (ie: "Updated values: SUMMARY changed to be 'Birthday Party for Janie'") and then it would let you do whatever you please w/it. If not, you see the new REQUEST and have to actually read it for a change to notice the change in SUMMARY. Since your particular ATTENDEE info has not changed (nor has the entry been rescheduled, etc) then your CUA has no reason to suggest that you resend a REPLY. If you noticed the change you could tell the CUA to Decline and send back a comment like "COMMENT:I can't stand Janie so cross me off the list". If you didn't notice it then whose to blame? The Organzier for not knowing you hate Janie?? Your CUA for not being psychic software(TM)? This all gets back to my question of WHY that you so nicely tried to avoid answering... Time to go home and discharge my sarcasm capacitors and cool off the frustration heatsinks in a nice cool bath of youthful optimism... 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 00765B3685256A49_= Content-Type: text/html; charset="us-ascii"
John replied on 05/11/2001 05:02:05 PM:
> > So _PLEASE_ explain to me why my CUA would automagically send a
> > REPLY to your 'typo' fix when my ATTENDEE value and property
> > parameters (ie: PART-STAT=Accepted) are the same?
>
> You're changing the subject.  You stated that the reasoning
> behind the design of RSVP included a desire to support systems
> that can't implement RSVP; I pointed out that such systems were
> not doing scheduling.  The typo-fix is another thread.

<TRYING TO HOLD FRUSTRATION AT BAY>
No I didnt.  Doesnt anyone actually read the text that gets posted??  I said that the reason the terms MUST/MUST NOT etc were not in the text was that it would have been impossible for some vendors to implement and if it were mandated then a CUA that could support it would expect the non-supporting CUA to senda  reply that it could NEVER generate.

Im not changing the subject either.  It was stipulated that the Organizer needed to set RSVP=FALSE on a typo update to avoid triggering the invitee's CUA from sending a reply (that smells a lot like...)  Given my clarification text about TRUE vs FALSE (that some have yet to at least read it seems) then the question I ask is _DIRECTLY_ on the subject.  Your argument was that a system that does not have the RSVP concept is not a C&S system, its a C system.  Thats orthogonal to the intended meaning of RSVP...
</TRYING>

> In addition, I'm not convinced that a typo fix shouldn't require
> new responses from the attendees.

If nothing about the event has signficantly changed (ie: If the Organizer thinks Im going or not) but rather the change was simply trivail (ie: "SUMMARY: Confarence call" -> "SUMMARY:Confence call") then I dont need to respond.  Even if the change was to fix the dial in information; my participation status has not changed and Im not going to counter w/a new time for that either.  So, riddle me this Batman: Why would I need to response w/a new REPLY for this case?

>                   How is the protocol supposed
> to distinguish between typo fixes and other changes?

I wont do an iCalendar 101/102 for you but I will use sarcasm since thats all I have left at 5PM on a Friday.  The CUA has a full snapshot copy of the REQUEST from when it was first sent (or later updated).  It also has the new REQUEST that is also a full snapshot.  Presumably the CUA is going to be able to parse the REQUEST and will be able to detect changes, deletions and additions.  Thats how we've talked about doing it for over 3 years now...

>           (For example, suppose I accept an invitation saying
> "SUMMARY:Birthday Party for Joanie", and the typo is that it
> should have been "Janie"; I like Joanie but can't stand Janie.
> It's not up to the ORGANIZER to decide whether I still want to
> come.)

I have no clue where you pulled that last thought from.  Id ask for enlightenment on it but I doubt it would help.  

Your CUA will have to process the "Janie" REQUEST and present it to you.  Presumably it would be nice enough to show you the differences only (ie: "Updated values: SUMMARY changed to be 'Birthday Party for Janie'") and then it would let you do whatever you please w/it.  If not, you see the new REQUEST and have to actually read it for a change to notice the change in SUMMARY.

Since your particular ATTENDEE info has not changed (nor has the entry been rescheduled, etc) then your CUA has no reason to suggest that you resend a REPLY.  If you noticed the change you could tell the CUA to Decline and send back a comment like "COMMENT:I can't stand Janie so cross me off the list".  If you didn't notice it then whose to blame?  The Organzier for not knowing you hate Janie??  Your CUA for not being psychic software(TM)?  

This all gets back to my question of WHY that you so nicely tried to avoid answering...

Time to go home and discharge my sarcasm capacitors and cool off the frustration heatsinks in a nice cool bath of youthful optimism...

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 00765B3685256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 17:51:20 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21367 for ; Fri, 11 May 2001 17:51:19 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA16720 for ietf-calendar-bks; Fri, 11 May 2001 14:41:50 -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 OAA16704 for ; Fri, 11 May 2001 14:41: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 RAA04644 for ; Fri, 11 May 2001 17:41:17 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4BLfGv21840 for ; Fri, 11 May 2001 17:41:16 -0400 (EDT) Message-Id: <5.0.0.25.0.20010511163801.02530820@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 May 2001 17:41:28 -0400 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: Attendee clarification 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 03:51 PM 11/05/2001 -0400, Bruce_Kahn@iris.com wrote: >Alan suggested: > >If Bruce's interpretation of RSVP is correct, there's > >not much difference between a REQ-PARTICIPANT with RSVP=FALSE > >and a NON-PARTICIPANT. > >First off, its not "my interpretation". I was expressly describing our >original intent when we designed and added RSVP. Ask Frank or Derik to >confirm this... Unfortunately I wasn't around at this time, so I am forced to base my interpretation on the RFCs themselves. It'd be nice to have some confirmation, especially as to why such vague language was used ("expectation of the favor of a response") for a property whose careless use would cause _no_ scheduling to take place between two CUAs. It'd also be nice also to hear from some other implementors as to how they interpret RSVP. >Another inherent part of this argument is that a ROLE=REQ-PARTICIAPNT (and >possibly OPT-PARTICPANT) have some implicit "respond" actions. That is, >if I see that Alan made me a REQ-PARTICIPANT then I must implicitly be >mandated to send him some kind of reply. Sorry, Alan cannot make me reply >if I dont want to nor is my role indicative of my abilty to >respond/counter/etc. You can reply as and when you want to. If you never reply, or you ignore my replies, then we're not doing any Scheduling; but that's your problem. >different entry line or some other GUI setup) instead of simply saying >"Send w/o requesting response" (or your favorite GUI action). Maybe (just speculating here...) you could send your REQUEST to Steve, with him as a REQ-PARTICIPANT, PARTSTAT=ACCEPTED, and RSVP=FALSE. He would see that as you already have the correct PARTSTAT (and RSVP was FALSE), he doesn't have to send a REPLY. Mind you, if he changed his mind in the meantime, he should be able to send you another REPLY to update his PARTSTAT- that's the idea behind 'my' version of RSVP=FALSE- he can send a REPLY as and when he wants to. >So _PLEASE_ explain to me why my CUA would automagically send a REPLY to >your 'typo' fix when my ATTENDEE value and property parameters (ie: >PART-STAT=Accepted) are the same? There is _NO_ need for it to so it >shouldn't. So why would the Organizer need/want to set RSVP=FALSE for >just that iTIP message?? They have none! To be reduced to quoting from the RFCs instead of my knowledge of past discussions again: RFC2446 2.1.4 Component Revisions In some circumstances the "Organizer" may not have received responses to the final revision sent out. In this situation, the "Organizer" may wish to send an update "REQUEST", and set "RSVP=TRUE" for all "Attendees", so that current responses can be collected. You see? The organiser was able to receive responses even though RSVP was set to FALSE, but he set it to TRUE to ensure Attendees responded to the "final version". Either RFC2446 is wrong or you are- one or the other, but we have to decide which so we can all interpret this property in the same way. --Alan From owner-ietf-calendar@mail.imc.org Fri May 11 18:10:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21754 for ; Fri, 11 May 2001 18:10:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA18981 for ietf-calendar-bks; Fri, 11 May 2001 15:00: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 PAA18974 for ; Fri, 11 May 2001 15:00:32 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4BM0hd14271 for ; Fri, 11 May 2001 18:00:43 -0400 Message-ID: <3AFC610B.53DCDD69@ecal.com> Date: Fri, 11 May 2001 18:00:43 -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: CalSched IETF Subject: Re: Attendee clarification 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: > Sorry. > No I didnt. Doesnt anyone actually read the text that gets > posted?? I said that the reason the terms MUST/MUST NOT etc > were not in the text was that it would have been impossible for > some vendors to implement I think that's what I meant. My position is just that those vendors are not doing scheduling, and a scheduling protocol does not need to accommodate them. > Im not changing the subject either. It was stipulated that the > Organizer needed to set RSVP=FALSE on a typo update to avoid > triggering the invitee's CUA from sending a reply (that smells > a lot like...) My point below was that there is no real difference between a typo update and any other update. The Organizer may guess that something is a trivial change, but they have no way of knowing whether I agree--and, if I don't, then sending RSVP=FALSE is a mistake, because it means I SHOULD NOT respond, even though my response is different now. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |All your problems can be solved by not caring!| |francis@ecal.com| | \===============================================================/ From owner-ietf-calendar@mail.imc.org Fri May 11 18:22:55 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22003 for ; Fri, 11 May 2001 18:22:54 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA19602 for ietf-calendar-bks; Fri, 11 May 2001 15:12:36 -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 PAA19598 for ; Fri, 11 May 2001 15:12:31 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 18:13:22 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 06:17:48 PM, Serialize complete at 05/11/2001 06:17:48 PM Content-Type: multipart/alternative; boundary="=_alternative 0079E78C85256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079E78C85256A49_= Content-Type: text/plain; charset="us-ascii" Alan replied on 05/11/2001 05:41:28 PM: > It'd be nice to have some confirmation, especially as to why > such vague language was used ("expectation of the favor of a > response") for a property whose careless use would cause _no_ > scheduling to take place between two CUAs. Hey Frank! Wake up and confirm/deny my clarification for these folks. Or you can use the archives and search for "RSVP". It should all be there somewhere. I dont think OOB emails were used for the entire thought process. > It'd also be nice also to hear from some other implementors as > to how they interpret RSVP. Ok this is probably the meat of the replys Im seeing. Clarification was asked for and I simply provided the original intent. Folks are still using their interpretation to argue over the clarification I provided... %^| > You can reply as and when you want to. If you never reply, or you > ignore my replies, then we're not doing any Scheduling; but that's > your problem. You are not hearing what Im saying. You as the Organizer cannot make me REPLY. You can only tell me if you want to hear back or not and I oblige. One thing you have ignored (or just forgot) is that each REQUEST is a full and complete snapshot of the current REQUEST. You however are treating the RSVP as a "one time use" setting. We do not have nor have we ever had a concept like that. It is simply not feasible to even try and do. Case in point: If I never get your 1st REQUEST then my CUA would be under the mistaken impression that you did not want me to send back ANY kind of Accept/Decline/Counter/etc. I could then NEVER have any workflow that you crave so strongly. If I receive your initial REQUEST afterwards then your CUA should ignore it by the simple rationale we put in Section 2.1.5 Message Sequencing of RFC 2446. So, the if the initial REQUEST arrives later then by your interpretation my CUA would have to use come criteria (voodoo?) to know if the RSVP=TRUE should be kept/set or not. (Or are you suggesting that for all ROLE=REQ-PARTICIPANTs that a REPLY must happen by virtue of the value I set???) All this still boils down to making RSVP a 'single shot' parameter and thats not wise! > Maybe (just speculating here...) you could send your REQUEST to Steve, with > him as a REQ-PARTICIPANT, PARTSTAT=ACCEPTED, and RSVP=FALSE. He would > see that as you already have the correct PARTSTAT (and RSVP was FALSE), > he doesn't have to send a REPLY. Ok, this again argues your view of RSVP against my clarification of intent. Its not exactly apples to apples but WHY would I want/need to set RSVP=FALSE for this invite?? > Mind you, if he changed his mind in the meantime, he should be able to send > you another REPLY to update his PARTSTAT- that's the idea behind 'my' version > of RSVP=FALSE- he can send a REPLY as and when he wants to. Ok, let me get this straight: The Organzier says "I do not want any responses back from any Attendee" and the Attendees just say "I dont care, Im going to send you a REPLY when I feel like it"? Why then would you even need/want the RSVP setting then in this view of things?? > RFC2446 2.1.4 Component Revisions > > In some circumstances the "Organizer" may not have received responses > to the final revision sent out. In this situation, the "Organizer" > may wish to send an update "REQUEST", and set "RSVP=TRUE" for all > "Attendees", so that current responses can be collected. > > You see? The organiser was able to receive responses even though > RSVP was set to FALSE, but he set it to TRUE to ensure Attendees > responded to the "final version". > > Either RFC2446 is wrong or you are- one or the other, but we have to > decide which so we can all interpret this property in the same way. What I expressed and continue to try and express so that it can be understood is that my reply was a clarification of the original intent of RSVP and why the text in 2445 seems a bit vague or wishy-washy. So its not a case of Im right or Im wrong. Im simply stating what was not accurately conveyd in the final 2445 descriptive text. As such, I suspect that 2446 has stale text in it. Oh my gosh! Say it isn't so!! The RFC could actually contain inconsistancies or inacuracies!! That can't be! Im crushed... Sob, sob... Damn it Frank, where are you!!!??? I dont like taking other peoples arrows! 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 0079E78C85256A49_= Content-Type: text/html; charset="us-ascii"
Alan replied on 05/11/2001 05:41:28 PM:
> It'd be nice to have some confirmation, especially as to why
> such vague language was used ("expectation of the favor of a
> response") for a property whose careless use would cause _no_
> scheduling to take place between two CUAs.
Hey Frank!  Wake up and confirm/deny my clarification for these folks.  Or you can use the archives and search for "RSVP".  It should all be there somewhere.  I dont think OOB emails were used for the entire thought process.

> It'd also be nice also to hear from some other implementors as
> to how they interpret RSVP.
Ok this is probably the meat of the replys Im seeing.  Clarification was asked for and I simply provided the original intent.  Folks are still using their interpretation to argue over the clarification I provided... %^|

> You can reply as and when you want to. If you never reply, or you
> ignore my replies, then we're not doing any Scheduling; but that's
> your problem.
You are not hearing what Im saying.  You as the Organizer cannot make me REPLY.  You can only tell me if you want to hear back or not and I oblige.  One thing you have ignored (or just forgot) is that each REQUEST is a full and complete snapshot of the current REQUEST.  You however are treating the RSVP as a "one time use" setting.  We do not have nor have we ever had a concept like that.  It is simply not feasible to even try and do.

Case in point: If I never get your 1st REQUEST then my CUA would be under the mistaken impression that you did not want me to send back ANY kind of Accept/Decline/Counter/etc.  I could then NEVER have any workflow that you crave so strongly.  If I receive your initial REQUEST afterwards then your CUA should ignore it by the simple rationale we put in Section 2.1.5 Message Sequencing of RFC 2446.  So, the if the initial REQUEST arrives later then by your interpretation my CUA would have to use come criteria (voodoo?) to know if the RSVP=TRUE should be kept/set or not.  (Or are you suggesting that for all ROLE=REQ-PARTICIPANTs that a REPLY must happen by virtue of the value I set???)  All this still boils down to making RSVP a 'single shot' parameter and thats not wise!

> Maybe (just speculating here...) you could send your REQUEST to Steve, with
> him as a REQ-PARTICIPANT, PARTSTAT=ACCEPTED, and RSVP=FALSE. He would
> see that as you already have the correct PARTSTAT (and RSVP was FALSE),
> he doesn't have to send a REPLY.
Ok, this again argues your view of RSVP against my clarification of intent.  Its not exactly apples to apples but WHY would I want/need to set RSVP=FALSE for this invite??  

> Mind you, if he changed his mind in the meantime, he should be able to send
> you another REPLY to update his PARTSTAT- that's the idea behind 'my' version
> of RSVP=FALSE- he can send a REPLY as and when he wants to.
Ok, let me get this straight: The Organzier says "I do not want any responses back from any Attendee" and the Attendees just say "I dont care, Im going to send you a REPLY when I feel like it"?  Why then would you even need/want the RSVP setting then in this view of things??

> RFC2446 2.1.4 Component Revisions
>
>      In some circumstances the "Organizer" may not have received responses
>      to the final revision sent out. In this situation, the "Organizer"
>      may wish to send an update "REQUEST", and set "RSVP=TRUE" for all
>      "Attendees", so that current responses can be collected.
>
> You see? The organiser was able to receive responses even though
> RSVP was set to FALSE, but he set it to TRUE to ensure Attendees
> responded to the "final version".
>
> Either RFC2446 is wrong or you are- one or the other, but we have to
> decide which so we can all interpret this property in the same way.
What I expressed and continue to try and express so that it can be understood is that my reply was a clarification of the original intent of RSVP and why the text in 2445 seems a bit vague or wishy-washy.  So its not a case of Im right or Im wrong.  Im simply stating what was not accurately conveyd in the final 2445 descriptive text.  As such, I suspect that 2446 has stale text in it.  Oh my gosh!  Say it isn't so!!  The RFC could actually contain inconsistancies or inacuracies!!  That can't be!  Im crushed...  Sob, sob...

Damn it Frank, where are you!!!???  I dont like taking other peoples arrows!

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 0079E78C85256A49_=-- From owner-ietf-calendar@mail.imc.org Fri May 11 18:39:09 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22225 for ; Fri, 11 May 2001 18:39:08 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA20751 for ietf-calendar-bks; Fri, 11 May 2001 15:29: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 PAA20742 for ; Fri, 11 May 2001 15:29:07 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: CalSched IETF Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Fri, 11 May 2001 18:30:04 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/11/2001 06:34:24 PM, Serialize complete at 05/11/2001 06:34:24 PM Content-Type: multipart/alternative; boundary="=_alternative 007B6F2485256A49_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B6F2485256A49_= Content-Type: text/plain; charset="us-ascii" John replied on 05/11/2001 06:00:43 PM: > I think that's what I meant. My position is just that those > vendors are not doing scheduling, and a scheduling protocol does > not need to accommodate them. Thats true for RFC 2446/2447 & CAP but not for RFC 2445. iCalendar is NOT a scheduling protocol. Its a canonical data format for representing calendar entries/tasks/journals/busytime/timezones/etc. iTIP is the scheduling protocol. As such, it may not belong in iTIP but it certainly does belong in iCalendar (it conveys the ability of the system or the desire of the Organizer or at least it was supposed to). > My point below was that there is no real difference between a > typo update and any other update. The Organizer may guess that > something is a trivial change, but they have no way of knowing > whether I agree--and, if I don't, then sending RSVP=FALSE is a > mistake, because it means I SHOULD NOT respond, even though my > response is different now. We already define 2 'classes' of update: Those that trigger rescheduling/renegotion automatically and those that do not. There are most defitely differences between them. Your response about "SHOULD NOT" is not as strong as it should be. The originally desired (and I think still desired) text was "MUST NOT". As for cases where FALSE is desireable: I can see building a kind of 'private calendar list' mechanism on it where events (et al) are REQUESTed from a central/coordinating Organizer but no response is desired. This would allow for ATTENDEEs to see who else may be involved and interact with them in some way (ie: "Bob & Paul & I are all invited to the BostonPM Reefknot presentation so maybe I can arrange to meet them for eats before hand!"). PUBLISH prohibits ATTENDEEs so using PUBLISH would never work to build this. (I told you guys back then that we should have kept ATTENDEEs in PUBLISHs for stuff like this!). Ok, I really am going home now... 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 007B6F2485256A49_= Content-Type: text/html; charset="us-ascii"
John replied on 05/11/2001 06:00:43 PM:
> I think that's what I meant.  My position is just that those
> vendors are not doing scheduling, and a scheduling protocol does
> not need to accommodate them.
Thats true for RFC 2446/2447 & CAP but not for RFC 2445.  iCalendar is NOT a scheduling protocol.  Its a canonical data format for representing calendar entries/tasks/journals/busytime/timezones/etc.  iTIP is the scheduling protocol.  As such, it may not belong in iTIP but it certainly does belong in iCalendar (it conveys the ability of the system or the desire of the Organizer or at least it was supposed to).

> My point below was that there is no real difference between a
> typo update and any other update.  The Organizer may guess that
> something is a trivial change, but they have no way of knowing
> whether I agree--and, if I don't, then sending RSVP=FALSE is a
> mistake, because it means I SHOULD NOT respond, even though my
> response is different now.
We already define 2 'classes' of update: Those that trigger rescheduling/renegotion automatically and those that do not.  There are most defitely differences between them.

Your response about "SHOULD NOT" is not as strong as it should be.  The originally desired (and I think still desired) text was "MUST NOT".  

As for cases where FALSE is desireable: I can see building a kind of 'private calendar list' mechanism on it where events (et al) are REQUESTed from a central/coordinating Organizer but no response is desired.  This would allow for ATTENDEEs to see who else may be involved and interact with them in some way (ie: "Bob & Paul & I are all invited to the BostonPM Reefknot presentation so maybe I can arrange to meet them for eats before hand!").  PUBLISH prohibits ATTENDEEs so using PUBLISH would never work to build this.  (I told you guys back then that we should have kept ATTENDEEs in PUBLISHs for stuff like this!).

Ok, I really am going home now...

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 007B6F2485256A49_=-- From owner-ietf-calendar@mail.imc.org Sat May 12 04:37:06 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13970 for ; Sat, 12 May 2001 04:37:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id BAA25623 for ietf-calendar-bks; Sat, 12 May 2001 01:24:38 -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 BAA25617 for ; Sat, 12 May 2001 01:24:33 -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 f4C8Nuv03716 for ; Sat, 12 May 2001 01:23:56 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GD7RBX00.GI8 for ; Sat, 12 May 2001 01:23:57 -0700 Message-ID: <3AFCF2E0.6CA1F0CB@netscape.com> Date: Sat, 12 May 2001 01:22:56 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: second try: RSVP usage in ITIP messages Content-Type: multipart/alternative; boundary="------------C14FB7697AF5B8565CBAA52A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------C14FB7697AF5B8565CBAA52A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All, Here's a second attempt to summarize RSVP in iTIP messages. * RSVP=TRUE is interpreted as: the Attendee is permitted to send the Organizer a REPLY message to change their PARTSTAT. The REPLY message can also be used to modify parameters such as DELEGATED-FROM and DELEGATED-TO. * RSVP=FALSE is interpreted as: the Attendee is not permitted to sent the Organizer a reply. In the case where the Organizer fixes a spelling error in the summary and resends the event to the attendees, the fact that RSVP=TRUE does not require an Attendee to send a REPLY. The REPLY is only necessary if the Attendee needs to change a parameter value (such as PARTSTAT). -Steve --------------C14FB7697AF5B8565CBAA52A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hey All,

Here's a second attempt to summarize RSVP in iTIP messages.

In the case where the Organizer fixes a spelling error in the summary and resends the event to the attendees, the fact that RSVP=TRUE does not require an Attendee to send a REPLY. The REPLY is only necessary if the Attendee needs to change a parameter value (such as PARTSTAT).

-Steve --------------C14FB7697AF5B8565CBAA52A-- From owner-ietf-calendar@mail.imc.org Sat May 12 07:41:02 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15216 for ; Sat, 12 May 2001 07:41:01 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA13604 for ietf-calendar-bks; Sat, 12 May 2001 04:23:25 -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 EAA13588; Sat, 12 May 2001 04:23:18 -0700 (PDT) Received: from [192.168.1.35] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA07377; Sat, 12 May 2001 13:21:57 +0200 (MET DST) Date: Sat, 12 May 2001 13:09:14 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: pregen@egenconsulting.com cc: Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com, owner-ietf-calendar@mail.imc.org, Ned Freed , Scott Bradner Subject: Calsch and CPL discussions Message-ID: <151796.989672954@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.0a5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id EAA13590 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 EAA13604 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA15216 The IESG is as a whole greatly concerned about the lack of ability to resolv the issues between the CPL spec and the spec which CALSH wg is working on. As responsible AD for the Calsh wg, I hereby ask the Calsh Wg to concentrate on this topic as the number one issue. It seems that you don't understand the seriousness of earlier requests from IESG. I don't see any other action items being worth working on until the CPL issues are resolved. This "not" is what blocks the whole work with CPL which an important ingredience in the architecture of IP Telephony. Regards, Patrik Faltstrom Co-Area Director, Applications Area --On 01-04-26 00.29 -0400 pregen@egenconsulting.com wrote: > > 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 ma! y ! 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 Patrik Fältström Cisco Systems Consulting Engineer Office of the CSO Phone: (Stockholm) +46-8-6859131 (San Jose) +1-408-525-8509 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Sat May 12 08:24:10 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15730 for ; Sat, 12 May 2001 08:24:09 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA18783 for ietf-calendar-bks; Sat, 12 May 2001 05:15:44 -0700 (PDT) Received: from biz1.mailsrvcs.net (biz1.gte.net [207.115.153.50]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA18773 for ; Sat, 12 May 2001 05:15:38 -0700 (PDT) Received: from [32.100.15.19] by biz1.mailsrvcs.net (Post.Office MTA v3.5.3 release 223 ID# 0-64117L5000S0V35) with ESMTP id net for ; Sat, 12 May 2001 06:56:44 -0500 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Sat, 12 May 2001 05:06:18 -0800 Subject: Mongolia time From: Rives McDow To: ietf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Arthur and all, In addition to Mongolia starting daylight savings as reported earlier (adopted dst on April 27, 2001,0200 local time, ending Sept. 28, 2001), there are three time zones. Provinces 19 hours from the IDL: Bayan-ulgii, Uvs, Khovd, Zavkhan, Govi-Altai Provinces 20 hours from the IDL: Khovsgol, Bulgan, Arkhangai, Khentii, Tov, Bayankhongor, Ovorkhangai, Dundgovi, Dornogovi, Omnogovi, Provinces 21 hours from the IDL: Choibalsan, Sukhbaatar Rives McDow From owner-ietf-calendar@mail.imc.org Sat May 12 13:17:35 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18521 for ; Sat, 12 May 2001 13:17:35 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA07136 for ietf-calendar-bks; Sat, 12 May 2001 10:07:14 -0700 (PDT) Received: from dancing-bare.dsl-only.net (dancing-bare.dsl-only.net [63.105.16.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA07127 for ; Sat, 12 May 2001 10:07:09 -0700 (PDT) Received: from coral (unverified [63.105.21.104]) by dancing-bare.dsl-only.net (Rockliffe SMTPRA 4.5.4) with SMTP id ; Sat, 12 May 2001 10:14:19 -0700 From: "coral" To: Cc: Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) Date: Sat, 12 May 2001 10:08:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Actually your "1*" change to "*1" makes the last 2 examples > illegal. They could ONLY have 0 or 1 digit so "15D" is bad > since it has 2 digits. Same for all the other cases subcomponents. Argh. Still new to ABNF. Thank you for the corrections, in the previous message as well. They make more sense now - I thought that ( a / b / c ) required all of {a,b,c} in any order, not any of {a,b,c}. > If you are trying to 'simplify' the ABNF so that you can have "PT10M" > (ie: no "0H") then this proposal wont do it. You would eliminate the > need for a "0" in front of the "H" but you would be left with "PTH10M" > instead. Not too helpful and kinda confusing. If you intend to make > it so that dur-hour is optional in a dur-time, thats not how it would > parse out. Im not sure if this just a misunderstaning on how to parse > the format or if there is a goal that is not being expressed so my > simple mind can grok it... Definitely a misunderstanding on how to write ABNF on my part. So, what would be the correct ABNF that would allow the following durations as valid? P4DT7H P1WT1M1S P1W PT23H59M PT0H0M59S P0WT0H1M P0W0DT0H0M1S P1W1D P1W1DT1M And how would that ABNF accomodate zero-value durations - "PT"? "PT0S"? Zero-value durations don't appear to be prevented by the RFC, and I'd like to be able to handle a request for a zero-value duration if the user of our Net::ICal module requested it (or reject it with an explanation of why the RFC prevents it). coral From owner-ietf-calendar@mail.imc.org Sat May 12 15:47:20 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19472 for ; Sat, 12 May 2001 15:47:19 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA11805 for ietf-calendar-bks; Sat, 12 May 2001 12:32:36 -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 MAA11797 for ; Sat, 12 May 2001 12:32:30 -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 PAA25745; Sat, 12 May 2001 15:32:17 -0400 Message-ID: <3AFD8ECD.A048BFE2@ximian.com> Date: Sat, 12 May 2001 15:28:13 -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: VTIMEZONE conflicts - possible solution References: <3AFC53E4.3963DB47@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: > > Bruce_Kahn@iris.com wrote: > > > > > John postualted on 05/11/2001 04:23:38 PM: > > > I think Damon's right; we should be able to put a TZNAME in > > the > > > VTIMEZONE. There would still be TZNAMEs in the > > STANDARD/DAYLIGHT > > > components. > > > > Can someone please tell me why we want it in both places when > > you and Damon just claimed that it is of no use in the > > VDAYLIGHT and VSTANDARD subcomponents? > > I did not say that. Having TZNAME in STANDARD & DAYLIGHT is > useful for when you want to tell the user what timezone a > non-recurring event is scheduled for. Having it in VTIMEZONE is > useful for when you want to describe a recurring event, or when > the user wants to pick a timezone from a list. This doesn't matter much for us, since we have a separate list of builtin timezones that the user gets to pick from. We are probably going to stick with the Olson city names for all references to our builtin timezones. So it just seems a bit silly to have to repeat the city name in each STANDARD/DAYLIGHT component. But it is probably too late to change the spec now. Damon From phoffman@above.proper.com Sat May 12 23:31:09 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24804 for ; Sat, 12 May 2001 23:31:08 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id UAA07256; Sat, 12 May 2001 20:31:12 -0700 (PDT) Date: Sat, 12 May 2001 20:31:12 -0700 (PDT) Message-Id: <200105130331.UAA07256@above.proper.com> To: calsch-archive@ietf.org From: subs-reminder@imc.org Subject: Subscription for calsch-archive@lists.ietf.org to the ietf-calendar mailing list Greetings. This message is a periodic reminder that you are subscribed to the ietf-calendar mailing list, and you are subscribed as: calsch-archive@lists.ietf.org There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-calendar mailing list, you do not need to do anyting. If you want to unsubscribe from this list, you can respond to this message and I will unsubscribe you. This may take a few days because it will be done by hand by a human. If you want to unsubscribe automatically, send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-calendar@mail.imc.org Sun May 13 05:02: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 FAA08432 for ; Sun, 13 May 2001 05:02:24 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id BAA26197 for ietf-calendar-bks; Sun, 13 May 2001 01:50:57 -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 BAA26188 for ; Sun, 13 May 2001 01:50:48 -0700 (PDT) Received: from [192.168.1.35] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA10659; Sun, 13 May 2001 10:50:16 +0200 (MET DST) Date: Sun, 13 May 2001 10:35:45 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: John Stracke , ietf-calendar@imc.org cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution Message-ID: <510344.989750145@localhost> In-Reply-To: <3AF6D1D5.8B1998B3@ecal.com> References: <3AF6D1D5.8B1998B3@ecal.com> X-Mailer: Mulberry/2.1.0a5 (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-05-07 12.48 -0400 John Stracke wrote: > It can happen, I think; there's no law that says that the Draft > Standard has to be a superset of the Proposed Standard. In fact, > there's at least one case where RFC-2026 mandates that features > be removed: Removing features when going from Proposed to Draft is not uncommon at all. It is one way of seeing that everything in the RFC is implementable and implemented and one find this out if nothing else while doing interoperability tests. paf From owner-ietf-calendar@mail.imc.org Mon May 14 10:25:57 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 KAA13242 for ; Mon, 14 May 2001 10:25:56 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA08951 for ietf-calendar-bks; Mon, 14 May 2001 06:54:55 -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 GAA08928 for ; Mon, 14 May 2001 06:54:49 -0700 (PDT) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: CalSched IETF Subject: Re: second try: RSVP usage in ITIP messages MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Mon, 14 May 2001 09:56:39 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/14/2001 09:55:54 AM, Serialize complete at 05/14/2001 09:55:54 AM Content-Type: multipart/alternative; boundary="=_alternative 004C55AE85256A4C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004C55AE85256A4C_= Content-Type: text/plain; charset="us-ascii" sman wrote on 05/12/2001 04:22:56 AM: > RSVP=TRUE is interpreted as: the Attendee is permitted to send the > Organizer a REPLY message to change their PARTSTAT. The REPLY > message can also be used to modify parameters such as DELEGATED-FROM > and DELEGATED-TO. The intent is good but Id add/modify this a tiny bit. I think you do not want to preclude a COUNTER (or to prevent a REFRESH request) do you?? You could expressly call out these cases too but then it would require us to revise the text if someone later addes a new METHOD. Can you/we phrase your text in such a way that it is clear that any workflow related kinds of actions (ie: accepting, declining, COUNTER, REFRESH, delegation, etc) are permitted only if RSVP=TRUE? > RSVP=FALSE is interpreted as: the Attendee is not permitted to sent > the Organizer a reply. Good (as long as that 'reply' is not a 'REPLY'). > In the case where the Organizer fixes a spelling error in the > summary and resends the event to the attendees, the fact that > RSVP=TRUE does not require an Attendee to send a REPLY. The REPLY is > only necessary if the Attendee needs to change a parameter value > (such as PARTSTAT). or if they want to COUNTER or REFRESH... 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 004C55AE85256A4C_= Content-Type: text/html; charset="us-ascii"
sman wrote on 05/12/2001 04:22:56 AM:
> RSVP=TRUE is interpreted as: the Attendee is permitted to send the
> Organizer a REPLY message to change their PARTSTAT. The REPLY
> message can also be used to modify parameters such as DELEGATED-FROM
> and DELEGATED-TO.
The intent is good but Id add/modify this a tiny bit.  I think you do not want to preclude a COUNTER (or to prevent a REFRESH request) do you??  You could expressly call out these cases too but then it would require us to revise the text if someone later addes a new METHOD.  Can you/we phrase your text in such a way that it is clear that any workflow related kinds of actions (ie: accepting, declining, COUNTER, REFRESH, delegation, etc) are permitted only if RSVP=TRUE?

> RSVP=FALSE is interpreted as: the Attendee is not permitted to sent
> the Organizer a reply.
Good (as long as that 'reply' is not a 'REPLY').

> In the case where the Organizer fixes a spelling error in the
> summary and resends the event to the attendees, the fact that
> RSVP=TRUE does not require an Attendee to send a REPLY. The REPLY is
> only necessary if the Attendee needs to change a parameter value
> (such as PARTSTAT).

or if they want to COUNTER or REFRESH...

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 004C55AE85256A4C_=-- From owner-ietf-calendar@mail.imc.org Mon May 14 10:42: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 KAA13862 for ; Mon, 14 May 2001 10:42:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA12891 for ietf-calendar-bks; Mon, 14 May 2001 07:27:55 -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 HAA12860 for ; Mon, 14 May 2001 07:27:42 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: hgs@cs.columbia.edu, ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Mon, 14 May 2001 10:29:40 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/14/2001 10:28:55 AM, Serialize complete at 05/14/2001 10:28:55 AM Content-Type: multipart/alternative; boundary="=_alternative 004F5BCA85256A4C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004F5BCA85256A4C_= Content-Type: text/plain; charset="us-ascii" John claimed: >> 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. > >Yeah, but RECUR is too big for calendaring, too. Pardon me but can you be a bit more vague w/that? Thats like saying "The PC wont work" and expecting someone to fix it over the phone... The recurrence grammar is somewhat confusing at first but is quite powerful. It can easily express farily complex and mundane recurrence patterns in a compact manner. That makes it ideal for Calendaring & Scheduling. We have had some ambiguities w/it but not all parts of it (or w/some of the parts proposed for removal). >It can happen, I think; there's no law that says that the Draft >Standard has to be a superset of the Proposed Standard. In fact, >there's at least one case where RFC-2026 mandates that features >be removed: This is not your other argument. You have claimed that its too "big" (err, complex??); not that 2 or more implementations do not implement it. The iptel argument so far seems to be one of "we want speed over complexity so we do not want to have x,y, & z in the grammar". These are not the same justifications you cite. In fact, there are at least 2 engines that I can think of that support stuff that is on the chopping list like BYSETPOS. Outlook uses it exclusively to represent stuff like "The 4th Thursday of the Month" and Organizer also supports it from what I recall. By removing 'unwanted' stuff from the grammar to make it easier for some to build, you have managed to make cuts that are non-backwards compatabile and that severly impact interoperatbility with existing early implimentors of the Drafts. Way to go. This is definitly starting to feel like a Monday already... Bruce PS: It seems this thread was not cross posted to the iptel list based on the addresses in my reply header above. Can someone repost that address and cross post this for me?? =========================================================================== 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 004F5BCA85256A4C_= Content-Type: text/html; charset="us-ascii"
John claimed:
>> 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.
>
>Yeah, but RECUR is too big for calendaring, too.
Pardon me but can you be a bit more vague w/that?  Thats like saying "The PC wont work" and expecting someone to fix it over the phone...

The recurrence grammar is somewhat confusing at first but is quite powerful.  It can easily express farily complex and mundane recurrence patterns in a compact manner.  That makes it ideal for Calendaring & Scheduling.  We have had some ambiguities w/it but not all parts of it (or w/some of the parts proposed for removal).

>It can happen, I think; there's no law that says that the Draft
>Standard has to be a superset of the Proposed Standard.  In fact,
>there's at least one case where RFC-2026 mandates that features
>be removed:

This is not your other argument.  You have claimed that its too "big" (err, complex??); not that 2 or more implementations do not implement it.  The iptel argument so far seems to be one of "we want speed over complexity so we do not want to have x,y, & z in the grammar".  These are not the same justifications you cite.

In fact, there are at least 2 engines that I can think of that support stuff that is on the chopping list like BYSETPOS.  Outlook uses it exclusively to represent stuff like "The 4th Thursday of the Month" and Organizer also supports it from what I recall.  By removing 'unwanted' stuff from the grammar to make it easier for some to build, you have managed to make cuts that are non-backwards compatabile and that severly impact interoperatbility with existing early implimentors of the Drafts.  Way to go.  

This is definitly starting to feel like a Monday already...

Bruce
PS: It seems this thread was not cross posted to the iptel list based on the addresses in my reply header above.  Can someone repost that address and cross post this for me??
===========================================================================
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 004F5BCA85256A4C_=-- From owner-ietf-calendar@mail.imc.org Mon May 14 10:57:35 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 KAA14257 for ; Mon, 14 May 2001 10:57:34 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA14174 for ietf-calendar-bks; Mon, 14 May 2001 07:45: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 HAA14156 for ; Mon, 14 May 2001 07:44: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 KAA19371; Mon, 14 May 2001 10:44:27 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4EEiRv26411; Mon, 14 May 2001 10:44:27 -0400 (EDT) Message-Id: <5.0.0.25.0.20010514101636.02461b10@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 14 May 2001 10:44:36 -0400 To: Bruce_Kahn@iris.com From: Alan Davies Subject: Re: Attendee clarification 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: At 06:13 PM 11/05/2001 -0400, Bruce_Kahn@iris.com wrote: >As such, I suspect that 2446 has stale text in it. Oh my gosh! Say it >isn't so!! The RFC could actually contain inconsistancies or >inacuracies!! That can't be! Im crushed... Sob, sob... I'm not crushed either, but we should at least log it as an issue for 2446; it seems that most of the text it contains related to RSVP is utterly wrong (the rest of the text refers to RSVP being subverted in a different way to allow a Delegator to continue to receive updates to an event, but that's another issue...). It's a shame that your "clarification" wasn't around when 2446 was submitted. If it was then the following sections would have stood out as being completely wrong: "2.1.4 Component Revisions" [...] In this situation, the "Organizer" may wish to send an update "REQUEST", and set "RSVP=TRUE" for all "Attendees", so that current responses can be collected. "3.2.2.7 Updating Attendee Status" The "Organizer" sends a "REQUEST" method "Attendee" and sets the "ATTENDEE;RSVP=TRUE" [...] The recipient SHOULD respond with a "REPLY" method indicating their current status with respect to the "REQUEST". "3.4.2.5 REQUEST Updated Attendee Status" The "Organizer" sends a "REQUEST" method to the "Attendee" with the "ATTENDEE;RSVP=TRUE" [...] The recipient SHOULD respond with a "REPLY" method indicating their current status with respect to the "REQUEST". "3.4.7 COUNTER" [...] the "Organizer" SHOULD reset the individual "RSVP" property parameter values to TRUE on each "ATTENDEE" property; in order to force a response by the "Attendees". --Alan From owner-ietf-calendar@mail.imc.org Mon May 14 11:13:03 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 LAA14738 for ; Mon, 14 May 2001 11:13:03 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA14827 for ietf-calendar-bks; Mon, 14 May 2001 07:55:42 -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 HAA14799 for ; Mon, 14 May 2001 07:55: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 KAA19641; Mon, 14 May 2001 10:55:05 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4EEt4v27416; Mon, 14 May 2001 10:55:05 -0400 (EDT) Message-Id: <5.0.0.25.0.20010514104600.0255bd00@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 14 May 2001 10:55:13 -0400 To: Bruce_Kahn@iris.com From: Alan Davies Subject: Re: Attendee clarification 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: At 06:13 PM 11/05/2001 -0400, Bruce_Kahn@iris.com wrote: >You are not hearing what Im saying. You as the Organizer cannot make me >REPLY. You can only tell me if you want to hear back or not and I oblige. None of the RFCs state this, and in some situations 2446 states the opposite: 3.2.2.3 Delegating an Event to another CU [...] In response to the request, the "Delegate" MUST send a "REPLY" method to the "Organizer" and optionally, to the "Delegator".[...] that was a 'MUST' in capital letters, implying that non-scheduling CUAs are not being considered. RFC2446 seems to have the funny notion that we are creating a scheduling protocol here, but that's may be just "stale text" as well. --Alan From owner-ietf-calendar@mail.imc.org Mon May 14 11:15: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 LAA14803 for ; Mon, 14 May 2001 11:15:13 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA15190 for ietf-calendar-bks; Mon, 14 May 2001 08:00:15 -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 IAA15178 for ; Mon, 14 May 2001 08:00:09 -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 f4EExdn19127 for ; Mon, 14 May 2001 07:59:39 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GDBYZE00.88M; Mon, 14 May 2001 07:59:38 -0700 Message-ID: <3AFFF316.6A95826A@netscape.com> Date: Mon, 14 May 2001 08:00:38 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: CalSched IETF Subject: Re: second try: RSVP usage in ITIP messages References: Content-Type: multipart/mixed; boundary="------------6AE14A4171088B85A2071BF0" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6AE14A4171088B85A2071BF0 Content-Type: multipart/alternative; boundary="------------740AAEC9DEEB3AFF370DC9E9" --------------740AAEC9DEEB3AFF370DC9E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > sman wrote on 05/12/2001 04:22:56 AM: > > RSVP=TRUE is interpreted as: the Attendee is permitted to send the > > Organizer a REPLY message to change their PARTSTAT. The REPLY > > message can also be used to modify parameters such as DELEGATED-FROM > > > and DELEGATED-TO. > > The intent is good but Id add/modify this a tiny bit. I think you do > not want to preclude a COUNTER (or to prevent a REFRESH request) do > you?? You could expressly call out these cases too but then it would > require us to revise the text if someone later addes a new METHOD. > Can you/we phrase your text in such a way that it is clear that any > workflow related kinds of actions (ie: accepting, declining, COUNTER, > REFRESH, delegation, etc) are permitted only if RSVP=TRUE? I see your point. Yes, I can reword it. Are others OK with this? > > RSVP=FALSE is interpreted as: the Attendee is not permitted to sent > > the Organizer a reply. > > Good (as long as that 'reply' is not a 'REPLY'). right, I'll watch the capitalization. > > In the case where the Organizer fixes a spelling error in the > > summary and resends the event to the attendees, the fact that > > RSVP=TRUE does not require an Attendee to send a REPLY. The REPLY is > > > only necessary if the Attendee needs to change a parameter value > > (such as PARTSTAT). > > or if they want to COUNTER or REFRESH... yep. I'll send out a 3rd try. -Steve > > > 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... > --------------740AAEC9DEEB3AFF370DC9E9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

sman wrote on 05/12/2001 04:22:56 AM:
> RSVP=TRUE is interpreted as: the Attendee is permitted to send the
> Organizer a REPLY message to change their PARTSTAT. The REPLY
> message can also be used to modify parameters such as DELEGATED-FROM
> and DELEGATED-TO.

The intent is good but Id add/modify this a tiny bit.  I think you do not want to preclude a COUNTER (or to prevent a REFRESH request) do you??  You could expressly call out these cases too but then it would require us to revise the text if someone later addes a new METHOD.  Can you/we phrase your text in such a way that it is clear that any workflow related kinds of actions (ie: accepting, declining, COUNTER, REFRESH, delegation, etc) are permitted only if RSVP=TRUE?

I see your point.  Yes, I can reword it.  Are others OK with this?
> RSVP=FALSE is interpreted as: the Attendee is not permitted to sent
> the Organizer a reply.

Good (as long as that 'reply' is not a 'REPLY').

right, I'll watch the capitalization.
> In the case where the Organizer fixes a spelling error in the
> summary and resends the event to the attendees, the fact that
> RSVP=TRUE does not require an Attendee to send a REPLY. The REPLY is
> only necessary if the Attendee needs to change a parameter value
> (such as PARTSTAT).

or if they want to COUNTER or REFRESH...

yep.  I'll send out a 3rd try.

-Steve

 

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...
 

--------------740AAEC9DEEB3AFF370DC9E9-- --------------6AE14A4171088B85A2071BF0 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------6AE14A4171088B85A2071BF0-- From owner-ietf-calendar@mail.imc.org Mon May 14 11:58: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 LAA16082 for ; Mon, 14 May 2001 11:58:08 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA18613 for ietf-calendar-bks; Mon, 14 May 2001 08:44:35 -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 IAA18581 for ; Mon, 14 May 2001 08:44:28 -0700 (PDT) From: Frank.Dawson@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4EFibg21318 for ; Mon, 14 May 2001 10:44:37 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 14 May 2001 10:44:20 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 14 May 2001 10:44:20 -0500 Message-ID: <30F2DED23724D311902D0008C7EABAFB03F34A6C@daeis06nok> To: aland@steltor.com, Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org Subject: RE: Attendee clarification Date: Mon, 14 May 2001 10:44:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > RFC2446 seems to have the funny notion > that we are creating a scheduling protocol here, but that's > may be just > "stale text" as well. The RFC2446/iTIP is in fact a scheduling protocol specification. -- Frank From owner-ietf-calendar@mail.imc.org Mon May 14 12:06: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 MAA16320 for ; Mon, 14 May 2001 12:06:24 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA19327 for ietf-calendar-bks; Mon, 14 May 2001 08:50:27 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA19311 for ; Mon, 14 May 2001 08:50:20 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4EFp0827545; Mon, 14 May 2001 11:51:00 -0400 Message-ID: <3AFFFEE3.FB1CF072@ecal.com> Date: Mon, 14 May 2001 11:50:59 -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: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution 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: > John claimed: > > >Yeah, but RECUR is too big for calendaring, too. > > Pardon me but can you be a bit more vague w/that? Heh. I suppose I could: "Um...RECUR...I dunno..." ;-) But I was vague because we've gone over this before, and I went into detail then. > The recurrence grammar is somewhat confusing at first but is > quite powerful. That is, in fact, the problem: how do you build a user interface that expresses the full power? It can be done, I suppose, but it's going to be *massively* complex, very hard for users to learn. The problem is that the recurrence rules are designed as a grammar, with the expectation that there'll be no difficulty in getting engines to understand and expand them. From that viewpoint, it's not a particularly complex grammar; but, from the viewpoint of a user who has to be able to take a recurrence rule, hold in their head, and maybe edit it, it's *far* too complicated. To repeat the example I posted in my draft-stracke-calsch-rrule-subset-00.txt (unsubmitted, but posted to the WG: ), iCalendar lets you specify an event which: * occurs every 79 seconds, * also occurs at 3:15:25 PM on the 12th, 37th, and 159th days of the year, * but does not occur unless it's 13 or 23 seconds after the minute, * and does not occur on the second Tuesday of the month. This is absurd--and yet, any compliant implementation has to be able to accept it, expand it (not too hard), show it to the user (difficult), and let the user edit it (well-nigh impossible). (In fact, I've since realized I could've come up with something even more complex, since RRULE and EXRULE can each appear multiple times in a VEVENT.) > >It can happen, I think; there's no law that says that the > Draft > >Standard has to be a superset of the Proposed Standard. In > fact, > >there's at least one case where RFC-2026 mandates that > features > >be removed: > > This is not your other argument. You have claimed that its too > "big" (err, complex??); not that 2 or more implementations do > not implement it. In fact, my objections are based largely on the prediction that no two implementations will implement the same subset of RECUR. To quote my draft again: In order to make the user interface comprehensible, each CUA will probably expose only a subset of the available recurrence features to the user. The risk, then, is that different CUAs will expose different subsets, and will not be properly tested for iCalendar objects which stray outside those subsets. Even if they expand those iCalendar objects correctly, they may not display the full recurrence rule correctly, since that would require complicating the UI. If that happens, the user will wind up seeing that the recurrence rule for their repeating event says it occurs every Monday, but the calendar does not show the event on every Monday; there are gaps. Confusing the users like this effectively means that there will not be interoperability: even if the underlying iCalendar implementations understand each other, the users don't. > In fact, there are at least 2 engines that I can think of that > support stuff that is on the chopping list like BYSETPOS. > Outlook uses it exclusively to represent stuff like "The 4th > Thursday of the Month" and Organizer also supports it from what > I recall. It is not enough to be able to say "implementations A and B use BYSETPOS, and implementations C and D use UNTIL, so they both can stay in". For iCalendar to advance to Draft Standard, there must be two implementations which implement the *entire* RECUR grammar. In my opinion, "implement" in this case must cover the user interface, not just the backend. (Patrik, am I right on this procedural point? I'm relying in part on your ruling that 1 day == 24 hours would confuse the users.) > By removing 'unwanted' stuff from the grammar to make it > easier for some to build, you have managed to make cuts that > are non-backwards compatabile and that severly impact > interoperatbility with existing early implimentors of the > Drafts. Way to go. But this is a normal part of the IETF process: the spec will change as it proceeds from Internet-Draft to Proposed Standard to Draft Standard to (rarely) Standard. The IETF's goal is produce good standards for interop, which will be used for a long, long time; the only way to be sure of that is to judge the early implementations, and tweak the specs accordingly. That necessarily implies that early adopters are risking some transition pain in the short run, in order to improve interop over the long run. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |You're just jealous because the voices only talk| |francis@ecal.com|to me. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon May 14 13:20: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 NAA18666 for ; Mon, 14 May 2001 13:20:24 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA27088 for ietf-calendar-bks; Mon, 14 May 2001 10:00:41 -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 KAA27080 for ; Mon, 14 May 2001 10:00:35 -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 NAA22666 for ; Mon, 14 May 2001 13:00:07 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4EH03v09317 for ; Mon, 14 May 2001 13:00:03 -0400 (EDT) Message-Id: <5.0.0.25.0.20010514114142.02573b18@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 14 May 2001 13:00:12 -0400 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: Calsch and CPL discussions In-Reply-To: <151796.989672954@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA27081 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 KAA27088 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA18666 I don't know how these issues are usually resolved, but it seems that the discussion came to a standstill, as many ideas were suggested but noone really pushed for any one solution. Here's a look at 3 candidate outcomes to this issue: 1. iCalendar uses the RRULE subset suggested in the CPL spec. 2. CPL adopts the full iCalendar RRULE grammar. 3. iCalendar doesn't change RRULE, iptel uses it's own RRULE subset. Most on the Calsch list seemed to be fine with 2. or 3., but some are opposed to 1. as it would break compatibility with existing implementations. Some think that 1. would be good for iCalendar though, as it's RRULEs are overly complex at the moment. The authors of CPL don't seem to consider 2. to be viable, as 0(1) computation of a given time within an RRULE is of prime importance to them. iCalendar RRULEs don't satisfy this, within the scope of our combined mathematical abilities at any rate. http://www.imc.org/ietf-calendar/mail-archive/msg06220.html Patrik seems to prefer a solution somewhere between 1. and 2. He implied that the IESG wouldn't be overjoyed with with 3., but may be willing to accept it. http://www.imc.org/ietf-calendar/mail-archive/msg06466.html So where do we go from here? --Alan At 01:09 PM 12/05/2001 +0200, Patrik Fältström wrote: >The IESG is as a whole greatly concerned about the lack of ability to >resolv the issues between the CPL spec and the spec which CALSH wg is >working on. > >As responsible AD for the Calsh wg, I hereby ask the Calsh Wg to >concentrate on this topic as the number one issue. It seems that you don't >understand the seriousness of earlier requests from IESG. > >I don't see any other action items being worth working on until the CPL >issues are resolved. > >This "not" is what blocks the whole work with CPL which an important >ingredience in the architecture of IP Telephony. > > Regards, Patrik Faltstrom > Co-Area Director, Applications Area > >--On 01-04-26 00.29 -0400 pregen@egenconsulting.com wrote: > > > > > 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 ma! y ! 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 > > > >Patrik Fältström Cisco Systems >Consulting Engineer Office of the CSO >Phone: (Stockholm) +46-8-6859131 (San Jose) +1-408-525-8509 > PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Mon May 14 13:53: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 NAA19784 for ; Mon, 14 May 2001 13:53:12 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA28797 for ietf-calendar-bks; Mon, 14 May 2001 10:39:44 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA28787 for ; Mon, 14 May 2001 10:39:38 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f4EHdb202626; Mon, 14 May 2001 10:39:37 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 14 May 2001 10:39:37 -0700 (PDT) From: Eric Busboom X-X-Sender: To: cc: , Subject: RECAP & Questions of CPL RECUR Issues. In-Reply-To: <3AFFFEE3.FB1CF072@ecal.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: John, Johnathan, This is how I understand the problems that the IPTEL group identified with RECUR. Are these correct? (1) Telephony equipment must be able to check that a given time is included with in the events specified by a DTSTART, DURATION and set of RRULES, RDATEs, EXRULEs and EXDATEs in constant time. ( Or is it O(n) for the number of elements in the byrules? ) Generally, RECUR rules require O(n) in the number of occurrences. Other problems that have been identified include: (2) Because the RRULEs are so complex, and because there are many different ways to specify a single set of occurrences, it will be very difficult for a CUA to create a GUI that can manipulate any arbitrary incoming RRULEs. The proposed solutions are: (1) Remove COUNT (2) Remove BYSETPOS (3) Remove byrules and frequencies for hour, minute and second. (4) Limit the duration of an event to less than 24 hours. (1) and (2) are proposed to directly allow constant time operation. (3) and (4) are proposed to disallow a RRULE from generating any two occurrences that overlap. Overlapping rules compicate a specific algotithm for performing (1). Now, for some questions. For (1). Is it O(1) or O(n) with number of BYrule elements? The body of draft-stracke-calsch-rrule-subset-XX.txt says O(1), but the algorithm in the appendix implies O(n). Or does the O(1) mean "O(1) in number of occurrences?" Past discussions noted that the algorithm may be O(1) in a single rule, but will be linear with respect to multiple rules. So what would you do with a client that always expanded recurrence rules to RDATE? (thereby forcing O(n). ) Would the telephony equipment set a limit on the maximum number of RDATE, RRULE, EXRULE and EXDATE properties it would accept, and reject anything over that limit? And, if the algorithm is O(n) with number of rules, and actually O(n) with number of BYxxx rule part elements in each rule, then in the general case the algorithm is O(n^2) in the size of the RRULE, a long way from O(1). So, do you really need O(1), or can you get by with an very fast check of the upper bound of the occurrence set? That is, what if you could quickly determine if the rrule is too complex for your processor to handle? Also, please review the current proposed text change for for RECUR, issue #15 at: http://softwarestudio.org/iCal/ProposedChanges.txt These restrictions prevent many absurd examples like the one in draft-stracke-calsch-rrule-subset-XX.txt. eric. From owner-ietf-calendar@mail.imc.org Mon May 14 13:57:18 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 NAA19930 for ; Mon, 14 May 2001 13:57:17 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA28847 for ietf-calendar-bks; Mon, 14 May 2001 10:42:26 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA28843 for ; Mon, 14 May 2001 10:42:20 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA19363 for ; Mon, 14 May 2001 12:39:32 -0500 From: "Shannon J. Clark" To: Subject: RE: Calsch and CPL discussions Date: Mon, 14 May 2001 12:41:35 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <5.0.0.25.0.20010514114142.02573b18@imap1.in.steltor.com> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id KAA28847 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA19930 A fourth option that I have suggested before - but does have a number of issues with it, is that the RRULE's are separated from the iCalendar draft and are made into a separate draft. This has some advantages: One - the resulting iCalendar draft is simplified which should help adoption Two - Issues specific to reoccurrence rules can be dealt with in isolation from a particular problem set (i.e. iCalendar) - this certainly includes whether the rules can be resolved in O(1) or not. Three - The reoccurrence rules would be available for use in new problem domains where the full iCalendar is inappropriate - to use examples that have been suggested here, as a possible grammar for reoccurrence rules for cache refresh schedules. To keep initial drift between standards to a minimum the first version of the RRULES spec could be exactly what is present in the current iCalendar spec. (it has been observed previously here that the RRULES are one of the "only things that make iCalendar special" - I beg to differ, and if this is the case, it is an argument for moving them to a separate document.) Shannon Shannon J. Clark 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 Alan Davies Sent: Monday, May 14, 2001 12:00 PM To: ietf-calendar@imc.org Subject: Re: Calsch and CPL discussions I don't know how these issues are usually resolved, but it seems that the discussion came to a standstill, as many ideas were suggested but noone really pushed for any one solution. Here's a look at 3 candidate outcomes to this issue: 1. iCalendar uses the RRULE subset suggested in the CPL spec. 2. CPL adopts the full iCalendar RRULE grammar. 3. iCalendar doesn't change RRULE, iptel uses it's own RRULE subset. Most on the Calsch list seemed to be fine with 2. or 3., but some are opposed to 1. as it would break compatibility with existing implementations. Some think that 1. would be good for iCalendar though, as it's RRULEs are overly complex at the moment. The authors of CPL don't seem to consider 2. to be viable, as 0(1) computation of a given time within an RRULE is of prime importance to them. iCalendar RRULEs don't satisfy this, within the scope of our combined mathematical abilities at any rate. http://www.imc.org/ietf-calendar/mail-archive/msg06220.html Patrik seems to prefer a solution somewhere between 1. and 2. He implied that the IESG wouldn't be overjoyed with with 3., but may be willing to accept it. http://www.imc.org/ietf-calendar/mail-archive/msg06466.html So where do we go from here? --Alan At 01:09 PM 12/05/2001 +0200, Patrik Fältström wrote: >The IESG is as a whole greatly concerned about the lack of ability to >resolv the issues between the CPL spec and the spec which CALSH wg is >working on. > >As responsible AD for the Calsh wg, I hereby ask the Calsh Wg to >concentrate on this topic as the number one issue. It seems that you don't >understand the seriousness of earlier requests from IESG. > >I don't see any other action items being worth working on until the CPL >issues are resolved. > >This "not" is what blocks the whole work with CPL which an important >ingredience in the architecture of IP Telephony. > > Regards, Patrik Faltstrom > Co-Area Director, Applications Area > >--On 01-04-26 00.29 -0400 pregen@egenconsulting.com wrote: > > > > > 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 ma! y ! 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 > > > >Patrik Fältström Cisco Systems >Consulting Engineer Office of the CSO >Phone: (Stockholm) +46-8-6859131 (San Jose) +1-408-525-8509 > PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Mon May 14 14:14:47 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 OAA20274 for ; Mon, 14 May 2001 14:14:46 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA29372 for ietf-calendar-bks; Mon, 14 May 2001 11:03:08 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA29364 for ; Mon, 14 May 2001 11:03:02 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4EI3h828063 for ; Mon, 14 May 2001 14:03:43 -0400 Message-ID: <3B001DFA.68069940@ecal.com> Date: Mon, 14 May 2001 14:03:38 -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: CalSched IETF Subject: Re: Attendee clarification 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: > John replied on 05/11/2001 06:00:43 PM: > > I think that's what I meant. My position is just that those > > vendors are not doing scheduling, and a scheduling protocol > does > > not need to accommodate them. > > Thats true for RFC 2446/2447 & CAP but not for RFC 2445. > iCalendar is NOT a scheduling protocol. Its a canonical data > format for representing calendar > entries/tasks/journals/busytime/timezones/etc. Then why does it define RSVP at all? RSVP is clearly for use in scheduling. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"And bring the search warrant." "You mean the| |francis@ecal.com|sledgehammer, sir?" "Yes." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon May 14 14:19:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20395 for ; Mon, 14 May 2001 14:19:25 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA29424 for ietf-calendar-bks; Mon, 14 May 2001 11:05:37 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA29420 for ; Mon, 14 May 2001 11:05:31 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4EI6A828071 for ; Mon, 14 May 2001 14:06:10 -0400 Message-ID: <3B001E91.9BA4AB92@ecal.com> Date: Mon, 14 May 2001 14:06:10 -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: Calsch and CPL discussions 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: > A fourth option that I have suggested before - but does have a number of > issues with it, is that the RRULE's are separated from the iCalendar draft > and are made into a separate draft. > > This has some advantages: > > One - the resulting iCalendar draft is simplified which should help adoption Actually, I suspect it would hurt adoption, because a calendar data model without recurring events is not very useful. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"If it failed then, there's no reason to think| |francis@ecal.com|we can't make it fail now." -- Colin Benson | \===============================================================/ From owner-ietf-calendar@mail.imc.org Mon May 14 14:26: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 OAA20679 for ; Mon, 14 May 2001 14:26:36 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA28944 for ietf-calendar-bks; Mon, 14 May 2001 10:46:39 -0700 (PDT) Received: from capricorn.iris.com (capricorn.iris.com [198.112.211.43]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA28939 for ; Mon, 14 May 2001 10:46:30 -0700 (PDT) From: Bruce_Kahn@iris.com To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Attendee clarification MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Mon, 14 May 2001 12:48:51 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Beta 2 M9_05062001|May 06, 2001) at 05/14/2001 01:47:40 PM, Serialize complete at 05/14/2001 01:47:40 PM Content-Type: multipart/alternative; boundary="=_alternative 005C2FCD85256A4C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C2FCD85256A4C_= Content-Type: text/plain; charset="us-ascii" Alan fired back on 05/14/2001 10:55:13 AM: > 3.2.2.3 Delegating an Event to another CU > [...] In response to the request, the "Delegate" MUST send a > "REPLY" method > to the "Organizer" and optionally, to the "Delegator".[...] > > that was a 'MUST' in capital letters, implying that non-scheduling > CUAs are not being considered. RFC2446 seems to have the funny notion > that we are creating a scheduling protocol here, but that's may be just > "stale text" as well. There is a difference between a REPLY and a reply. The former is an iTIP response of some kind. The latter is a delivery confirmation (in this context). So, from your text do I infer that you expect me, as the Delegated arrow taker for Frank, to automagically send a REPLY in response to the delegation notice EVEN IF NOTHING CHANGED (ie: I didnt accept/decline/redelegate)??? Id hope not but if so (to save time), WHY!? What is gained by this?? If you implicitly assume that I _must_ take action immediately upon receipt then that too is something Id question. I would never use a product that made me do something I did not want to do (ie: "You MUST reply to Franks delegated REQUEST now!") If you are assuming that at some point in the future I will want to reply and that the "MUST" you cited is my imperative for this then you are treating it differently than you are describing it. I would expect that any delegate (or original invitee) would actually send a REPLY if their participation status (or other settings) change but only then, not before. Im going to abide by Patricks admonishment and no longer persue this thread until we reach some closure on the iptel issues. Plus I like Steve's latest clarification; I think its right on. Bruce PS: With only 1 editor in common between 2445 and 2446 it is no wonder that some changes were not equally applied or concepts are not necessarily 100% in agreement between the two RFCs. This is not a reflection on the editors skills but more a reflection on our WG's ability to intercommunicate clearly. =========================================================================== 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 005C2FCD85256A4C_= Content-Type: text/html; charset="us-ascii"
Alan fired back on 05/14/2001 10:55:13 AM:
> 3.2.2.3 Delegating an Event to another CU
>     [...] In response to the request, the "Delegate" MUST send a
> "REPLY" method
>     to the "Organizer" and optionally, to the "Delegator".[...]
>
> that was a 'MUST' in capital letters, implying that non-scheduling
> CUAs are not being considered. RFC2446 seems to have the funny notion
> that we are creating a scheduling protocol here, but that's may be just
> "stale text" as well.
There is a difference between a REPLY and a reply.  The former is an iTIP response of some kind.  The latter is a delivery confirmation (in this context).  

So, from your text do I infer that you expect me, as the Delegated arrow taker for Frank, to automagically send a REPLY in response to the delegation notice EVEN IF NOTHING CHANGED (ie: I didnt accept/decline/redelegate)???  Id hope not but if so (to save time), WHY!?  What is gained by this??  

If you implicitly assume that I _must_ take action immediately upon receipt then that too is something Id question.  I would never use a product that made me do something I did not want to do (ie: "You MUST reply to Franks delegated REQUEST now!")

If you are assuming that at some point in the future I will want to reply and that the "MUST" you cited is my imperative for this then you are treating it differently than you are describing it.  I would expect that any delegate (or original invitee) would actually send a REPLY if their participation status (or other settings) change but only then, not before.  

Im going to abide by Patricks admonishment and no longer persue this thread until we reach some closure on the iptel issues.  Plus I like Steve's latest clarification; I think its right on.

Bruce
PS: With only 1 editor in common between 2445 and 2446 it is no wonder that some changes were not equally applied or concepts are not necessarily 100% in agreement between the two RFCs.  This is not a reflection on the editors skills but more a reflection on our WG's ability to intercommunicate clearly.
===========================================================================
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 005C2FCD85256A4C_=-- From owner-ietf-calendar@mail.imc.org Mon May 14 14:28:28 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 OAA20720 for ; Mon, 14 May 2001 14:28:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA29534 for ietf-calendar-bks; Mon, 14 May 2001 11:11:56 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA29530 for ; Mon, 14 May 2001 11:11:50 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4EICT828091; Mon, 14 May 2001 14:12:29 -0400 Message-ID: <3B00200C.EB7F3D03@ecal.com> Date: Mon, 14 May 2001 14:12: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: lennox@cs.columbia.edu Subject: Re: RECAP & Questions of CPL RECUR Issues. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric Busboom wrote: > Past discussions noted that the algorithm may be O(1) in a single rule, > but will be linear with respect to multiple rules. So what would you do > with a client that always expanded recurrence rules to RDATE? Personally, I wouldn't worry about it, because such a client is not likely to get many users. If my calendar turns "every Monday for a year" into "1/1, 1/8, 1/15, 1/22, ...", then I can't edit it to be "every Tuesday" without a massive investment of my time. > Would the telephony equipment set a limit on the maximum > number of RDATE, RRULE, EXRULE and EXDATE properties it would accept, and > reject anything over that limit? Jonathan? > Also, please review the current proposed text change for for RECUR, issue > #15 at: > > http://softwarestudio.org/iCal/ProposedChanges.txt > > These restrictions prevent many absurd examples like the one in > draft-stracke-calsch-rrule-subset-XX.txt. Yeah, but I don't think they simplify the conceptual model; they just add extra limitations that the user has to understand. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Speak softly and carry an Illudium Q-32 | |francis@ecal.com|Explosive Space Disintegrator. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon May 14 14:29:03 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 OAA20742 for ; Mon, 14 May 2001 14:29:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA29578 for ietf-calendar-bks; Mon, 14 May 2001 11:12:54 -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 LAA29571 for ; Mon, 14 May 2001 11:12:47 -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 OAA24233; Mon, 14 May 2001 14:12:13 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4EICDv15639; Mon, 14 May 2001 14:12:13 -0400 (EDT) Message-Id: <5.0.0.25.0.20010514134808.0247cde8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 14 May 2001 14:12:22 -0400 To: Eric Busboom , From: Alan Davies Subject: Re: RECAP & Questions of CPL RECUR Issues. In-Reply-To: References: <3AFFFEE3.FB1CF072@ecal.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:39 AM 14/05/2001 -0700, Eric Busboom wrote: >And, if the algorithm is O(n) with number of rules, and actually O(n) with >number of BYxxx rule part elements in each rule, then in the general case >the algorithm is O(n^2) in the size of the RRULE, a long way from O(1). Surely it's O(n) with the number of BYxxx rule part elements in all of the rules combined? --Alan From owner-ietf-calendar@mail.imc.org Mon May 14 14:49:08 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 OAA21429 for ; Mon, 14 May 2001 14:49:07 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA00539 for ietf-calendar-bks; Mon, 14 May 2001 11:39:00 -0700 (PDT) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA00535 for ; Mon, 14 May 2001 11:38:53 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA18704; Mon, 14 May 2001 14:38:46 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA10465; Mon, 14 May 2001 14:38:42 -0400 (EDT) Received: from [18.18.1.170] (BOB.MIT.EDU [18.18.1.170]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19968; Mon, 14 May 2001 14:38:39 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <151796.989672954@localhost> References: <151796.989672954@localhost> Date: Mon, 14 May 2001 14:38:37 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Bob Mahoney Subject: Re: Calsch and CPL discussions Cc: pregen@egenconsulting.com, Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com, Ned Freed , Scott Bradner Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA00536 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 LAA00539 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA21429 Patrik- Pat and I have spoken about this, as well as some of the calsch document editors, and we're making a resolution of this question our highest priority. We think we have a couple of outstanding questions not yet answered by CPL, and we're going to try and refresh those to the list. Also, one of the document editors (Eric Busboom) is going to try and call Jonathan today and discuss the issue. In short: Message Received, and we're working on it. -Bob At 1:09 PM +0200 5/12/01, Patrik Fältström wrote: >The IESG is as a whole greatly concerned about the lack of ability to >resolv the issues between the CPL spec and the spec which CALSH wg is >working on. > >As responsible AD for the Calsh wg, I hereby ask the Calsh Wg to >concentrate on this topic as the number one issue. It seems that you don't >understand the seriousness of earlier requests from IESG. > >I don't see any other action items being worth working on until the CPL >issues are resolved. > >This "not" is what blocks the whole work with CPL which an important >ingredience in the architecture of IP Telephony. > > Regards, Patrik Faltstrom > Co-Area Director, Applications Area From owner-ietf-calendar@mail.imc.org Mon May 14 14:50:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21467 for ; Mon, 14 May 2001 14:50:23 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA00497 for ietf-calendar-bks; Mon, 14 May 2001 11:37:29 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA00493 for ; Mon, 14 May 2001 11:37:22 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f4EIbJh02758; Mon, 14 May 2001 11:37:19 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 14 May 2001 11:37:19 -0700 (PDT) From: Eric Busboom X-X-Sender: To: Alan Davies cc: Subject: Re: RECAP & Questions of CPL RECUR Issues. In-Reply-To: <5.0.0.25.0.20010514134808.0247cde8@imap1.in.steltor.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, 14 May 2001, Alan Davies wrote: > At 10:39 AM 14/05/2001 -0700, Eric Busboom wrote: > > >And, if the algorithm is O(n) with number of rules, and actually O(n) with > >number of BYxxx rule part elements in each rule, then in the general case > >the algorithm is O(n^2) in the size of the RRULE, a long way from O(1). > > Surely it's O(n) with the number of BYxxx rule part elements > in all of the rules combined? Oh yes -- that is more sensible. Anyway, the point still holds -- the algorithm can't be constant time. eric. From owner-ietf-calendar@mail.imc.org Mon May 14 15:07:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21865 for ; Mon, 14 May 2001 15:07:36 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA01538 for ietf-calendar-bks; Mon, 14 May 2001 11:53:06 -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 LAA01522 for ; Mon, 14 May 2001 11:52:59 -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 OAA26027; Mon, 14 May 2001 14:53:01 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id OAA08982; Mon, 14 May 2001 14:53:01 -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: <15104.10636.756381.136067@conrail.cs.columbia.edu> Date: Mon, 14 May 2001 14:53:00 -0400 (EDT) To: Eric Busboom Cc: , Subject: Re: RECAP & Questions of CPL RECUR Issues. In-Reply-To: References: <3AFFFEE3.FB1CF072@ecal.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, May 14 2001, "Eric Busboom" wrote to ", , " saying: > John, Johnathan, > > This is how I understand the problems that the IPTEL group identified with > RECUR. Are these correct? > > (1) Telephony equipment must be able to check that a given time is > included with in the events specified by a DTSTART, DURATION and set of > RRULES, RDATEs, EXRULEs and EXDATEs in constant time. ( Or is it > O(n) for the number of elements in the byrules? ) Generally, RECUR > rules require O(n) in the number of occurrences. O(n) in the textual length of a rule, specifically. (With the constant factor small, hopefully.) This is clearly inevitable, because the server has to read and parse the rule in order to execute it. O(1) in the value of any parameter, though. > Other problems that have been identified include: > > (2) Because the RRULEs are so complex, and because there are many > different ways to specify a single set of occurrences, it will be very > difficult for a CUA to create a GUI that can manipulate any arbitrary > incoming RRULEs. This is the issue John identified. Seeing what existing GUIs do was a motivating factor for my decisions as to which parts would be okay to drop, but it's not directly behind my decision to create a subset. > The proposed solutions are: > > (1) Remove COUNT > (2) Remove BYSETPOS > (3) Remove byrules and frequencies for hour, minute and second. > (4) Limit the duration of an event to less than 24 hours. > (1) and (2) are proposed to directly allow constant time operation. (3) > and (4) are proposed to disallow a RRULE from generating any two > occurrences that overlap. Overlapping rules compicate a specific algotithm > for performing (1). It's a bit more complicated than "occurences which overlap", but yes, that's basically correct. > Now, for some questions. > > For (1). Is it O(1) or O(n) with number of BYrule elements? The body of > draft-stracke-calsch-rrule-subset-XX.txt says O(1), but the algorithm in > the appendix implies O(n). Or does the O(1) mean "O(1) in number of > occurrences?" See above. O(n) in the textual size of the rule; O(1) both in the number occurences and in the elapsed time since DTSTART. (I suspect any algorithm which can resolve COUNT and BYSETPOS has to be non-constant-time in at least one of these.) > Past discussions noted that the algorithm may be O(1) in a single rule, > but will be linear with respect to multiple rules. So what would you do > with a client that always expanded recurrence rules to RDATE? (thereby > forcing O(n). ) Would the telephony equipment set a limit on the maximum > number of RDATE, RRULE, EXRULE and EXDATE properties it would accept, and > reject anything over that limit? If it always expanded its rules, then yes, it would. I suppose the equipment would have to have a "don't be absurd" response if someone dropped a 10-megabyte rule on it. > And, if the algorithm is O(n) with number of rules, and actually O(n) with > number of BYxxx rule part elements in each rule, then in the general case > the algorithm is O(n^2) in the size of the RRULE, a long way from O(1). No, because rules are resolved sequentially, from what I understand. Check the first one, check the second one, etc. Yes, it's O(m*s) (if you have 'm' rules, each of average size 's'), but that's the same thing as O(n). > So, do you really need O(1), or can you get by with an very fast check of > the upper bound of the occurrence set? That is, what if you could quickly > determine if the rrule is too complex for your processor to handle? > > Also, please review the current proposed text change for for RECUR, issue > #15 at: > > http://softwarestudio.org/iCal/ProposedChanges.txt > > These restrictions prevent many absurd examples like the one in > draft-stracke-calsch-rrule-subset-XX.txt. Yes, but I think they're orthogonal. (I.e. they add additional restrictions to prevent paradoxical rules, but don't alter theoretical algorithmic complexity needed needed to resolve an RRULE.) -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon May 14 15:14:43 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 PAA22093 for ; Mon, 14 May 2001 15:14:42 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA01719 for ietf-calendar-bks; Mon, 14 May 2001 12:00:12 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01711 for ; Mon, 14 May 2001 12:00:05 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id NAA19540 for ; Mon, 14 May 2001 13:57:15 -0500 From: "Shannon J. Clark" To: Subject: RE: Calsch and CPL discussions Date: Mon, 14 May 2001 13:59: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 In-Reply-To: <3B001E91.9BA4AB92@ecal.com> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I didn't mean to imply that the iCalendar would then not have a reoccurrence rules - that would indeed not be very useful at all. Rather, I mean to suggest that iCalendar USE reoccurrence rules which are themselves defined in a separate document. That is, the iCalendar spec would be spec that uses the RRULES, which would be available to be used by other specs or used separately by applications. Thus the revised iCalendar spec would be a simpler document which used the RRULES by reference, rather than by definition. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Monday, May 14, 2001 1:06 PM To: ietf-calendar@imc.org Subject: Re: Calsch and CPL discussions "Shannon J. Clark" wrote: > A fourth option that I have suggested before - but does have a number of > issues with it, is that the RRULE's are separated from the iCalendar draft > and are made into a separate draft. > > This has some advantages: > > One - the resulting iCalendar draft is simplified which should help adoption Actually, I suspect it would hurt adoption, because a calendar data model without recurring events is not very useful. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"If it failed then, there's no reason to think| |francis@ecal.com|we can't make it fail now." -- Colin Benson | \===============================================================/ From owner-ietf-calendar@mail.imc.org Mon May 14 15: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 PAA22743 for ; Mon, 14 May 2001 15:45:44 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA03251 for ietf-calendar-bks; Mon, 14 May 2001 12:27:10 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA03236 for ; Mon, 14 May 2001 12:27:02 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4EJRV828423; Mon, 14 May 2001 15:27:31 -0400 Message-ID: <3B0031A3.44244335@ecal.com> Date: Mon, 14 May 2001 15:27: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: "Shannon J. Clark" CC: ietf-calendar@imc.org Subject: Re: Calsch and CPL discussions 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: > That is, the iCalendar spec would > be spec that uses the RRULES, which would be available to be used by other > specs or used separately by applications. I don't see how that would be useful, though; if you want to incorporate RECUR, you really need most of the machinery of iCalendar. You may not need, say, COMMENT, or ATTENDEE, but it'll be easier to leave those out than to reinvent RRULE, RDATE, EXRULE, EXDATE, DTSTART, DTEND, TZID, VTIMEZONE, and all the rest. > Thus the revised iCalendar spec would be a simpler document which used the > RRULES by reference, rather than by definition. But, if you have to use the external document, then things aren't simpler, they're harder, because you have to keep chasing pointers. Worse, if people don't realize they have to go find the RECUR definition, then we can wind up with noncompliant implementations. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Some days, it just doesn't pay to gnaw through| |francis@ecal.com|the straps. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Mon May 14 17:00: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 RAA24589 for ; Mon, 14 May 2001 17:00:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA09134 for ietf-calendar-bks; Mon, 14 May 2001 13:44:12 -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 NAA09113 for ; Mon, 14 May 2001 13:44:06 -0700 (PDT) From: pregen@egenconsulting.com To: Patrik =?iso-8859-1?q?F=E4ltstr=F6m?= Cc: ietf-calendar@imc.org, jdrosen@dynamicsoft.com, Jonathan Lennox , Ned Freed , owner-ietf-calendar@mail.imc.org, Scott Bradner Subject: Re: Calsch and CPL discussions X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 14 May 2001 16:43:44 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 05/14/2001 04:43:55 PM, Serialize complete at 05/14/2001 04:43:56 PM, Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 05/14/2001 04:43:56 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0071DDFC85256A4C_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071DDFC85256A4C_= Content-Type: text/plain; charset="us-ascii" Patrick, I know quite a bit of dialog happened in Minneapolis. There seemed to be some agreement that a change to Recurrence rules would benefit everyone. I know the Calsch group owed some answers back to IPTEL and I think IPTEL people owed some responses back. I believe Bob Mahoney knows these items (he was at MN) and is furiously forwarding notes around. I too asked Eric Busboom, who is working on changes to RFC2445 (iCalendar) to work with Jonathan because Eric has some ideas. I believe there are some things happening (though maybe not as fast as everyone would like). Bob and i will see what we can do to "light some fires" and get them moving a bit more agressively. However, in defense of the crew, i do believe they are trying to see what they can do to help the CPL group get what they need. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0071DDFC85256A4C_= Content-Type: text/html; charset="us-ascii"
Patrick, I know quite a bit of dialog happened in Minneapolis.  There seemed to be some agreement that a change to Recurrence rules would benefit everyone.  I know the Calsch group owed some answers back to IPTEL and I think IPTEL people owed some responses back.  I believe Bob Mahoney knows these items (he was at MN) and is furiously forwarding notes around.  I too asked Eric Busboom, who is working on changes to RFC2445 (iCalendar) to work with Jonathan because Eric has some ideas.  I believe there are some things happening (though maybe not as fast as everyone would like).  Bob and i will see what we can do to "light some fires" and get them moving a bit more agressively.  However, in defense of the crew, i do believe they are trying to see what they can do to help the CPL group get what they need.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0071DDFC85256A4C_=-- From owner-ietf-calendar@mail.imc.org Mon May 14 21:36: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 VAA29442 for ; Mon, 14 May 2001 21:36:08 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA23328 for ietf-calendar-bks; Mon, 14 May 2001 18:17:06 -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 SAA23309 for ; Mon, 14 May 2001 18:16:59 -0700 (PDT) From: Bruce_Kahn@iris.com Subject: Re: Attendee clarification To: John Stracke Cc: CalSched IETF X-Mailer: Lotus Notes Build V60_05062001 May 06, 2001 Message-ID: Date: Mon, 14 May 2001 21:22:13 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/14/2001 09:18:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John asked on 05/14/2001 02:03:38 PM: > Then why does it define RSVP at all? RSVP is clearly for use in > scheduling. Ill get back to this after ipTel if need be... 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 May 14 23:18:18 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 XAA01625 for ; Mon, 14 May 2001 23:18:17 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id UAA27392 for ietf-calendar-bks; Mon, 14 May 2001 20:07:01 -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 UAA27385 for ; Mon, 14 May 2001 20:06:53 -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 f4F36Pv14551 for ; Mon, 14 May 2001 20:06:25 -0700 (PDT) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GDCWMQ00.CRK; Mon, 14 May 2001 20:06:26 -0700 Message-ID: <3B009D6F.F2B6625C@netscape.com> Date: Mon, 14 May 2001 20:07:27 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: CalSched IETF Subject: Re: Attendee clarification References: <3B001DFA.68069940@ecal.com> Content-Type: multipart/mixed; boundary="------------8089067B6E4992375489B8CC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8089067B6E4992375489B8CC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > Bruce_Kahn@iris.com wrote: > > > John replied on 05/11/2001 06:00:43 PM: > > > I think that's what I meant. My position is just that those > > > vendors are not doing scheduling, and a scheduling protocol > > does > > > not need to accommodate them. > > > > Thats true for RFC 2446/2447 & CAP but not for RFC 2445. > > iCalendar is NOT a scheduling protocol. Its a canonical data > > format for representing calendar > > entries/tasks/journals/busytime/timezones/etc. > > Then why does it define RSVP at all? RSVP is clearly for use in > scheduling. The model we have been working with is that iCalendar defines a common schema, but that the protocols define usage semantics. So, in this case, ITIP needs to define what RSVP means in the case of scheduling REQUEST operations. -Steve --------------8089067B6E4992375489B8CC Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------8089067B6E4992375489B8CC-- From owner-ietf-calendar@mail.imc.org Tue May 15 13:07: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 NAA03136 for ; Tue, 15 May 2001 13:07:32 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA02241 for ietf-calendar-bks; Tue, 15 May 2001 09:14:22 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA02203 for ; Tue, 15 May 2001 09:14:14 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f4FGE1N05215 for ; Tue, 15 May 2001 09:14:01 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Tue, 15 May 2001 09:14:01 -0700 (PDT) From: Eric Busboom X-X-Sender: To: Subject: CPL & RECUR: Notes from phone call. 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 called Jonathan Lennox Monday afternoon to discuss how to resolve the IPTEL group's issues with recurrence rules. Here are my notes from the call. 1) Computational requirements for checking recurrence rules. Jonathan and I believe that the critical computational requirement for recurrence rules is that an implementation can operate on them in bounded time. The operations that need to be bounded are: Checking that a given time is included in a recurrence set specified by DTSTART, DURATION and one or more of RRULE, RDATE, EXRULE and EXDATE. (For Telephony equipment) Expanding a recurrence rule set ( DTSTART, and one or more of RRULE, RDATE, EXRULE and EXDATE) in to a set of occurrences. ( For CAP servers ) By "bounded time" we mean that an implementation can perform the operation in a known amount of time, or in a known amount of time determine how long the operation will take to complete. Using this computational requirement instead of O(1) means that iCalendar may be able to keep much of its current expressiveness while CPL can ensure that the recurrence rule will not pose excessive load on a server. The time bound for a rule will, of course, vary with the complexity of a rule. The goal is for implementations to be able to determine the time bound for a rule in constant time, and then determine if the implementation has the computing resources to actually process the rule. If the rule is too complex, the implementation may reject it. "Bounded time" is a weaker concept than O(1), but it will still require that we reduce the complexity of iCalendar. 2) Complications in ensuring bounded time. When an implementation is expanding a rule or checking existence of a time in the set of occurrences generated by a rule, the form of the rule is significant in determining how long it will take to perform the operations. Some of the problems are: (1) BYSETPOS generally requires a rule to be expanded completely to check the non-existence of a time in the recurrence set. (2) BYSETPOS with negative valued arguments requires a rule to be expanded completely to get any elements in the occurrence set. (3) Many recurrence sets can be described by many different rules, some of which are potentially much more computationally intensive than others. (4) COUNT requires a rule to be expanded completely to check the non-existence of a time in the recurrence set. 3) Complications involving checking that a given time is in an occurrence set. If the duration of an event is allowed to be longer than timespan associated with the frequency of a rule, it is difficult to check that a given time is within the occurrences specified by the rrule. The algorithm that Jonathan implemented for this check examines the parts of a given time and checks that those parts all are accounted for by some element in the recurrence rule. Ie: That the day of month of the time is either listed in the BYMONTHDAY rule part or (in a DAILY RULE) it is N*INTERVAL days from the start time. If the duration of the event was 2 days, then the given time could be in the second day, and neither of the checks above would work. The computationally least expensive way to solve this problem is to restrict DURATIONs to be less than 1 day and remove some frequencies and BYxxx rule parts. (Call it the algebraic method ) The other way is to check existence in the set by generating all occurrences in the set, and checking that the time is in the set. ( Call it the expansion method. ) I think that the restrictions required to make the algebraic method work are a serious imposition on the recurrence rule specification; I don't think we can get rid of intra-day occurrences. But, Jonathan suggested that the expansion method may be acceptable, if for the vast majority of cases, the computation time can be bounded into acceptable limits. Jonathan notes that the algebraic method can still work even if you eliminate the limitation on duration and restore sub-day rules; you're just no longer inherently time-bounded. The running time is proportional to ceil(duration / (smallest mentioned time interval)). So, iCalendar could keep the H,M,S frequencies and rule parts, and allow DURATIONS longer than a day, if nearly all expansions of rules can be very fast, and an algorithm can quickly establish an upper bound on expansion time. 4) Other complications A side issue, that we may as well address now, is that (anecdotally) implementers are stymied by the problem of creating a GUI that can display an arbitrary rule. I believe that this problem is particularly complicated by problems (2) and (3) above. 4) Proposals Jonathan and I discussed the following proposals: (1) Get rid of BYSETPOS. It is a major problem for the IPTEL folks, a PITA for iCalendar, and is rarely actually required. (2) iCalendar can probably keep COUNT, but CPL will have to convert it to UNTIL on the client side. (3) Ensure that expanding most common rules is computationally efficient. Things in the original draft of IPTEL proposed changes to RECUR that we discussed NOT implementing are: (4) Removal of BYHOUR, BYSECOND, BYMINUTE by rules (5) Removal of HOURLY, MINUTELY and SECONDLY frequencies (6) Restricting DURATION to less than 1 day. (1) is something that the CalSch group will have to debate some more. (Before we finally come to the correct conclusion and decide to remove it :) ) (2) does not require any CalSch action. (3) Will require further discussion and some new proposals. Jonathan will send out some more information about guidelines for the computational limits for recurrence rules to give us a guide for updating the RECUR specification. (4), (5) and (6) are contingent on a suitable solution to (3). That is, if expanding recurrence rules can be very inexpensive in the general cases, and easily bounded in the complex cases, then the CPL recurrence operations can use an expansion method rather than an algebraic method and (4), (5) and (6) are not necessary. But again, that is an "if" eric. From owner-ietf-calendar@mail.imc.org Wed May 16 01:21:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16888 for ; Wed, 16 May 2001 01:21:54 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA20781 for ietf-calendar-bks; Tue, 15 May 2001 22:07:41 -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 WAA20772 for ; Tue, 15 May 2001 22:07:34 -0700 (PDT) Received: from [192.168.1.35] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id HAA13672; Wed, 16 May 2001 07:05:50 +0200 (MET DST) Date: Wed, 16 May 2001 07:01:23 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Bob Mahoney cc: pregen@egenconsulting.com, Jonathan Lennox , ietf-calendar@imc.org, jdrosen@dynamicsoft.com, Ned Freed , Scott Bradner Subject: Re: Calsch and CPL discussions Message-ID: <3919295.989996483@localhost> In-Reply-To: References: <151 96.989672954@localhost> X-Mailer: Mulberry/2.1.0a5 (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-05-14 14.38 -0400 Bob Mahoney wrote: > In short: Message Received, and we're working on it. Thanks! paf From owner-ietf-calendar@mail.imc.org Wed May 16 01:24:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16889 for ; Wed, 16 May 2001 01:21:54 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA20702 for ietf-calendar-bks; Tue, 15 May 2001 22:06:32 -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 WAA20686; Tue, 15 May 2001 22:06:25 -0700 (PDT) Received: from [192.168.1.35] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id HAA13679; Wed, 16 May 2001 07:05:53 +0200 (MET DST) Date: Wed, 16 May 2001 07:04:45 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: pregen@egenconsulting.com cc: ietf-calendar@imc.org, jdrosen@dynamicsoft.com, Jonathan Lennox , Ned Freed , owner-ietf-calendar@mail.imc.org, Scott Bradner Subject: Re: Calsch and CPL discussions Message-ID: <3931437.989996685@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.0a5 (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-05-14 16.43 -0400 pregen@egenconsulting.com wrote: > However, in defense of the crew, i do believe they are trying to see what > they can do to help the CPL group get what they need. No defense talk needed. I know you are working hard, very hard. I just try to help getting the group focused on this specific issue. When the brocoli is taken care of, you can go back to desert again. paf From owner-ietf-calendar@mail.imc.org Wed May 16 10:41:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10484 for ; Wed, 16 May 2001 10:41:57 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA02402 for ietf-calendar-bks; Wed, 16 May 2001 07:23:18 -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 HAA02388 for ; Wed, 16 May 2001 07:23:10 -0700 (PDT) From: pregen@egenconsulting.com To: Patrik =?iso-8859-1?q?F=E4ltstr=F6m?= Cc: ietf-calendar@imc.org, jdrosen@dynamicsoft.com, Jonathan Lennox , Ned Freed , owner-ietf-calendar@mail.imc.org, Scott Bradner Subject: Re: Calsch and CPL discussions X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 16 May 2001 10:22:34 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 05/16/2001 10:22:55 AM, Serialize complete at 05/16/2001 10:22:55 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004C52AF85256A4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004C52AF85256A4E_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable thanks Patrick. I believe Eric Busboom spent some time on the phone with=20 Jonathan so there may be some progress. We'll keep at it. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Patrik F=E4ltstr=F6m Sent by: owner-ietf-calendar@mail.imc.org 05/16/01 01:04 AM =20 To: pregen@egenconsulting.com cc: ietf-calendar@imc.org, jdrosen@dynamicsoft.com, Jonathan Le= nnox=20 , Ned Freed ,=20 owner-ietf-calendar@mail.imc.org, Scott Bradner Subject: Re: Calsch and CPL discussions --On 01-05-14 16.43 -0400 pregen@egenconsulting.com wrote: > However, in defense of the crew, i do believe they are trying to see=20 what > they can do to help the CPL group get what they need. No defense talk needed. I know you are working hard, very hard. I just try to help getting the group focused on this specific issue. When the brocoli is taken care of, you can go back to desert again. paf --=_alternative 004C52AF85256A4E_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
thanks Patrick.  I believe Eric= Busboom spent some time on the phone with Jonathan so there may be some pr= ogress.  We'll keep at it.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

05/16/01 01:04 AM

       
        To: &nbs= p;      pregen@egenconsulting.com
        cc: &nbs= p;      ietf-calendar@imc.org, jdrosen@dynamicsoft.com, Jona= than Lennox <lennox@cs.columbia.edu>, Ned Freed <ned.freed@mrochek= .com>, owner-ietf-calendar@mail.imc.org, Scott Bradner <sob@harvard.e= du>
        Subject:=        Re: Calsch and CPL discussions



--On 01-05-14 16.43 -0400 pregen@eg= enconsulting.com wrote:

> However, in defense of the crew, i do believe they are trying to see w= hat
> they can do to help the CPL group get what they need.

No defense talk needed. I know you are working hard, very hard. I just try<= br> to help getting the group focused on this specific issue.

When the brocoli is taken care of, you can go back to desert again.

  paf

--=_alternative 004C52AF85256A4E_=-- From owner-ietf-calendar@mail.imc.org Wed May 16 15:20:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17530 for ; Wed, 16 May 2001 15:20:56 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA19794 for ietf-calendar-bks; Wed, 16 May 2001 12:06:42 -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 MAA19787 for ; Wed, 16 May 2001 12:06:35 -0700 (PDT) From: Bruce_Kahn@iris.com To: Jonathan Lennox Cc: Eric Busboom , francis@ecal.com, ietf-calendar@imc.org Subject: Re: RECAP & Questions of CPL RECUR Issues. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05132001 May 13, 2001 Message-ID: Date: Wed, 16 May 2001 15:07:39 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/16/2001 03:08:48 PM, Serialize complete at 05/16/2001 03:08:48 PM Content-Type: multipart/alternative; boundary="=_alternative 0068D94F85256A4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068D94F85256A4E_= Content-Type: text/plain; charset="us-ascii" Jonathan replied: >> Would the telephony equipment set a limit on the maximum >> number of RDATE, RRULE, EXRULE and EXDATE properties it would accept, and >> reject anything over that limit? > >If it always expanded its rules, then yes, it would. I suppose the >equipment would have to have a "don't be absurd" response if someone dropped >a 10-megabyte rule on it. Well given that it is possible to use, say, 4 RRULEs or 1 RRULE to represent the same set of instances then when it the size/count 'absurd'? For example, "Every other Monday, Tuesday, Wednesday, Friday for 18 months" can be 4 separate BYDAY= rules with 1 value each (BYDAY=MO in 1, BYDAY=TU in next, etc) OR it can be simply "BYDAY=MO, TU,WE,TH" in 1 rule. Since RRULEs are combined to make the final recurrence set both sets are equivalent and both would generate the same results; 1 case is just 4 times the size of the other. I did not notice in the iptel draft if there was any mention of a mechanism by which the entry was bounced back as "illegal", "too complex" or "too many instances". Is there any such mechanism? (This gets back to my 1st posting but it bears reconfirming) 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 0068D94F85256A4E_= Content-Type: text/html; charset="us-ascii"
Jonathan replied:
>>               Would the telephony equipment set a limit on the maximum
>> number of RDATE, RRULE, EXRULE and EXDATE properties it would accept, and
>> reject anything over that limit?
>
>If it always expanded its rules, then yes, it would.  I suppose the
>equipment would have to have a "don't be absurd" response if someone dropped
>a 10-megabyte rule on it.

Well given that it is possible to use, say, 4 RRULEs or 1 RRULE to represent the same set of instances then when it the size/count 'absurd'?  

For example, "Every other Monday, Tuesday, Wednesday, Friday for 18 months" can be 4 separate BYDAY= rules with 1 value each (BYDAY=MO in 1, BYDAY=TU in next, etc) OR it can be simply "BYDAY=MO, TU,WE,TH" in 1 rule.  Since RRULEs are combined to make the final recurrence set both sets are equivalent and both would generate the same results; 1 case is just 4 times the size of the other.  

I did not notice in the iptel draft if there was any mention of a mechanism by which the entry was bounced back as "illegal", "too complex" or "too many instances".  Is there any such mechanism?  (This gets back to my 1st posting but it bears reconfirming)

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 0068D94F85256A4E_=-- From owner-ietf-calendar@mail.imc.org Wed May 16 15:21:32 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 PAA17556 for ; Wed, 16 May 2001 15:21:32 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA19741 for ietf-calendar-bks; Wed, 16 May 2001 12:05:46 -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 MAA19728 for ; Wed, 16 May 2001 12:05:40 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org, lennox@cs.columbia.edu Subject: Re: RECAP & Questions of CPL RECUR Issues. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05132001 May 13, 2001 Message-ID: Date: Wed, 16 May 2001 15:06:44 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/16/2001 03:07:53 PM, Serialize complete at 05/16/2001 03:07:53 PM Content-Type: multipart/alternative; boundary="=_alternative 0068C3DF85256A4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068C3DF85256A4E_= Content-Type: text/plain; charset="us-ascii" John wrote: > If my calendar turns "every Monday for a year" into "1/1, 1/8, 1/15, >1/22, ...", then I can't edit it to be "every Tuesday" without a massive >investment of my time. Under the covers it is going to have to roll it out somehow so that the entries can be shown in the UI to you (or so that 'exceptions' or changes to individual instances can be applied and managed!). If the UI makes a change that requires _you_ to jump thru hoops to reschedule them all, is that the problem w/the spec or w/the CUA? We are not in the business of spec'ing out UIs for CUAs here, we are in the business of specing out a data interchange and interop format. They are not the same things; go get a better CUA w/a better UI... >Yeah, but I don't think they simplify the conceptual model; they just add extra >limitations that the user has to understand. From what Ive been able to get out of the exchange between iptel and calsch is that the concerns are not those of the end users but rather the vendors implementing iptel. As such, "user confusion" is not a likely conern (unless you expect a poor UI/GUI and thats not something we can or should try to spec out). Besides, what CU is actually reading RRULEs that their CUA generates and trying to understand them?!?! A whole lot fewer than those that don't do/try it. The recurrence grammar/model is not something that CUs will (or should!) really have to worry about. They simply want to be able to schedule "that weekly Monday AM and Thursday PM team meeting for the next 18 months at 9AM". 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 0068C3DF85256A4E_= Content-Type: text/html; charset="us-ascii"
John wrote:
>         If my calendar turns "every Monday for a year" into "1/1, 1/8, 1/15,
>1/22, ...", then I can't edit it to be "every Tuesday" without a massive
>investment of my time.

Under the covers it is going to have to roll it out somehow so that the entries can be shown in the UI to you (or so that 'exceptions' or changes to individual instances can be applied and managed!).  If the UI makes a change that requires _you_ to jump thru hoops to reschedule them all, is that the problem w/the spec or w/the CUA?  We are not in the business of spec'ing out UIs for CUAs here, we are in the business of specing out a data interchange and interop format.  They are not the same things; go get a better CUA w/a better UI...

>Yeah, but I don't think they simplify the conceptual model; they just add extra
>limitations that the user has to understand.

From what Ive been able to get out of the exchange between iptel and calsch is that the concerns are not those of the end users but rather the vendors implementing iptel.  As such, "user confusion" is not a likely conern (unless you expect a poor UI/GUI and thats not something we can or should try to spec out).

Besides, what CU is actually reading RRULEs that their CUA generates and trying to understand them?!?!  A whole lot fewer than those that don't do/try it.  The recurrence grammar/model is not something that CUs will (or should!) really have to worry about.  They simply want to be able to schedule "that weekly Monday AM and Thursday PM team meeting for the next 18 months at 9AM".  

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 0068C3DF85256A4E_=-- From owner-ietf-calendar@mail.imc.org Wed May 16 15:26: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 PAA17678 for ; Wed, 16 May 2001 15:26:11 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA19724 for ietf-calendar-bks; Wed, 16 May 2001 12:05:38 -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 MAA19713 for ; Wed, 16 May 2001 12:05:32 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: francis@ecal.com, ietf-calendar@imc.org, lennox@cs.columbia.edu Subject: Re: RECAP & Questions of CPL RECUR Issues. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05132001 May 13, 2001 Message-ID: Date: Wed, 16 May 2001 15:06:34 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/16/2001 03:07:44 PM, Serialize complete at 05/16/2001 03:07:44 PM Content-Type: multipart/alternative; boundary="=_alternative 0068BFDD85256A4E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068BFDD85256A4E_= Content-Type: text/plain; charset="us-ascii" Eric wrote: > (2) Because the RRULEs are so complex, and because there are many > different ways to specify a single set of occurrences, it will be very > difficult for a CUA to create a GUI that can manipulate any arbitrary > incoming RRULEs. So far, none of the proposed ipTel changes I've seen simplify or resolve this. I also do not think that there is any real 'fix' for this as it may not really be a problem. Since RRULEs are 'compounded' to generate the the final recurrence set (ignoring other relevant stuff to keep this simple) then is it really a problem if I specify: RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH (from p119 of 2445) or RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TH Not really. The UI/GUI will have to decompose both into "Weekly on Tuesday and Thursday for 5 weeks" when it presents it to me (or at least present it as "Weekly on Tuesday for 5 weeks" and "And also weekly on Thursday for 5 weeks" if it cannot 'merge' them textually). The changes proposed by iptel do not address this need really. They may reduce the available set of subcomponents that may be split (ie: no more BYHOUR, BYMINUTE, BYSECOND) but this does not really address (2). >The proposed solutions are: > > (1) Remove COUNT This is a feature that at least 3 CUAs implemented and actively use in their UIs. Its a typical C&S feature that CUs use and have come to expect so its hard to justify why it should go away in my mind. iptel justified this with: iCal also defines a count parameter, which allows an alternate method of specifying a bound to a recurrence. This bound has been removed from CPL. Translating from full iCal recurrences to CPL recurrences requires that the count parameter be converted to an until parameter, which can be done by enumerating the recurrence and determining its final date. The bit about translating works for when the set is presented in a UI or when mapiuplations on the set are necessary (ie: rescheduling ranges, etc) but this wont work for storage. There is a very fundamental difference between rolling it out at creating time into an UNTIL date-time and keeping it as a COUNT. The former case 'fixes' the end and there is absolutely no way that a CUA can distinguish it from an UNTIL that was actually specified at creation or a COUNT that was munged. As such, when the set gets moved (ie: John's "change all my Monday entrys to Tuesday" elsewhere in the thread) then the CUA has no way to know if the set should shrink or if it should stay the same size. That is to say, if I move my 1st DTSTART from 01-Jan-01 to 05-Feb-01 then how can the CUA know if the set should still end at 31-Dec-01 or 04-Feb-02 unless it knows if the UNTIL was 'hard' or if it was generated based on a COUNT value that is no longer known?? Its not possible. COUNT is a feature that nearly all CUAs Ive used have and implement so it cannot simply be removed from the spec. This sounds like something the iptel engines could do as part of their preprocessing work on each rule though though. I assume some preprocessing is done to check for 'non-supported' subcomponent values in recurrence rules, etc since this filtering is not described in Appendix A of the iptel draft. Also, feature removal of already demonstrated interop features is not good is it?? > (2) Remove BYSETPOS This feature is actively used by at least 1 shipping CUA (Outlook) and supported by 2 others (Organizer and Notes). Again, feature removal is not good if folks rely on it. While all of vendors besides Microsoft may dream of making killer CUAs (or killer C&S based apps), we all realize that we need (if not want) to interoperate with Outlook. This is a good step _away_ from that in a very big way. > (3) Remove byrules and frequencies for hour, minute and second. This has a very negative impact on schemas that may want (or really need) to have 'subday' recurrence. Real world examples include: Admin case (ie "Change the backup tape in the system every 90 minutes or 2 times a day"), Tourism (ie: "The Boston Harbor tour boats leave at 9AM and again at 1PM every day, no matter the weather"), Entertainment (ie: "The movie Star Wars: Episode II shows every 30 minutes 24 hours a day during opening week", "David Copperfield has a matinee and an evening show on Sunday", "Life in the ER is on at 7PM EST and again at 11PM on The Discovery Channel on Sunday"). The list of actual uses is not that short. For iptels needs though these components may not be that useful (or at least the BYMINUTE and BYSECOND easily). This does not make them unnecessary for other applications where scheduling is involved. So is their need reason to remove these useful (even necessary?) subcomponents?? Perhaps the approach needs to be taken is one of identifying subcomponents that are logical to the usage and ruling out those that are not. iCalendar/iTIP defined a mechanism for the recieving CUA to communicate back to the sender "I did not grok your BYSETPOS of the RRULE:... but I accept the rest" or "Your RRULE:... is illogical so I did not use it", etc. Check out section 3.6 Status Replies of iTIP for a more concrete listing. I did not see this kind of mechanism in ipTel; perhaps adding one is in order to facilitate future expansion of ipTel as systems get faster and O(n) becomes larger so more values are allowable... > (4) Limit the duration of an event to less than 24 hours. It may be logical to think that a phone call may not go > 24 hours but I can see lots of other events/tasks that are longer than that in duration. Lets see, Lotusphere 2001, DevCon, E3, Quake 3 "Frag Fests" kinds of events come to mind. Hey, so does IETF. Guess we cant use iCalendar to publish "IETF" this summer... For the iptel world it may be logical but I profess some confusion as to the practical uses of iptel from just reading the draft. If this is an attempt to avoid overlapping entries if the repeat interval is DAILY then why not allow > 1 day durations if the interval is, say, WEEKLY?? Since it seems everyone agrees with Erics: > (3) >and (4) are proposed to disallow a RRULE from generating any two >occurrences that overlap. so this then this would argue again for a mechanism in iptel to communcate back (to the user or to some system somewhere?) that "Hey, entries cannot overlap" instead of trying to hide the problem by making recurrence never be able to be subday and having the duration max of 1 day. As systems get faster then the amount of processing that can be done in the fixed time O(n) increases. This means that future iptel implementations could conceivably be able to implement the full recurrence grammar at some point in the not too distant future. I am very rusty in my set theory and other relevant math topics but it appears to me that as the repeat instance dates get farther from DTSTART that the time required to evaluate becomes longer since there are more intervening instances to iterate over. I did not notice this increasing time impact being factored into the O(n) discussion. Was it and I just missed it?? I am VERY skittish of making changes like removing subcomponents just because the current processing ability of some implementations may not be able to handle very complex constructs w/a given time constraint. If this were a good motivation then software would never have progressed to its current state from, say, 10 years ago. I can empathize with those trying to solve the problem but simply cutting stuff out that is not convenient is not the way to go. Have the iptel folks looked at the REQUEST-STATUS mechanism that we put in to partially solve this problem? We build the REQUEST-STATUS property to allow 'weaker' or "less robust" CUAs to easily communicate with "more robust" CUAs that can do more. As time rolls on, the less robust folks will be able to improve their abilities and the problem will go away (hopefully). At least we put in place a mechanism to convey this kind of communication so that as implementations got more robust and faster they were still able to function with older ones w/o causing serious incompatabilities or growth restrictions. 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 0068BFDD85256A4E_= Content-Type: text/html; charset="us-ascii"
Eric wrote:
>                 (2) Because the RRULEs are so complex, and because there are many
>                 different ways to specify a single set of occurrences, it will be very
>                 difficult for a CUA to create a GUI that can manipulate any arbitrary
>                 incoming RRULEs.
So far, none of the proposed ipTel changes I've seen simplify or resolve this.  I also do not think that there is any real 'fix' for this as it may not really be a problem.  Since RRULEs are 'compounded' to generate the the final recurrence set (ignoring other relevant stuff to keep this simple) then is it really a problem if I specify:

     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH
(from p119 of 2445) or

     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU
    RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TH
Not really.  The UI/GUI will have to decompose both into "Weekly on Tuesday and Thursday for 5 weeks" when it presents it to me (or at least present it as "Weekly on Tuesday for 5 weeks" and "And also weekly on Thursday for 5 weeks" if it cannot 'merge' them textually).  The changes proposed by iptel do not address this need really.  They may reduce the available set of subcomponents that may be split (ie: no more BYHOUR, BYMINUTE, BYSECOND) but this does not really address (2).

>The proposed solutions are:
>
>                 (1) Remove COUNT
This is a feature that at least 3 CUAs implemented and actively use in their UIs. Its a typical C&S feature that CUs use and have come to expect so its hard to justify why it should go away in my mind.  iptel justified this with:

        iCal also defines a count parameter, which allows an
       alternate method of specifying a bound to a recurrence.
       This bound has been removed from CPL. Translating from full
       iCal recurrences to CPL recurrences requires that the count
       parameter be converted to an until parameter, which can be
       done by enumerating the recurrence and determining its
       final date.

The bit about translating works for when the set is presented in a UI or when mapiuplations on the set are necessary (ie: rescheduling ranges, etc) but this wont work for storage.  There is a very fundamental difference between rolling it out at creating time into an UNTIL date-time and keeping it as a COUNT.  The former case 'fixes' the end and there is absolutely no way that a CUA can distinguish it from an UNTIL that was actually specified at creation or a COUNT that was munged.  

As such, when the set gets moved (ie: John's "change all my Monday entrys to Tuesday" elsewhere in the thread) then the CUA has no way to know if the set should shrink or if it should stay the same size.  That is to say, if I move my 1st DTSTART from 01-Jan-01 to 05-Feb-01 then how can the CUA know if the set should still end at 31-Dec-01 or 04-Feb-02 unless it knows if the UNTIL was 'hard' or if it was generated based on a COUNT value that is no longer known??  Its not possible.

COUNT is a feature that nearly all CUAs Ive used have and implement so it cannot simply be removed from the spec.  This sounds like something the iptel engines could do as part of their preprocessing work on each rule though though.  I assume some preprocessing is done to check for 'non-supported' subcomponent values in recurrence rules, etc since this filtering is not described in Appendix A of the iptel draft.

Also, feature removal of already demonstrated interop features is not good is it??

>                 (2) Remove BYSETPOS
This feature is actively used by at least 1 shipping CUA (Outlook) and supported by 2 others (Organizer and Notes).  Again, feature removal is not good if folks rely on it.  While all of vendors besides Microsoft may dream of making killer CUAs (or killer C&S based apps), we all realize that we need (if not want) to interoperate with Outlook.  This is a good step _away_ from that in a very big way.

>                 (3) Remove byrules and frequencies for hour, minute and second.

This has a very negative impact on schemas that may want (or really need) to have 'subday' recurrence.  Real world examples include: Admin case (ie "Change the backup tape in the system every 90 minutes or 2 times a day"), Tourism (ie: "The Boston Harbor tour boats leave at 9AM and again at 1PM every day, no matter the weather"), Entertainment (ie: "The movie Star Wars: Episode II shows every 30 minutes 24 hours a day during opening week", "David Copperfield has a matinee and an evening show on Sunday", "Life in the ER is on at 7PM EST and again at 11PM on The Discovery Channel on Sunday").   The list of actual uses is not that short.

For iptels needs though these components may not be that useful (or at least the BYMINUTE and BYSECOND easily).  This does not make them unnecessary for other applications where scheduling is involved.  So is their need reason to remove these useful (even necessary?) subcomponents??  

Perhaps the approach needs to be taken is one of identifying subcomponents that are logical to the usage and ruling out those that are not.  iCalendar/iTIP defined a mechanism for the recieving CUA to communicate back to the sender "I did not grok your BYSETPOS of the RRULE:... but I accept the rest" or "Your RRULE:... is illogical so I did not use it", etc.  Check out section 3.6 Status Replies of iTIP for a more concrete listing.  I did not see this kind of mechanism in ipTel; perhaps adding one is in order to facilitate future expansion of ipTel as systems get faster and O(n) becomes larger so more values are allowable...
>                 (4) Limit the duration of an event to less than 24 hours.

It may be logical to think that a phone call may not go > 24 hours but I can see lots of other events/tasks that are longer than that in duration.  Lets see, Lotusphere 2001, DevCon, E3, Quake 3 "Frag Fests" kinds of events come to mind.  Hey, so does IETF.  Guess we cant use iCalendar to publish "IETF" this summer...

For the iptel world it may be logical but I profess some confusion as to the practical uses of iptel from just reading the draft.  If this is an attempt to avoid overlapping entries if the repeat interval is DAILY then why not allow > 1 day durations if the interval is, say, WEEKLY??  Since it seems everyone agrees with Erics:

>                                                       (3)
>and (4) are proposed to disallow a RRULE from generating any two
>occurrences that overlap.

so this then this would argue again for a mechanism in iptel to communcate back (to the user or to some system somewhere?) that "Hey, entries cannot overlap" instead of trying to hide the problem by making recurrence never be able to be subday and having the duration max of 1 day.  

As systems get faster then the amount of processing that can be done in the fixed time O(n) increases.  This means that future iptel implementations could conceivably be able to implement the full recurrence grammar at some point in the not too distant future.

I am very rusty in my set theory and other relevant math topics but it appears to me that as the repeat instance dates get farther from DTSTART that the time required to evaluate becomes longer since there are more intervening instances to iterate over.  I did not notice this increasing time impact being factored into the O(n) discussion.  Was it and I just missed it??

I am VERY skittish of making changes like removing subcomponents just because the current processing ability of some implementations may not be able to handle very complex constructs w/a given time constraint.  If this were a good motivation then software would never have progressed to its current state from, say, 10 years ago.  I can empathize with those trying to solve the problem but simply cutting stuff out that is not convenient is not the way to go.

Have the iptel folks looked at the REQUEST-STATUS mechanism that we put in to partially solve this problem?  We build the REQUEST-STATUS property to allow 'weaker' or "less robust" CUAs to easily communicate with "more robust" CUAs that can do more.  As time rolls on, the less robust folks will be able to improve their abilities and the problem will go away (hopefully).  At least we put in place a mechanism to convey this kind of communication so that as implementations got more robust and faster they were still able to function with older ones w/o causing serious incompatabilities or growth restrictions.

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 0068BFDD85256A4E_=-- From owner-ietf-calendar@mail.imc.org Wed May 16 18:04: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 SAA19980 for ; Wed, 16 May 2001 18:04:32 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA05675 for ietf-calendar-bks; Wed, 16 May 2001 14:51:19 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA05644 for ; Wed, 16 May 2001 14:51:12 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f4GLowa08270 for ; Wed, 16 May 2001 14:51:04 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Wed, 16 May 2001 14:50:58 -0700 (PDT) From: Eric Busboom X-X-Sender: To: Subject: Correction: CPL & RECUR: Notes from phone call. 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, 15 May 2001, Eric Busboom wrote: > Things in the original draft of IPTEL proposed changes to RECUR that we > discussed NOT implementing are: > > (4) Removal of BYHOUR, BYSECOND, BYMINUTE by rules > > (5) Removal of HOURLY, MINUTELY and SECONDLY frequencies > > (6) Restricting DURATION to less than 1 day. Major faux pas here: these are things that the CPL draft suggested removing, but which Jonathan and I sugessted would not really need to be removed. That is, it should be "NOT removing" instead of "NOT implementing" Sorry for the confusion. eric. From owner-ietf-calendar@mail.imc.org Wed May 16 18:38:03 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 SAA20332 for ; Wed, 16 May 2001 18:38:01 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA09905 for ietf-calendar-bks; Wed, 16 May 2001 15:27: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 PAA09896 for ; Wed, 16 May 2001 15:27:32 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA32481 for ; Wed, 16 May 2001 18:26:59 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4GMQwv24093 for ; Wed, 16 May 2001 18:26:58 -0400 (EDT) Message-Id: <5.0.0.25.0.20010516165304.02696a00@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 16 May 2001 18:27:15 -0400 To: ietf-calendar@imc.org From: Alan Davies Subject: Re: RECAP & Questions of CPL RECUR Issues. 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 03:06 PM 16/05/2001 -0400, Bruce_Kahn@iris.com wrote: >The bit about translating works for when the set is presented in a UI or >when mapiuplations on the set are necessary (ie: rescheduling ranges, etc) >but this wont work for storage. There is a very fundamental difference >between rolling it out at creating time into an UNTIL date-time and >keeping it as a COUNT. The former case 'fixes' the end and there is >absolutely no way that a CUA can distinguish it from an UNTIL that was >actually specified at creation or a COUNT that was munged. > >As such, when the set gets moved (ie: John's "change all my Monday entrys >to Tuesday" elsewhere in the thread) then the CUA has no way to know if >the set should shrink or if it should stay the same size. That is to say, >if I move my 1st DTSTART from 01-Jan-01 to 05-Feb-01 then how can the CUA >know if the set should still end at 31-Dec-01 or 04-Feb-02 unless it knows >if the UNTIL was 'hard' or if it was generated based on a COUNT value that >is no longer known?? Its not possible. I'm not sure that storage, or the way that a CUA adjusts one property when another changes, are concerns we need to worry about. But you're right that there is a subtle semantic difference between COUNT and UNTIL that may be useful. All we're trying to lay out is a data format, and if it is useful to differentiate between these two concepts then they should stay in. > > (3) Remove byrules and frequencies for hour, minute and > second. > >This has a very negative impact on schemas that may want (or really need) >to have 'subday' recurrence. Real world examples include: Admin case (ie >"Change the backup tape in the system every 90 minutes or 2 times a day"), >Tourism (ie: "The Boston Harbor tour boats leave at 9AM and again at 1PM >every day, no matter the weather"), Entertainment (ie: "The movie Star >Wars: Episode II shows every 30 minutes 24 hours a day during opening >week", "David Copperfield has a matinee and an evening show on Sunday", >"Life in the ER is on at 7PM EST and again at 11PM on The Discovery >Channel on Sunday"). The list of actual uses is not that short. Many of these could be expressed in other ways, such as multiple recurrence rules, e.g. one for "Life in the ER is at 7pm EST", and one for "11PM on The Discovery Channel on Sunday". I agree that the sub-day recurrences might be useful in some situations though. >so this then this would argue again for a mechanism in iptel to communcate >back (to the user or to some system somewhere?) that "Hey, entries cannot >overlap" instead of trying to hide the problem by making recurrence never >be able to be subday and having the duration max of 1 day. Testing for overlapping entries might not always be that easy, for example when there are multiple infinitely repeating rules. >I am very rusty in my set theory and other relevant math topics but it >appears to me that as the repeat instance dates get farther from DTSTART >that the time required to evaluate becomes longer since there are more >intervening instances to iterate over. I did not notice this increasing >time impact being factored into the O(n) discussion. Was it and I just >missed it?? The algorithm proposed didn't need to expand the set of occurrences, it just tested whether the date-time intersected the rule, but it was only O(n) if there was only one candidate occurrence, hence the non-overlapping restriction. >Have the iptel folks looked at the REQUEST-STATUS mechanism that we put in >to partially solve this problem? We build the REQUEST-STATUS property to >allow 'weaker' or "less robust" CUAs to easily communicate with "more >robust" CUAs that can do more. As time rolls on, the less robust folks >will be able to improve their abilities and the problem will go away >(hopefully). At least we put in place a mechanism to convey this kind of >communication so that as implementations got more robust and faster they >were still able to function with older ones w/o causing serious >incompatabilities or growth restrictions. Something like that seems pretty sensible solution- CPL could just 'refuse' overly-complex events, as could any CUA. --Alan From owner-ietf-calendar@mail.imc.org Wed May 16 19:28: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 TAA21165 for ; Wed, 16 May 2001 19:28:17 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA14131 for ietf-calendar-bks; Wed, 16 May 2001 16:09:20 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA14122 for ; Wed, 16 May 2001 16:09:13 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id SAA23232 for ; Wed, 16 May 2001 18:08:15 -0500 From: "Shannon J. Clark" To: Subject: RE: RECAP & Questions of CPL RECUR Issues. Date: Wed, 16 May 2001 18:08:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <5.0.0.25.0.20010516165304.02696a00@imap1.in.steltor.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A few quick observations. If CPL is proposing an algorithm that tests "whether the date-time intersected the rule" this implies that given a large set of RRULES - ALL rules must be tested at ALL points in time... this seems potentially very complex vs. evaluating out the RRULES and testing against a set that contains all occurrences for ALL objects (for the given calendar) - which should be a very manageable test. I.E. - are they really proposing that for every point in time that their software needs to "do" something, it checks (and evaluates) ALL RRULES on ALL objects in the calendar(s) present for the software and then do something based on those events? In developing my company's software we are evaluating RRULES when the enter our server to get to a set of occurrences - subsequently we check against this set for occurrences that overlap the period of time that we need to evaluate for. For some types of RRULES (i.e. rules with no end boundary) we will periodically re-evaluate the rules (but will evaluate them past the boundaries of most of our client's interest ranges i.e. few clients are looking 10+ years forward) so this is less critical. To handle changes to an RRULE we grab the previous set of occurrence, reevaluate the RRULE, and adjust the occurrence set accordingly - so if Monday becomes Tuesday the Monday occurrences are removed, and the Tuesday occurrences are added. (note we are not implementing scheduling functions fully so we only have a few workflow issues with this - in a full scheduling environment this would potentially trigger some additional workflow related exchanges of data) This means that I can evaluate complex RRULES since I occur the cost of evaluation rarely - i.e. just upon the calendar object containing the RRULE being added to a calendar in my system - subsequently I will be using a set of occurrences vs. checking all objects for RRULES and then evaluating all RRULES every time I need to get the events for a given period of time (for example events for TODAY or "now"). Hope this helps - it seems that the standards and supporting documentation are very vague and unclear about many underlying assumptions - for instance in this case - when RRULES will be expanded and how systems will deal with real world issues of large sets of calendar objects. 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 Alan Davies Sent: Wednesday, May 16, 2001 5:27 PM To: ietf-calendar@imc.org Subject: Re: RECAP & Questions of CPL RECUR Issues. >This has a very negative impact on schemas that may want (or really need) >to have 'subday' recurrence. Real world examples include: Admin case (ie >"Change the backup tape in the system every 90 minutes or 2 times a day"), >Tourism (ie: "The Boston Harbor tour boats leave at 9AM and again at 1PM >every day, no matter the weather"), Entertainment (ie: "The movie Star >Wars: Episode II shows every 30 minutes 24 hours a day during opening >week", "David Copperfield has a matinee and an evening show on Sunday", >"Life in the ER is on at 7PM EST and again at 11PM on The Discovery >Channel on Sunday"). The list of actual uses is not that short. Many of these could be expressed in other ways, such as multiple recurrence rules, e.g. one for "Life in the ER is at 7pm EST", and one for "11PM on The Discovery Channel on Sunday". I agree that the sub-day recurrences might be useful in some situations though. >so this then this would argue again for a mechanism in iptel to communcate >back (to the user or to some system somewhere?) that "Hey, entries cannot >overlap" instead of trying to hide the problem by making recurrence never >be able to be subday and having the duration max of 1 day. Testing for overlapping entries might not always be that easy, for example when there are multiple infinitely repeating rules. >I am very rusty in my set theory and other relevant math topics but it >appears to me that as the repeat instance dates get farther from DTSTART >that the time required to evaluate becomes longer since there are more >intervening instances to iterate over. I did not notice this increasing >time impact being factored into the O(n) discussion. Was it and I just >missed it?? The algorithm proposed didn't need to expand the set of occurrences, it just tested whether the date-time intersected the rule, but it was only O(n) if there was only one candidate occurrence, hence the non-overlapping restriction. >Have the iptel folks looked at the REQUEST-STATUS mechanism that we put in >to partially solve this problem? We build the REQUEST-STATUS property to >allow 'weaker' or "less robust" CUAs to easily communicate with "more >robust" CUAs that can do more. As time rolls on, the less robust folks >will be able to improve their abilities and the problem will go away >(hopefully). At least we put in place a mechanism to convey this kind of >communication so that as implementations got more robust and faster they >were still able to function with older ones w/o causing serious >incompatabilities or growth restrictions. Something like that seems pretty sensible solution- CPL could just 'refuse' overly-complex events, as could any CUA. --Alan From owner-ietf-calendar@mail.imc.org Wed May 16 23:40:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25443 for ; Wed, 16 May 2001 23:40:45 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id UAA28298 for ietf-calendar-bks; Wed, 16 May 2001 20:26:34 -0700 (PDT) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA28293 for ; Wed, 16 May 2001 20:26:27 -0700 (PDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA10216; Wed, 16 May 2001 23:30:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 May 2001 23:26:25 -0400 Message-ID: From: Jonathan Rosenberg To: "'Shannon J. Clark'" , ietf-calendar@imc.org Subject: RE: RECAP & Questions of CPL RECUR Issues. Date: Wed, 16 May 2001 23:26:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Shannon J. Clark [mailto:shannon@jigzaw.com] > Sent: Wednesday, May 16, 2001 7:09 PM > To: ietf-calendar@imc.org > Subject: RE: RECAP & Questions of CPL RECUR Issues. > > > A few quick observations. > > If CPL is proposing an algorithm that tests "whether the date-time > intersected the rule" this implies that given a large set of > RRULES - ALL > rules must be tested at ALL points in time... this seems > potentially very > complex vs. evaluating out the RRULES and testing against a set that > contains all occurrences for ALL objects (for the given > calendar) - which > should be a very manageable test. > > I.E. - are they really proposing that for every point in time > that their > software needs to "do" something, it checks (and evaluates) > ALL RRULES on > ALL objects in the calendar(s) present for the software and then do > something based on those events? The specifications don't mandate one way or the other. I suspect the current implementations probably do evaluate the RRULES on all objects to find a match against the current time, when an incoming call arrives. In typical CPL usage, a user will make use of some kind of tool to specify some call features they would like to apply. The CPL specifying those features is then constructed and uploaded to a server. The means by which it is uploaded are outside the specification, and several possibilities exist. Jonathan L. has written a draft that proposes using SIP REGISTER for uploading the CPL: http://search.ietf.org/internet-drafts/draft-lennox-sip-reg-payload-01.txt at that time, the server validates the CPL and stores it. When a call arrives for that user, the CPL is fetched and processed to determine how to handle the call. It is possible that the CPL had a time-switch, which determines call processing actions based on whether the current time of day is within a recurrence. You can read more about CPL usage scenarios in RFC2824. Typically, a single server will store and manage a large number of CPL scripts, one for each of the users it owns. > > In developing my company's software we are evaluating RRULES > when the enter > our server to get to a set of occurrences - subsequently we > check against > this set for occurrences that overlap the period of time that > we need to > evaluate for. Interesting. So, for the CPL case, you would basically expand the recurrences at CPL upload time, trim those in the past or far in the future, and then store the CPL script with the subset of the recurrences? Presumably this would require storage of the recurrences, so that we still want to have bounds on that size. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From owner-ietf-calendar@mail.imc.org Thu May 17 10:35:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18626 for ; Thu, 17 May 2001 10:35:51 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA29018 for ietf-calendar-bks; Thu, 17 May 2001 07:18:41 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA28988 for ; Thu, 17 May 2001 07:18:31 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4HEJ7303442; Thu, 17 May 2001 10:19:08 -0400 Message-ID: <3B03DDDB.7BD1CB13@ecal.com> Date: Thu, 17 May 2001 10:19: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 CC: lennox@cs.columbia.edu Subject: Re: RECAP & Questions of CPL RECUR Issues. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > Also, feature removal of already demonstrated interop features > is not good is it?? Again, it is not forbidden. If we can't get two interoperating CUAs that support the entire RECUR syntax, we'll have to cut something. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |A successful tool is one that was used to do | |francis@ecal.com|something undreamed of by its author. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 10:41: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 KAA18755 for ; Thu, 17 May 2001 10:41:51 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA29455 for ietf-calendar-bks; Thu, 17 May 2001 07:25:00 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29447 for ; Thu, 17 May 2001 07:24:54 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4HEPF303456; Thu, 17 May 2001 10:25:16 -0400 Message-ID: <3B03DF4B.40E3123D@ecal.com> Date: Thu, 17 May 2001 10:25:15 -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: Bruce_Kahn@iris.com CC: coral , ietf-calendar@imc.org, Rk-Devel Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) 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: > If you are trying to 'simplify' the ABNF so that you can have > "PT10M" (ie: no "0H") then this proposal wont do it. I believe the current ABNF permits it, actually, because: dur-time = "T" (dur-hour / dur-minute / dur-second) ...and 10M matches dur-minute. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |In the country of the blind, the one-eyed man is| |francis@ecal.com|in therapy. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 10:46:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18886 for ; Thu, 17 May 2001 10:46:54 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA29884 for ietf-calendar-bks; Thu, 17 May 2001 07:31:52 -0700 (PDT) Received: from dancing-bare.dsl-only.net (dancing-bare.dsl-only.net [63.105.16.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29862 for ; Thu, 17 May 2001 07:31:45 -0700 (PDT) Received: from coral (unverified [63.105.21.104]) by dancing-bare.dsl-only.net (Rockliffe SMTPRA 4.5.4) with SMTP id ; Thu, 17 May 2001 07:38:20 -0700 From: "coral" To: "John Stracke" Cc: , "Rk-Devel" Subject: RE: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) Date: Thu, 17 May 2001 07:32:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3B03DF4B.40E3123D@ecal.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > Bruce_Kahn@iris.com wrote: > > > If you are trying to 'simplify' the ABNF so that you can have > > "PT10M" (ie: no "0H") then this proposal wont do it. > > I believe the current ABNF permits it, actually, because: > > dur-time = "T" (dur-hour / dur-minute / dur-second) > > ...and 10M matches dur-minute. So, this leaves us with "PT10M" and "P1W" valid? Great! I'll continue using PT0S for zero durations, it seems the most useful of the possibilities. coral From owner-ietf-calendar@mail.imc.org Thu May 17 11:58: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 LAA20844 for ; Thu, 17 May 2001 11:58:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA05108 for ietf-calendar-bks; Thu, 17 May 2001 08:43:00 -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 IAA05083 for ; Thu, 17 May 2001 08:42: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 LAA10411 for ; Thu, 17 May 2001 11:42:53 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id LAA68875; Thu, 17 May 2001 11:42:53 -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: <15107.61820.912612.674288@conrail.cs.columbia.edu> Date: Thu, 17 May 2001 11:42:52 -0400 (EDT) To: ietf-calendar@imc.org Subject: Clarification and current status of CPL RECUR thoughts In-Reply-To: <3B03DDDB.7BD1CB13@ecal.com> References: <3B03DDDB.7BD1CB13@ecal.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I thought I'd clarify further my current thoughts on RECUR in CPL. After my phone conversation with Eric Busboom, we agreed that we could do everything CPL needed with only one change to RECUR: * Drop BYSETPOS. I also suggested two clarifications/recommendations: * A server (CPL server, calendaring server, whatever) MAY reject any RECUR rule on the grounds that it's too "expensive" (complex, whatever). The definition of expense/complexity is implementation-dependent. * We ought to add text to the recur definition which says that a server SHOULD support any RECUR which meets certain constraints. This allows us to guarantee that unconditionally compliant implementations will be interoperable. (The exact nature and values of these constraints can be hashed out later.) Note that this means: * COUNT is back (but may be subject to the server's complexity rules). * Sub-day frequencies and BY* rules are back. * Durations can be any length (subject to the server's complexity rules). I have (mostly) completed an implementation -- a modification to the Java code I released late last year -- which implements this RECUR-minus- BYSETPOS. It correctly generates all the RECUR examples from 2445 except the two which use BYSETPOS. The two complexity constraints I impose in my code are that if a rule has a COUNT value, it must be fully satisifed before a caller-specified time and a caller-specified recurrence of the smallest time unit mentioned in the rule; and the duration of a recurrence must be less than a caller-specified multiple of the smallest time unit mentioned in the rule. The running time of my code is linear in the caller-specified bounds. (The COUNT bounds are linear once; the duration bound is linear every time the rule is evaluated.) In all other respects it's linear in the textual size of the rule. It's possible to determine whether a rule exceeds the bounds at the time a script is submitted to a server. In the phone conversation, Eric seemed to indicate that he thought that BYSETPOS was too complex for iCalendar as well. And of course iCalendar (2446, yes?) already has the concept of rejecting a calendering object for being too complex. What's the feeling of the working group on this proposal? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Thu May 17 12:06:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21108 for ; Thu, 17 May 2001 12:06:58 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA05925 for ietf-calendar-bks; Thu, 17 May 2001 08:48:16 -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 IAA05905 for ; Thu, 17 May 2001 08:48:08 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org, lennox@cs.columbia.edu Subject: Re: RECAP & Questions of CPL RECUR Issues. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05132001 May 13, 2001 Message-ID: Date: Thu, 17 May 2001 11:53:20 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/17/2001 11:50:24 AM, Serialize complete at 05/17/2001 11:50:24 AM Content-Type: multipart/alternative; boundary="=_alternative 0056A87785256A4F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0056A87785256A4F_= Content-Type: text/plain; charset="us-ascii" John replied on 05/17/2001 10:19:07 AM: > > Also, feature removal of already demonstrated interop features > > is not good is it?? > > Again, it is not forbidden. If we can't get two interoperating > CUAs that support the entire RECUR syntax, we'll have to cut > something. Removing the subcomponent in this case would suite the intent of interop testing. If 2 independent implementations have demonstrated that they use and support it, WHY cut that?!?!? The intent is to cut stuff that is not implemented/supported, not stuff that is! Still Im not buying the argument that cutting is necessary yet. As we have seen from our own internal WG discussions, clarifications (and some minor tweaks) are in order to make the recurrence grammar less ambiguous and to make interop easier. Nearly all, if actually all, of the recurrence grammar subcomponents have been implemented by at least 2 different implementions that I can think of so what is there to really cut? 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 0056A87785256A4F_= Content-Type: text/html; charset="us-ascii"
John replied on 05/17/2001 10:19:07 AM:
> > Also, feature removal of already demonstrated interop features
> > is not good is it??
>
> Again, it is not forbidden.  If we can't get two interoperating
> CUAs that support the entire RECUR syntax, we'll have to cut
> something.
Removing the subcomponent in this case would suite the intent of interop testing.  If 2 independent implementations have demonstrated that they use and support it, WHY cut that?!?!?  The intent is to cut stuff that is not implemented/supported, not stuff that is!  

Still Im not buying the argument that cutting is necessary yet.  As we have seen from our own internal WG discussions, clarifications (and some minor tweaks) are in order to make the recurrence grammar less ambiguous and to make interop easier.  

Nearly all, if actually all, of the recurrence grammar subcomponents have been implemented by at least 2 different implementions that I can think of so what is there to really cut?  

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 0056A87785256A4F_=-- From owner-ietf-calendar@mail.imc.org Thu May 17 12:11: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 MAA21259 for ; Thu, 17 May 2001 12:11:33 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA04306 for ietf-calendar-bks; Thu, 17 May 2001 08:38:00 -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 IAA04282 for ; Thu, 17 May 2001 08:37:54 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org, Rk-Devel , coral Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05132001 May 13, 2001 Message-ID: Date: Thu, 17 May 2001 11:42:47 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/17/2001 11:40:08 AM, Serialize complete at 05/17/2001 11:40:08 AM Content-Type: multipart/alternative; boundary="=_alternative 0055B11985256A4F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0055B11985256A4F_= Content-Type: text/plain; charset="us-ascii" John wrote on 05/17/2001 10:25:15 AM: > I believe the current ABNF permits it, actually, because: > > dur-time = "T" (dur-hour / dur-minute / dur-second) > > ...and 10M matches dur-minute. You are correct. The online copy at RFC-Editor.org matches it. My copy did not and it supposedly came from the IETF archives when we got our #. My printed copy from Frank also has that so I think the IBM archived copp is not the final one. Hmm, sorry about that. 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 0055B11985256A4F_= Content-Type: text/html; charset="us-ascii"
John wrote on 05/17/2001 10:25:15 AM:
> I believe the current ABNF permits it, actually, because:
>
>      dur-time   = "T" (dur-hour / dur-minute / dur-second)
>
> ...and 10M matches dur-minute.

You are correct.  The online copy at RFC-Editor.org matches it.  My copy did not and it supposedly came from the IETF archives when we got our #.  My printed copy from Frank also has that so I think the IBM archived copp is not the final one.  Hmm, sorry about that.

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 0055B11985256A4F_=-- From owner-ietf-calendar@mail.imc.org Thu May 17 12:22: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 MAA21521 for ; Thu, 17 May 2001 12:22:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA08882 for ietf-calendar-bks; Thu, 17 May 2001 09:08:27 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA08865 for ; Thu, 17 May 2001 09:08:21 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4HG95303944; Thu, 17 May 2001 12:09:06 -0400 Message-ID: <3B03F7A1.474A6541@ecal.com> Date: Thu, 17 May 2001 12:09: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 CC: Jonathan Lennox Subject: Re: RECAP & Questions of CPL RECUR Issues. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > John wrote: > > If my calendar turns "every Monday for a year" into > "1/1, 1/8, 1/15, > >1/22, ...", then I can't edit it to be "every Tuesday" without > a massive > >investment of my time. > > Under the covers it is going to have to roll it out somehow so > that the entries can be shown in the UI to you (or so that > 'exceptions' or changes to individual instances can be applied > and managed!). If the UI makes a change that requires _you_ to > jump thru hoops to reschedule them all, is that the problem > w/the spec or w/the CUA? With the CUA. In context, I was pointing out that a CUA that does that is not worrying about. > >Yeah, but I don't think they simplify the conceptual model; > they just add extra > >limitations that the user has to understand. > > From what Ive been able to get out of the exchange between > iptel and calsch is that the concerns are not those of the end > users but rather the vendors implementing iptel. That's iptel's concern. Meanwhile, I am concerned with the fact that RECUR is too complex for calendar users; if we're going to come up with a fix for iptel, I want a fix that makes RECUR usable for calendaring, too. > As such, "user confusion" is not a likely conern (unless you > expect a poor UI/GUI and thats not something we can or should > try to spec out). We don't spec a UI, but we spec the data model that the UI has to represent. At present, I doubt it is possible to build a good UI to represent RECUR. The UI has to reflect the concepts in the data model, and RECUR contains far too many concepts. > Besides, what CU is actually reading RRULEs that their CUA > generates and trying to understand them?!?! In effect, everybody. They won't read the RECUR syntax, but they will read the UI's presentation of them. Anybody who gets an invitation to a recurring meeting wants to remember the rule for when it happens (e.g., "Mondays at 3:00"), so that they're less dependent on the calendar. If there's a part of the rule that their CUA's backend understands, but the UI can't represent, then it'll be on their calendar, but it won't be in their mental model of when the event occurs, so they're likely to miss it. > They simply want to be able to schedule "that weekly Monday AM > and Thursday PM team meeting for the next 18 months at 9AM". The problem is that they can receive invitations that are *far* more complex than that. -- /==============================================================\ |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 Thu May 17 12:32:20 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 MAA21766 for ; Thu, 17 May 2001 12:32:19 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA09868 for ietf-calendar-bks; Thu, 17 May 2001 09:14:02 -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 JAA09861 for ; Thu, 17 May 2001 09:13:55 -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 MAA09030 for ; Thu, 17 May 2001 12:13:27 -0400 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f4HGDQv27618 for ; Thu, 17 May 2001 12:13:26 -0400 (EDT) Message-ID: <077d01c0deec$0ff8ddf0$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: Subject: Re: RECAP & Questions of CPL RECUR Issues. Date: Thu, 17 May 2001 12:11:42 -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: "John Stracke" Cc: ; Sent: 17 May, 2001 11:53 Subject: Re: RECAP & Questions of CPL RECUR Issues. > John replied on 05/17/2001 10:19:07 AM: > > > Also, feature removal of already demonstrated interop features > > > is not good is it?? > > > > Again, it is not forbidden. If we can't get two interoperating > > CUAs that support the entire RECUR syntax, we'll have to cut > > something. > > Removing the subcomponent in this case would suite the intent of interop > testing. If 2 independent implementations have demonstrated that they use > and support it, WHY cut that?!?!? The intent is to cut stuff that is not implemented/supported, not stuff that is! > > Still Im not buying the argument that cutting is necessary yet. As we > have seen from our own internal WG discussions, clarifications (and some > minor tweaks) are in order to make the recurrence grammar less ambiguous > and to make interop easier. > > Nearly all, if actually all, of the recurrence grammar subcomponents have > been implemented by at least 2 different implementions that I can think of > so what is there to really cut? Isn't the whole point of pushing for these standards to make it easier for people looking to implement something that can communicate with other implementations? What's the point of having a standard that's so complex and difficult that only the largest/most resourceful organizations can actually create a working implementation? How many vCalendar (1.0) implementations exist out there simply because iCalendar was seen as too hard to implement? Excuse my idealism.... Graham From owner-ietf-calendar@mail.imc.org Thu May 17 12:54:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22279 for ; Thu, 17 May 2001 12:54:36 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA10445 for ietf-calendar-bks; Thu, 17 May 2001 09:24:20 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10438 for ; Thu, 17 May 2001 09:24:13 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA24098; Thu, 17 May 2001 11:22:52 -0500 From: "Shannon J. Clark" To: "Jonathan Rosenberg" , Subject: RE: RECAP & Questions of CPL RECUR Issues. Date: Thu, 17 May 2001 11:23:40 -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: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jonathan, Thanks for the explanation about the CPL usage. Some observations that this leads to about calendar usage in general and RRULES specifically. CPL has a model of use that supposed FEW calendar objects in a calendar (you cite one, I suspect in real usage it will be more than one but still a small number). CPL is also interested in a POINT TIME question - i.e. which CalObjects apply NOW (where "NOW" is the current time of the switch, perhaps adjusted per the user's timezone settings). My software, and I suspect many other company's software in the calendaring/scheduling space have a model which assumes MANY CalObjects for a given user (perhaps in one vCalendar, perhaps in a collection of vCalendars) and are mostly dealing with TIME RANGES - i.e. what CalObjects to return for "TODAY", "THIS WEEK", "NEXT MONTH" - this frequently is based on a use of "NOW" also adjusted for the user's timezone settings, but from a calendar server's perspective is rarely dealing with POINT TIME issues. This leads to a number of algorithmic differences - which may also point to some simplifications for CPL. One - CPL may NOT need to deal with the full set of occurrences of each CalObject - rather, CPL needs an algorithm that given the following properties of the CalObject and "NOW" returns whether the given CalObject is in effect "NOW": DTSTART, DTEND, DURATION, + all RRULE properties (including exception rules). Processing can perhaps take advantage of various optimizations made possible by these constraints. Two - since CPL assumes FEW CalObjects it is probable that the calculation time needed to check each CalObject at every usage occurrence (i.e. whenever a call comes into the switch) is manageable - but does need to be very fast so as not to delay the processing of the call. CPL will need to deal with aging of events - otherwise after a while there will be more CalObjects that occur only in the past than are potentially applicable to the present. Three - CPL's model of usage appears to imply no need to worry about the future OR the past - all CPL is concerned with is whether or not the CalObject is active NOW (where "active" is defined by Start/end/duration settings on the object) this differs from traditional calendar usage with is concerned with the past, the future, and the present period (i.e. what did I do last week, what am I doing today, what will I be doing next week). Four - the requirements of a traditional calendar/scheduling application is that the server can return to a Calendar User Agent the correct set of calendar objects. Some CUA's may request the FULL calendar(s) for the user and expand the RRULES themselves, others may expect just a set of CalObjects and not perform RRULE expansion (for example in wireless devices it is not sensible to send a large many year, 1000's of object calendar if the user just wants to look at next week - but the server does have to send EVERY object that applies for next week). Five - this leads to some calendar systems to differentiate between CalObject with and without RRULES (based on usage observations I think that MS Outlook is one example of a CUA that segregates object with RRULES). Six - thus the algorithm's used by a traditional C&S server (or CUA) will need to be able to check RRULE's against a TIME PERIOD i.e. set mathematics vs. point mathematics. Time periods are a set of times with two boundary conditions - each possible CalObject has to in some way be checked whether it falls within that set. I have observed a number of Calendar systems that FAIL to do this correctly - most usually by failing to show events starting on one day but continuing into the next day on the following day - this implies that the algorithm used checked only for START times in the period (in this case one day) and did not look at the duration and/or end times (depending on how the user defined the event). I would be interested to know if my observations gel with other members of this group - and perhaps someone with more formal training in these types of time mathematics can help with the algorithmic differences and differing optimizations that are possible for CPL vs. traditional C&S systems. 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 Jonathan Rosenberg Sent: Wednesday, May 16, 2001 10:26 PM To: 'Shannon J. Clark'; ietf-calendar@imc.org Subject: RE: RECAP & Questions of CPL RECUR Issues. > -----Original Message----- > From: Shannon J. Clark [mailto:shannon@jigzaw.com] > Sent: Wednesday, May 16, 2001 7:09 PM > To: ietf-calendar@imc.org > Subject: RE: RECAP & Questions of CPL RECUR Issues. > > > A few quick observations. > > If CPL is proposing an algorithm that tests "whether the date-time > intersected the rule" this implies that given a large set of > RRULES - ALL > rules must be tested at ALL points in time... this seems > potentially very > complex vs. evaluating out the RRULES and testing against a set that > contains all occurrences for ALL objects (for the given > calendar) - which > should be a very manageable test. > > I.E. - are they really proposing that for every point in time > that their > software needs to "do" something, it checks (and evaluates) > ALL RRULES on > ALL objects in the calendar(s) present for the software and then do > something based on those events? The specifications don't mandate one way or the other. I suspect the current implementations probably do evaluate the RRULES on all objects to find a match against the current time, when an incoming call arrives. In typical CPL usage, a user will make use of some kind of tool to specify some call features they would like to apply. The CPL specifying those features is then constructed and uploaded to a server. The means by which it is uploaded are outside the specification, and several possibilities exist. Jonathan L. has written a draft that proposes using SIP REGISTER for uploading the CPL: http://search.ietf.org/internet-drafts/draft-lennox-sip-reg-payload-01.txt at that time, the server validates the CPL and stores it. When a call arrives for that user, the CPL is fetched and processed to determine how to handle the call. It is possible that the CPL had a time-switch, which determines call processing actions based on whether the current time of day is within a recurrence. You can read more about CPL usage scenarios in RFC2824. Typically, a single server will store and manage a large number of CPL scripts, one for each of the users it owns. > > In developing my company's software we are evaluating RRULES > when the enter > our server to get to a set of occurrences - subsequently we > check against > this set for occurrences that overlap the period of time that > we need to > evaluate for. Interesting. So, for the CPL case, you would basically expand the recurrences at CPL upload time, trim those in the past or far in the future, and then store the CPL script with the subset of the recurrences? Presumably this would require storage of the recurrences, so that we still want to have bounds on that size. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From owner-ietf-calendar@mail.imc.org Thu May 17 12:54: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 MAA22290 for ; Thu, 17 May 2001 12:54:41 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA10779 for ietf-calendar-bks; Thu, 17 May 2001 09:30:16 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10762 for ; Thu, 17 May 2001 09:30:09 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA24115; Thu, 17 May 2001 11:28:38 -0500 From: "Shannon J. Clark" To: Cc: Subject: RE: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) Date: Thu, 17 May 2001 11:29:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0DEC4.A1115D80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0DEC4.A1115D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This points out something I have suspected from previous discussions here (where people cited different paginations, different ABNF texts etc), we (all members of the working group) should be VERY clear in our correspondences the VERSION of the documentation(s) that we are working from. If we make this a practice it should minimize future problems like this - and help bring out respective archives up to date if they have fallen behind - there are enough topics for discussion without miscommunications needing to be one. (for the RFC's this means RFC# + submission date, for the proposals like CAP this would be the CAP version #, as well as perhaps the expiry date) Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Bruce_Kahn@iris.com Sent: Thursday, May 17, 2001 10:43 AM To: John Stracke Cc: ietf-calendar@imc.org; Rk-Devel; coral Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) John wrote on 05/17/2001 10:25:15 AM: > I believe the current ABNF permits it, actually, because: > > dur-time = "T" (dur-hour / dur-minute / dur-second) > > ...and 10M matches dur-minute. You are correct. The online copy at RFC-Editor.org matches it. My copy did not and it supposedly came from the IETF archives when we got our #. My printed copy from Frank also has that so I think the IBM archived copp is not the final one. Hmm, sorry about that. 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... ------=_NextPart_000_0014_01C0DEC4.A1115D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This = points out=20 something I have suspected from previous discussions here (where people = cited=20 different paginations, different ABNF texts etc), we (all members of the = working=20 group) should be VERY clear in our correspondences the VERSION of the=20 documentation(s) that we are working from.
 
If we = make this a=20 practice it should minimize future problems like this - and help bring = out=20 respective archives up to date if they have fallen behind - there are = enough=20 topics for discussion without miscommunications needing to be=20 one.
 
(for = the RFC's this=20 means RFC# + submission date, for the proposals like CAP this would be = the CAP=20 version #, as well as perhaps the expiry date)
 
Shannon
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of=20 Bruce_Kahn@iris.com
Sent: Thursday, May 17, 2001 10:43=20 AM
To: John Stracke
Cc: ietf-calendar@imc.org; = Rk-Devel;=20 coral
Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration = (original=20 and May 10th draft)


John wrote on 05/17/2001 10:25:15 AM:
> I believe the = current=20 ABNF permits it, actually, because:
>
>    =20  dur-time   =3D "T" (dur-hour / dur-minute / = dur-second)
>=20
> ...and 10M matches dur-minute.

You are correct.  The online copy at RFC-Editor.org = matches it.=20  My copy did not and it supposedly came from the IETF archives = when we=20 got our #.  My printed copy from Frank also has that so I think = the IBM=20 archived copp is not the final one.  Hmm, sorry about = that.=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=20 Kahn                   =  =20            INet: = Bruce_Kahn@iris.com
Iris=20 Associates                 =  =20        Phone: 978.392.5335
Westford, MA, USA = 01886=20                   =  FAX: and=20 nothing but the FAX...
Standard disclaimers apply, even where = prohibited by=20 law...
------=_NextPart_000_0014_01C0DEC4.A1115D80-- From owner-ietf-calendar@mail.imc.org Thu May 17 14:17:08 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 OAA24017 for ; Thu, 17 May 2001 14:17:07 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA14987 for ietf-calendar-bks; Thu, 17 May 2001 10:54:29 -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 KAA14983 for ; Thu, 17 May 2001 10:54:22 -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 NAA20528; Thu, 17 May 2001 13:54:24 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id NAA69059; Thu, 17 May 2001 13:54:23 -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: <15108.4175.399831.946304@conrail.cs.columbia.edu> Date: Thu, 17 May 2001 13:54:23 -0400 (EDT) To: "Shannon J. Clark" Cc: "Jonathan Rosenberg" , Subject: RE: RECAP & Questions of CPL RECUR Issues. 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 Thursday, May 17 2001, "Shannon J. Clark" wrote to "Jonathan Rosenberg, " saying: > Some observations that this leads to about calendar usage in general and > RRULES specifically. > > CPL has a model of use that supposed FEW calendar objects in a calendar > (you cite one, I suspect in real usage it will be more than one but still a > small number). CPL is also interested in a POINT TIME question - i.e. which > CalObjects apply NOW (where "NOW" is the current time of the switch, perhaps > adjusted per the user's timezone settings). Yes, exactly. We anticipate there being a small number of rules (but more than one) per user. (Timezones actually bind to rules, not to NOW -- NOW is now (e.g. time(0) on Unix), always. Note this is in contrast to things like "TODAY" -- the definition of "TODAY" varies by timezone, so you have to describe both "TODAY", and the user's rules, by the user's timezone.) > My software, and I suspect many other company's software in the > calendaring/scheduling space have a model which assumes MANY CalObjects for > a given user (perhaps in one vCalendar, perhaps in a collection of > vCalendars) and are mostly dealing with TIME RANGES - i.e. what CalObjects > to return for "TODAY", "THIS WEEK", "NEXT MONTH" - this frequently is based > on a use of "NOW" also adjusted for the user's timezone settings, but from a > calendar server's perspective is rarely dealing with POINT TIME issues. Yes. I guess the question "who is Joe meeting with right now" is perhaps occasionally interesting, but hardly the usual case. > This leads to a number of algorithmic differences - which may also point to > some simplifications for CPL. > > One - CPL may NOT need to deal with the full set of occurrences of each > CalObject - rather, CPL needs an algorithm that given the following > properties of the CalObject and "NOW" returns whether the given CalObject is > in effect "NOW": DTSTART, DTEND, DURATION, + all RRULE properties (including > exception rules). Processing can perhaps take advantage of various > optimizations made possible by these constraints. Yes. This is what my code does -- the algorithm is a two-phase operation. First, "if we were in an event right now, when could it have started?" Secondly, "is that time actually a valid recurrence time for this rule?" This is a lot simpler than fully expanding a set. > Two - since CPL assumes FEW CalObjects it is probable that the calculation > time needed to check each CalObject at every usage occurrence (i.e. whenever > a call comes into the switch) is manageable - but does need to be very fast > so as not to delay the processing of the call. There are two other interesting properties of CPL vs. the usual calendar model. First of all, I imagine CPL rules are much more likely to expand to huge numbers of events than typical calendars would. For instance, it would be entirely probable to have a rule "during working hours" -- in other words, "9 to 5, Monday through Friday, forever." This expands to hundreds of events per year, many more than you'd expect for normal calendar usage I imagine. Another important thing to note is that for CPL you need to have a concept of the *relative priority* of recurrences. For instance, you can have a "during working hours, ring the phone at my desk" rule, and a "during this meeting, send my calls to voicemail" rule. If your meeting is during working hours (as one would hope), there needs to be some way of specifying which one wins. In CPL we do this by just letting the rules have a physical order in the file, and giving them first-match semantics. One nice side effect of this is that EXRULE and EXDATE can just turn into special cases of the above ordering semantics. (With some trickiness (which I just posted to IPTel about) involving earlier EXRULEs falling through to later rules, but this is resolvable.) > CPL will need to deal with > aging of events - otherwise after a while there will be more CalObjects that > occur only in the past than are potentially applicable to the present. I haven't really thought about this much, but in CPL's model, this is left up to the client-side, not the server-side. > Three - CPL's model of usage appears to imply no need to worry about the > future OR the past - all CPL is concerned with is whether or not the > CalObject is active NOW (where "active" is defined by Start/end/duration > settings on the object) this differs from traditional calendar usage with is > concerned with the past, the future, and the present period (i.e. what did I > do last week, what am I doing today, what will I be doing next week). Yes. > Six - thus the algorithm's used by a traditional C&S server (or CUA) will > need to be able to check RRULE's against a TIME PERIOD i.e. set mathematics > vs. point mathematics. Time periods are a set of times with two boundary > conditions - each possible CalObject has to in some way be checked whether > it falls within that set. > > I have observed a number of Calendar systems that FAIL to do this > correctly - most usually by failing to show events starting on one day but > continuing into the next day on the following day - this implies that the > algorithm used checked only for START times in the period (in this case one > day) and did not look at the duration and/or end times (depending on how the > user defined the event). Actually, I don't think set-mathematics vs. point-mathematics are that different. The fundamental operation of the point-mathematics algorithm is "what is the previous possible time this event could have started." It's pretty easy to use much the same operations (modulo a few tricky details involving irregularly-sized units such as months) to instead ask the question "what is the next possible time this event could start." Set-mathematics is basically "start at beginning of interval, roll backward for DURATION checking candidate start times, roll forward to end of set checking candidate start times." It's pretty straightforward. (This is essentially what I have to do for the COUNT -> computed virtual UNTIL transformation, and it seems to be reasonably efficient.) The problem with this is that it doesn't seem to be possible to resolve BYSETPOS (especially negative BYSETPOS) without actually expanding the set, which breaks this whole mechanism. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Thu May 17 15:06:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24998 for ; Thu, 17 May 2001 15:06:25 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA15965 for ietf-calendar-bks; Thu, 17 May 2001 11:47:11 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15960 for ; Thu, 17 May 2001 11:47:05 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4HIlo304548 for ; Thu, 17 May 2001 14:47:51 -0400 Message-ID: <3B041CD6.973113A9@ecal.com> Date: Thu, 17 May 2001 14:47:50 -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 & Questions of CPL RECUR Issues. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > John replied on 05/17/2001 10:19:07 AM: > > If we can't get two interoperating > > CUAs that support the entire RECUR syntax, we'll have to cut > > something. > > Removing the subcomponent in this case would suite the intent > of interop testing. If 2 independent implementations have > demonstrated that they use and support it, WHY cut that?!?!? > The intent is to cut stuff that is not implemented/supported, > not stuff that is! To reach Draft Standard, there need to be two implementations which implement the *entire* specification. You can't cherry-pick; you can't say, "A and B support X, and C and D support Y, so we keep X and Y" (unless X and Y are optional). -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Know your limits, then destroy 'em. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 15:13:00 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 PAA25084 for ; Thu, 17 May 2001 15:12:59 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA16127 for ietf-calendar-bks; Thu, 17 May 2001 11: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 LAA16100 for ; Thu, 17 May 2001 11:53:01 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4HIrh304587 for ; Thu, 17 May 2001 14:53:44 -0400 Message-ID: <3B041E37.9E571D7B@ecal.com> Date: Thu, 17 May 2001 14:53:43 -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: Clarification and current status of CPL RECUR thoughts References: <3B03DDDB.7BD1CB13@ecal.com> <15107.61820.912612.674288@conrail.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > * A server (CPL server, calendaring server, whatever) MAY reject any RECUR > rule on the grounds that it's too "expensive" (complex, whatever). The > definition of expense/complexity is implementation-dependent. > > * We ought to add text to the recur definition which says that a server > SHOULD support any RECUR which meets certain constraints. This allows us > to guarantee that unconditionally compliant implementations will be > interoperable. This will be equivalent to cutting some parts of RECUR and allowing for extensions. But, really, extensions in the data model are poison; if I schedule a meeting using extensions, and I can't send that meeting to everyone I want to be there, then I just can't use the extensions. Worse, it's going to be really hard to explain to the user which part of their invitation caused the problem. > In the phone conversation, Eric seemed to indicate that he thought that > BYSETPOS was too complex for iCalendar as well. And of course iCalendar > (2446, yes?) already has the concept of rejecting a calendering object for > being too complex. Does it? I haven't been able to find such a thing in 2445 or 2446. CAP might have it, but CAP is special; it's got a real-time channel over which it can send errors. That gets harder in iTIP. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"Music is not a noun, it's a verb." --John Perry| |francis@ecal.com|Barlow | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 15:53:05 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 PAA25975 for ; Thu, 17 May 2001 15:53:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA18517 for ietf-calendar-bks; Thu, 17 May 2001 12:34:37 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA18508 for ; Thu, 17 May 2001 12:34:31 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4HJZG304815 for ; Thu, 17 May 2001 15:35:16 -0400 Message-ID: <3B0427F3.A5D789E7@ecal.com> Date: Thu, 17 May 2001 15:35:15 -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: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) 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: > This points out something I have suspected from previous > discussions here (where people cited different paginations, > different ABNF texts etc), we (all members of the working > group) should be VERY clear in our correspondences the VERSION > of the documentation(s) that we are working from. There is only supposed to be one version of an RFC. An oddity like this is an exception, not the norm. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Any sufficiently rigged demo is | |francis@ecal.com|indistinguishable from advanced technology. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 16:56: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 QAA26886 for ; Thu, 17 May 2001 16:56:43 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA21456 for ietf-calendar-bks; Thu, 17 May 2001 13:28:53 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA21435 for ; Thu, 17 May 2001 13:28:46 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id PAA24492; Thu, 17 May 2001 15:27:22 -0500 From: "Shannon J. Clark" To: "John Stracke" , Subject: RE: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) Date: Thu, 17 May 2001 15:28:14 -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) In-Reply-To: <3B0427F3.A5D789E7@ecal.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit How then are corrections and updates to the RFC's done? In my own files I have TWO versions of RFC2445, one dated November 1998, and a more recently submitted one that has some changes/corrections dated May 2001. I agree that this should be the exception - but it is a sticky issue with the whole process - as the drafts go through their changes the underlying document WILL change. Since individuals and companies will copy the files, store them offline and/or mirror copies online there will be different versions of what could appear to be the same draft... not a happy state of affairs perhaps, but it has and will happen. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Thursday, May 17, 2001 2:35 PM To: ietf-calendar@imc.org Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) "Shannon J. Clark" wrote: > This points out something I have suspected from previous > discussions here (where people cited different paginations, > different ABNF texts etc), we (all members of the working > group) should be VERY clear in our correspondences the VERSION > of the documentation(s) that we are working from. There is only supposed to be one version of an RFC. An oddity like this is an exception, not the norm. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Any sufficiently rigged demo is | |francis@ecal.com|indistinguishable from advanced technology. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 17:04:35 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 RAA27086 for ; Thu, 17 May 2001 17:04:34 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA22583 for ietf-calendar-bks; Thu, 17 May 2001 13:36:15 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA22559 for ; Thu, 17 May 2001 13:36:06 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4HKaq305010 for ; Thu, 17 May 2001 16:36:53 -0400 Message-ID: <3B043664.CD4032B4@ecal.com> Date: Thu, 17 May 2001 16:36:52 -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: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) 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: > How then are corrections and updates to the RFC's done? Please read RFC-2026. > In my own files I > have TWO versions of RFC2445, one dated November 1998, and a more recently > submitted one that has some changes/corrections dated May 2001. That second one is not an RFC; it's Eric's proposed updated version of 2445. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Vote for Ron, and nobody gets hurt! --actual | |francis@ecal.com|campaign poster from Chicago | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 17:14:05 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 RAA27293 for ; Thu, 17 May 2001 17:14:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA24176 for ietf-calendar-bks; Thu, 17 May 2001 13:56: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 NAA24163 for ; Thu, 17 May 2001 13:56:32 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA18690; Thu, 17 May 2001 16:56:04 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4HKu3v24925; Thu, 17 May 2001 16:56:03 -0400 (EDT) Message-Id: <5.0.0.25.0.20010517165427.026e7bf0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 May 2001 16:56:19 -0400 To: "Shannon J. Clark" From: Alan Davies Subject: RE: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) Cc: ietf-calendar@imc.org In-Reply-To: References: <3B0427F3.A5D789E7@ecal.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Once an RFC is published, it can't be updated in any way- not even for an error or typo: http://www.rfc-editor.org/rfcfaq.html --Alan At 03:28 PM 17/05/2001 -0500, you wrote: >How then are corrections and updates to the RFC's done? In my own files I >have TWO versions of RFC2445, one dated November 1998, and a more recently >submitted one that has some changes/corrections dated May 2001. > >I agree that this should be the exception - but it is a sticky issue with >the whole process - as the drafts go through their changes the underlying >document WILL change. Since individuals and companies will copy the files, >store them offline and/or mirror copies online there will be different >versions of what could appear to be the same draft... not a happy state of >affairs perhaps, but it has and will happen. > >Shannon > >-----Original Message----- >From: owner-ietf-calendar@mail.imc.org >[mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke >Sent: Thursday, May 17, 2001 2:35 PM >To: ietf-calendar@imc.org >Subject: Re: [RFC2445] Discrepancy in 4.3.6 Duration (original and May >10th draft) > > >"Shannon J. Clark" wrote: > > > This points out something I have suspected from previous > > discussions here (where people cited different paginations, > > different ABNF texts etc), we (all members of the working > > group) should be VERY clear in our correspondences the VERSION > > of the documentation(s) that we are working from. > >There is only supposed to be one version of an RFC. An oddity >like this is an exception, not the norm. > >-- >/==============================================================\ >|John Stracke | http://www.ecal.com |My opinions are my own.| >|Chief Scientist |=============================================| >|eCal Corp. |Any sufficiently rigged demo is | >|francis@ecal.com|indistinguishable from advanced technology. | >\==============================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 18:16:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27895 for ; Thu, 17 May 2001 18:16:26 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA27991 for ietf-calendar-bks; Thu, 17 May 2001 15:02:27 -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 PAA27973 for ; Thu, 17 May 2001 15:02:21 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: RECAP & Questions of CPL RECUR Issues. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05132001 May 13, 2001 Message-ID: Date: Thu, 17 May 2001 18:03:28 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/17/2001 06:12:26 PM, Serialize complete at 05/17/2001 06:12:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0078EA4385256A4F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0078EA4385256A4F_= Content-Type: text/plain; charset="us-ascii" John claimed: >To reach Draft Standard, there need to be two implementations >which implement the *entire* specification. You can't >cherry-pick; you can't say, "A and B support X, and C and D >support Y, so we keep X and Y" (unless X and Y are optional). Thats not how I read RFC 2026, section 4.1.2 Draft Standard, paragraph 2 where it says: In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. This tells me that both X and Y would stay in the spec as it progressed since at least 2 implementations implement those "options or features". That confirms what I was first told when I was new to IETF. However, perhaps Patrick or some other AD can confirm / decline / clarify this. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0078EA4385256A4F_= Content-Type: text/html; charset="us-ascii"
John claimed:
>To reach Draft Standard, there need to be two implementations
>which implement the *entire* specification.  You can't
>cherry-pick; you can't say, "A and B support X, and C and D
>support Y, so we keep X and Y" (unless X and Y are optional).
Thats not how I read RFC 2026, section 4.1.2  Draft Standard, paragraph 2 where it says:

              In cases in which one or more options or features
  have not been demonstrated in at least two interoperable
  implementations, the specification may advance to the Draft Standard
  level only if those options or features are removed.

This tells me that both X and Y would stay in the spec as it progressed since at least 2 implementations implement those "options or features".  That confirms what I was first told when I was new to IETF.  However, perhaps Patrick or some other AD can confirm / decline / clarify this.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0078EA4385256A4F_=-- From owner-ietf-calendar@mail.imc.org Thu May 17 18:24:47 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 SAA27947 for ; Thu, 17 May 2001 18:24:46 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA27638 for ietf-calendar-bks; Thu, 17 May 2001 15:00:19 -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 PAA27597 for ; Thu, 17 May 2001 15:00:06 -0700 (PDT) From: pregen@egenconsulting.com To: Alan Davies Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, "Shannon J. Clark" Subject: RE: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 17 May 2001 17:59:46 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 05/17/2001 05:59:49 PM, Serialize complete at 05/17/2001 05:59:49 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0078D04385256A4F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0078D04385256A4F_= Content-Type: text/plain; charset="us-ascii" Alan, minor errors can not be corrected in a published RFC - that is correct. That's the errata list. However, if there are changes required to a draft (i.e. ones that impact interoperability), the process is to reissue the draft with a new number. --=_alternative 0078D04385256A4F_= Content-Type: text/html; charset="us-ascii"
Alan, minor errors can not be corrected in a published RFC - that is correct. That's the errata list.  However, if there are changes required to a draft (i.e. ones that impact interoperability), the process is to reissue the draft with a new number. --=_alternative 0078D04385256A4F_=-- From owner-ietf-calendar@mail.imc.org Thu May 17 18:38:28 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 SAA28014 for ; Thu, 17 May 2001 18:38:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA29266 for ietf-calendar-bks; Thu, 17 May 2001 15:15:59 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA29256 for ; Thu, 17 May 2001 15:15:52 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4HMGc305455 for ; Thu, 17 May 2001 18:16:39 -0400 Message-ID: <3B044DC6.68AE14B8@ecal.com> Date: Thu, 17 May 2001 18:16:38 -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 & Questions of CPL RECUR Issues. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > John claimed: > >To reach Draft Standard, there need to be two implementations > >which implement the *entire* specification. You can't > >cherry-pick; you can't say, "A and B support X, and C and D > >support Y, so we keep X and Y" (unless X and Y are optional). > > Thats not how I read RFC 2026, section 4.1.2 Draft Standard, > paragraph 2 where it says: > > In cases in which one or more options or features > > have not been demonstrated in at least two interoperable > implementations, the specification may advance to the Draft > Standard > level only if those options or features are removed. > > This tells me that both X and Y would stay in the spec as it > progressed since at least 2 implementations implement those > "options or features". I *think* "options or features" means things that are not mandatory. If X is mandatory, and C does not support it, then C is not an implementation of the spec. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |You're just jealous because the voices only talk| |francis@ecal.com|to me. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 18:59: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 SAA28263 for ; Thu, 17 May 2001 18:59:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA00460 for ietf-calendar-bks; Thu, 17 May 2001 15:34:56 -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 PAA00450 for ; Thu, 17 May 2001 15:34:50 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA19988; Thu, 17 May 2001 18:34:23 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4HMYNv02212; Thu, 17 May 2001 18:34:23 -0400 (EDT) Message-Id: <5.0.0.25.0.20010517181916.026acbf8@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 May 2001 18:34:38 -0400 To: John Stracke From: Alan Davies Subject: Re: RECAP & Questions of CPL RECUR Issues. Cc: ietf-calendar@imc.org In-Reply-To: <3B044DC6.68AE14B8@ecal.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sometimes it's difficult to work out what is and isn't mandatory- there are lots of places where 'MUST' seems to be implied, without being stated- e.g. iTIP's restriction tables. Also the level of support that implies that a feature has been 'demonstrated' is a grey area- for instance we noticed several properties and values at CalConnect that 1 or more vendor(s) supported on their inputs, but which they couldn't generate themselves. If a CUA can understand property X and allow users to view it, but wouldn't let them create or modify it, have they implemented X? Another example is the VJOURNAL component- it seems that to be compliant with all MUSTs a CUA doesn't have to fully implement VJOURNALs, just return an appropriate status to show that they're not supported. How do other groups test for conformance to RFCs when progressing to Standard Protocol status? --Alan At 06:16 PM 17/05/2001 -0400, you wrote: >Bruce_Kahn@iris.com wrote: > > > > > John claimed: > > >To reach Draft Standard, there need to be two implementations > > >which implement the *entire* specification. You can't > > >cherry-pick; you can't say, "A and B support X, and C and D > > >support Y, so we keep X and Y" (unless X and Y are optional). > > > > Thats not how I read RFC 2026, section 4.1.2 Draft Standard, > > paragraph 2 where it says: > > > > In cases in which one or more options or features > > > > have not been demonstrated in at least two interoperable > > implementations, the specification may advance to the Draft > > Standard > > level only if those options or features are removed. > > > > This tells me that both X and Y would stay in the spec as it > > progressed since at least 2 implementations implement those > > "options or features". > >I *think* "options or features" means things that are not >mandatory. If X is mandatory, and C does not support it, then C >is not an implementation of the spec. > >-- >/=================================================================\ >|John Stracke | http://www.ecal.com |My opinions are my own. | >|Chief Scientist |================================================| >|eCal Corp. |You're just jealous because the voices only talk| >|francis@ecal.com|to me. | >\=================================================================/ From owner-ietf-calendar@mail.imc.org Thu May 17 19:03: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 TAA28306 for ; Thu, 17 May 2001 19:03:05 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA00147 for ietf-calendar-bks; Thu, 17 May 2001 15:30:21 -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 PAA00137; Thu, 17 May 2001 15:30:14 -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 SAA19936; Thu, 17 May 2001 18:29:46 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f4HMTjv01897; Thu, 17 May 2001 18:29:45 -0400 (EDT) Message-Id: <5.0.0.25.0.20010517180550.09918ca0@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 May 2001 18:30:01 -0400 To: pregen@egenconsulting.com From: Alan Davies Subject: RE: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, "Shannon J. Clark" 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: Yes, so referring to RFC2445 is specific enough, as 2445 will not change. 2445 may be obsoleted by RFC9999 at some time in the future though. I assume you're using the term 'draft' to refer to a 'Draft Standard' as opposed to an 'Internet Draft'. iCalendar, iTIP and IMIP are of course 'Proposed Standards' [RFC2800, May 2001]. --Alan At 05:59 PM 17/05/2001 -0400, pregen@egenconsulting.com wrote: >Alan, minor errors can not be corrected in a published RFC - that is >correct. That's the errata list. However, if there are changes required >to a draft (i.e. ones that impact interoperability), the process is to >reissue the draft with a new number. From owner-ietf-calendar@mail.imc.org Fri May 18 14:10:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10217 for ; Fri, 18 May 2001 14:10:50 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA13330 for ietf-calendar-bks; Fri, 18 May 2001 10:48:10 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13326 for ; Fri, 18 May 2001 10:48:03 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f4IHlcd12794; Fri, 18 May 2001 10:47:38 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Fri, 18 May 2001 10:47:37 -0700 (PDT) From: Eric Busboom X-X-Sender: To: Jonathan Lennox , cc: Subject: Can we fix BYSETPOS? In-Reply-To: <15107.61820.912612.674288@conrail.cs.columbia.edu> 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, 17 May 2001, Jonathan Lennox wrote: > I thought I'd clarify further my current thoughts on RECUR in CPL. > > After my phone conversation with Eric Busboom, we agreed that we could do > everything CPL needed with only one change to RECUR: > > * Drop BYSETPOS. > BYSETPOS is problematic for a number of reasons, but there may be a way to fix it so that CPL can use it. The way BYSETPOS is currently specified is that it can take values from 1 to 366 and -1 to -366. Clearly is was intended to enumerate days, but there is no restriction to keep it from being used on a rule that can generate intra-day events, potentially millions of values in the occurrence set, such as by specifying every second of a year. It is silly for BYSETPOS to only let you access the first 366 and the last 366 of a set of 31 million events. There are a few possible fixes for this: (1) Let BYSETPOS take a full range of vlaues from -31 million to +31 million. (2) Declare that BYSETPOS cannot be used on a rule that gnenerates more than 366 events before BYSETPOS is applied. ( Throw an error) (3) Declare that when BYSETPOS appears, the implementation must only consider the first 366 occurrences it generates to be part of the set that BYSETPOS is applied to. (1) is the concept that makes BYSETPOS it unusuable for CPL. However, (2) and (3) imply that an implementation only has to expand 366 events -- they are restrictions that bound the execution time for BYSETPOS. So, could CPL use BYSETPOS if we instituted (2) or (3)? Bruce, would you be happy with (2) or (3)? eric. From owner-ietf-calendar@mail.imc.org Fri May 18 15:01: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 PAA12061 for ; Fri, 18 May 2001 15:01:01 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA14303 for ietf-calendar-bks; Fri, 18 May 2001 11:32:38 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA14299 for ; Fri, 18 May 2001 11:32:32 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id NAA01832 for ; Fri, 18 May 2001 13:32:10 -0500 From: "Shannon J. Clark" To: Subject: RE: Can we fix BYSETPOS? Date: Fri, 18 May 2001 13:31:55 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Along a similar line, what about the following: Restrict BYSETPOS to events of value DATE - that is restrict it to events enumerated by DAY? Now this does raise the point that it is not exactly clear how to define this - events currently could have a DTSTART of type DATE (i.e. no TIME portions) but have a DURATION which include Hours (i.e. an event declared to start on Monday, May 21st, 2001 - and last for 36 hours. On the face of it a not unreasonable type of event - but could also be defined as an event that STARTS Monday May 20th, 2001 at just after midnight with a duration of 36 hours. If defined in the first manner a restriction rule using BYSETPOS could be potentially be ugly (but not impossible to interpret), if defined in my second manner my suggestion would make the use of BYSETPOS invalid (which I am not certain it should be). Just a thought - if it was intended for use when DAYS are enumerated, why not clearly define and specify that that is the case? Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Eric Busboom Sent: Friday, May 18, 2001 12:48 PM To: Jonathan Lennox; Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org Subject: Can we fix BYSETPOS? On Thu, 17 May 2001, Jonathan Lennox wrote: > I thought I'd clarify further my current thoughts on RECUR in CPL. > > After my phone conversation with Eric Busboom, we agreed that we could do > everything CPL needed with only one change to RECUR: > > * Drop BYSETPOS. > BYSETPOS is problematic for a number of reasons, but there may be a way to fix it so that CPL can use it. The way BYSETPOS is currently specified is that it can take values from 1 to 366 and -1 to -366. Clearly is was intended to enumerate days, but there is no restriction to keep it from being used on a rule that can generate intra-day events, potentially millions of values in the occurrence set, such as by specifying every second of a year. It is silly for BYSETPOS to only let you access the first 366 and the last 366 of a set of 31 million events. There are a few possible fixes for this: (1) Let BYSETPOS take a full range of vlaues from -31 million to +31 million. (2) Declare that BYSETPOS cannot be used on a rule that gnenerates more than 366 events before BYSETPOS is applied. ( Throw an error) (3) Declare that when BYSETPOS appears, the implementation must only consider the first 366 occurrences it generates to be part of the set that BYSETPOS is applied to. (1) is the concept that makes BYSETPOS it unusuable for CPL. However, (2) and (3) imply that an implementation only has to expand 366 events -- they are restrictions that bound the execution time for BYSETPOS. So, could CPL use BYSETPOS if we instituted (2) or (3)? Bruce, would you be happy with (2) or (3)? eric. From owner-ietf-calendar@mail.imc.org Fri May 18 16:35: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 QAA15666 for ; Fri, 18 May 2001 16:35:29 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA19791 for ietf-calendar-bks; Fri, 18 May 2001 13:20:06 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19778 for ; Fri, 18 May 2001 13:19:59 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id PAA02059; Fri, 18 May 2001 15:18:49 -0500 From: "Shannon J. Clark" To: "Eric Busboom" Cc: Subject: RE: Can we fix BYSETPOS? Date: Fri, 18 May 2001 15:18:37 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric, My intention - which was unclear on rereading - was indeed to explicitly restrict BYSETPOS to Sets of events that were of the type DATEs - I think that a set of RRULES that do not imply "BYHOUR, BYMINUTE, or BYSECOND" could be that. That said, it does raise a related point - why the restriction to +/- 366 days - which implies a formal assumption that the SET of events will not stretch beyond one year from now. Or is it intended to be combined in some manner to extend past that? All in all it does seem unclearly defined and restricted in its current form. Shannon -----Original Message----- From: Eric Busboom [mailto:eric@softwarestudio.org] Sent: Friday, May 18, 2001 3:14 PM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: RE: Can we fix BYSETPOS? On Fri, 18 May 2001, Shannon J. Clark wrote: > Along a similar line, what about the following: > > Restrict BYSETPOS to events of value DATE - that is restrict it to events > enumerated by DAY? Do you mean that DTSTART has VALUE=DATE? That would mean that you could not use BYSETPOS on an event that, for instance, ran from 10:00 to 11:00 every day of the year. Probably not what you intended to exclude. Or, do you mean that BYSETPOS could not be used in an RRULE that had BYHOUR, BYMINUTE or BYSECOND? That would work, and it is much easier to check in constant time. This case might be acceptable if current implementations are only using BYSETPOS to select days. If so, I like it more than my (2) and (3), since it makes the use of BYSETPOS for dates explicit. eric. From owner-ietf-calendar@mail.imc.org Fri May 18 16:35: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 QAA15678 for ; Fri, 18 May 2001 16:35:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA19371 for ietf-calendar-bks; Fri, 18 May 2001 13:14:45 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19361 for ; Fri, 18 May 2001 13:14:39 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f4IKE7R13162; Fri, 18 May 2001 13:14:07 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Fri, 18 May 2001 13:14:07 -0700 (PDT) From: Eric Busboom X-X-Sender: To: "Shannon J. Clark" cc: Subject: RE: Can we fix BYSETPOS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 May 2001, Shannon J. Clark wrote: > Along a similar line, what about the following: > > Restrict BYSETPOS to events of value DATE - that is restrict it to events > enumerated by DAY? Do you mean that DTSTART has VALUE=DATE? That would mean that you could not use BYSETPOS on an event that, for instance, ran from 10:00 to 11:00 every day of the year. Probably not what you intended to exclude. Or, do you mean that BYSETPOS could not be used in an RRULE that had BYHOUR, BYMINUTE or BYSECOND? That would work, and it is much easier to check in constant time. This case might be acceptable if current implementations are only using BYSETPOS to select days. If so, I like it more than my (2) and (3), since it makes the use of BYSETPOS for dates explicit. eric. From owner-ietf-calendar@mail.imc.org Fri May 18 19:11:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18774 for ; Fri, 18 May 2001 19:11:54 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA00748 for ietf-calendar-bks; Fri, 18 May 2001 15:51:34 -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 PAA00726 for ; Fri, 18 May 2001 15:51:23 -0700 (PDT) From: pregen@egenconsulting.com To: Jonathan Lennox Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Clarification and current status of CPL RECUR thoughts X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 18 May 2001 18:51:00 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 05/18/2001 06:51:04 PM, Serialize complete at 05/18/2001 06:51:04 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 007D834F85256A50_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007D834F85256A50_= Content-Type: text/plain; charset="us-ascii" Jonathan, that's great that you and Eric have come up with something that appears to be nearing an agreement. We do, however, need to have our method reviewer, Bruce Kahn, review the thoughts to make sure they dont' "break" iCalendar. I know Bruce has put some thoughts on the list but have seen no replies to his comments. Does that mean that his comments are accepted as is? Want to make sure we go through the right steps. IT does sound like we might be close here. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Jonathan Lennox Sent by: owner-ietf-calendar@mail.imc.org 05/17/01 11:42 AM To: ietf-calendar@imc.org cc: Subject: Clarification and current status of CPL RECUR thoughts I thought I'd clarify further my current thoughts on RECUR in CPL. After my phone conversation with Eric Busboom, we agreed that we could do everything CPL needed with only one change to RECUR: * Drop BYSETPOS. I also suggested two clarifications/recommendations: * A server (CPL server, calendaring server, whatever) MAY reject any RECUR rule on the grounds that it's too "expensive" (complex, whatever). The definition of expense/complexity is implementation-dependent. * We ought to add text to the recur definition which says that a server SHOULD support any RECUR which meets certain constraints. This allows us to guarantee that unconditionally compliant implementations will be interoperable. (The exact nature and values of these constraints can be hashed out later.) Note that this means: * COUNT is back (but may be subject to the server's complexity rules). * Sub-day frequencies and BY* rules are back. * Durations can be any length (subject to the server's complexity rules). I have (mostly) completed an implementation -- a modification to the Java code I released late last year -- which implements this RECUR-minus- BYSETPOS. It correctly generates all the RECUR examples from 2445 except the two which use BYSETPOS. The two complexity constraints I impose in my code are that if a rule has a COUNT value, it must be fully satisifed before a caller-specified time and a caller-specified recurrence of the smallest time unit mentioned in the rule; and the duration of a recurrence must be less than a caller-specified multiple of the smallest time unit mentioned in the rule. The running time of my code is linear in the caller-specified bounds. (The COUNT bounds are linear once; the duration bound is linear every time the rule is evaluated.) In all other respects it's linear in the textual size of the rule. It's possible to determine whether a rule exceeds the bounds at the time a script is submitted to a server. In the phone conversation, Eric seemed to indicate that he thought that BYSETPOS was too complex for iCalendar as well. And of course iCalendar (2446, yes?) already has the concept of rejecting a calendering object for being too complex. What's the feeling of the working group on this proposal? -- Jonathan Lennox lennox@cs.columbia.edu --=_alternative 007D834F85256A50_= Content-Type: text/html; charset="us-ascii"
Jonathan, that's great that you and Eric have come up with something that appears to be nearing an agreement.  We do, however, need to have our method reviewer, Bruce Kahn, review the thoughts to make sure they dont' "break" iCalendar.  I know Bruce has put some thoughts on the list but have seen no replies to his comments.  Does that mean that his comments are accepted as is?  Want to make sure we go through the right steps.  IT does sound like we might be close here.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Jonathan Lennox <lennox@cs.columbia.edu>
Sent by: owner-ietf-calendar@mail.imc.org

05/17/01 11:42 AM

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Clarification and current status of CPL RECUR thoughts



I thought I'd clarify further my current thoughts on RECUR in CPL.

After my phone conversation with Eric Busboom, we agreed that we could do
everything CPL needed with only one change to RECUR:

* Drop BYSETPOS.

I also suggested two clarifications/recommendations:

* A server (CPL server, calendaring server, whatever) MAY reject any RECUR
 rule on the grounds that it's too "expensive" (complex, whatever).  The
 definition of expense/complexity is implementation-dependent.

* We ought to add text to the recur definition which says that a server
 SHOULD support any RECUR which meets certain constraints.  This allows us
 to guarantee that unconditionally compliant implementations will be
 interoperable.  (The exact nature and values of these constraints can be
 hashed out later.)

Note that this means:
* COUNT is back (but may be subject to the server's complexity rules).
* Sub-day frequencies and BY* rules are back.
* Durations can be any length (subject to the server's complexity rules).

I have (mostly) completed an implementation -- a modification to the Java
code I released late last year -- which implements this RECUR-minus-
BYSETPOS.  It correctly generates all the RECUR examples from 2445 except
the two which use BYSETPOS.

The two complexity constraints I impose in my code are that if a rule has a
COUNT value, it must be fully satisifed before a caller-specified time and a
caller-specified recurrence of the smallest time unit mentioned in the rule;
and the duration of a recurrence must be less than a caller-specified
multiple of the smallest time unit mentioned in the rule.

The running time of my code is linear in the caller-specified bounds.  (The
COUNT bounds are linear once; the duration bound is linear every time the
rule is evaluated.)  In all other respects it's linear in the textual size
of the rule.  It's possible to determine whether a rule exceeds the bounds
at the time a script is submitted to a server.


In the phone conversation, Eric seemed to indicate that he thought that
BYSETPOS was too complex for iCalendar as well.  And of course iCalendar
(2446, yes?) already has the concept of rejecting a calendering object for
being too complex.


What's the feeling of the working group on this proposal?

--
Jonathan Lennox
lennox@cs.columbia.edu

--=_alternative 007D834F85256A50_=-- From owner-ietf-calendar@mail.imc.org Fri May 18 19:38: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 TAA19364 for ; Fri, 18 May 2001 19:38:05 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA02966 for ietf-calendar-bks; Fri, 18 May 2001 16:21:47 -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 QAA02958 for ; Fri, 18 May 2001 16:21:41 -0700 (PDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA11509; Fri, 18 May 2001 19:21:43 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3+Sun/8.9.3) id TAA22986; Fri, 18 May 2001 19:21:42 -0400 (EDT) X-Authentication-Warning: ind.cs.columbia.edu: lennox set sender to lennox@ind.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: <15109.44677.303897.569435@ind.cs.columbia.edu> Date: Fri, 18 May 2001 19:21:41 -0400 (EDT) To: Eric Busboom Cc: , Subject: Re: Can we fix BYSETPOS? In-Reply-To: References: <15107.61820.912612.674288@conrail.cs.columbia.edu> 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 One further comment on why BYSETPOS is horribly broken. RECUR:FREQ=YEARLY;INTERVAL=100000000;BYSECOND=0,1,2,3,4,5,6,7,8,9,10,11,12,13, 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36, 37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59; BYSETPOS=-1 is a legal RFC 2445 recurrence. It expands to approximately three quadrillion events before BYSETPOS is applied. Good luck... Yes, this is clearly pathological. But how well can it be prevented? And what should a calendaring program do upon receiving it? (This is also an example of where the "expand the set to resolve it" strategy falls over. The above rule without BYSETPOS needs to be expanded to three quadrillion events. The point-evaluation method, by contrast, handles it in O(duration) time just like anything else...) -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Fri May 18 20:05:00 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 UAA19974 for ; Fri, 18 May 2001 20:04:59 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA01918 for ietf-calendar-bks; Fri, 18 May 2001 16:09:45 -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 QAA01902 for ; Fri, 18 May 2001 16:09:38 -0700 (PDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA10885; Fri, 18 May 2001 19:09:40 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3+Sun/8.9.3) id TAA22920; Fri, 18 May 2001 19:09:39 -0400 (EDT) X-Authentication-Warning: ind.cs.columbia.edu: lennox set sender to lennox@ind.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: <15109.43954.115639.697465@ind.cs.columbia.edu> Date: Fri, 18 May 2001 19:09:38 -0400 (EDT) To: Eric Busboom Cc: , Subject: Re: Can we fix BYSETPOS? In-Reply-To: References: <15107.61820.912612.674288@conrail.cs.columbia.edu> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, May 18 2001, "Eric Busboom" wrote to "Jonathan Lennox, , " saying: > BYSETPOS is problematic for a number of reasons, but there may be a way to > fix it so that CPL can use it. I appreciate trying to fix BYSETPOS. In doing so, I think the first thing to do is to actually *understand* BYSETPOS. I think it's terribly confusing as it is. RFC 2445 says about BYSETPOS only: The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal 44) separated list of values which corresponds to the nth occurrence within the set of events specified by the rule. However, the concept "set of events specified by the rule" is terribly vague. At least one person on this list thought that this meant that you expand the recurrence rule completely, and then if you have, say, BYSETPOS=3 you take only the third event from the list, once. But from the examples that's clearly not what's intended. So we have to have some understanding of what the "set repitition interval" is. Let's take some examples.... RRULE:FREQ=DAILY;BYMONTH=8;BYSETPOS=6 (Contracting rules with BYSETPOS) RRULE:FREQ=YEARLY;INTERVAL=10;BYDAY=TH;BYSETPOS=25 (Interaction of BYSETPOS and INTERVAL. Also note that the "least common multiple" of YEARLY and BYDAY is 28 years, even disregarding the Gregorian adjustment. Does this make this a 280-year set?) RRULE:FREQ=WEEKLY;INTERVAL=4;BYMONTH=8;BYSETPOS=2 ("Semi-expanding" rules. I seem to recall something that said these were forbidden, but now I can't find it.) RRULE:FREQ=YEARLY;INTERVAL=10000;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 (Sets can be arbitrarily large.) Is there a good algorithm for "given a time, give me the beginning of the set enclosing this time"? I don't necessarily mind having to roll through 366 instances to evaluate a rule (though I'm not thrilled about it), but I *must not* be forced to fully evaluate a rule starting at DTSTART. Or was the intention that BYSETPOS only makes sense with expanding rules, and the set interval is always FREQ? This is a lot more tractable, but definitely not what the spec currently says. I think that once we agree on what BYSETPOS means, we can agree on what should be done with it. (I'm still in favor of throwing it out. It's too confusing.) -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon May 21 01:16:28 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19057 for ; Mon, 21 May 2001 01:16:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id VAA07863 for ietf-calendar-bks; Sun, 20 May 2001 21:57:41 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA07859 for ; Sun, 20 May 2001 21:57:33 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f4L4uqE23133; Sun, 20 May 2001 21:56:52 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Sun, 20 May 2001 21:56:52 -0700 (PDT) From: Eric Busboom X-X-Sender: To: Jonathan Lennox cc: , Subject: Re: Can we fix BYSETPOS? In-Reply-To: <15109.43954.115639.697465@ind.cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 May 2001, Jonathan Lennox wrote: > On Friday, May 18 2001, "Eric Busboom" wrote to "Jonathan Lennox, , " saying: > > > BYSETPOS is problematic for a number of reasons, but there may be a way to > > fix it so that CPL can use it. > > However, the concept "set of events specified by the rule" is terribly > vague. Right. How about this as proposed text, as an addition to 4.3.10, Recurrence Rule: --------------------------------------------------------------------------- BYSETPOS operates on a set of events in one interval of the recurrence rule. For a WEEKLY RULE, the interval is one week, for a MONTHLY rule, one month, and for a YEARLY rule, one year. After the recurrence rule is expanded for one week, month or year, occurrences are selected from this set according to the positions in the set specified by the elements of BYSETPOS. BYSETPOS is applied to each successive week, month or yearly interval of the rule to generate the final occurrence set. BYSETPOS MUST NOT be used with SECONDLY, MINUTELY, HOURLY or DAILY rules. If any of BYSECOND, BYMINUTE or BYHOUR rule parts appear in a rule, BYSETPOS MUST NOT appear. --------------------------------------------------------------------------- The first paragraph clarifies how to use BYSETPOS, and the second limits it's use to rules that generate no more than one occurrence per day, so an implementation will never have to expand more than 366 occurrences per interval. Jonathan, will this work for CPL? Bruce, is this acceptable for iCalendar? eric. From owner-ietf-calendar@mail.imc.org Mon May 21 11:28:10 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11186 for ; Mon, 21 May 2001 11:28:09 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA05030 for ietf-calendar-bks; Mon, 21 May 2001 08:12:09 -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 IAA05021 for ; Mon, 21 May 2001 08:11:57 -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 LAA22146; Mon, 21 May 2001 11:11:52 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id LAA76676; Mon, 21 May 2001 11:11:51 -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: <15113.12343.26051.619788@conrail.cs.columbia.edu> Date: Mon, 21 May 2001 11:11:51 -0400 (EDT) To: Eric Busboom Cc: , Subject: Re: Can we fix BYSETPOS? In-Reply-To: References: <15109.43954.115639.697465@ind.cs.columbia.edu> 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 Sunday, May 20 2001, "Eric Busboom" wrote to "Jonathan Lennox, , " saying: > Right. How about this as proposed text, as an addition to 4.3.10, > Recurrence Rule: > > --------------------------------------------------------------------------- > > BYSETPOS operates on a set of events in one interval of the recurrence > rule. For a WEEKLY RULE, the interval is one week, for a MONTHLY rule, > one month, and for a YEARLY rule, one year. After the recurrence rule is > expanded for one week, month or year, occurrences are selected from this > set according to the positions in the set specified by the elements of > BYSETPOS. BYSETPOS is applied to each successive week, month or yearly > interval of the rule to generate the final occurrence set. > > BYSETPOS MUST NOT be used with SECONDLY, MINUTELY, HOURLY or DAILY > rules. If any of BYSECOND, BYMINUTE or BYHOUR rule parts appear in a > rule, BYSETPOS MUST NOT appear. > > --------------------------------------------------------------------------- > > The first paragraph clarifies how to use BYSETPOS, and the second limits > it's use to rules that generate no more than one occurrence per day, so an > implementation will never have to expand more than 366 occurrences per > interval. > > Jonathan, will this work for CPL? Bruce, is this acceptable for iCalendar? Hmm. From a specification point of view, there's one thing I'd add: the current text that BYSETPOS "MUST only be used in conjunction with another BYxxx rule part" should be clarified that it MUST only be used in conjunction with an *expanding* rule part. Using contracting rules in conjunction with BYSETPOS, given the above definition, is nonsensical: RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1 since a RECUR with only contracting rules will always have only single-element sets. From a CPL point of view, this is inherently bounded in time, so I think it's okay. I'm a little nervous about the fact that we're adding more and more things that push the bound upward, but it's probably okay. Other than that, I like this re-definition. I think it clears up all the pathological BYSETPOS cases. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon May 21 11:42:55 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11468 for ; Mon, 21 May 2001 11:42:54 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA05686 for ietf-calendar-bks; Mon, 21 May 2001 08:27:58 -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 IAA05678 for ; Mon, 21 May 2001 08:27: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 LAA23373 for ; Mon, 21 May 2001 11:27:53 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id LAA76688; Mon, 21 May 2001 11:27:53 -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: <15113.13305.264462.70095@conrail.cs.columbia.edu> Date: Mon, 21 May 2001 11:27:53 -0400 (EDT) To: ietf-calendar@imc.org Subject: Corner cases of DTEND semantics with RECUR 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 I have a question about the semantics of DTEND with RECUR: Any duration associated with the iCalendar object applies to all members of the generated recurrence set. Can I interpret this to mean that, if a recurring VEVENT has its end specified with DTEND, I'm always safe to consider its duration to be the number of seconds between the given DTSTART and DTEND? Thus, for instance: DTSTART;TZID=America/New_York:19970902T003000 DTEND;TZID=America/New_York:19970902T023000 RRULE:FREQ=DAILY is a two-hour (7200 second) daily event. It normally ends at 2:30 AM, but on October 26, 1997, it ends at 1:30 AM EST (the second occurence of 1:30), and on April 5, 1998, it ends at 3:30 AM EDT. The obvious alternative would be to say that DTEND rules always carry over their actual time-of-day. However, this breaks down once you have sub-day BYxxx rules: DTSTART;TZID=America/New_York:19970902T083000 DTEND;TZID=America/New_York:19970902T103000 RRULE:FREQ=DAILY;BYHOUR=0,8,16 This rule also generates an event which starts at 1997-10-26 00:30:00, just like the previous one. When would it end? How would you calculate it? I'd consider this to be a difference between DTEND and DURATION. If you say "DURATION:PT2H", it always means "add 2 to the hour field of the calendar". (Though this is probably also controversial...) Agreement/disagreement? Should new wording be added to 2445bis to clarify this? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon May 21 12:58:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13479 for ; Mon, 21 May 2001 12:58:18 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA10117 for ietf-calendar-bks; Mon, 21 May 2001 09:41:23 -0700 (PDT) Received: from ae.poss.com (adam-m.poss.com [198.70.184.161]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10101 for ; Mon, 21 May 2001 09:41:16 -0700 (PDT) Received: from homer ([198.70.184.210]) by ae.poss.com (Netscape Messaging Server 4.1) with ESMTP id GDP2CG00.CJO for ; Mon, 21 May 2001 12:41:05 -0400 From: "David King" To: Subject: iCalendar and XML Date: Mon, 21 May 2001 12:43:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit What are the group's thoughts on the DTD[1] and XML[2] drafts created for iCalendar? Good/bad? Has any body used them to implement an application? I've been tasked with implementing a calendar app in one of my company's products and am finding it to be a daunting experience. After looking at iCal for the first time, I was immediately confused on why this hasn't moved over to be an XML based format. Thanks, David King [1] http://www.watersprings.org/pub/id/draft-dawson-ical-xml-dtd-01.txt [2] http://www.watersprings.org/pub/id/draft-reddy-xml-ical-00.txt From owner-ietf-calendar@mail.imc.org Mon May 21 14:18:30 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15638 for ; Mon, 21 May 2001 14:18:29 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA14669 for ietf-calendar-bks; Mon, 21 May 2001 11:06:36 -0700 (PDT) Received: from ae.poss.com (adam-m.poss.com [198.70.184.161]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA14665 for ; Mon, 21 May 2001 11:06:30 -0700 (PDT) Received: from homer ([198.70.184.210]) by ae.poss.com (Netscape Messaging Server 4.1) with ESMTP id GDP6AJ00.VJL for ; Mon, 21 May 2001 14:06:19 -0400 From: "David King" To: Subject: Syndicated events Date: Mon, 21 May 2001 14:08:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm currently looking into having syndicated events. Very similar to what RSS[1] does with news feeds. ex 1) Red Hat has a list of training events. ex 2) A list of holidays. (federal, religious, etc.) Is it a good idea to use iCalendar for this? The only reference I could find to syndicated events on the list is this thread[2]. However, it appears that it would be a bad idea to use iCalendar because of all its extraneous information. What are your thoughts on syndicated events? Have people seen this implemented somewhere? Is there a format that already handles this? Are there any examples of syndicated event feeds? Maybe this is a job for an RSS 1.0 module? -David [1] http://blogspace.com/rss/ [2] http://www.imc.org/ietf-calendar/mail-archive/msg07385.html From owner-ietf-calendar@mail.imc.org Mon May 21 14:35:29 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15901 for ; Mon, 21 May 2001 14:35:28 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA15106 for ietf-calendar-bks; Mon, 21 May 2001 11:25:34 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15102 for ; Mon, 21 May 2001 11:25:28 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f4LIQJq20913 for ; Mon, 21 May 2001 14:26:19 -0400 Message-ID: <3B095DCB.F097E7BE@ecal.com> Date: Mon, 21 May 2001 14:26: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: iCalendar and XML 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 David King wrote: > I've been tasked with implementing a calendar app in one of my company's > products and am finding it to be a daunting experience. After looking at > iCal for the first time, I was immediately confused on why this hasn't moved > over to be an XML based format. (a) Because it doesn't need to be. It might be nice, but it wouldn't really buy us any new expressiveness. Syntax is easy; the hard part is the schema. (b) Because the early proponents of expressing iCalendar in XML disagreed on whether it should permit free-form extensions, and the working group moved on to more useful topics. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Stupid, adj.: Losing $25 on the game and $50 on| |francis@ecal.com|the instant replay. | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon May 21 16:21:14 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17664 for ; Mon, 21 May 2001 16:21:13 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA19077 for ietf-calendar-bks; Mon, 21 May 2001 13:08: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 NAA19069 for ; Mon, 21 May 2001 13:08:11 -0700 (PDT) From: Bruce_Kahn@iris.com To: "David King" Cc: ietf-calendar@imc.org Subject: Re: Syndicated events MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05172001 May 17, 2001 Message-ID: Date: Mon, 21 May 2001 16:13:26 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/21/2001 04:17:42 PM, Serialize complete at 05/21/2001 04:17:42 PM Content-Type: multipart/alternative; boundary="=_alternative 006E603E85256A53_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E603E85256A53_= Content-Type: text/plain; charset="us-ascii" David wrote on 05/21/2001 02:08:52 PM: > I'm currently looking into having syndicated events. Very similar to what > RSS[1] does with news feeds. > > ex 1) Red Hat has a list of training events. > ex 2) A list of holidays. (federal, religious, etc.) > > Is it a good idea to use iCalendar for this? This is quite easily done in iCalendar. Check out many of the examples under Section 4.8.5.4 Recurrence Rule of the spec (starting on p 118). You can also check out Section 4.1.5 Anniversaries or Events attached to entire days in RFC 2446 (iTIP) for one of the editors favorite examples, Bastille Day. Also in RFC 2446, Section 4.1 Published Event Examples covers some examples of publishing something like your 1st example. > The only reference I could > find to syndicated events on the list is this thread[2]. However, it > appears that it would be a bad idea to use iCalendar because of all its > extraneous information. If you were doing 'workflow' then there is much more overhead then in a simple PUBLISH. Again, check out the cited examples/sections from above. > What are your thoughts on syndicated events? Have people seen this > implemented somewhere? Is there a format that already handles this? Are > there any examples of syndicated event feeds? In order: iCalendar fits your needs; not as you have described (Ive seen it in some web calendars for 'personal' stuff); vCalendar (the precursor to iCalendar) can do it but the recurrence grammar for vCalendar is different and not compatable so Id recommend using iCalendar; not that I know of. > Maybe this is a job for an RSS 1.0 module? Dont know RSS so I can't answer this... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... > > [1] http://blogspace.com/rss/ > [2] http://www.imc.org/ietf-calendar/mail-archive/msg07385.html > --=_alternative 006E603E85256A53_= Content-Type: text/html; charset="us-ascii"
David wrote on 05/21/2001 02:08:52 PM:
> I'm currently looking into having syndicated events.  Very similar to what
> RSS[1] does with news feeds.
>
> ex 1) Red Hat has a list of training events.
> ex 2) A list of holidays. (federal, religious, etc.)
>
> Is it a good idea to use iCalendar for this?  

This is quite easily done in iCalendar.  Check out many of the examples under Section 4.8.5.4 Recurrence Rule of the spec (starting on p 118).  You can also check out Section 4.1.5 Anniversaries or Events attached to entire days in RFC 2446 (iTIP) for one of the editors favorite examples, Bastille Day.  Also in RFC 2446, Section 4.1 Published Event Examples covers some examples of publishing something like your 1st example.

>                                         The only reference I could
> find to syndicated events on the list is this thread[2].  However, it
> appears that it would be a bad idea to use iCalendar because of all its
> extraneous information.
If you were doing 'workflow' then there is much more overhead then in a simple PUBLISH.  Again, check out the cited examples/sections from above.

> What are your thoughts on syndicated events?  Have people seen this
> implemented somewhere?  Is there a format that already handles this?  Are
> there any examples of syndicated event feeds?
In order:  
iCalendar fits your needs;
not as you have described (Ive seen it in some web calendars for 'personal' stuff);
vCalendar (the precursor to iCalendar) can do it but the recurrence grammar for vCalendar is different and not compatable so Id recommend using iCalendar;
not that I know of.

> Maybe this is a job for an RSS 1.0 module?
Dont know RSS so I can't answer this...

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


>
> [1] http://blogspace.com/rss/
> [2] http://www.imc.org/ietf-calendar/mail-archive/msg07385.html
>
--=_alternative 006E603E85256A53_=-- From owner-ietf-calendar@mail.imc.org Tue May 22 10:45:46 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20726 for ; Tue, 22 May 2001 10:45:45 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA10608 for ietf-calendar-bks; Tue, 22 May 2001 07:32:02 -0700 (PDT) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA10561 for ; Tue, 22 May 2001 07:31:52 -0700 (PDT) Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.136.193.32]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 30ED71CF for ; Tue, 22 May 2001 16:31:31 +0200 (METDST) Received: from eiach.bbn.hp.com (eiach.bbn.hp.com [15.140.168.10]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id QAA07156 for ; Tue, 22 May 2001 16:31:45 +0200 (METDST) Received: from 15.140.168.10 by eiach.bbn.hp.com (InterScan E-Mail VirusWall NT); Tue, 22 May 2001 16:31:44 +0200 (W. Europe Daylight Time) Received: by eiach.bbn.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 May 2001 16:31:44 +0200 Message-ID: From: "NITSCH,FRANK (HP-Germany,ex1)" To: ietf-calendar@imc.org Subject: RE: iCalendar and XML Date: Tue, 22 May 2001 16:31:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi David, yes, it seems to be much work to implement a calendar server... ;-) I'm also gathering information about calendaring and scheduling since weeks. I guess it's hard work for one employee to implement a calendar store. If you ever programmed a simple component that's able to distinguish weekdays vs. weekend days, working time, etc. you might have an idea about the complexity of all this. Implementing the recurrence rules is something very special I think. That's the reason why I'm looking for a solution that I can plug into my application and just use it. Have you heard of the libical project? You can find the web page and the code at http://www.softwarestudio.org/libical/. They also maintain a mailing list btw. Well, XML is something I had wished to find as well. I understand the reasons why iCal RFCs aren't using XML (existing products already using the "normal" format, historical reasons, vCalendar legacy,...). Indeed the standard doesn't require XML. In my opinion it's more or less independent from any representation. I'd say that the structure of today's iCal data can be mapped very nicely into XML (attributes and tags). I would appreciate if there was a XML DTD available and maintained. XML gives developers so many good parsers and tools. It would definitely help. I haven't looked yet at the DTD links you provided but I will. I know that there've been some discussions about iCal and XML in the past and unfortunately none of these resulted in anything really helpful. I would be interested whether there are some other people around who are interested in an XML DTD. If so why don't we just discuss how to get this from the RFC? Maybe creating a tool that reads the RFC and generates a DTD of it? I know that this might not be trivial but if there're enough interested people I might be worth doing it. I believe most people are more interested in having a DTD of iCal than to change the RFC's format into XML. As I said the standard itself is more or less independent. Why don't we just try to satisfy both sides? What do you think? Best Regards Frank -- ==================================================================== Frank Nitsch mailto:frank_nitsch@hp.com -------------------------------------------------------------------- Hewlett-Packard GmbH | http://www.hewlett-packard.de Mailstop ASM-NGP, Building B32/3M17 | HP-Telnet 777-2135 Herrenberger Strasse 110-140 | Phone (+49) 07031/14-2135 D-71034 Boeblingen | Fax (+49) 07031/14-8253 ==================================================================== Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus, Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081 ==================================================================== > -----Original Message----- > From: John Stracke [mailto:francis@ecal.com] > Sent: Monday, 21 May, 2001 20:26 > To: ietf-calendar@imc.org > Subject: Re: iCalendar and XML > > > David King wrote: > > > I've been tasked with implementing a calendar app in one of > my company's > > products and am finding it to be a daunting experience. > After looking at > > iCal for the first time, I was immediately confused on why > this hasn't moved > > over to be an XML based format. > > (a) Because it doesn't need to be. It might be nice, but it > wouldn't really > buy us any new expressiveness. Syntax is easy; the hard part > is the schema. > > (b) Because the early proponents of expressing iCalendar in > XML disagreed on > whether it should permit free-form extensions, and the > working group moved on > to more useful topics. > > -- > /================================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own. | > |Chief Scientist |===============================================| > |eCal Corp. |Stupid, adj.: Losing $25 on the game and $50 on| > |francis@ecal.com|the instant replay. | > \================================================================/ > > > From owner-ietf-calendar@mail.imc.org Fri May 25 15:33:04 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23865 for ; Fri, 25 May 2001 15:33:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA22679 for ietf-calendar-bks; Fri, 25 May 2001 11:55:24 -0700 (PDT) Received: from ae.poss.com (adam-m.poss.com [198.70.184.161]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA22674 for ; Fri, 25 May 2001 11:55:18 -0700 (PDT) Received: from homer ([198.70.184.210]) by ae.poss.com (Netscape Messaging Server 4.1) with ESMTP id GDWN7R00.FT8 for ; Fri, 25 May 2001 14:55:03 -0400 From: "David King" To: Subject: Recurrence implementation question Date: Fri, 25 May 2001 14:57:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm trying to think through an implementation of recurrence so I'm discussing this at a high level rather than actual code. Repeating events are my only concern right now and the datasource doesn't matter. Viewing the month of May for a single user of a calendar app. I need to know what events occur during May for this user. I grab all the user's repeating events from the past and the month of May. For each event, generate a recurrence set that includes all the recurrence dates of the event from the event's start date to the end of May using the recurrence rules. Return the dates that occur during May from the recurrence set. Issue 1: After using the calendar for a while, a user might have a large number of recurring events in the system. As a result, it will take longer and longer to figure out if a recurring event occurs within a specified time frame. Issue 2: It's necessary to calculate all the recurrence dates that occur between the event's start date and the specified time frame's start date even though they are not needed. Am I moving in the right direction? Are the issues I've brought up unavoidable when calculating recurrence? It appears that a beefy machine would be needed to run any calendaring app that gets heavily used. Any tips from others on the subject? Thanks for _any_ insights you can provide, -David King From owner-ietf-calendar@mail.imc.org Mon May 28 08:50:20 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04248 for ; Mon, 28 May 2001 08:50:19 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA15265 for ietf-calendar-bks; Mon, 28 May 2001 05:33:40 -0700 (PDT) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA15226 for ; Mon, 28 May 2001 05:33:29 -0700 (PDT) Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.136.193.32]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 0F57D57E; Mon, 28 May 2001 14:33:07 +0200 (METDST) Received: from isar.bbn.hp.com (isar.bbn.hp.com [15.140.168.13]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id OAA14376; Mon, 28 May 2001 14:33:06 +0200 (METDST) Received: from 15.140.168.13 by isar.bbn.hp.com (InterScan E-Mail VirusWall NT); Mon, 28 May 2001 14:33:05 +0200 (W. Europe Daylight Time) Received: by isar.bbn.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 May 2001 14:33:05 +0200 Message-ID: From: "NITSCH,FRANK (HP-Germany,ex1)" To: "'David King'" , "IETF-Calendar Mailing List (E-mail)" Subject: RE: Recurrence implementation question Date: Mon, 28 May 2001 14:33:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi David, don't ask me where I got this from. Maybe from this mailing list or it's archive or whereever... ;-) I read - and it makes sense - that expanding recurrence roules should take place as soon as a new schedule entry is being made. I.e. a calendar server would expand recurring events when a user stores the event. There's an issue to distinguish expanded and not expanded events now... Could we use a boolean attribute named EXPAND for this? It exists for the query language and could be useful on the server side, too. Pre-expanded recurring events could set this attribute to TRUE while the originally entered events with the recurrence rule would have this attribute set to FALSE. Of course it doesn't make much sense to expand it to infinity... ;-) I would propose the timeframe to be used for "pre-expansion" to be a configuration item of the serverapplication/component. This way the calendar administrator would be able to adjust this time frame to the needs of the actual client applications. If the server received a request outside of this pre-calculated area it would need to compute it. This still could take a while if one had hundreds or thousands of recurring events in the Calendar Store... Therefore an additional proposal: for each recurring event that is valid (i.e. the end date of the recurring event is later than the start date of the requested time frame) create a "helper" event that starts at the end of the pre-calculated time frame. When the server would need to calculate expanded events it could safely ignore all events in the past. It would just take all pre-expanded events and take care of standard and "helper" recurrence events after the pre-calculated time frame. I don't get your 2nd issue. Why wouldn't they be needed? Just my 2 cent... ;-) Any feedback? Best Regards Frank -- ==================================================================== Frank Nitsch mailto:frank_nitsch@hp.com -------------------------------------------------------------------- Hewlett-Packard GmbH | http://www.hewlett-packard.de Mailstop ASM-NGP, Building B32/3M17 | HP-Telnet 777-2135 Herrenberger Strasse 110-140 | Phone (+49) 07031/14-2135 D-71034 Boeblingen | Fax (+49) 07031/14-8253 ==================================================================== Geschaeftsfuehrer: Heribert Schmitz (Vorsitzender), Hans-Jochen Lueckefett, Heiko Meyer, Fritz Schuller, Regine Stachelhaus, Juergen Banhardt, Vorsitzender des Aufsichtsrates: Joerg Menno Harms Sitz der Gesellschaft: Boeblingen, Amtsgericht Boeblingen HRB 4081 ==================================================================== > -----Original Message----- > From: David King [mailto:david.king@commnav.com] > Sent: Friday, 25 May, 2001 20:58 > To: ietf-calendar@imc.org > Subject: Recurrence implementation question > > > I'm trying to think through an implementation of recurrence so I'm > discussing this at a high level rather than actual code. > Repeating events > are my only concern right now and the datasource doesn't matter. > > Viewing the month of May for a single user of a calendar app. > I need to > know what events occur during May for this user. I grab all > the user's > repeating events from the past and the month of May. For each event, > generate a recurrence set that includes all the recurrence > dates of the > event from the event's start date to the end of May using the > recurrence > rules. Return the dates that occur during May from the > recurrence set. > > Issue 1: > After using the calendar for a while, a user might have a > large number of > recurring events in the system. As a result, it will take > longer and longer > to figure out if a recurring event occurs within a specified > time frame. > > Issue 2: > It's necessary to calculate all the recurrence dates that > occur between the > event's start date and the specified time frame's start date > even though > they are not needed. > > Am I moving in the right direction? Are the issues I've brought up > unavoidable when calculating recurrence? It appears that a > beefy machine > would be needed to run any calendaring app that gets heavily > used. Any tips > from others on the subject? > > Thanks for _any_ insights you can provide, > -David King > From owner-ietf-calendar@mail.imc.org Mon May 28 10:31:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04987 for ; Mon, 28 May 2001 10:31:35 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA20480 for ietf-calendar-bks; Mon, 28 May 2001 07:16:16 -0700 (PDT) Received: from ae.poss.com (adam-m.poss.com [198.70.184.161]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA20473 for ; Mon, 28 May 2001 07:16:10 -0700 (PDT) Received: from homer ([151.205.192.74]) by ae.poss.com (Netscape Messaging Server 4.1) with ESMTP id GE1UA800.1UN; Mon, 28 May 2001 10:15:44 -0400 Message-ID: <000e01c0e780$92bddb40$6401a8c0@homer> From: "David King" To: "NITSCHFRANK \(HP-Germanyex1\)" , "IETF-Calendar Mailing List \(E-mail\)" References: Subject: Re: Recurrence implementation question Date: Mon, 28 May 2001 10:14: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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Issue 2: > > It's necessary to calculate all the recurrence dates that > > occur between the > > event's start date and the specified time frame's start date > > even though > > they are not needed. > I don't get your 2nd issue. Why wouldn't they be needed? An event's first recurrence date happens in January. I am only viewing May. Since I won't see the event's recurrence dates that happened in Jan, Feb, Mar, and Apr, I don't really want to have to calculate them. However, I _have_ to calculate them since the only date I have is back in January. -David From owner-ietf-calendar@mail.imc.org Mon May 28 10:51:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05116 for ; Mon, 28 May 2001 10:51:43 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA23653 for ietf-calendar-bks; Mon, 28 May 2001 07:39:49 -0700 (PDT) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA23647 for ; Mon, 28 May 2001 07:39:43 -0700 (PDT) Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.136.193.32]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id D9AD916D; Mon, 28 May 2001 16:39:43 +0200 (METDST) Received: from isar.bbn.hp.com (isar.bbn.hp.com [15.140.168.13]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id QAA11864; Mon, 28 May 2001 16:39:42 +0200 (METDST) Received: from 15.140.168.13 by isar.bbn.hp.com (InterScan E-Mail VirusWall NT); Mon, 28 May 2001 16:39:41 +0200 (W. Europe Daylight Time) Received: by isar.bbn.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 May 2001 16:29:41 +0200 Message-ID: From: "NITSCH,FRANK (HP-Germany,ex1)" To: "'David King'" , "IETF-Calendar Mailing List (E-mail)" Subject: RE: Recurrence implementation question Date: Mon, 28 May 2001 16:29:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > Issue 2: > > > It's necessary to calculate all the recurrence dates that > > > occur between the > > > event's start date and the specified time frame's start date > > > even though > > > they are not needed. > > > I don't get your 2nd issue. Why wouldn't they be needed? > > An event's first recurrence date happens in January. I am > only viewing May. > Since I won't see the event's recurrence dates that happened > in Jan, Feb, > Mar, and Apr, I don't really want to have to calculate them. > However, I > _have_ to calculate them since the only date I have is back > in January. Ok, clear now! ;-) But don't you think my idea would solve this problem? BR Frank From owner-ietf-calendar@mail.imc.org Mon May 28 16:10:04 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06787 for ; Mon, 28 May 2001 16:10:03 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA17129 for ietf-calendar-bks; Mon, 28 May 2001 12:57:21 -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 MAA17120 for ; Mon, 28 May 2001 12:57:14 -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 PAA30048; Mon, 28 May 2001 15:57:02 -0400 Message-ID: <3B12AD31.92904C4D@ximian.com> Date: Mon, 28 May 2001 15:55:29 -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: David King CC: ietf-calendar@imc.org Subject: Re: Recurrence implementation question 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 David King wrote: > > I'm trying to think through an implementation of recurrence so I'm > discussing this at a high level rather than actual code. Repeating events > are my only concern right now and the datasource doesn't matter. > > Viewing the month of May for a single user of a calendar app. I need to > know what events occur during May for this user. I grab all the user's > repeating events from the past and the month of May. For each event, > generate a recurrence set that includes all the recurrence dates of the > event from the event's start date to the end of May using the recurrence > rules. Return the dates that occur during May from the recurrence set. > > Issue 1: > After using the calendar for a while, a user might have a large number of > recurring events in the system. As a result, it will take longer and longer > to figure out if a recurring event occurs within a specified time frame. > > Issue 2: > It's necessary to calculate all the recurrence dates that occur between the > event's start date and the specified time frame's start date even though > they are not needed. > > Am I moving in the right direction? Are the issues I've brought up > unavoidable when calculating recurrence? It appears that a beefy machine > would be needed to run any calendaring app that gets heavily used. Any tips > from others on the subject? You can avoid calculating all the recurrence dates. You can use the recurrence interval (YEARLY/MONTHLY etc.) and the frequency to skip events before the period you are interested in. As an aside, writing the recurrence expansion code is extremely difficult. I made several errors when implementing it, and I recently realized that my code doesn't handle timezone changes (e.g. switching to daylight saving time.) I think iCalendar really needs to include an algorithm for expanding recurrences, or we'll all be making the same mistakes. Damon From owner-ietf-calendar@mail.imc.org Tue May 29 13:48:17 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07862 for ; Tue, 29 May 2001 13:48:16 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA02158 for ietf-calendar-bks; Tue, 29 May 2001 10:31:31 -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 KAA02145 for ; Tue, 29 May 2001 10:31:24 -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 NAA19463; Tue, 29 May 2001 13:31:22 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id NAA89642; Tue, 29 May 2001 13:31:21 -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: <15123.56553.149558.514814@conrail.cs.columbia.edu> Date: Tue, 29 May 2001 13:31:21 -0400 (EDT) To: "David King" Cc: Subject: Re: Recurrence implementation question 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 Friday, May 25 2001, "David King" wrote to "" saying: > Issue 2: > It's necessary to calculate all the recurrence dates that occur between the > event's start date and the specified time frame's start date even though > they are not needed. This is only true if a recurrence has a COUNT parameter, and it's easy enough to do a one-time translation of COUNT into a "virtual" UNTIL. BYSETPOS needs to calculate all the dates from the beginning of the set (enclosing FREQ unit) until the specified range. Everything else can be computed using my "candidate start time" algorithm, which should be pretty efficient for non-pathological recurrences. See earlier mail I've sent to this list. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed May 30 04:46:47 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03729 for ; Wed, 30 May 2001 04:46:46 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id BAA08228 for ietf-calendar-bks; Wed, 30 May 2001 01:33:43 -0700 (PDT) Received: from bbnmg1.net.external.hp.com (bbnmg1.net.external.hp.com [192.6.76.73]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA08212 for ; Wed, 30 May 2001 01:33:36 -0700 (PDT) Received: from isoit213.bbn.hp.com (isoit213.bbn.hp.com [15.136.193.32]) by bbnmg1.net.external.hp.com (Postfix) with ESMTP id 62E3E497; Wed, 30 May 2001 10:33:30 +0200 (METDST) Received: from isar.bbn.hp.com (isar.bbn.hp.com [15.140.168.13]) by isoit213.bbn.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id KAA13233; Wed, 30 May 2001 10:33:28 +0200 (METDST) Received: from 15.140.168.13 by isar.bbn.hp.com (InterScan E-Mail VirusWall NT); Wed, 30 May 2001 10:33:27 +0200 (W. Europe Daylight Time) Received: by isar.bbn.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 10:33:27 +0200 Message-ID: From: "NITSCH,FRANK (HP-Germany,ex1)" To: "'Jonathan Lennox'" , "IETF-Calendar Mailing List (E-mail)" Subject: RE: Recurrence implementation question Date: Wed, 30 May 2001 10:33:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Issue 2: > > It's necessary to calculate all the recurrence dates that > occur between the > > event's start date and the specified time frame's start > date even though > > they are not needed. > > This is only true if a recurrence has a COUNT parameter, and it's easy > enough to do a one-time translation of COUNT into a "virtual" UNTIL. But this would change the definition as set by the user. Imagine you - as a user - enter a recurring schedule using the COUNT parameter. The CS would "translate" it into a UNTIL statement. Someday wou want to edit the schedule and it follows a different rule! Let's say you have the following rule from the RFC2445 (end of chapter 4.3.10) FREQ=DAILY;COUNT=10;INTERVAL=2 If you'd convert the COUNT parameter to UNTIL and then the user changes the INTERVAL from 2 to 3 then he won't get 10 occurrences as specified initially! Always keep in mind that "helper techniques" within a CS implementation must be transparent to the user. What I could think of is to have translated recurrence rules within the CS. As soon as a user modifies a schedule the CS would need to updated the translated helper schedules. This is pretty much the same concept that I proposed. At least what "pre-calculation" concerns. But this way one could save lots of database entries and smartly skip recurrence rules that don't affect the timeframe a user is requesting. ;-) So what about pre-translating CS internal schedule objects which need to be maintained by the CS? -- Frank Nitsch mailto:frank_nitsch@hp.com From owner-ietf-calendar@mail.imc.org Wed May 30 13:02:32 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17992 for ; Wed, 30 May 2001 13:02:31 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA21382 for ietf-calendar-bks; Wed, 30 May 2001 09:46:09 -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 JAA21374 for ; Wed, 30 May 2001 09:46:02 -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 MAA02295; Wed, 30 May 2001 12:46:03 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.11.3/8.11.3) id f4UGk2m06012; Wed, 30 May 2001 12:46:03 -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: <15125.9158.5024.675692@conrail.cs.columbia.edu> Date: Wed, 30 May 2001 12:45:57 -0400 (EDT) To: "NITSCH,FRANK (HP-Germany,ex1)" Cc: "IETF-Calendar Mailing List (E-mail)" Subject: RE: Recurrence implementation question 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, May 30 2001, "NITSCH,FRANK (HP-Germany,ex1)" wrote to "'Jonathan Lennox', IETF-Calendar Mailing List (E-mail)" saying: > > > Issue 2: > > > It's necessary to calculate all the recurrence dates that > > occur between the > > > event's start date and the specified time frame's start > > date even though > > > they are not needed. > > > > This is only true if a recurrence has a COUNT parameter, and it's easy > > enough to do a one-time translation of COUNT into a "virtual" UNTIL. > > But this would change the definition as set by the user. Imagine you - as a > user - enter a recurring schedule using the COUNT parameter. The CS would > "translate" it into a UNTIL statement. Someday wou want to edit the schedule > and it follows a different rule! Well, yes, clearly -- that's why I said "virtual" UNTIL. The server calculates the date of the last recurrence (by count) whenever a new or changed recurrence rule is sent to it. It caches this value locally alongside the rule, for its calculation purposes, but it still presents the actual COUNT value -- and not the UNTIL -- whenever the rule is queried or edited. The point of this is just to speed calculations -- if the period of time you're interested in is earlier than a rule's start, or later than its computed until, you can quickly conclude that you don't need to worry about that rule for now. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Thu May 31 14:52:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05974 for ; Thu, 31 May 2001 14:52:02 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA15855 for ietf-calendar-bks; Thu, 31 May 2001 11:32:49 -0700 (PDT) Received: from spf11.us4.outblaze.com (205-158-62-43.outblaze.com [205.158.62.43] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15850 for ; Thu, 31 May 2001 11:32:44 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44] (may be forged)) by spf11.us4.outblaze.com (8.11.0/8.11.0) with SMTP id f4VIWGf24419 for ; Thu, 31 May 2001 18:32:16 GMT Received: (qmail 18433 invoked by uid 0); 31 May 2001 18:30:47 -0000 MBOX-Line: From owner-ietf-calendar@mail.imc.org Thu May 17 22:44:55 2001 Received: (qmail 5662 invoked from network); 17 May 2001 22:44:50 -0000 Received: from unknown (HELO spf3.us4.outblaze.com) (205.158.62.25) by 205-158-62-44.outblaze.com with SMTP; 17 May 2001 22:44:50 -0000 Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf3.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f4HMiTs13926 for ; Thu, 17 May 2001 22:44:29 GMT Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA27991 for ietf-calendar-bks; Thu, 17 May 2001 15:02:27 -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 PAA27973 for ; Thu, 17 May 2001 15:02:21 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: RECAP & Questions of CPL RECUR Issues. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_05132001 May 13, 2001 Message-ID: Date: Thu, 17 May 2001 18:03:28 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.7 |March 21, 2001) at 05/17/2001 06:12:26 PM, Serialize complete at 05/17/2001 06:12:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0078EA4385256A4F_=" List-Archive: List-ID: List-Unsubscribe: Status: O Lines: 54 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0078EA4385256A4F_= Content-Type: text/plain; charset="us-ascii" John claimed: >To reach Draft Standard, there need to be two implementations >which implement the *entire* specification. You can't >cherry-pick; you can't say, "A and B support X, and C and D >support Y, so we keep X and Y" (unless X and Y are optional). Thats not how I read RFC 2026, section 4.1.2 Draft Standard, paragraph 2 where it says: In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. This tells me that both X and Y would stay in the spec as it progressed since at least 2 implementations implement those "options or features". That confirms what I was first told when I was new to IETF. However, perhaps Patrick or some other AD can confirm / decline / clarify this. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0078EA4385256A4F_= Content-Type: text/html; charset="us-ascii"
John claimed:
>To reach Draft Standard, there need to be two implementations
>which implement the *entire* specification.  You can't
>cherry-pick; you can't say, "A and B support X, and C and D
>support Y, so we keep X and Y" (unless X and Y are optional).
Thats not how I read RFC 2026, section 4.1.2  Draft Standard, paragraph 2 where it says:

              In cases in which one or more options or features
  have not been demonstrated in at least two interoperable
  implementations, the specification may advance to the Draft Standard
  level only if those options or features are removed.

This tells me that both X and Y would stay in the spec as it progressed since at least 2 implementations implement those "options or features".  That confirms what I was first told when I was new to IETF.  However, perhaps Patrick or some other AD can confirm / decline / clarify this.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0078EA4385256A4F_=-- From owner-ietf-calendar@mail.imc.org Thu May 31 14:52:05 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05984 for ; Thu, 31 May 2001 14:52:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA15839 for ietf-calendar-bks; Thu, 31 May 2001 11:32:30 -0700 (PDT) Received: from spf11.us4.outblaze.com (205-158-62-43.outblaze.com [205.158.62.43] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15829 for ; Thu, 31 May 2001 11:32:25 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44] (may be forged)) by spf11.us4.outblaze.com (8.11.0/8.11.0) with SMTP id f4VIVvf22158 for ; Thu, 31 May 2001 18:31:57 GMT Received: (qmail 18053 invoked by uid 0); 31 May 2001 18:30:24 -0000 MBOX-Line: From owner-ietf-calendar@mail.imc.org Thu May 17 22:41:04 2001 Received: (qmail 27997 invoked from network); 17 May 2001 22:40:55 -0000 Received: from unknown (HELO spf11.us4.outblaze.com) (205.158.62.43) by 205-158-62-44.outblaze.com with SMTP; 17 May 2001 22:40:55 -0000 Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf11.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f4HMec231085 for ; Thu, 17 May 2001 22:40:38 GMT Received: by above.proper.com (8.9.3/8.9.3) id PAA27638 for ietf-calendar-bks; Thu, 17 May 2001 15:00:19 -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 PAA27597 for ; Thu, 17 May 2001 15:00:06 -0700 (PDT) From: pregen@egenconsulting.com To: Alan Davies Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org, "Shannon J. Clark" Subject: RE: [RFC2445] Discrepancy in 4.3.6 Duration (original and May 10th draft) X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 17 May 2001 17:59:46 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 05/17/2001 05:59:49 PM, Serialize complete at 05/17/2001 05:59:49 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0078D04385256A4F_=" List-Archive: List-ID: List-Unsubscribe: Status: O Lines: 14 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0078D04385256A4F_= Content-Type: text/plain; charset="us-ascii" Alan, minor errors can not be corrected in a published RFC - that is correct. That's the errata list. However, if there are changes required to a draft (i.e. ones that impact interoperability), the process is to reissue the draft with a new number. --=_alternative 0078D04385256A4F_= Content-Type: text/html; charset="us-ascii"
Alan, minor errors can not be corrected in a published RFC - that is correct. That's the errata list.  However, if there are changes required to a draft (i.e. ones that impact interoperability), the process is to reissue the draft with a new number. --=_alternative 0078D04385256A4F_=--