From owner-ietf-calendar@mail.imc.org  Thu Jun  1 15:31:57 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01775
	for <calsch-archive@odin.ietf.org>; Thu, 1 Jun 2000 15:31:57 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA06226
	for ietf-calendar-bks; Thu, 1 Jun 2000 12:04:29 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06221
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 12:04:24 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: ietf-calendar@imc.org
Subject: RFC 2446 Quickie 
X-Mailer: Lotus Notes Build V60_05302000 May 30, 2000
Message-ID: <OF69C379D5.7DF121FF-ON852568F1.0068FF1F@iris.com>
Date: Thu, 1 Jun 2000 15:12:11 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/01/2000
 03:12:20 PM,
	Serialize complete at 06/01/2000 03:12:21 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/01/2000
 03:12:21 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0069856D852568F1_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0069856D852568F1_=
Content-Type: text/plain; charset="us-ascii"

In looking at the details of RFC 2446 I noticed what may be either an 
oversight or at least some inconsistancies in the tables of what 
properties are allowed in each message type.

In particular, for a VEVENT under nearly all METHODs except REPLY, CANCEL 
and COUNTER the description for SUMMARY and DESCRIPTION says "Can be 
null".  Is there any reason that for these methods we do NOT allow SUMMARY 
and/or DESCRIPTION to be null as well??

If not, can the current holder of RFC 244x errata and updates please note 
this.  Im sure there are other inconsistancies like this but Im not 
focused on them just yet...

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 0069856D852568F1_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">In looking at the details of RFC 2446 I noticed what may be either an oversight or at least some inconsistancies in the tables of what properties are allowed in each message type.</font>
<br>
<br><font size=2 face="sans-serif">In particular, for a VEVENT under nearly all METHODs except REPLY, CANCEL and COUNTER the description for SUMMARY and DESCRIPTION says &quot;Can be null&quot;. &nbsp;Is there any reason that for these methods we do NOT allow SUMMARY and/or DESCRIPTION to be null as well??</font>
<br>
<br><font size=2 face="sans-serif">If not, can the current holder of RFC 244x errata and updates please note this. &nbsp;Im sure there are other inconsistancies like this but Im not focused on them just yet...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0069856D852568F1_=--


From owner-ietf-calendar@mail.imc.org  Thu Jun  1 15:40:41 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01939
	for <calsch-archive@odin.ietf.org>; Thu, 1 Jun 2000 15:40:40 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA06378
	for ietf-calendar-bks; Thu, 1 Jun 2000 12:14:26 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06373
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 12:14:24 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Recurrence rule clarification
X-Mailer: Lotus Notes Build V60_05302000 May 30, 2000
Message-ID: <OFF1C39551.4AAE8710-ON852568F1.0069AFE9@iris.com>
Date: Thu, 1 Jun 2000 15:22:07 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/01/2000
 03:22:17 PM,
	Serialize complete at 06/01/2000 03:22:17 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006A6E53852568F1_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 006A6E53852568F1_=
Content-Type: text/plain; charset="us-ascii"

In banging my head against the monitor trying to totally absorb the 
nuances of a full recurrence rule engine and parsing I think I ran across 
a slight discrepancy in the description of the recurrence rule data type. 
In particular:

4.3.10 Recurrence Rule
...
   Description: If the property permits, multiple "recur" values are
   specified by a COMMA character (US-ASCII decimal 44) separated list
   of values. [Snip, snip, snip]               The rule parts are not
   ordered in any particular sequence. Individual rule parts MUST only
   be specified once.

  The first line says that multiple recurrence rules on a single property 
that takes this data type can be separated by commas.  However this would 
be totally unparsable hence we put in that last line.  Just how 
would/should a parser deal with something like:

        RRULE:FREQ=Daily,COUNT=5,BYDAY=MO,FREQ=Weekly,BYDAY=FR

  The fix for this is quite simple: remove the first sentence of the 
description and replace it with:

   Description: Multiple "recur" values are not permitted on any property.

  If there are no amendments or objections Id propose that it get added to 
the list of 2445 updates that Frank is maintaining...

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 006A6E53852568F1_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">In banging my head against the monitor trying to totally absorb the nuances of a full recurrence rule engine and parsing I think I ran across a slight discrepancy in the description of the recurrence rule data type. &nbsp;In particular:</font>
<br>
<br><font size=2><tt>4.3.10 Recurrence Rule</tt></font>
<br><font size=2 face="sans-serif">...</font>
<br><font size=2><tt>&nbsp; &nbsp;Description: If the property permits, multiple &quot;recur&quot; values are<br>
 &nbsp; specified by a COMMA character (US-ASCII decimal 44) separated list<br>
 &nbsp; of values. [Snip, snip, snip] &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The rule parts are not<br>
 &nbsp; ordered in any particular sequence. Individual rule parts MUST only<br>
 &nbsp; be specified once.</tt></font>
<br>
<br><font size=2 face="sans-serif">&nbsp; The first line says that multiple recurrence rules on a single property that takes this data type can be separated by commas. &nbsp;However this would be totally unparsable hence we put in that last line. &nbsp;Just how would/should a parser deal with something like:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; RRULE:FREQ=Daily,COUNT=5,BYDAY=MO,FREQ=Weekly,BYDAY=FR</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; The fix for this is quite simple: remove the first sentence of the description and replace it with:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;Description: Multiple &quot;recur&quot; values are not permitted on any property.<br>
</tt></font>
<br><font size=2 face="sans-serif">&nbsp; If there are no amendments or objections Id propose that it get added to the list of 2445 updates that Frank is maintaining...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 006A6E53852568F1_=--


From owner-ietf-calendar@mail.imc.org  Thu Jun  1 15:58:00 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02237
	for <calsch-archive@odin.ietf.org>; Thu, 1 Jun 2000 15:57:59 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA06704
	for ietf-calendar-bks; Thu, 1 Jun 2000 12:30:28 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06700
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 12:30:26 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Poll: How should this "recur" value be handled       
X-Mailer: Lotus Notes Build V60_05302000 May 30, 2000
Message-ID: <OFA8194704.910C3CDE-ON852568F1.006A6BA9@iris.com>
Date: Thu, 1 Jun 2000 15:38:10 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/01/2000
 03:38:20 PM,
	Serialize complete at 06/01/2000 03:38:20 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006BE670852568F1_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 006BE670852568F1_=
Content-Type: text/plain; charset="us-ascii"

As others who have worked on building actual engines to handle our very 
powerfull recurrence grammar can attest to, there are some areas where the 
RFC is not clear on what action should be taken.  The case in particular I 
am thinking of is what is the prescribed behaviour of a CUA to a 
recurrence value that is 'discontiguous' when evaluated.  For example:

DTSTART:20000601T040000Z
DTEND:20000601T043000Z
RRULE:FREQ=DAILY,INTERVAL=1,BYMONTH=1,BYYEARDAY=10,200;COUNT=10

The BYMONTH sets the selection range to "all days in January" and then the 
BYYEARDAY part specifies the  10th and 200th day of the year.  The former 
is in January but the latter is not.

So, what is the expected handling of this RRULE?  I can name a few 
choices:

1: Ignore the entire rule and flag the BYYEARDAY value as being 'invalid'
2: Ignore the offending part entirely (BYYEARDAY) and flag the BYYEARDAY 
value as partially 'invalid'
3: Snap your spine bending over backwards to allow the 'out of range' 
BYYEARDAY and say nothing.

Using "The Mantra" (KISS), I would opt for choice #1 any day.

Option #2 is also a possible behaviour but I have to question its 
validity.  If the ORGANIZER really wanted the 100th day of the year to be 
part of the recurrence set, it is MUCH simpler to put it either into a 
separate RRULE or RDATE rather than forcing it into another RRULE.

Option #3 is WAAY too much work for the fractionally tiny case that this 
MAY occur in that its not worth really considering...  From what Ive seen 
of those CUAs that support recurrence anyways, they are well behaved 
enough NOT to try and generate such a funky rule.  (Ive noticed that some 
folks will eat RRULEs they do not like and NOT tell the user too, tsk 
tsk!!)

Sooo, Id be interested in hearing what others think of this and once we 
reach some concensus Ill be glad to propose some new text for the 2445 
maintainers to add.  If I hear no discussion then Ill assume everyone 
agrees that #1 is acceptable and scribble something up for the list to 
that effect.

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 006BE670852568F1_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">As others who have worked on building actual engines to handle our very powerfull recurrence grammar can attest to, there are some areas where the RFC is not clear on what action should be taken. &nbsp;The case in particular I am thinking of is what is the prescribed behaviour of a CUA to a recurrence value that is 'discontiguous' when evaluated. &nbsp;For example:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART:20000601T040000Z</font>
<br><font size=2 face="sans-serif">DTEND:20000601T043000Z</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=DAILY,INTERVAL=1,BYMONTH=1,BYYEARDAY=10,200;COUNT=10</font>
<br>
<br><font size=2 face="sans-serif">The BYMONTH sets the selection range to &quot;all days in January&quot; and then the BYYEARDAY part specifies the &nbsp;10th and 200th day of the year. &nbsp;The former is in January but the latter is not.</font>
<br>
<br><font size=2 face="sans-serif">So, what is the expected handling of this RRULE? &nbsp;I can name a few choices:</font>
<br>
<br><font size=2 face="sans-serif">1: Ignore the entire rule and flag the BYYEARDAY value as being 'invalid'</font>
<br><font size=2 face="sans-serif">2: Ignore the offending part entirely (BYYEARDAY) and flag the BYYEARDAY value as partially 'invalid'</font>
<br><font size=2 face="sans-serif">3: Snap your spine bending over backwards to allow the 'out of range' BYYEARDAY and say nothing.</font>
<br>
<br><font size=2 face="sans-serif">Using &quot;The Mantra&quot; (KISS), I would opt for choice #1 any day.</font>
<br>
<br><font size=2 face="sans-serif">Option #2 is also a possible behaviour but I have to question its validity. &nbsp;If the ORGANIZER really wanted the 100th day of the year to be part of the recurrence set, it is MUCH simpler to put it either into a separate RRULE or RDATE rather than forcing it into another RRULE.</font>
<br>
<br><font size=2 face="sans-serif">Option #3 is WAAY too much work for the fractionally tiny case that this MAY occur in that its not worth really considering... &nbsp;From what Ive seen of those CUAs that support recurrence anyways, they are well behaved enough NOT to try and generate such a funky rule. &nbsp;(Ive noticed that some folks will eat RRULEs they do not like and NOT tell the user too, tsk tsk!!)</font>
<br>
<br><font size=2 face="sans-serif">Sooo, Id be interested in hearing what others think of this and once we reach some concensus Ill be glad to propose some new text for the 2445 maintainers to add. &nbsp;If I hear no discussion then Ill assume everyone agrees that #1 is acceptable and scribble something up for the list to that effect.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 006BE670852568F1_=--


From owner-ietf-calendar@mail.imc.org  Thu Jun  1 17:47:01 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04821
	for <calsch-archive@odin.ietf.org>; Thu, 1 Jun 2000 17:47:00 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09126
	for ietf-calendar-bks; Thu, 1 Jun 2000 14:20:43 -0700 (PDT)
Received: from agony.busboom.org (24-25-198-225.san.rr.com [24.25.198.225])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09122
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 14:20:41 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id OAA26806;
	Thu, 1 Jun 2000 14:28:13 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Thu, 1 Jun 2000 14:28:12 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: Bruce_Kahn@iris.com
cc: ietf-calendar@imc.org
Subject: Re: Recurrence rule clarification
In-Reply-To: <OFF1C39551.4AAE8710-ON852568F1.0069AFE9@iris.com>
Message-ID: <Pine.LNX.4.10.10006011422340.3403-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>



On Thu, 1 Jun 2000 Bruce_Kahn@iris.com wrote:

> In banging my head against the monitor trying to totally absorb the 
> nuances of a full recurrence rule engine and parsing I think I ran across 
> a slight discrepancy in the description of the recurrence rule data type. 

Ah... it is good to know that I am not suffering alone...

>   The first line says that multiple recurrence rules on a single property 
> that takes this data type can be separated by commas.  However this would 
> be totally unparsable hence we put in that last line.  Just how 

Well, it isn't unparsable, but it is not pretty. My code that splits
values based on commas has a special case for recur: it is a value
separating comma only if it is followed by "FREQ." Since "FREQ" must be
the first thing in a rrule ( contrary to some RFC2446 examples ) this
should always work. 

But, this is a is horribly ugly hack. I'd like to second Bruce's request
to make RECUR values take only one value.

eric. 






From owner-ietf-calendar@mail.imc.org  Thu Jun  1 17:54:08 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04972
	for <calsch-archive@odin.ietf.org>; Thu, 1 Jun 2000 17:54:07 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09235
	for ietf-calendar-bks; Thu, 1 Jun 2000 14:30:26 -0700 (PDT)
Received: from agony.busboom.org (24-25-198-225.san.rr.com [24.25.198.225])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09230
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 14:30:25 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id OAA26850
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 14:38:16 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Thu, 1 Jun 2000 14:38:15 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: ietf-calendar@imc.org
Subject: Max # of occurences in a recur rule?
Message-ID: <Pine.LNX.4.10.10006011401300.3403-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


RFC2445 says that BYSETPOS can select from only 366 occurences in an
interval. This seems sensible, since any recurrence rule that had more
than 366 occurences per interval could be re-written to have less. Can an
implementation assume that there will be no more 366 occurences per
interval and reject any rule that has more?

Implementing recurrence rules gets difficult when you have to handle the
most general case, since some of these cases get excessive. For instance: 

	RRULE:FREQ=YEARLY; BYYEARDAY=1,2,3,4,...,364,365,366;
	 BYHOUR=0,...,23;BYMINUTE=0,...59;BYSECOND=0,...,59;
	 BYSETPOS=1,100,-100,-1

This rule selects 4 out of 31 million occurences, and the use of SETPOS is
an abuse of the original intent.  Handling it without resource exhaustion
or excessive run times requires an extraordinary programmer or an ugly
special case.

Can an implementation reject a strictly conforming but logically
insensible rrule? Or can we make un-normalized RRULEs non-conforming? I
think we need to reduce some of the unlimited possibilites of the
recurrence grammar to be able to write conforming, efficient and
bug-free code.

eric. 





From owner-ietf-calendar@mail.imc.org  Thu Jun  1 19:50:06 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07122
	for <calsch-archive@odin.ietf.org>; Thu, 1 Jun 2000 19:50:05 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id QAA10483
	for ietf-calendar-bks; Thu, 1 Jun 2000 16:16:48 -0700 (PDT)
Received: from agony.busboom.org (24-25-198-225.san.rr.com [24.25.198.225])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10476
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 16:16:47 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id QAA04943;
	Thu, 1 Jun 2000 16:24:36 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Thu, 1 Jun 2000 16:24:36 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: Bruce_Kahn@iris.com
cc: ietf-calendar@imc.org
Subject: Re: Poll: How should this "recur" value be handled       
In-Reply-To: <OFA8194704.910C3CDE-ON852568F1.006A6BA9@iris.com>
Message-ID: <Pine.LNX.4.10.10006011605050.3403-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>



On Thu, 1 Jun 2000 Bruce_Kahn@iris.com wrote:

> The case in particular I am thinking of is what is the prescribed
> behaviour of a CUA to a recurrence value that is 'discontiguous' when
> evaluated.  For example:
> 
> DTSTART:20000601T040000Z
> DTEND:20000601T043000Z
> RRULE:FREQ=DAILY,INTERVAL=1,BYMONTH=1,BYYEARDAY=10,200;COUNT=10
> 
> The BYMONTH sets the selection range to "all days in January" and then the 
> BYYEARDAY part specifies the  10th and 200th day of the year.  The former 
> is in January but the latter is not.

There is a similar ambigulty between some interval frequencies and BYxxx
parts. 

RFC2445 indicates that based on the frequency (FREQ) the BYxxx parts can
expand or contract the occurence set. Many of these relationships are
clear, but some are not. RFC 4.3.10 gives some good examples of the clear
cases. 

But, how do the BYxxx parts expand or contract the followig recurrence
intervals?

FREQ=WEEKLY: BYMONTHDAY, BYYEARDAY
FREQ=MONTHLY: BYYEARDAY, BYWEEKNO

I am guessing that for the WEEKLY case, both are contracting, and for the
MONTHLY case, both are expanding. But, we need to make sure other
developers make the same guess.

eric. 



From owner-ietf-calendar@mail.imc.org  Thu Jun  1 22:29:24 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09787
	for <calsch-archive@odin.ietf.org>; Thu, 1 Jun 2000 22:29:23 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id SAA21817
	for ietf-calendar-bks; Thu, 1 Jun 2000 18:39:32 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21806
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 18:39:30 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: Eric Busboom <eric@softwarestudio.org>
Cc: ietf-calendar@imc.org
Subject: Re: Recurrence rule clarification
X-Mailer: Lotus Notes Build V60_05312000 May 31, 2000
Message-ID: <OF872603D2.26B17E72-ON852568F2.00080F8C@iris.com>
Date: Thu, 1 Jun 2000 21:47:02 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/01/2000
 09:47:24 PM,
	Serialize complete at 06/01/2000 09:47:24 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0009D678852568F2_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0009D678852568F2_=
Content-Type: text/plain; charset="us-ascii"

Eric consoled me with:
>Well, it isn't unparsable, but it is not pretty.

Ok, "unparsable" is the wrong term.  I should have used "illogical" or 
"un-unwindable" since there is not a likely chance that a recurrence 
engine would know which FREQ go with which INTERVAL or other recur rule 
parts...

>My code that splits
>values based on commas has a special case for recur: it is a value
>separating comma only if it is followed by "FREQ." Since "FREQ" must be
>the first thing in a rrule ( contrary to some RFC2446 examples ) this
>should always work.

Better be careful there.  I know the ABNF starts with:

     recur      = "FREQ"=freq *(

but the first paragraph of the Description clearly says:

                                           The rule parts are not
   ordered in any particular sequence.

So, if you believe the intro text under 1.0 that says:

                                      This ABNF is required for
   the implementation of parsers and to serve as the definitive
   reference when ambiguities or questions arise in interpreting the
   descriptive prose definition of the memo.

then you _should_ be ok.  Its MUCH simpler in the long run if we just 
restrict the recurrence rule data type to ALWAYS be single valued...  I 
cant think of any reason that a 'double' RRULE could not just be simply 
written as 2 separate RRULEs.  I admire your approach but I prefer my gray 
cells functioning rather than smoking.

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 0009D678852568F2_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Eric consoled me with:</font>
<br><font size=2 face="Courier New">&gt;Well, it isn't unparsable, but it is not pretty.</font>
<br>
<br><font size=2 face="sans-serif">Ok, &quot;unparsable&quot; is the wrong term. &nbsp;I should have used &quot;illogical&quot; or &quot;un-unwindable&quot; since there is not a likely chance that a recurrence engine would know which FREQ go with which INTERVAL or other recur rule parts...</font>
<br>
<br><font size=2 face="Courier New">&gt;My code that splits<br>
&gt;values based on commas has a special case for recur: it is a value<br>
&gt;separating comma only if it is followed by &quot;FREQ.&quot; Since &quot;FREQ&quot; must be<br>
&gt;the first thing in a rrule ( contrary to some RFC2446 examples ) this<br>
&gt;should always work.</font>
<br>
<br><font size=2 face="sans-serif">Better be careful there. &nbsp;I know the ABNF starts with:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp;recur &nbsp; &nbsp; &nbsp;= &quot;FREQ&quot;=freq *(<br>
<br>
</tt></font><font size=2 face="sans-serif">but the first paragraph of the Description clearly says:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The rule parts are not<br>
 &nbsp; ordered in any particular sequence.</tt></font>
<br>
<br><font size=2 face="sans-serif">So, if you believe the intro text under 1.0 that says:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; This ABNF is required for<br>
 &nbsp; the implementation of parsers and to serve as the definitive<br>
 &nbsp; reference when ambiguities or questions arise in interpreting the<br>
 &nbsp; descriptive prose definition of the memo.</tt></font>
<br>
<br><font size=2 face="sans-serif">then you _should_ be ok. &nbsp;Its MUCH simpler in the long run if we just restrict the recurrence rule data type to ALWAYS be single valued... &nbsp;I cant think of any reason that a 'double' RRULE could not just be simply written as 2 separate RRULEs. &nbsp;I admire your approach but I prefer my gray cells functioning rather than smoking.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
--=_alternative 0009D678852568F2_=--


From owner-ietf-calendar@mail.imc.org  Thu Jun  1 22:41:39 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11019
	for <calsch-archive@odin.ietf.org>; Thu, 1 Jun 2000 22:41:38 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id SAA23559
	for ietf-calendar-bks; Thu, 1 Jun 2000 18:57:17 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA23555
	for <ietf-calendar@imc.org>; Thu, 1 Jun 2000 18:57:16 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: Eric Busboom <eric@softwarestudio.org>
Cc: ietf-calendar@imc.org
Subject: Re: Max # of occurences in a recur rule?
X-Mailer: Lotus Notes Build V60_05312000 May 31, 2000
Message-ID: <OFEB7B0E46.EEA4C4CE-ON852568F2.000A09D4@iris.com>
Date: Thu, 1 Jun 2000 22:04:48 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/01/2000
 10:08:20 PM,
	Serialize complete at 06/01/2000 10:08:20 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 000B7707852568F2_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 000B7707852568F2_=
Content-Type: text/plain; charset="us-ascii"

Eric pondered:
>Can an
>implementation assume that there will be no more 366 occurences per
>interval and reject any rule that has more?[Snip]
>Implementing recurrence rules gets difficult when you have to handle the
>most general case, since some of these cases get excessive.

Id point out a MUCH simpler case than your very very nasty one: if the 
rule is simply FREQ=DAILY;BYHOUR=9,10 then you are automatically over over 
the limit after just 6 months of instances.  Then I realized that if the 
rule were just simply FREQ=DAILY;COUNT=400 then we've already blown the 
ability to use BYSETPOS for instances 367-400.  If you used negative 
values you could get to them simply make COUNT=800 and there is now a 
'hole' in the middle we cannot access by BYSETPOS.  The same can be said 
for infinite recurrences (ie: FREQ=DAILY;BYDAY=MO)...

So, I think that BYSETPOS probably needs to be expanded to allow for any 
values that that the rest of the recurrence rule can generate.  Do I want 
to be the one that does the rewrite of the prose and ABNF (MUST be precise 
w/that ABNF); no way!  I dont know of anyone using or supporting BYSETPOS 
yet (I havent played w/libical, just commercial stuff) so Im not too 
worried yet.

>Can an implementation reject a strictly conforming but logically
>insensible rrule?

A CUA can reject anything it likes (hopefully w/in reason; I wont reject 
GEO: even if I may not use it).  In the cases Ive seen so far, the CUAs 
simply ignore (w/o any indication) those properties or property values 
they do not like in things like RRULEs.  They SHOULD be sending back some 
REQUEST-STATUS that indicates to the Organizer "Hey, I didnt quite grok 
your RRULE" or "You generate bogus RRULEs" or some other such response 
status.  Thats why we allowed > 1 REQUEST-STATUS in a REPLY.

If your CUA can parse the iCalendar data then its in conformance w/the 
RFCs.  Thats not to say it must support every property otherwise we'd 
never get CalConnect 2.0 off the ground as we will all be busy writing for 
features we cannot or do not want to support.

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 000B7707852568F2_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Eric pondered:</font>
<br><font size=2 face="Courier New">&gt;Can an<br>
&gt;implementation assume that there will be no more 366 occurences per<br>
&gt;interval and reject any rule that has more?[Snip]</font>
<br><font size=2 face="Courier New">&gt;Implementing recurrence rules gets difficult when you have to handle the<br>
&gt;most general case, since some of these cases get excessive.</font>
<br>
<br><font size=2 face="sans-serif">Id point out a MUCH simpler case than your very very nasty one: if the rule is simply FREQ=DAILY;BYHOUR=9,10 then you are automatically over over the limit after just 6 months of instances. &nbsp;Then I realized that if the rule were just simply FREQ=DAILY;COUNT=400 then we've already blown the ability to use BYSETPOS for instances 367-400. &nbsp;If you used negative values you could get to them simply make COUNT=800 and there is now a 'hole' in the middle we cannot access by BYSETPOS. &nbsp;The same can be said for infinite recurrences (ie: FREQ=DAILY;BYDAY=MO)...</font>
<br>
<br><font size=2 face="sans-serif">So, I think that BYSETPOS probably needs to be expanded to allow for any values that that the rest of the recurrence rule can generate. &nbsp;Do I want to be the one that does the rewrite of the prose and ABNF (MUST be precise w/that ABNF); no way! &nbsp;I dont know of anyone using or supporting BYSETPOS yet (I havent played w/libical, just commercial stuff) so Im not too worried yet.</font>
<br>
<br><font size=2 face="Courier New">&gt;Can an implementation reject a strictly conforming but logically<br>
&gt;insensible rrule?</font>
<br>
<br><font size=2 face="sans-serif">A CUA can reject anything it likes (hopefully w/in reason; I wont reject GEO: even if I may not use it). &nbsp;In the cases Ive seen so far, the CUAs simply ignore (w/o any indication) those properties or property values they do not like in things like RRULEs. &nbsp;They SHOULD be sending back some REQUEST-STATUS that indicates to the Organizer &quot;Hey, I didnt quite grok your RRULE&quot; or &quot;You generate bogus RRULEs&quot; or some other such response status. &nbsp;Thats why we allowed &gt; 1 REQUEST-STATUS in a REPLY.</font>
<br>
<br><font size=2 face="sans-serif">If your CUA can parse the iCalendar data then its in conformance w/the RFCs. &nbsp;Thats not to say it must support every property otherwise we'd never get CalConnect 2.0 off the ground as we will all be busy writing for features we cannot or do not want to support.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
--=_alternative 000B7707852568F2_=--


From owner-ietf-calendar@mail.imc.org  Sun Jun  4 03:28:16 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03395
	for <calsch-archive@odin.ietf.org>; Sun, 4 Jun 2000 03:28:15 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA08041
	for ietf-calendar-bks; Sat, 3 Jun 2000 23:52:15 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08037
	for <ietf-calendar@imc.org>; Sat, 3 Jun 2000 23:52:13 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA00478
	for ietf-calendar@imc.org; Sun, 4 Jun 2000 00:00:03 -0700 (PDT)
Date: Sun, 4 Jun 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200006040700.AAA00478@royer.com>
X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r
To: ietf-calendar@imc.org
Subject: CALSCH Action Items
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a list of action items for the CALSCH Working Group.
This list will be sent out once a week and updated as often
as practical (That means if I am not available it may take
an extra week or two before you see your changes).

Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM .

There are three parts to this action list:

	(W) Working group action items.
	(C) CAP editor action items.
	(I) iCalendar action items (Frank Dawson)

Each action item will be assigned a unique ID that will aid in
tracking the items.

------------------------------------------------------------------------------

			Working Group Action Items   

Where Resolution is one of:

	U - undecided.
	Y - Chair determined consensus is in favor of the proposal.
	N - Chair determined consensus is NOT in favor of the proposal.
	D - Dropped. Chair has decided that it may never reach consensus.

 The following are a list of proposals and their status in the WG:
 
 WG Action Item					Resolution
 --------------					----------

 W-1 CAP Use HTTP as transport			N
 
 W-2 CAP If all booked and scheduled		Y
     appointments are in same table
 
 W-3 CAP Use SASL as authentication method	Y
 
 W-4 Add UID and COUNTER to VFREEBUSY		N 

 W-5 CAP Should CAPABILITY reply be sent	N
     as result of successful AUTHENTICATE
     and IDENTITY 

 W-6 Do we need to handle 'unscheduled
     event' as described by the SKI project?	N
     (In CAP - 'N', SKI to be a seperate
      project/draft as it will effect
      RFC2445,6,7)

 W-7 CAP Auto-logout Timer issues		
      Do we need one?				Y
      How long?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	Y
     [see note in CAP 7.2.1.5]
 
 W-10 CAP Text mandatory in all response	N
      codes
 
 W-11 CAP Text optional in response codes	Y
      (some response codes may have 
       mandatory data that follows)
       
 W-12 CAP Should parts of response code be	Y
      separated by ';'
      
 W-13 CAP Store Schema				Y
 
 W-14 CAP VEVENT Schema				Y
 
 W-15 CAP VTODO Schema				Y
 
 W-16 CAP VJOURNAL Schema			Y
 
 W-17 CAP VCAR Schema				Y

 W-18 CAP UPN definition, including anonymous	Y
      user and how UPN's are used in LDAP and
      certificates.
 
 W-19 CAP Group definitions, dynamic and	Y
      static and how groups are used in VCARs.
      Policy definitions, in a VCAR format.

 W-20 Associating UPN values with CREATED	N
      and LAST-MODIFIED properties.

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			Y in process

 W-23 CAP Calendar property to allow/disallow	N
      overlapped booking OPAQUE entries?

 W-24 CAP Calendar CHARSET property issues	Y

 W-25 Remove MUST from UID in 4.8.4.7		Y

 W-26 Write/Submit information draft/rfc	Y

 W-27 How a query can specify if the recurrence	Y
      rules are to be expanded by the CS.

 W-28 Cal-Props - PATH				N
      (CAP-00 - 12.2)
      Will there need to be one?		N
      Optional?					N

 W-29 Import/Export				Y - sync only

 W-30 Transport protocol name (transport vs	Y
      application layer)

 W-31 NOOP command?				Y

 W-32 NOOP advisory only?			Y

 W-33 Should DISCONNECT be called QUIT?		U

 W-34 Format following error codes. Are		Y
      they well defined? If not they
      need to be machine determinable. 

 W-35 Move DNS and SLP to seperate draft?	Y

------------------------------------------------------------------------------

 The following are a list of action items for the CAP draft editors:
 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

 C-2 Fix up changes in authentication		Alex	N
     text as commented on the list		Paul

 C-3 Text for 2.7 [Finding CAP Servers]		Doug	N
 
 C-4 VCAR examples				Doug?	N
 
 C-5 PUBLISH text
 
 C-6 REQUEST text
 
 C-7 REPLY text

 C-8 ADD text
 
 C-9 CANCEL text 
 
 C-10 REFRESH text
 
 C-11 COUNTER text
 
 C-12 DECLINECOUNTER Text

 C-13 Post CAP-00.txt					Y

 C-14 Redo state diagram to include STARTTLS
      and IDENTIFY command.

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------

 I-1 MIME alternate/related			Frank	?
     MUST be supported.

 I-2 Remove ordering of properties and		Frank	?
     parameters in draft.

 I-3 S/MIME and RFC1847.			U
     [CAP] 2.2.3

 I-4 Add ALARMID to VALARM ?			Y

------------------------------------------------------------------------------


Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM

--------------------------------------------------------------------------
Work: Doug.Royer@Software.com              Home    801 Woodside Rd #14-244
      530 E. Montecito St.                 Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541                    Personal Email: Doug@Royer.com



From owner-ietf-calendar@mail.imc.org  Sun Jun  4 13:42:52 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08960
	for <calsch-archive@odin.ietf.org>; Sun, 4 Jun 2000 13:42:51 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA29191
	for ietf-calendar-bks; Sun, 4 Jun 2000 10:17:22 -0700 (PDT)
Received: from agony.busboom.org (24-25-198-225.san.rr.com [24.25.198.225])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29186
	for <ietf-calendar@imc.org>; Sun, 4 Jun 2000 10:17:20 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id KAA21875
	for <ietf-calendar@imc.org>; Sun, 4 Jun 2000 10:25:16 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Sun, 4 Jun 2000 10:25:16 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: ietf-calendar@imc.org
Subject: Proposed change to RECUR, RFC2445, 4.3.10
Message-ID: <Pine.LNX.4.10.10005311552230.3403-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


To address some of the comments that Bruce Kahn and I have made about
recurrence rules over the last week, I propose the following text changes
to RFC2445. 

Since I was not privy to the original recurrence rule discussions, I don't
have a complete understanding of the complete purpose for the grammar as
it exists today. This proposal is based entirely on implementation
experiences. 

Though the grammar can represent almost any conceivable recurrence
pattern, it can also represent inconceivable patterns. These insensible
patterns are entirely due to the overlaps in ways to specify a specific
day, and the proposed text would make these ambiguous overlaps illegal. 

For instance, BYYEARDAY specifies a day of the year, a day of the week, a
month, and a week number, so it conflicts with many of the other BYxxx
rule parts. We could define a way to merge these rule parts to eliminate
conflicts, but how useful is a rule like "Every year on the 100th day of
the year, when the 100th day is also a Saturday in March"? Weird stuff
like this can be handled with multiple RRULE or EXRULEs. 

eric. 

This proposed text is an addition to RFC2445, section 4.3.10
--------------------------------------------------------------------------

There are two types of BYxxx rules; date BYxxx rule parts that specify
time periods equal to or longer than a day, and time BYxxx rule parts that
specify the time within a day. The day BYxxx rule parts are : BYMONTH,
BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY. The time BYxxx rule parts are
BYHOUR, BYMINUTE, and BYSECOND. BYSETPOS is neither a date rule part nor
a time rule part. 

Not all date BYxxx rule parts can appear simultaneously in a single
recurrence rule. Date BYxxx rule part restrictions are:

  If the BYYEARDAY appears, no other date rule part may appear. 

  BYWEEKNO and BYMONTH rule parts may not both appear. 

Furthermore, not all date rule parts may be used with all recurrence
intervals. 

  For MONTHLY recurrences (FREQ=MONTHLY) neither BYYEARDAY nor BYWEEKNO
  may appear.

  For WEEKLY recurrences (FREQ=WEEKLY) neither BYMONTHDAY nor BYYEARDAY
  may appear.
 
There are no restrictions regarding use of date rule parts and time rule
parts. There are no restrictions with using any combination of time rule
parts






From owner-ietf-calendar@mail.imc.org  Mon Jun  5 12:07:26 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05290
	for <calsch-archive@odin.ietf.org>; Mon, 5 Jun 2000 12:07:25 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14694
	for ietf-calendar-bks; Mon, 5 Jun 2000 08:29:43 -0700 (PDT)
Received: from epic.iris.com (epic.iris.com [198.112.211.41])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14688
	for <ietf-calendar@imc.org>; Mon, 5 Jun 2000 08:29:40 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: ietf-calendar@imc.org
Subject: Just a quick update 
X-Mailer: Lotus Notes Build V60_06012000 June 01, 2000
Message-ID: <OF5D967F37.B509BFCF-ON852568F5.005529D9@iris.com>
Date: Mon, 5 Jun 2000 11:31:15 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Epic/Iris(Build V5010625|June 25, 1999) at 06/05/2000
 11:41:09 AM,
	Serialize complete at 06/05/2000 11:41:10 AM,
	Serialize by Router on Epic/Iris(Build V5010625|June 25, 1999) at 06/05/2000
 11:41:10 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005549AD852568F5_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 005549AD852568F5_=
Content-Type: text/plain; charset="us-ascii"

to let those of you who have been accessing my personal threaded archive of this WG that the admins moved my archive from 
http://www.iris.com/web/CalSched.nsf was moved and renamed (w/o my control 
or concent) to http://www.iris.com/web/bkahn/IETFCnS.nsf .  Update your 
bookmarks accordingly...

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 005549AD852568F5_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">to let those of you who have been accessing my <u>personal</u> threaded archive of this WG that the admins moved my archive from http://www.iris.com/web/CalSched.nsf was moved and renamed (w/o my control or concent) to http://www.iris.com/web/bkahn/IETFCnS.nsf . &nbsp;Update your bookmarks accordingly...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 005549AD852568F5_=--


From owner-ietf-calendar@mail.imc.org  Mon Jun  5 14:14:46 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07928
	for <calsch-archive@odin.ietf.org>; Mon, 5 Jun 2000 14:14:45 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA20816
	for ietf-calendar-bks; Mon, 5 Jun 2000 10:39:35 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20812
	for <ietf-calendar@imc.org>; Mon, 5 Jun 2000 10:39:33 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: RFC 2446 conflict: Delegation and REPLY
X-Mailer: Lotus Notes Build V60_06012000 June 01, 2000
Message-ID: <OF4D495EDD.313967D9-ON852568F5.0060B977@iris.com>
Date: Mon, 5 Jun 2000 13:49:16 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_06012000|June 01, 2000) at
 06/05/2000 01:47:05 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_06012000|June 01, 2000) at
 06/05/2000 01:47:05 PM,
	Serialize complete at 06/05/2000 01:47:05 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_06012000|June 01, 2000) at
 06/05/2000 01:47:44 PM,
	S/MIME Sign complete at 06/05/2000 01:47:44 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/05/2000
 01:47:47 PM,
	Serialize complete at 06/05/2000 01:47:47 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z54591_boundary_sign
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is an S/MIME signed message.

---------z54591_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0061B1B1852568F5_="

This is a multipart message in MIME format.
--=_alternative 0061B1B1852568F5_=
Content-Type: text/plain; charset="us-ascii"

Ok, while taking a breather to reread the RFCs yet again Ive found a 
discrepancy in RFC 2446 with respect to delegation and ATTENDEE 
properties.  In particular 

4.2.5 Delegating an Event

   When delegating an event request to another "Calendar User", the
   "Delegator" must both update the "Organizer" with a "REPLY" and send
   a request to the "Delegate". [Snip, snip]      The "Delegator" MUST:

     .  Send a "REPLY" to the "Organizer" with the following updates:
     .  The "Delegator's" "ATTENDEE" property "partstat" parameter set
        to "delegated" and the "delegated-to" parameter is set to the
        address of the "Delegate"
     .  Add an additional "ATTENDEE" property for the "Delegate" with
        the "delegated-from" property parameter set to the "Delegator"

says that on my REPLY to the Organizer I can have 2 (or possibly more if I 
do delegation to > 1 CU!) ATTENDEE properties in it.  A supporting example 
can be found in 4.2.6 Delegate Accepts the Meeting.  However these are in direct conflict with:

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". The "REPLY"
   method " SHOULD include the "ATTENDEE" property with the "delegated-
   from" parameter value of the "Delegator's" calendar address.

and

3.2.3 REPLY
...
Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST be "REPLY"
VEVENT              1+      All components MUST have the same UID
    ATTENDEE        1       MUST be the address of the Attendee
                            replying.

This last line precludes doing what 4.2.5 advocates.  Since we have not 
precluded that a Delegator can delegate to > 1 Delegatee, I think the 
table entry for ATTENDEE under 3.2.3 should be amended to:

    ATTENDEE        1+      MUST be the address of the Attendee
                            replying and MAY include addresses of
                            any delegates.

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 0061B1B1852568F5_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Ok, while taking a breather to reread the RFCs yet again Ive found a discrepancy in RFC 2446 with respect to delegation and ATTENDEE properties. &nbsp;In particular </font>
<br>
<br><font size=2><tt>4.2.5 Delegating an Event<br>
<br>
 &nbsp; When delegating an event request to another &quot;Calendar User&quot;, the<br>
 &nbsp; &quot;Delegator&quot; must both update the &quot;Organizer&quot; with a &quot;REPLY&quot; and send<br>
 &nbsp; a request to the &quot;Delegate&quot;. [Snip, snip] &nbsp; &nbsp; &nbsp;The &quot;Delegator&quot; MUST:<br>
<br>
 &nbsp; &nbsp; . &nbsp;Send a &quot;REPLY&quot; to the &quot;Organizer&quot; with the following updates:<br>
 &nbsp; &nbsp; . &nbsp;The &quot;Delegator's&quot; &quot;ATTENDEE&quot; property &quot;partstat&quot; parameter set<br>
 &nbsp; &nbsp; &nbsp; &nbsp;to &quot;delegated&quot; and the &quot;delegated-to&quot; parameter is set to the<br>
 &nbsp; &nbsp; &nbsp; &nbsp;address of the &quot;Delegate&quot;<br>
 &nbsp; &nbsp; . &nbsp;Add an additional &quot;ATTENDEE&quot; property for the &quot;Delegate&quot; with<br>
 &nbsp; &nbsp; &nbsp; &nbsp;the &quot;delegated-from&quot; property parameter set to the &quot;Delegator&quot;<br>
</tt></font>
<br><font size=2 face="sans-serif">says that on my REPLY to the Organizer I can have 2 (or possibly more if I do delegation to &gt; 1 CU!) ATTENDEE properties in it. &nbsp;A supporting example can be found in </font><font size=2><tt>4.2.6 Delegate Accepts the Meeting</tt></font><font size=2 face="sans-serif">. &nbsp;However these are in direct conflict with:</font>
<br>
<br><font size=2><tt>3.2.2.3 Delegating an Event to another CU<br>
...</tt></font>
<br><font size=2><tt>&nbsp; &nbsp;In response to the request, the &quot;Delegate&quot; MUST send a &quot;REPLY&quot; method<br>
 &nbsp; to the &quot;Organizer&quot; and optionally, to the &quot;Delegator&quot;. The &quot;REPLY&quot;<br>
 &nbsp; method &quot; SHOULD include the &quot;ATTENDEE&quot; property with the &quot;delegated-<br>
 &nbsp; from&quot; parameter value of the &quot;Delegator's&quot; calendar address.<br>
</tt></font>
<br><font size=2 face="sans-serif">and</font>
<br>
<br><font size=2><tt>3.2.3 REPLY</tt></font>
<br><font size=2><tt>...</tt></font>
<br><font size=2><tt>Component/Property &nbsp;Presence<br>
------------------- ----------------------------------------------<br>
METHOD &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; MUST be &quot;REPLY&quot;<br>
VEVENT &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1+ &nbsp; &nbsp; &nbsp;All components MUST have the same UID<br>
 &nbsp; &nbsp;ATTENDEE &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp; &nbsp; &nbsp; MUST be the address of the Attendee<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;replying.</tt></font>
<br>
<br><font size=2 face="sans-serif">This last line precludes doing what 4.2.5 advocates. &nbsp;Since we have not precluded that a Delegator can delegate to &gt; 1 Delegatee, I think the table entry for ATTENDEE under 3.2.3 should be amended to:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; ATTENDEE &nbsp; &nbsp; &nbsp; &nbsp;1+ &nbsp; &nbsp; &nbsp;MUST be the address of the Attendee<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;replying and MAY include addresses of</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; any delegates.</tt></font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0061B1B1852568F5_=--

---------z54591_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYwNTE3NDcwNVowIwYJKoZIhvcNAQkEMRYEFJygMCT6e7Z1
FrPExjQ40mhdhuu4MA0GCSqGSIb3DQEBAQUABEC7aU6R9Jwd36qOG8Jn1KXb2nlHh0oQV5X5RkZs
p1wIUwhYVNOj6w3n5JBARx9G4phkmvIo5OCr3ON3VXVGoywg

---------z54591_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Mon Jun  5 15:50:03 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09376
	for <calsch-archive@odin.ietf.org>; Mon, 5 Jun 2000 15:50:02 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA22303
	for ietf-calendar-bks; Mon, 5 Jun 2000 12:07:19 -0700 (PDT)
Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22299
	for <ietf-calendar@imc.org>; Mon, 5 Jun 2000 12:07:15 -0700 (PDT)
From: Thierryb@cst.ca
Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44])
	by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA32039;
	Mon, 5 Jun 2000 15:14:52 -0400
Received: by apollo.CST.CA with Internet Mail Service (5.5.2650.21)
	id <K0ZKZ70X>; Mon, 5 Jun 2000 15:14:50 -0400
Message-ID: <D28949FC21D5D311843500104B6D1D8F50A892@apollo.CST.CA>
To: Bruce_Kahn@iris.com, ietf-calendar@imc.org
Subject: RE: RFC 2446 conflict: Delegation and REPLY
Date: Mon, 5 Jun 2000 15:14:49 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFCF22.52005276"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFCF22.52005276
Content-Type: text/plain;
	charset="iso-8859-1"

Why do I receive this email thread since last Friday?
I don't think I suscribed to that?
 
Thks 
 
Thierry Bonfante
Product Manager - Wireless Applications
 
CS&T / Lexacom
3333 Graham Boulevard, 5th floor, 
Montreal, QC., Canada
H3R 3L5
 
Tel: (514) 861-9146
Mobile: (514) 992-3397
E-mail: thierryb@cst.ca
 
-----Original Message-----
From: Bruce_Kahn@iris.com [mailto:Bruce_Kahn@iris.com]
Sent: Monday, June 05, 2000 10:49 AM
To: ietf-calendar@imc.org
Subject: RFC 2446 conflict: Delegation and REPLY
Importance: High
 

Ok, while taking a breather to reread the RFCs yet again Ive found a
discrepancy in RFC 2446 with respect to delegation and ATTENDEE properties.
In particular 

4.2.5 Delegating an Event

  When delegating an event request to another "Calendar User", the
  "Delegator" must both update the "Organizer" with a "REPLY" and send
  a request to the "Delegate". [Snip, snip]      The "Delegator" MUST:

    .  Send a "REPLY" to the "Organizer" with the following updates:
    .  The "Delegator's" "ATTENDEE" property "partstat" parameter set
       to "delegated" and the "delegated-to" parameter is set to the
       address of the "Delegate"
    .  Add an additional "ATTENDEE" property for the "Delegate" with
       the "delegated-from" property parameter set to the "Delegator"

says that on my REPLY to the Organizer I can have 2 (or possibly more if I
do delegation to > 1 CU!) ATTENDEE properties in it.  A supporting example
can be found in 4.2.6 Delegate Accepts the Meeting.  However these are in
direct conflict with: 

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". The "REPLY"
  method " SHOULD include the "ATTENDEE" property with the "delegated-
  from" parameter value of the "Delegator's" calendar address.

and 

3.2.3 REPLY 
... 
Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST be "REPLY"
VEVENT              1+      All components MUST have the same UID
   ATTENDEE        1       MUST be the address of the Attendee
                           replying. 

This last line precludes doing what 4.2.5 advocates.  Since we have not
precluded that a Delegator can delegate to > 1 Delegatee, I think the table
entry for ATTENDEE under 3.2.3 should be amended to: 

    ATTENDEE        1+      MUST be the address of the Attendee
                           replying and MAY include addresses of 
                            any delegates. 

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_001_01BFCF22.52005276
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01BFCF01.3CF5C580">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
@font-face
	{font-family:sans-serif;
	panose-1:0 0 0 0 0 0 0 0 0 0;
	mso-font-alt:"Times New Roman";
	mso-font-charset:0;
	mso-generic-font-family:roman;
	mso-font-format:other;
	mso-font-pitch:auto;
	mso-font-signature:0 0 0 0 0 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
tt
	{mso-ascii-font-family:"Courier New";
	mso-fareast-font-family:"Courier New";
	mso-hansi-font-family:"Courier New";
	mso-bidi-font-family:"Courier New";}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>W=
hy do I
receive this email thread since last =
Friday?<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
 don&#8217;t
think I suscribed to that?<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
hks <o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoAutoSig><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span style=3D'mso-element:field-separator'></span></spa=
n></font></span><![endif]--><font
color=3Dnavy><span style=3D'color:navy'>Thierry =
Bonfante</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Product Manager - Wireless =
Applications</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><b><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;font-weight:bold'>CS&amp;T / =
Lexacom</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/b></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>3333 Graham Boulevard, 5th floor, =
</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Montreal, QC., =
Canada</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>H3R 3L5</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Tel: (514) =
861-9146</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Mobile: (514) =
992-3397</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>E-mail: =
thierryb@cst.ca</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle16><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
Bruce_Kahn@iris.com
[mailto:Bruce_Kahn@iris.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, June 05, =
2000 10:49
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
ietf-calendar@imc.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RFC 2446 =
conflict:
Delegation and REPLY<br>
<b><span style=3D'font-weight:bold'>Importance:</span></b> =
High</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3Dsans-serif><span =
style=3D'font-size:
10.0pt;font-family:sans-serif;color:black'>Ok, while taking a breather =
to
reread the RFCs yet again Ive found a discrepancy in RFC 2446 with =
respect to
delegation and ATTENDEE properties. &nbsp;In particular =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
<br>
</span></font><tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>4.2.5 =
Delegating
an Event</span></font></tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-font-family:"Courier New";
color:black'><br>
<br>
<tt>&nbsp; When delegating an event request to another &quot;Calendar
User&quot;, the</tt><br>
<tt>&nbsp; &quot;Delegator&quot; must both update the =
&quot;Organizer&quot;
with a &quot;REPLY&quot; and send</tt><br>
<tt>&nbsp; a request to the &quot;Delegate&quot;. [Snip, snip] &nbsp; =
&nbsp;
&nbsp;The &quot;Delegator&quot; MUST:</tt><br>
<br>
<tt>&nbsp; &nbsp; . &nbsp;Send a &quot;REPLY&quot; to the =
&quot;Organizer&quot;
with the following updates:</tt><br>
<tt>&nbsp; &nbsp; . &nbsp;The &quot;Delegator's&quot; =
&quot;ATTENDEE&quot;
property &quot;partstat&quot; parameter set</tt><br>
<tt>&nbsp; &nbsp; &nbsp; &nbsp;to &quot;delegated&quot; and the
&quot;delegated-to&quot; parameter is set to the</tt><br>
<tt>&nbsp; &nbsp; &nbsp; &nbsp;address of the =
&quot;Delegate&quot;</tt><br>
<tt>&nbsp; &nbsp; . &nbsp;Add an additional &quot;ATTENDEE&quot; =
property for
the &quot;Delegate&quot; with</tt><br>
<tt>&nbsp; &nbsp; &nbsp; &nbsp;the &quot;delegated-from&quot; property
parameter set to the &quot;Delegator&quot;</tt><br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3Dsans-serif><span =
style=3D'font-size:
10.0pt;font-family:sans-serif;color:black'>says that on my REPLY to the
Organizer I can have 2 (or possibly more if I do delegation to &gt; 1 =
CU!)
ATTENDEE properties in it. &nbsp;A supporting example can be found in =
</span></font><tt><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:
"Courier New";color:black'>4.2.6 Delegate Accepts the =
Meeting</span></font></tt><font
size=3D2 color=3Dblack face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:
sans-serif;color:black'>. &nbsp;However these are in direct conflict =
with:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
<br>
</span></font><tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";color:black'>3.2.2.3
Delegating an Event to another CU</span></font></tt><font size=3D2 =
color=3Dblack
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New";
mso-fareast-font-family:"Courier New";color:black'><br>
<tt>...</tt></span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>&nbsp; =
&nbsp;In
response to the request, the &quot;Delegate&quot; MUST send a =
&quot;REPLY&quot;
method</span></font></tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-font-family:"Courier New";
color:black'><br>
<tt>&nbsp; to the &quot;Organizer&quot; and optionally, to the
&quot;Delegator&quot;. The &quot;REPLY&quot;</tt><br>
<tt>&nbsp; method &quot; SHOULD include the &quot;ATTENDEE&quot; =
property with
the &quot;delegated-</tt><br>
<tt>&nbsp; from&quot; parameter value of the &quot;Delegator's&quot; =
calendar
address.</tt><br>
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3Dsans-serif><span =
style=3D'font-size:
10.0pt;font-family:sans-serif;color:black'>and</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
<br>
</span></font><tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>3.2.3 =
REPLY</span></font></tt><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";color:black'>...</span></font></tt><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";color:black'>Component/Property
&nbsp;Presence</span></font></tt><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-font-family:"Courier New";
color:black'><br>
<tt>------------------- =
----------------------------------------------</tt><br>
<tt>METHOD &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp; =
&nbsp;
&nbsp; MUST be &quot;REPLY&quot;</tt><br>
<tt>VEVENT &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1+ &nbsp; =
&nbsp;
&nbsp;All components MUST have the same UID</tt><br>
<tt>&nbsp; &nbsp;ATTENDEE &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp; &nbsp; =
&nbsp;
MUST be the address of the Attendee</tt><br>
<tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;replying.</tt></span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
<br>
</span></font><font size=3D2 color=3Dblack face=3Dsans-serif><span =
style=3D'font-size:
10.0pt;font-family:sans-serif;color:black'>This last line precludes =
doing what
4.2.5 advocates. &nbsp;Since we have not precluded that a Delegator can =
delegate
to &gt; 1 Delegatee, I think the table entry for ATTENDEE under 3.2.3 =
should be
amended to:</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
<br>
</span></font><tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>&nbsp; =
&nbsp;
ATTENDEE &nbsp; &nbsp; &nbsp; &nbsp;1+ &nbsp; &nbsp; &nbsp;MUST be the =
address
of the Attendee</span></font></tt><font size=3D2 color=3Dblack =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New";mso-fareast-font-family:"Courier New";
color:black'><br>
<tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;replying and MAY include addresses =
of</tt></span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><tt><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>&nbsp; =
&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;
&nbsp; any delegates.</span></font></tt><font color=3Dblack><span
style=3D'color:black'> <br>
<br>
</span></font><font size=3D2 color=3Dblack face=3Dsans-serif><span =
style=3D'font-size:
10.0pt;font-family:sans-serif;color:black'>Bruce</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3Dsans-serif><span =
style=3D'font-size:
10.0pt;font-family:sans-serif;color:black'>=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<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;
&nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by =
law...</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

</div>

</body>

</html>

------_=_NextPart_001_01BFCF22.52005276--


From owner-ietf-calendar@mail.imc.org  Tue Jun  6 16:30:22 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18726
	for <calsch-archive@odin.ietf.org>; Tue, 6 Jun 2000 16:30:21 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13126
	for ietf-calendar-bks; Tue, 6 Jun 2000 13:00:54 -0700 (PDT)
Received: from smtp-2.opaltelecom.net (smtp-2.opaltelecom.net [62.24.128.69])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13122
	for <ietf-calendar@imc.org>; Tue, 6 Jun 2000 13:00:52 -0700 (PDT)
Received: from 124-140-ras11-1.ppp.opaltelecom.net ([62.24.140.124] helo=cs.bris.ac.uk)
	by smtp-2.opaltelecom.net with esmtp (Exim 3.13 #1)
	id 12zPel-0005AK-00
	for ietf-calendar@imc.org; Tue, 06 Jun 2000 21:08:59 +0100
Message-ID: <393D5AA5.9DB08D2E@cs.bris.ac.uk>
Date: Tue, 06 Jun 2000 21:10:13 +0100
From: Stephen Vangasse <vangasse@cs.bris.ac.uk>
Organization: Netscape Online member
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13-4mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF <ietf-calendar@imc.org>
Subject: "text/calendar" MIME type with JavaMail API
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I am studying to do a Masters Degree in Computer Science. For my
dissertation I am making a calendaring application that sends and
recieves iMIP e-mail messages. I am writing it using the JavaMail API.

If anyone is familiar with the JavaMail API and the JavaBeans Activation
framework (JAF), and knows how to implement a DataHandler for the
"text/calendar" MIME type, any advice would be very welcome.

Thanks in advance,

Steve Vangasse
University of Bristol
vangasse@cs.bris.ac.uk



From owner-ietf-calendar@mail.imc.org  Wed Jun  7 09:48:39 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10477
	for <calsch-archive@odin.ietf.org>; Wed, 7 Jun 2000 09:48:38 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26202
	for ietf-calendar-bks; Wed, 7 Jun 2000 06:16:20 -0700 (PDT)
Received: from lnsmtp.on.com (lnsmtp.on.com [207.18.216.12])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA26198
	for <ietf-calendar@imc.org>; Wed, 7 Jun 2000 06:16:18 -0700 (PDT)
From: MCiavari@meetingmaker.com
Received: by lnsmtp.on.com(Lotus SMTP MTA v4.6.2  (693.3 8-11-1998))  id 852568F7.0049F6AF ; Wed, 7 Jun 2000 09:27:52 -0400
X-Lotus-FromDomain: ON TECHNOLOGY
To: ietf-calendar@imc.org
Message-ID: <852568F7.0049F6A6.00@lnsmtp.on.com>
Date: Wed, 7 Jun 2000 09:16:23 -0400
Subject: Timezone database availability...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>



Hi all, I'm wondering if you have finished work on the timezone database?
If so can I have a copy?  If not, can you point me to the one you are using
as a base for yours?

Thank you...

Michael Ciavarini




From owner-ietf-calendar@mail.imc.org  Fri Jun  9 11:34:31 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13254
	for <calsch-archive@odin.ietf.org>; Fri, 9 Jun 2000 11:34:31 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA21670
	for ietf-calendar-bks; Fri, 9 Jun 2000 08:02:20 -0700 (PDT)
Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21662
	for <ietf-calendar@imc.org>; Fri, 9 Jun 2000 08:02:18 -0700 (PDT)
Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44])
	by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA29579;
	Fri, 9 Jun 2000 11:10:19 -0400
Received: from cst.ca (dyn14.int.cst.ca [192.168.1.14]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id K0ZK5FYB; Fri, 9 Jun 2000 11:10:18 -0400
Message-ID: <394108D1.4AE9381F@cst.ca>
Date: Fri, 09 Jun 2000 11:10:09 -0400
From: George Babics <georgeb@cst.ca>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>,
        Bob Mahoney <bobmah@mit.edu>
Subject: Implementors' Guide
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


Bob, Alex,

  As you know "Implementors' Guide to Internet Calendaring"
has expired. I feel that it should be brought back to life.
It provides a useful introduction to the calendering standards
and points people to the documents they should know based on
their needs. The document can be further improved by providing
more examples, guidelines, open issues, information on what is
not covered by the standards, and so forth.

  As CS&T and others develop applications that support the
standards we can continue to update the document.

  If we do bring it back, we should do so soon so that we will
be able to discuss it in Pittsburgh.  There are a few small 
changes that I suggest, and a few questions relating to the 
document.

  First, we can consider removing references to iRIP. It
seems to me that everyone has lost interest in it.

  Secondly, in section 2.1, we can add an example of a person
using a calendar for his or her own personal use and accessed only
from one CUA. It can be something like this:

   A doctor wishes to keep track of all his appointments.

   Need: Read and manipulate one's own calendar with only one CUA.

   Solution: The doctor can use a proprietary CUA with a local store,
             and perhaps use [ICAL] as a storage mechanism.

   Even though it is the simplest need, and it does not require
the standards for a solution, it can be part of the section
titled "Fundamental Needs" since it is very fundamental (many, if
not most people's calendars are like the one in the example).

  Third, we can add updates of CAP to the draft. For instance,
we should mention in the Authentication section (5.2) that CAP
must use SASL as its authentication mechanism.

  Fourth, do we want to clarify or add to the intent of the document?
Currently its intent is:

   It is the intent of this document to provide guidance for
   implementors of calendaring and scheduling products in determining
   which of the various existing protocol documents are applicable to
   their work, as well as providing some background information and
   pointers to the less obvious implications of the available choices.

   (from the introduction of the draft)

   Do we want to make its intent to provide a guide to implementors,
such as provide information on issues, common mistakes or misconceptions,
things related to calendering that are not part of the standards
(such as synchronization), and so forth? After all, it is an
"Implementors' Guide."

  Fifth, are there other sections that we can add to the document?
Currently, there are sections on Requirements, Solutions, Open
Issues, and Security Considerations. For instance, we can add
a section describing why certain decisions were made during
the development of the standard.

  Sixth, the examples given in section 3.2, "Systems", can easily
be updated. By adding more examples, we can show the wide variety
of systems that can exist. These new examples, can include calendar
services, multi-user systems, CUA without local stores, fanout,
services communicating using iMIP, situations where a CUA may need
to synchronize its local store with that of one or more calendar
services. Some possibilities:

   Single-user with multiple CUA

   A single user may use more than one CUA to access his or her
   calendar. The user may use a PDA, a web client, a PC, or some other
   device, depending an accessibility.  Some of these clients may have
   local stores and others may not.  If they do, then they need to
   ensure that the data on the CUA is synchronized with the data on
   the CS.

              -----------
             |   CUA w   | -----[CAP]----------+
             |local store|                     |
        O     -----------                    ----------
       -+-                                  |   CS     |
        A                                   |          |
       / \                                   ----------
              -----------                      |
             |  CUA w/o  | -----[CAP]----------+
             |local store|
              -----------

   Single-user with multiple calendars

   A single user may have many independent calendars.  One may be work
   related, another for personal use.  The CUA may or may not have a
   local store.  If it does, then it needs to ensure that the data on
   the CUA is synchronized with the data on both of the CS.

                                             ----------
                   +------------[CAP]------ |   CS     |
                   |                        |          |
        O     -----------                    ----------
       -+-   |  CUA      |
        A    |           |
       / \    -----------
                   |                         ----------
                   +------------[CAP]------ |   CS     |
                                            |          |
                                             ----------

   Users communicating on a multi-user system

   Users on a multi-user system may schedule meetings with each other
   using [CAP]-enabled CUA and service.  The CUA may or may not have
   a local store.  If they do, then they need to ensure that the
   data on the CUA is synchronized with the data on the CS.

        O     -----------
       -+-   |   CUA w   | -----[CAP]----------+
        A    |local store|                     |
       / \    -----------                    ----------
                                            |   CS     |
                                            |          |
                                             ----------
        O     -----------                      |
       -+-   |  CUA w/o  | -----[CAP]----------+
        A    |local store|
       / \    -----------

  Users communicating through different multi-user systems

  Users on a multi-user system may need to schedule meetings with
  user on a different multi user system.  The services can
  communicate using [CAP]

       O     -----------                    ----------
      -+-   |   CUA w   | -----[CAP]-------|   CS     |
       A    |local store|                  |          |
      / \    -----------                    ----------
                                                |
                                              [CAP]
                                                |
       O     -----------                    ----------
      -+-   |  CUA w/o  | -----[CAP]-------|   CS     |
       A    |local store|                  |          |
      / \    -----------                    ----------




George Babics
Research & Development
Corporate Software & Technologies
3333 Graham Boulevard, 5th floor
Montréal, Québec, Canada
H3R 3L5
Tel: (514) 733-8500 x303
Fax: (514) 733-8878
E-mail: georgeb@cst.ca


From owner-ietf-calendar@mail.imc.org  Fri Jun  9 12:15:52 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14370
	for <calsch-archive@odin.ietf.org>; Fri, 9 Jun 2000 12:15:51 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26981
	for ietf-calendar-bks; Fri, 9 Jun 2000 08:47:39 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26974
	for <ietf-calendar@imc.org>; Fri, 9 Jun 2000 08:47:34 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: <ietf-calendar@imc.org>
Message-ID: <OF14C66872.016F46DE-ON852568F9.0055D8B3@iris.com>
Date: Fri, 9 Jun 2000 11:55:58 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/09/2000
 11:58:00 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


George asked several things among them:
>                                  For instance, we can add
>a section describing why certain decisions were made during
>the development of the standard.

I think that some may find this useful but it is not something that an
implementor really needs to know to implement the standards.  Its more
background that they can get by reading the archives of the WG mailing list
(or asking on the list if they have the think skin to take the sometimes
toasty responses).

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  Fri Jun  9 14:44:33 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17084
	for <calsch-archive@odin.ietf.org>; Fri, 9 Jun 2000 14:44:32 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03503
	for ietf-calendar-bks; Fri, 9 Jun 2000 11:16:39 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03499
	for <ietf-calendar@imc.org>; Fri, 9 Jun 2000 11:16:37 -0700 (PDT)
From: andys@iris.com
Received: from internet1.lotus.com (internet1.lotus.com [9.95.4.235])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA29217
	for <ietf-calendar@imc.org>; Fri, 9 Jun 2000 14:24:51 -0400 (EDT)
Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177])
	by internet1.lotus.com (8.9.3/8.9.3) with SMTP id OAA11879
	for <ietf-calendar@imc.org>; Fri, 9 Jun 2000 14:24:36 -0400 (EDT)
Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 852568F9.00642E9D ; Fri, 9 Jun 2000 14:14:15 -0400
X-Lotus-FromDomain: NOTES@ALPHABETA
To: "ietf-calendar@imc.org"@iris.com
Message-ID: <852568F9.00642E74.00@motorcity2.lotus.com>
Date: Fri, 9 Jun 2000 13:11:21 -0500
Subject: test - ignore
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>





______________________________
From the Notes 5.0 Desktop of
Andy Scharmer




From owner-ietf-calendar@mail.imc.org  Sun Jun 11 03:22:36 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02619
	for <calsch-archive@odin.ietf.org>; Sun, 11 Jun 2000 03:22:35 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA23397
	for ietf-calendar-bks; Sat, 10 Jun 2000 23:51:37 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23393
	for <ietf-calendar@imc.org>; Sat, 10 Jun 2000 23:51:35 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA07120
	for ietf-calendar@imc.org; Sun, 11 Jun 2000 00:00:03 -0700 (PDT)
Date: Sun, 11 Jun 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200006110700.AAA07120@royer.com>
X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r
To: ietf-calendar@imc.org
Subject: CALSCH Action Items
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a list of action items for the CALSCH Working Group.
This list will be sent out once a week and updated as often
as practical (That means if I am not available it may take
an extra week or two before you see your changes).

Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM .

There are three parts to this action list:

	(W) Working group action items.
	(C) CAP editor action items.
	(I) iCalendar action items (Frank Dawson)

Each action item will be assigned a unique ID that will aid in
tracking the items.

------------------------------------------------------------------------------

			Working Group Action Items   

Where Resolution is one of:

	U - undecided.
	Y - Chair determined consensus is in favor of the proposal.
	N - Chair determined consensus is NOT in favor of the proposal.
	D - Dropped. Chair has decided that it may never reach consensus.

 The following are a list of proposals and their status in the WG:
 
 WG Action Item					Resolution
 --------------					----------

 W-1 CAP Use HTTP as transport			N
 
 W-2 CAP If all booked and scheduled		Y
     appointments are in same table
 
 W-3 CAP Use SASL as authentication method	Y
 
 W-4 Add UID and COUNTER to VFREEBUSY		N 

 W-5 CAP Should CAPABILITY reply be sent	N
     as result of successful AUTHENTICATE
     and IDENTITY 

 W-6 Do we need to handle 'unscheduled
     event' as described by the SKI project?	N
     (In CAP - 'N', SKI to be a seperate
      project/draft as it will effect
      RFC2445,6,7)

 W-7 CAP Auto-logout Timer issues		
      Do we need one?				Y
      How long?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	Y
     [see note in CAP 7.2.1.5]
 
 W-10 CAP Text mandatory in all response	N
      codes
 
 W-11 CAP Text optional in response codes	Y
      (some response codes may have 
       mandatory data that follows)
       
 W-12 CAP Should parts of response code be	Y
      separated by ';'
      
 W-13 CAP Store Schema				Y
 
 W-14 CAP VEVENT Schema				Y
 
 W-15 CAP VTODO Schema				Y
 
 W-16 CAP VJOURNAL Schema			Y
 
 W-17 CAP VCAR Schema				Y

 W-18 CAP UPN definition, including anonymous	Y
      user and how UPN's are used in LDAP and
      certificates.
 
 W-19 CAP Group definitions, dynamic and	Y
      static and how groups are used in VCARs.
      Policy definitions, in a VCAR format.

 W-20 Associating UPN values with CREATED	N
      and LAST-MODIFIED properties.

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			Y in process

 W-23 CAP Calendar property to allow/disallow	N
      overlapped booking OPAQUE entries?

 W-24 CAP Calendar CHARSET property issues	Y

 W-25 Remove MUST from UID in 4.8.4.7		Y

 W-26 Write/Submit information draft/rfc	Y

 W-27 How a query can specify if the recurrence	Y
      rules are to be expanded by the CS.

 W-28 Cal-Props - PATH				N
      (CAP-00 - 12.2)
      Will there need to be one?		N
      Optional?					N

 W-29 Import/Export				Y - sync only

 W-30 Transport protocol name (transport vs	Y
      application layer)

 W-31 NOOP command?				Y

 W-32 NOOP advisory only?			Y

 W-33 Should DISCONNECT be called QUIT?		U

 W-34 Format following error codes. Are		Y
      they well defined? If not they
      need to be machine determinable. 

 W-35 Move DNS and SLP to seperate draft?	Y

------------------------------------------------------------------------------

 The following are a list of action items for the CAP draft editors:
 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

 C-2 Fix up changes in authentication		Alex	N
     text as commented on the list		Paul

 C-3 Text for 2.7 [Finding CAP Servers]		Doug	N
 
 C-4 VCAR examples				Doug?	N
 
 C-5 PUBLISH text
 
 C-6 REQUEST text
 
 C-7 REPLY text

 C-8 ADD text
 
 C-9 CANCEL text 
 
 C-10 REFRESH text
 
 C-11 COUNTER text
 
 C-12 DECLINECOUNTER Text

 C-13 Post CAP-00.txt					Y

 C-14 Redo state diagram to include STARTTLS
      and IDENTIFY command.

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------

 I-1 MIME alternate/related			Frank	?
     MUST be supported.

 I-2 Remove ordering of properties and		Frank	?
     parameters in draft.

 I-3 S/MIME and RFC1847.			U
     [CAP] 2.2.3

 I-4 Add ALARMID to VALARM ?			Y

------------------------------------------------------------------------------


Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM

--------------------------------------------------------------------------
Work: Doug.Royer@Software.com              Home    801 Woodside Rd #14-244
      530 E. Montecito St.                 Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541                    Personal Email: Doug@Royer.com



From owner-ietf-calendar@mail.imc.org  Sun Jun 11 09:31:33 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07206
	for <calsch-archive@odin.ietf.org>; Sun, 11 Jun 2000 09:31:32 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14502
	for ietf-calendar-bks; Sun, 11 Jun 2000 06:04:36 -0700 (PDT)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14498
	for <ietf-calendar@imc.org>; Sun, 11 Jun 2000 06:04:33 -0700 (PDT)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA12547; Sun, 11 Jun 00 09:13:00 EDT
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id JAA13886;
	Sun, 11 Jun 2000 09:13:08 -0400 (EDT)
Received: from [216.254.65.43] (airport.bobmah.com [216.254.65.43])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id JAA03784;
	Sun, 11 Jun 2000 09:13:03 -0400 (EDT)
Mime-Version: 1.0
X-Sender: bobmah@18.69.0.43
Message-Id: <p04320409b5693f2d4c7d@[216.254.65.43]>
In-Reply-To: <OF39048FE0.8D791EDC-ON852568F9.00559554@iris.com>
References: <OF39048FE0.8D791EDC-ON852568F9.00559554@iris.com>
Date: Sun, 11 Jun 2000 09:11:56 -0400
To: <Bruce_Kahn@iris.com>
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: Implementors' Guide
Cc: George Babics <georgeb@cst.ca>, Bob Mahoney <bobmah@mit.edu>,
        ietf-calendar@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

At 11:37 AM -0400 6/9/00, <Bruce_Kahn@iris.com> wrote:
>George asked several things among them:
>>                                   For instance, we can add
>>a section describing why certain decisions were made during
>>the development of the standard.
>
>I think that some may find this useful but it is not something that 
>an implementor really needs to know to implement the standards.  Its 
>more background that they can get by reading the archives of the WG 
>mailing list (or asking on the list if they have the think skin to 
>take the sometimes toasty responses).

I have to disagree here.  We want to pass along some of the reasons 
that certain decisions were made, and what the issues involved were. 
We can always reference the archives for a more complete record of 
various debates, but I think it's important to capture some of the 
debates we've had, at least enough to know the topic was considered.

We want to have developers aware of Why, not just How.  Expecting 
that anyone approaching development of a calendar app will read 
several years of (often boring) archives first, to get the full 
design context, is probably not reasonable...

-Bob


From owner-ietf-calendar@mail.imc.org  Sun Jun 11 15:13:59 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09006
	for <calsch-archive@odin.ietf.org>; Sun, 11 Jun 2000 15:13:59 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA17475
	for ietf-calendar-bks; Sun, 11 Jun 2000 11:43:43 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17471;
	Sun, 11 Jun 2000 11:43:41 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA26420;
	Sun, 11 Jun 2000 14:52:09 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA13772;
	Sun, 11 Jun 2000 14:51:51 -0400 (EDT)
To: Bob Mahoney <bobmah@mit.edu>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: Implementors' Guide
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OF88CFCA59.D51054DC-ON852568FB.00660D84@lotus.com>
Date: Sun, 11 Jun 2000 14:44:44 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 06/11/2000 02:44:44 PM,
	Serialize complete at 06/11/2000 02:44:44 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00677E3F852568FB_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 00677E3F852568FB_=
Content-Type: text/plain; charset="us-ascii"

Bob:
If the information/commentary is has a technical basis that will assist 
the implementor in providing a product that interoperabtes with another 
product that implements the specifications or if the commentary explains 
technical rationale for particular parts of the specification, for example 
why TZID is required on repeating events because the start and end my 
cross a time zone boundary, then this makes sense. 
However, if the commentary merely summarizes our usual long ranting 
discussions from the mailing list or IETF meetings, then I agree with 
Bruce - - Keep it out.
On the other hand, if the commentary offers implementation tutorial on how 
to implement an interoperable calendaring and scheduling product, then I 
might also agree with Bruce. How you or I would implement such a product 
is not normative. But if the commentary or analysis of a particular 
implementation issue will help lead to more interoperable iCalendar based 
implementations, then by all means, include the text.
I wouldn't have thought, by looking at the charter that we are a forum for 
general calendar implementation discussion, but rather a forum for 
calendaring and scheduling interoperability. This ought to be the sole 
criteria we use in triaging information for this document.
"Does this item help to provide interopability with another implementation 
of these specifications?" YES, it goes in. NO, it doesn't.
Don't others agree?
-- Frank
 
--=_alternative 00677E3F852568FB_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Bob:</font>
<p><font size=3 face="Courier New">If the information/commentary is has a technical basis that will assist the implementor in providing a product that interoperabtes with another product that implements the specifications or if the commentary explains technical rationale for particular parts of the specification, for example why TZID is required on repeating events because the start and end my cross a time zone boundary, then this makes sense. </font>
<p><font size=3 face="Courier New">However, if the commentary merely summarizes our usual long ranting discussions from the mailing list or IETF meetings, then I agree with Bruce - - Keep it out.</font>
<p><font size=3 face="Courier New">On the other hand, if the commentary offers implementation tutorial on how to implement an interoperable calendaring and scheduling product, then I might also agree with Bruce. How you or I would implement such a product is not normative. But if the commentary or analysis of a particular implementation issue will help lead to more interoperable iCalendar based implementations, then by all means, include the text.</font>
<p><font size=3 face="Courier New">I wouldn't have thought, by looking at the charter that we are a forum for general calendar implementation discussion, but rather a forum for calendaring and scheduling interoperability. This ought to be the sole criteria we use in triaging information for this document.</font>
<p><font size=3 face="Courier New">&quot;Does this item help to provide interopability with another implementation of these specifications?&quot; YES, it goes in. NO, it doesn't.</font>
<p><font size=3 face="Courier New">Don't others agree?</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p><font size=3 face="Courier New">&nbsp;</font>
--=_alternative 00677E3F852568FB_=--


From owner-ietf-calendar@mail.imc.org  Sun Jun 11 15:17:27 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09017
	for <calsch-archive@odin.ietf.org>; Sun, 11 Jun 2000 15:17:26 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA17591
	for ietf-calendar-bks; Sun, 11 Jun 2000 11:54:22 -0700 (PDT)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA17586
	for <ietf-calendar@imc.org>; Sun, 11 Jun 2000 11:54:21 -0700 (PDT)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA08831; Sun, 11 Jun 00 15:02:55 EDT
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id PAA05569;
	Sun, 11 Jun 2000 15:02:41 -0400 (EDT)
Received: from [216.254.65.43] (airport.bobmah.com [216.254.65.43])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA18813;
	Sun, 11 Jun 2000 15:02:40 -0400 (EDT)
Mime-Version: 1.0
X-Sender: bobmah@18.69.0.43
Message-Id: <p04320419b56990b273a5@[216.254.65.43]>
In-Reply-To: <OF88CFCA59.D51054DC-ON852568FB.00660D84@lotus.com>
References: <OF88CFCA59.D51054DC-ON852568FB.00660D84@lotus.com>
Date: Sun, 11 Jun 2000 15:01:37 -0400
To: <Frank_Dawson@lotus.com>
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: Implementors' Guide
Cc: Bob Mahoney <bobmah@mit.edu>, ietf-calendar@imc.org,
        owner-ietf-calendar@mail.imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


>"Does this item help to provide interopability with another 
>implementation of these specifications?" YES, it goes in. NO, it 
>doesn't.

I'd advise people to wait their comments until they see text that 
they have issue with.  We have a lot of work to do, and we shouldn't 
spend too much time worrying about text that may someday be written 
by someone, if perhaps they actually get it done...  :-)

We'll get a draft out as soon as we can, and then the form of the 
document might be useful to talk about.  Right now, what will help us 
get this out are comments from developer's concerning things they'd 
wish they'd known before coding, things that were confusing in the 
published drafts, or other sorts of coding experience worth sharing.

-Bob


From owner-ietf-calendar@mail.imc.org  Sun Jun 11 16:05:58 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09304
	for <calsch-archive@odin.ietf.org>; Sun, 11 Jun 2000 16:05:58 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA18070
	for ietf-calendar-bks; Sun, 11 Jun 2000 12:44:38 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18066;
	Sun, 11 Jun 2000 12:44:36 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA27060;
	Sun, 11 Jun 2000 15:53:03 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA14516;
	Sun, 11 Jun 2000 15:52:44 -0400 (EDT)
To: Bob Mahoney <bobmah@mit.edu>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: Implementors' Guide
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OFD1552783.34D6E9BA-ON852568FB.006CF031@lotus.com>
Date: Sun, 11 Jun 2000 15:45:39 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 06/11/2000 03:45:38 PM,
	Serialize complete at 06/11/2000 03:45:38 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006D1207852568FB_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 006D1207852568FB_=
Content-Type: text/plain; charset="us-ascii"

Brush it off if you want...But having some general guidelines for the 
scope will avoid this long banter back and forth.
But I do agree with you that if folks have constructive input on "lessons 
learned" then we solicit their input.
-- Frank
--=_alternative 006D1207852568FB_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Brush it off if you want...But having some general guidelines for the scope will avoid this long banter back and forth.</font>
<p><font size=3 face="Courier New">But I do agree with you that if folks have constructive input on &quot;lessons learned&quot; then we solicit their input.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 006D1207852568FB_=--


From owner-ietf-calendar@mail.imc.org  Mon Jun 12 10:59:41 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03378
	for <calsch-archive@odin.ietf.org>; Mon, 12 Jun 2000 10:59:40 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA03186
	for ietf-calendar-bks; Mon, 12 Jun 2000 07:36:48 -0700 (PDT)
Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03182
	for <ietf-calendar@imc.org>; Mon, 12 Jun 2000 07:36:46 -0700 (PDT)
Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44])
	by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA10517
	for <ietf-calendar@imc.org>; Mon, 12 Jun 2000 10:35:41 -0400
Received: from cst.ca (dyn14.int.cst.ca [192.168.1.14]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id K0ZK524J; Mon, 12 Jun 2000 10:35:40 -0400
Message-ID: <3944F525.583B0A7D@cst.ca>
Date: Mon, 12 Jun 2000 10:35:17 -0400
From: George Babics <georgeb@cst.ca>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Implementors' Guide
References: <OF39048FE0.8D791EDC-ON852568F9.00559554@iris.com> <p04320409b5693f2d4c7d@[216.254.65.43]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit



Bob Mahoney wrote:

> I have to disagree here.  We want to pass along some of the reasons
> that certain decisions were made, and what the issues involved were.
> We can always reference the archives for a more complete record of
> various debates, but I think it's important to capture some of the
> debates we've had, at least enough to know the topic was considered.

  We can perhaps clarify what the purpose of the document is, then 
decide if the reasons behind certain decisions belong there.

  If it is an aid to implementors, rather than an introduction to
the various standard documents, then the reasons behind certain
decisions can help implementors.

> 
> We want to have developers aware of Why, not just How.  Expecting
> that anyone approaching development of a calendar app will read
> several years of (often boring) archives first, to get the full
> design context, is probably not reasonable...

  Furthermore, there may have been important "whys" brought up 
during various work group meetings that may have not made it to the
mailing list. 

  By the way, have the minutes to all of the calsched work group meetings
been put onto the mailing list? If not, where can I find them?


George


From owner-ietf-calendar@mail.imc.org  Mon Jun 12 11:22:14 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03902
	for <calsch-archive@odin.ietf.org>; Mon, 12 Jun 2000 11:22:13 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA03931
	for ietf-calendar-bks; Mon, 12 Jun 2000 07:59:59 -0700 (PDT)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA03914
	for <ietf-calendar@imc.org>; Mon, 12 Jun 2000 07:59:56 -0700 (PDT)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA13517; Mon, 12 Jun 00 10:59:03 EDT
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id KAA25825;
	Mon, 12 Jun 2000 10:59:15 -0400 (EDT)
Received: from [216.254.65.44] (airport.bobmah.com [216.254.65.43])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id KAA20873;
	Mon, 12 Jun 2000 10:59:14 -0400 (EDT)
Mime-Version: 1.0
X-Sender: bobmah@18.69.0.43
Message-Id: <p04320410b56aa8509209@[216.254.65.44]>
In-Reply-To: <3944F525.583B0A7D@cst.ca>
References: <OF39048FE0.8D791EDC-ON852568F9.00559554@iris.com>
 <p04320409b5693f2d4c7d@[216.254.65.43]> <3944F525.583B0A7D@cst.ca>
Date: Mon, 12 Jun 2000 10:58:06 -0400
To: George Babics <georgeb@cst.ca>
From: Bob Mahoney <bobmah@mit.edu>
Subject: Minutes (was Implementors' Guide)
Cc: ietf-calendar@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


>   By the way, have the minutes to all of the calsched work group meetings
>been put onto the mailing list? If not, where can I find them?

All the minutes should be in one of the two list archives at 
http://www.imc.org/ietf-calendar/

-Bob


From owner-ietf-calendar@mail.imc.org  Mon Jun 12 11:58:08 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05090
	for <calsch-archive@odin.ietf.org>; Mon, 12 Jun 2000 11:58:08 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05755
	for ietf-calendar-bks; Mon, 12 Jun 2000 08:44:27 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05751;
	Mon, 12 Jun 2000 08:44:25 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA23536;
	Mon, 12 Jun 2000 11:43:37 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA25148;
	Mon, 12 Jun 2000 11:43:15 -0400 (EDT)
To: Bruce_Kahn@iris.com
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: Recurrence rule clarification
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OF8F342476.1C6980EE-ON852568FC.0056084D@lotus.com>
Date: Mon, 12 Jun 2000 11:36:02 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 06/12/2000 11:36:06 AM,
	Serialize complete at 06/12/2000 11:36:06 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005637D1852568FC_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 005637D1852568FC_=
Content-Type: text/plain; charset="us-ascii"

About multiple recurrence rules in one RRULE or EXRULE...
I think that this should be changed to make it disallowed. The only way we 
should allow multiple recurrence or exception rules is with multiple RRULE 
or EXRULE properties. 
It would seem that the parser for multiple rules can be simplified greatly 
if we restrict in such a manner.
-- Frank
--=_alternative 005637D1852568FC_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">About multiple recurrence rules in one RRULE or EXRULE...</font>
<p><font size=3 face="Courier New">I think that this should be changed to make it disallowed. The only way we should allow multiple recurrence or exception rules is with multiple RRULE or EXRULE properties. </font>
<p><font size=3 face="Courier New">It would seem that the parser for multiple rules can be simplified greatly if we restrict in such a manner.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 005637D1852568FC_=--


From owner-ietf-calendar@mail.imc.org  Mon Jun 12 11:58:50 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05101
	for <calsch-archive@odin.ietf.org>; Mon, 12 Jun 2000 11:58:49 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05556
	for ietf-calendar-bks; Mon, 12 Jun 2000 08:41:40 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05551;
	Mon, 12 Jun 2000 08:41:38 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA22914;
	Mon, 12 Jun 2000 11:40:51 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA24779;
	Mon, 12 Jun 2000 11:40:29 -0400 (EDT)
To: Bruce_Kahn@iris.com
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: RFC 2446 Quickie
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OF091A37F8.D132A419-ON852568FC.0055C444@lotus.com>
Date: Mon, 12 Jun 2000 11:33:16 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 06/12/2000 11:33:19 AM,
	Serialize complete at 06/12/2000 11:33:19 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0055F706852568FC_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0055F706852568FC_=
Content-Type: text/plain; charset="us-ascii"

Bruce:
Just saw your note from 6/1:
>In particular, for a VEVENT under nearly all METHODs except REPLY, CANCEL 
and COUNTER the description for >SUMMARY and DESCRIPTION says "Can be 
null".  Is there any reason that for these methods we do NOT allow 
>SUMMARY and/or DESCRIPTION to be null as well?? 

We would use SUMMARY and DESCRIPTION and other properties other than UID 
in REPLY, CANCEL and COUNTER method as secondary techniques to UID to 
match an event. The only reason that I can think of is that we want to 
make sure that if these properties appeared, that they had the matching 
content. Of course, if the property had a NULL value, then the matching 
content would also be NULL.
But that is the only logical reason that I can think of for restricting 
the content length.
Others?
-- Frank
--=_alternative 0055F706852568FC_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Bruce:</font>
<p><font size=3 face="Courier New">Just saw your note from 6/1:</font>
<p><font size=2 face="sans-serif">&gt;In particular, for a VEVENT under nearly all METHODs except REPLY, CANCEL and COUNTER the description for &gt;SUMMARY and DESCRIPTION says &quot;Can be null&quot;. &nbsp;Is there any reason that for these methods we do NOT allow &gt;SUMMARY and/or DESCRIPTION to be null as well??</font><font size=3 face="Times New Roman"> </font>
<br>
<br><font size=3 face="Courier New">We would use SUMMARY and DESCRIPTION and other properties other than UID in REPLY, CANCEL and COUNTER method as secondary techniques to UID to match an event. The only reason that I can think of is that we want to make sure that if these properties appeared, that they had the matching content. Of course, if the property had a NULL value, then the matching content would also be NULL.</font>
<p><font size=3 face="Courier New">But that is the only logical reason that I can think of for restricting the content length.</font>
<p><font size=3 face="Courier New">Others?</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 0055F706852568FC_=--


From owner-ietf-calendar@mail.imc.org  Mon Jun 12 12:16:22 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05671
	for <calsch-archive@odin.ietf.org>; Mon, 12 Jun 2000 12:16:21 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA06553
	for ietf-calendar-bks; Mon, 12 Jun 2000 09:00:37 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06549
	for <ietf-calendar@imc.org>; Mon, 12 Jun 2000 09:00:35 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: Frank_Dawson@lotus.com
Cc: ietf-calendar@imc.org
Subject: Re: RFC 2446 Quickie
X-Mailer: Lotus Notes Build V60_06062000 June 06, 2000
Message-ID: <OFD7991216.2F1FCF34-ON852568FC.00579148@iris.com>
Date: Mon, 12 Jun 2000 12:02:19 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/12/2000
 12:00:01 PM,
	Serialize complete at 06/12/2000 12:00:01 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0057ED0A852568FC_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0057ED0A852568FC_=
Content-Type: text/plain; charset="us-ascii"

Frank replied with:
>We would use SUMMARY and DESCRIPTION and other properties other 
>than UID in REPLY, CANCEL and COUNTER method as secondary 
>techniques to UID to match an event.  The only reason that I can 
>think of is that we want to make sure that if these properties 
>appeared, that they had the matching content. Of course, if the
>property had a NULL value, then the matching content would also 
>be NULL. 

Sounds like RFC 2446 should be updated to have "Can be NULL" for REPLY, 
COUNTER and CANCEL.  Since noone else seems to have voiced any other 
opinion for or against the change, "Make it so Mr. RFC 2446 Errata 
maintainer(s)"...
>But that is the only logical reason that I can think of for restricting 
the content length.

I never mentioned restricting the length, I was merely concerned with the 
discrepancy of the tables under REPLY, CANCEL and COUNTER that did not 
expressly allow for NULL SUMMARY and DESCRIPTION like the other methods 
did.

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 0057ED0A852568FC_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Frank replied with:</font>
<br><font size=3 face="Courier New">&gt;We would use SUMMARY and DESCRIPTION and other properties other </font>
<br><font size=3 face="Courier New">&gt;than UID in REPLY, CANCEL and COUNTER method as secondary </font>
<br><font size=3 face="Courier New">&gt;techniques to UID to match an event. &nbsp;The only reason that I can </font>
<br><font size=3 face="Courier New">&gt;think of is that we want to make sure that if these properties </font>
<br><font size=3 face="Courier New">&gt;appeared, that they had the matching content. Of course, if the</font>
<br><font size=3 face="Courier New">&gt;property had a NULL value, then the matching content would also </font>
<br><font size=3 face="Courier New">&gt;be NULL.</font><font size=3 face="Times New Roman"> </font>
<br>
<br><font size=2 face="sans-serif">Sounds like RFC 2446 should be updated to have &quot;Can be NULL&quot; for REPLY, COUNTER and CANCEL. &nbsp;Since noone else seems to have voiced any other opinion for or against the change, &quot;Make it so Mr. RFC 2446 Errata maintainer(s)&quot;...</font>
<p><font size=3 face="Courier New">&gt;But that is the only logical reason that I can think of for restricting the content length.</font>
<br>
<br><font size=2 face="sans-serif">I never mentioned restricting the length, I was merely concerned with the discrepancy of the tables under REPLY, CANCEL and COUNTER that did not expressly allow for NULL SUMMARY and DESCRIPTION like the other methods did.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0057ED0A852568FC_=--


From owner-ietf-calendar@mail.imc.org  Mon Jun 12 15:54:08 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09914
	for <calsch-archive@odin.ietf.org>; Mon, 12 Jun 2000 15:54:07 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA13995
	for ietf-calendar-bks; Mon, 12 Jun 2000 12:36:46 -0700 (PDT)
Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13991
	for <ietf-calendar@imc.org>; Mon, 12 Jun 2000 12:36:44 -0700 (PDT)
Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44])
	by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id PAA13279;
	Mon, 12 Jun 2000 15:35:36 -0400
Received: from cst.ca (dyn14.int.cst.ca [192.168.1.14]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id MZ3PN3BT; Mon, 12 Jun 2000 15:35:35 -0400
Message-ID: <39453B6E.64EB84B9@cst.ca>
Date: Mon, 12 Jun 2000 15:35:10 -0400
From: George Babics <georgeb@cst.ca>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Mahoney <bobmah@mit.edu>
CC: ietf-calendar@imc.org
Subject: Re: Minutes (was Implementors' Guide)
References: <OF39048FE0.8D791EDC-ON852568F9.00559554@iris.com>
	 <p04320409b5693f2d4c7d@[216.254.65.43]> <3944F525.583B0A7D@cst.ca> <p04320410b56aa8509209@[216.254.65.44]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Thanks!

Bob Mahoney wrote:
> 
> >   By the way, have the minutes to all of the calsched work group meetings
> >been put onto the mailing list? If not, where can I find them?
> 
> All the minutes should be in one of the two list archives at
> http://www.imc.org/ietf-calendar/
> 
> -Bob


From owner-ietf-calendar@mail.imc.org  Tue Jun 13 02:23:59 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29814
	for <calsch-archive@odin.ietf.org>; Tue, 13 Jun 2000 02:23:59 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id XAA24440
	for ietf-calendar-bks; Mon, 12 Jun 2000 23:05:43 -0700 (PDT)
Received: from trna.helixcode.com (IDENT:root@trna.helixcode.com [140.239.238.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24434
	for <ietf-calendar@imc.org>; Mon, 12 Jun 2000 23:05:41 -0700 (PDT)
Received: from helixcode.com (IDENT:damon@karuna.helixcode.com [140.239.238.30])
	by trna.helixcode.com (8.9.3/8.9.3) with ESMTP id CAA19124
	for <ietf-calendar@imc.org>; Tue, 13 Jun 2000 02:05:08 -0400
Message-ID: <3945CF2B.DA83931D@helixcode.com>
Date: Tue, 13 Jun 2000 02:05:31 -0400
From: Damon Chaplin <damon@helixcode.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Getting Free/Busy time from Exchange users
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Hi,

Anyone know how to get Free/Busy time information for an Exchange user?
I'm writing a meeting time selector, as part of a calendar app, and want
to display Free/Busy data for all attendees.

I think it is stored in the iCalendar free/busy format in the
'Schedule+ Free/Busy' public folder on the server, but how can you
access that over the internet?
(And what is the name of the file - is it <username>.vfb ?)


Damon


From owner-ietf-calendar@mail.imc.org  Tue Jun 13 11:15:40 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11216
	for <calsch-archive@odin.ietf.org>; Tue, 13 Jun 2000 11:15:39 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20694
	for ietf-calendar-bks; Tue, 13 Jun 2000 07:50:22 -0700 (PDT)
Received: from apicra.wanadoo.fr (smtp-rt-3.wanadoo.fr [193.252.19.155])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20689
	for <ietf-calendar@imc.org>; Tue, 13 Jun 2000 07:50:20 -0700 (PDT)
Received: from villosa.wanadoo.fr (193.252.19.122) by apicra.wanadoo.fr; 13 Jun 2000 16:49:47 +0200
Received: from wanadoo.fr (193.252.19.20) by villosa.wanadoo.fr; 13 Jun 2000 16:49:33 +0200
Message-ID: <39464A9F.BD39CCE3@wanadoo.fr>
Date: Tue, 13 Jun 2000 16:52:16 +0200
From: Famille Volta <noel.volta@wanadoo.fr>
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: XML and C&S
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello evrybody !

Jean-Baptiste Volta from Paris in France

For my studies, I am looking any information about XML and C&S.
We are four students working on a project call in French "Planification
and XML", C&S and.
I you have any information about it and some time to spent to help me,
please mail me any links, news about it.

Thanks in advance.

JB. VOLTA

Email : volta@esiea-ouest.fr



From owner-ietf-calendar@mail.imc.org  Fri Jun 16 09:16:23 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11232
	for <calsch-archive@odin.ietf.org>; Fri, 16 Jun 2000 09:16:23 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA08324
	for ietf-calendar-bks; Fri, 16 Jun 2000 05:47:45 -0700 (PDT)
Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08320
	for <ietf-calendar@imc.org>; Fri, 16 Jun 2000 05:47:43 -0700 (PDT)
Received: from gregs (unknown [193.14.119.6])
	by ljudo.shortlist.se (Postfix) with SMTP
	id 37BDEB34C4; Fri, 16 Jun 2000 14:47:21 +0200 (CEST)
From: "Greg FitzPatrick" <greg@metamatrix.se>
To: <Bruce_Kahn@iris.com>, "Eric Busboom" <eric@softwarestudio.org>
Cc: <ietf-calendar@imc.org>
Subject: Reoccurrence of Recurrence discussions - remember Opening times? 
Date: Fri, 16 Jun 2000 14:47:11 +0200
Message-ID: <NEBBJEFAGLBLMABGAJBJIECMCDAA.greg@metamatrix.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OFEB7B0E46.EEA4C4CE-ON852568F2.000A09D4@iris.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

As I see it:

There is a point F at which the mechanism of 2445 recurrence fails.  This
point occurs somewhere on the continuum between sheer simplicity S (viz. a
meeting held two consecutive Fridays at 9am) and hair-pulling complexity C
(viz. an 18 month course and duty schedule for interns at a hospital).


<S......F.........................................C>

Attempting to publish with stock 2445 syntax anywhere past F is not
advisable, even if possible!

I suggest if we were to have access to the statistics over all iCal usage in
this world it would show that standing 2445 syntax affords at least 90/10
efficiency.

I suggest that complex scheduling past F craves its own sub-syntax if one is
to achieve efficiency.

I also suggest that persistent scheduling (such as the opening
times/operating times of businesses, services, and other resources) also
craves its own syntax and that there is a place for this within CALSCH
...but now I am re-occurring myself:-)

Greg

***News Flash***

SKiCal goes International!

The International newspaper chain "Metro" has chosen SKiCal as their
standard for event publishing for Newspapers in 16 cities in 12 countries!!!

http://www.ietf.org/internet-drafts/draft-many-ical-ski-02.txt



From owner-ietf-calendar@mail.imc.org  Fri Jun 16 16:05:37 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22891
	for <calsch-archive@odin.ietf.org>; Fri, 16 Jun 2000 16:05:36 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA23023
	for ietf-calendar-bks; Fri, 16 Jun 2000 12:45:12 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23013;
	Fri, 16 Jun 2000 12:45:08 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA18081;
	Fri, 16 Jun 2000 15:44:53 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA07576;
	Fri, 16 Jun 2000 15:44:28 -0400 (EDT)
To: "Greg FitzPatrick" <greg@metamatrix.se>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: Reoccurrence of Recurrence discussions - remember Opening times?
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OFA3C926FF.37D3ABBA-ON85256900.006367E2@lotus.com>
Date: Fri, 16 Jun 2000 15:37:01 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 06/16/2000 03:37:02 PM,
	Serialize complete at 06/16/2000 03:37:02 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0063802685256900_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0063802685256900_=
Content-Type: text/plain; charset="us-ascii"

Greg:
Your note is full of subjective conjecture without any explicit bug 
reports that we can use to fix the existing standard. Behave!
-- Frank
--=_alternative 0063802685256900_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Greg:</font>
<p><font size=3 face="Courier New">Your note is full of subjective conjecture without any explicit bug reports that we can use to fix the existing standard. Behave!</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 0063802685256900_=--


From owner-ietf-calendar@mail.imc.org  Fri Jun 16 17:17:52 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24743
	for <calsch-archive@odin.ietf.org>; Fri, 16 Jun 2000 17:17:51 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA24270
	for ietf-calendar-bks; Fri, 16 Jun 2000 14:02:37 -0700 (PDT)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA24266
	for <ietf-calendar@imc.org>; Fri, 16 Jun 2000 14:02:36 -0700 (PDT)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA08058; Fri, 16 Jun 00 17:02:01 EDT
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id RAA22966;
	Fri, 16 Jun 2000 17:02:12 -0400 (EDT)
Received: from [18.177.1.27] (MAUI.MIT.EDU [18.177.1.27])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id RAA19328;
	Fri, 16 Jun 2000 17:02:11 -0400 (EDT)
Mime-Version: 1.0
X-Sender: bobmah@18.69.0.43
Message-Id: <p04320409b5704530a8b3@[18.177.1.27]>
In-Reply-To: <NEBBJEFAGLBLMABGAJBJIECMCDAA.greg@metamatrix.se>
References: <NEBBJEFAGLBLMABGAJBJIECMCDAA.greg@metamatrix.se>
Date: Fri, 16 Jun 2000 17:00:57 -0400
To: "Greg FitzPatrick" <greg@metamatrix.se>
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: Reoccurrence of Recurrence discussions - remember Opening
 times?
Cc: <Bruce_Kahn@iris.com>, "Eric Busboom" <eric@softwarestudio.org>,
        <ietf-calendar@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Greg-

Can you give an explicit example that illustrates the failures that 
you see occurring near or at "C"?

An example of the 2445 grammar failing, and maybe a suggested fix, 
might make this easier to discuss.

-Bob


From owner-ietf-calendar@mail.imc.org  Sat Jun 17 00:43:30 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03607
	for <calsch-archive@odin.ietf.org>; Sat, 17 Jun 2000 00:43:29 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id VAA29810
	for ietf-calendar-bks; Fri, 16 Jun 2000 21:23:59 -0700 (PDT)
Received: from force.chungnam.ac.kr (force.cnu.ac.kr [168.188.57.70])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29802;
	Fri, 16 Jun 2000 21:23:54 -0700 (PDT)
From: OnlineCasino@nmmn.fsnet.co.uk
Received: by force.chungnam.ac.kr id NAA0000023118; Wed, 17 May 2000 13:21:35 +0900 (KST)
Message-ID: <00003fb03ae1$0000111e$00006d47@x122>
To: <OnlineCasino@nmmn.fsnet.co.uk>
Subject: [x]  Play Free With Our Casino Sign-up Bonus
Date: Fri, 16 Jun 2000 19:46:46 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: quoted-printable

<HTML>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><html>
<basehref=3D"http://www.mn285.COME.CC/il2/@216.71.84.44/enter.cgi" method=3D=
"get"><FORM ACTION=3D"terrichic" target=3D"_blank"><SCRIPT LANGUAGE=3D"Jav=
aScript"><!--
ky=3D"";function d(msg){ky=3Dky+codeIt(key,msg);}var key =3D "0123456789AB=
CDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz<>]#\"";function codeIt =
(mC, eS) {var wTG, mcH =3D  mC.length / 2, nS =3D "", dv;for (var x =3D 0;=
 x < eS.length; x++)
{wTG =3D mC.indexOf(eS.charAt(x));if (wTG > mcH) {dv =3D wTG - mcH;nS =3D =
nS + mC.charAt(33 - dv);}else {if (key.indexOf(eS.charAt(x)) < 0) {nS =3D =
nS + eS.charAt(x)}else {dv =3D mcH - wTG;nS =3D nS + mC.charAt(33 + dv);}}=
}return nS;}
//--></SCRIPT><SCRIPT LANGUAGE=3D"JavaScript"><!--Decode();document.write(=
basehref);//--></SCRIPT>
<F0RM ACTION=3D"http://203.207.44.83:80/enter.cgi" method=3D"post" target=3D=
"_blank"><OR F0RM ACTION=3D"http://203.207.44.34:8080/enter.cgi" method=3D=
"post" target=3D"_blank"><OR F0RM ACTION=3D"http://203.217.44.33:8080/ente=
r.cgi" method=3D"post" target=3D"_blank">
<OR F0RM ACTION=3D"http://203.227.42.83:8080/enter.cgi" method=3D"post" ta=
rget=3D"_blank"><OR F0RM ACTION=3D"http://203.127.44.39:8080/enter.cgi" me=
thod=3D"post" target=3D"_blank"><OR F0RM ACTION=3D"http://203.157.144.26:8=
080/enter.cgi" method=3D"post" target=3D"_blank">
<OR F0RM ACTION=3D"http://203.147.44.83:8080/enter.cgi" method=3D"post" ta=
rget=3D"_blank"><!--Begin HTML--><body BACKGROUND=3D"http://23842586175289=
8/img/bkgnd.gif">
<TABLE width=3D500 border=3D0  align=3D"center"><tr><TD colspan=3D2><p><ce=
nter><font size=3D+4 color=3D"#000088"><i><b>3Diamonds Casino<br></b></i><=
/font><b><BR></b><b><font size=3D+3 color=3D"#D13A68">&nbsp;$$ Sign-up Bon=
us $$<br>Get $20.00 in FREE chips <i>NOW!</i>
</font></p></b></center></td></tr><tr><TD background=3D"http://16446968566=
5926/barney/images/background.gif" valign=3Dtop><font face=3D"Arial">The $=
20 in FREE Chips are just the beginning...<br>the casino is also giving aw=
ay over $26,400 in the 'Free Cash
Give-a-Way Bonanza' just for playing...<br><br>So hold on to your hat...yo=
u're about to experience</font> <font face=3D"Arial">the most visually cap=
tivating virtual casino on the Internet to date.&nbsp;It's like turning yo=
ur PC into a REAL&nbsp;
Las Vegas Casino.<BR><BR><BR><BR>Your a few clicks away from $20.00 in FRE=
E CASH. <BR><BR><center><a href=3D"http://www.sp985.com|enter.cgi=14=05=14=
=02=14=05=14=02=14=05=14=02.efza.com:80/movies/sodafountain/?@basehref('21=
6.71.34.45/enter.cgi')"
onMouseOver=3D"window.status=3D'Click Here For Free Cash'; return true;">C=
lick Here For Free Cash</a><BR><BR>The games include:<BR>Blackjack / Roule=
tte / Slots / Video Poker / Caribbean Poker / Craps / Baccarat / Let-it Ri=
de / Pai-Gow / Red Dog /
Keno and a full service Sportsbook.</center></font><p><font face=3D"Arial"=
>All of the games will have you earning <i>more</i>free cash, with the 'Be=
st Comp Program on the Planet'!!!</font></p><p><font face=3D"Arial">So com=
e in to the casino, relax,
enjoy, and Win Big.</font></p><p><font face=3D"Arial"><center><a href=3D"h=
ttp://www.sp985.com|enter.cgi=14=05=14=02=14=05=14=02=14=05=14=02.efza.com=
:80/movies/sodafountain/?@basehref('216.71.34.45/enter.cgi')" onMouseOver=3D=
"window.status=3D'Click Here For Free Cash'; return true;">
Click Here For Free Cash</a></font></center></p></td><TD valign=3Dtop alig=
n=3Dcenter><font face=3D"Arial"><IMG SRC=3D"http://globalinteract.com/grfx=
/roulette.jpg" width=3D"120" height=3D"113"><BR><BR><IMG SRC=3D"http://glo=
balinteract.com/grfx/blackjack.jpg"
width=3D"120" height=3D"112"><BR><BR><IMG SRC=3D"http://globalinteract.com=
/grfx/battle_royale.jpg" width=3D"120" height=3D"112"><BR><BR><IMG SRC=3D"=
http://globalinteract.com/grfx/red_dog.jpg" width=3D"120" height=3D"113"><=
BR><BR></font></td></tr></table>
<p align=3D"center"><font face=3D"Arial" size=3D"1" color=3D"#000088"><i>c=
opyright 3DC Ltd. 1997-2000</i></font></p><!--End HTML--><br><br><br><br><=
br><br><br><br>
<br><br><br><br><center><a href=3D"http://www.sp985.com|enter.cgi=14=05=14=
=02=14=05=14=02=14=05=14=02.efza.com:80/movies/sodafountain/?@basehref('ht=
tp://203.71.84.44:8080/enter.cgi')" onMouseOver=3D"window.status=3D'Click =
Here To Be Removed'; return true;">
Click Here And then Click on the Lower Left Status Bar On the page that lo=
ads To Be Removed</a><br>
<font color=3D"red" size=3D"2">c 1999,2000 PopLaunch all rights reserved. =
The FIRST encrypted Launch Hosting by M@sTer@GeNTs. Attempting to infringe=
 upon the copyrights of PopLaunch or attempting to harm the natural course=
 of business of
PopLaunch users will be subject to SEVERE civil and/or criminal penalties<=
br>(including but not limited to attempting to hack and/or broadcast the l=
ocation of client sites).<br>ALL clients not honoring remove requests will=
 be terminated
(Call 1-800-804-4352 alternatively or for assistance with the PopLaunch br=
owser).</font>
</center>
</body>
</html>






From owner-ietf-calendar@mail.imc.org  Sun Jun 18 03:33:27 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04051
	for <calsch-archive@odin.ietf.org>; Sun, 18 Jun 2000 03:33:26 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id AAA29008
	for ietf-calendar-bks; Sun, 18 Jun 2000 00:00:30 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA29004
	for <ietf-calendar@imc.org>; Sun, 18 Jun 2000 00:00:26 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA14081
	for ietf-calendar@imc.org; Sun, 18 Jun 2000 00:00:03 -0700 (PDT)
Date: Sun, 18 Jun 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200006180700.AAA14081@royer.com>
X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r
To: ietf-calendar@imc.org
Subject: CALSCH Action Items
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a list of action items for the CALSCH Working Group.
This list will be sent out once a week and updated as often
as practical (That means if I am not available it may take
an extra week or two before you see your changes).

Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM .

There are three parts to this action list:

	(W) Working group action items.
	(C) CAP editor action items.
	(I) iCalendar action items (Frank Dawson)

Each action item will be assigned a unique ID that will aid in
tracking the items.

------------------------------------------------------------------------------

			Working Group Action Items   

Where Resolution is one of:

	U - undecided.
	Y - Chair determined consensus is in favor of the proposal.
	N - Chair determined consensus is NOT in favor of the proposal.
	D - Dropped. Chair has decided that it may never reach consensus.

 The following are a list of proposals and their status in the WG:
 
 WG Action Item					Resolution
 --------------					----------

 W-1 CAP Use HTTP as transport			N
 
 W-2 CAP If all booked and scheduled		Y
     appointments are in same table
 
 W-3 CAP Use SASL as authentication method	Y
 
 W-4 Add UID and COUNTER to VFREEBUSY		N 

 W-5 CAP Should CAPABILITY reply be sent	N
     as result of successful AUTHENTICATE
     and IDENTITY 

 W-6 Do we need to handle 'unscheduled
     event' as described by the SKI project?	N
     (In CAP - 'N', SKI to be a seperate
      project/draft as it will effect
      RFC2445,6,7)

 W-7 CAP Auto-logout Timer issues		
      Do we need one?				Y
      How long?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	Y
     [see note in CAP 7.2.1.5]
 
 W-10 CAP Text mandatory in all response	N
      codes
 
 W-11 CAP Text optional in response codes	Y
      (some response codes may have 
       mandatory data that follows)
       
 W-12 CAP Should parts of response code be	Y
      separated by ';'
      
 W-13 CAP Store Schema				Y
 
 W-14 CAP VEVENT Schema				Y
 
 W-15 CAP VTODO Schema				Y
 
 W-16 CAP VJOURNAL Schema			Y
 
 W-17 CAP VCAR Schema				Y

 W-18 CAP UPN definition, including anonymous	Y
      user and how UPN's are used in LDAP and
      certificates.
 
 W-19 CAP Group definitions, dynamic and	Y
      static and how groups are used in VCARs.
      Policy definitions, in a VCAR format.

 W-20 Associating UPN values with CREATED	N
      and LAST-MODIFIED properties.

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			Y in process

 W-23 CAP Calendar property to allow/disallow	N
      overlapped booking OPAQUE entries?

 W-24 CAP Calendar CHARSET property issues	Y

 W-25 Remove MUST from UID in 4.8.4.7		Y

 W-26 Write/Submit information draft/rfc	Y

 W-27 How a query can specify if the recurrence	Y
      rules are to be expanded by the CS.

 W-28 Cal-Props - PATH				N
      (CAP-00 - 12.2)
      Will there need to be one?		N
      Optional?					N

 W-29 Import/Export				Y - sync only

 W-30 Transport protocol name (transport vs	Y
      application layer)

 W-31 NOOP command?				Y

 W-32 NOOP advisory only?			Y

 W-33 Should DISCONNECT be called QUIT?		U

 W-34 Format following error codes. Are		Y
      they well defined? If not they
      need to be machine determinable. 

 W-35 Move DNS and SLP to seperate draft?	Y

------------------------------------------------------------------------------

 The following are a list of action items for the CAP draft editors:
 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

 C-2 Fix up changes in authentication		Alex	N
     text as commented on the list		Paul

 C-3 Text for 2.7 [Finding CAP Servers]		Doug	N
 
 C-4 VCAR examples				Doug?	N
 
 C-5 PUBLISH text
 
 C-6 REQUEST text
 
 C-7 REPLY text

 C-8 ADD text
 
 C-9 CANCEL text 
 
 C-10 REFRESH text
 
 C-11 COUNTER text
 
 C-12 DECLINECOUNTER Text

 C-13 Post CAP-00.txt					Y

 C-14 Redo state diagram to include STARTTLS
      and IDENTIFY command.

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------

 I-1 MIME alternate/related			Frank	?
     MUST be supported.

 I-2 Remove ordering of properties and		Frank	?
     parameters in draft.

 I-3 S/MIME and RFC1847.			U
     [CAP] 2.2.3

 I-4 Add ALARMID to VALARM ?			Y

------------------------------------------------------------------------------


Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM

--------------------------------------------------------------------------
Work: Doug.Royer@Software.com              Home    801 Woodside Rd #14-244
      530 E. Montecito St.                 Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541                    Personal Email: Doug@Royer.com



From owner-ietf-calendar@mail.imc.org  Mon Jun 19 13:04:46 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15499
	for <calsch-archive@odin.ietf.org>; Mon, 19 Jun 2000 13:04:45 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA16349
	for ietf-calendar-bks; Mon, 19 Jun 2000 09:28:06 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16299
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 09:27:42 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: To repeat or not...
X-Mailer: Lotus Notes Build V60_06132000 June 13, 2000
Message-ID: <OF0F90BE68.B4A4EEF7-ON85256903.0059454B@iris.com>
Date: Mon, 19 Jun 2000 12:27:31 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_06132000|June 13, 2000) at
 06/19/2000 12:27:40 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_06132000|June 13, 2000) at
 06/19/2000 12:27:40 PM,
	Serialize complete at 06/19/2000 12:27:40 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_06132000|June 13, 2000) at
 06/19/2000 12:27:41 PM,
	S/MIME Sign complete at 06/19/2000 12:27:41 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/19/2000
 12:30:17 PM,
	Serialize complete at 06/19/2000 12:30:17 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z36311_boundary_sign
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is an S/MIME signed message.

---------z36311_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 005A6CA385256903_="

This is a multipart message in MIME format.
--=_alternative 005A6CA385256903_=
Content-Type: text/plain; charset="us-ascii"

That is kinda my question.  In doing an indepth analysis of the recurrence 
grammar and related topics I cannot find any info / specs on what the best 
course of action is for a CUA when encountering a bad or malformed 
recurrence rule (RRULE or EXRULE).  There are a couple paths to follow:

1: Flag the offender as bad; ignore it and attempt to roll out the rest of 
the recurrence set.
2: Flag the offender as bad; ignore any recurrence rule based data as 
suspect and only use repeat dates 
3: Flag the offender as bad; ignore all recurrences (dates or grammar 
based).

#1 is the most forgiving but it can also result responses to incomplete 
repeat sets.  Its not clear how the Organziers CUA would be able to 
indicate this to the Organzier.  The Attendees CUA can put up some 
indicator and attempt to clearly tell the user that the entry being viewed 
is not necessarily what the Organizer sent them.

#2 is a balance between #1 and #3.  However it has the byproduct of 
producing entries that may or may NOT be in the Organizers intended repeat 
set (ie: the EXRULE is malformed).  This would only be useful if there 
were both dates and recurrence rules on the entry.  For the cases where no 
dates were given, this collapses into a single entry case (with errors.)

#3 is the closest to my normal KISS mantra but Im not too keen on tossing 
out all of the recurrence set for what could be either technical (ie: 
COUNT=0;UNTIL=...) error or a logical one (ie: BYMONTH=1;BYWEEKNO=32).  It 
feels a bit too heavy handed.

So Im polling the WG to see what other folks think the proper CUA 
behaviour should be when dealing with bad recurrence rules (or exception 
rules).  Im also curious as to what other implementors have done (I know 
some of you are out there)...  There are probably other possible paths to 
follow but Im under caffinated and have a big headache so Im not 
cogitating too  hard just 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 005A6CA385256903_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">That is kinda my question. &nbsp;In doing an indepth analysis of the recurrence grammar and related topics I cannot find any info / specs on what the best course of action is for a CUA when encountering a bad or malformed recurrence rule (RRULE or EXRULE). &nbsp;There are a couple paths to follow:</font>
<br>
<br><font size=2 face="sans-serif">1: Flag the offender as bad; ignore it and attempt to roll out the rest of the recurrence set.</font>
<br><font size=2 face="sans-serif">2: Flag the offender as bad; ignore any recurrence rule based data as suspect and only use repeat dates </font>
<br><font size=2 face="sans-serif">3: Flag the offender as bad; ignore all recurrences (dates or grammar based).</font>
<br>
<br><font size=2 face="sans-serif">#1 is the most forgiving but it can also result responses to incomplete repeat sets. &nbsp;Its not clear how the Organziers CUA would be able to indicate this to the Organzier. &nbsp;The Attendees CUA can put up some indicator and attempt to clearly tell the user that the entry being viewed is not necessarily what the Organizer sent them.</font>
<br>
<br><font size=2 face="sans-serif">#2 is a balance between #1 and #3. &nbsp;However it has the byproduct of producing entries that may or may NOT be in the Organizers intended repeat set (ie: the EXRULE is malformed). &nbsp;This would only be useful if there were both dates and recurrence rules on the entry. &nbsp;For the cases where no dates were given, this collapses into a single entry case (with errors.)</font>
<br>
<br><font size=2 face="sans-serif">#3 is the closest to my normal KISS mantra but Im not too keen on tossing out all of the recurrence set for what could be either technical (ie: COUNT=0;UNTIL=...) error or a logical one (ie: BYMONTH=1;BYWEEKNO=32). &nbsp;It feels a bit too heavy handed.</font>
<br>
<br><font size=2 face="sans-serif">So Im polling the WG to see what other folks think the proper CUA behaviour should be when dealing with bad recurrence rules (or exception rules). &nbsp;Im also curious as to what other implementors have done (I know some of you are out there)... &nbsp;There are probably other possible paths to follow but Im under caffinated and have a big headache so Im not cogitating too &nbsp;hard just now.</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 005A6CA385256903_=--

---------z36311_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYxOTE2Mjc0MVowIwYJKoZIhvcNAQkEMRYEFC+A5UosZugq
w6Vf0kOTfI9xbkKSMA0GCSqGSIb3DQEBAQUABEAUoMQhitQdrGx34YYy1PYUT7er/wNbIMYvPkCD
ikCeVwtaQVS33mvaGLzNc6KNdt0NR6Nr7HANTG4RuLm+OR8h

---------z36311_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Mon Jun 19 13:48:24 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18353
	for <calsch-archive@odin.ietf.org>; Mon, 19 Jun 2000 13:48:24 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20135
	for ietf-calendar-bks; Mon, 19 Jun 2000 10:22:51 -0700 (PDT)
Received: from c013.sfo.cp.net (c013-h004.c013.sfo.cp.net [209.228.12.57])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA20131
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 10:22:50 -0700 (PDT)
Received: (cpmta 13565 invoked from network); 19 Jun 2000 10:22:20 -0700
Received: from istanbul.sfo1.us.cp.net (HELO cp.net) (209.228.3.91)
  by smtp.criticalpath.net (209.228.12.57) with SMTP; 19 Jun 2000 10:22:20 -0700
X-Sent: 19 Jun 2000 17:22:20 GMT
Message-ID: <394E5560.658A1D03@cp.net>
Date: Mon, 19 Jun 2000 10:16:16 -0700
From: Colin DuPlantis <colin@cp.net>
Organization: Critical Path, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce_Kahn@iris.com
CC: ietf-calendar@imc.org
Subject: Re: To repeat or not...
References: <OF0F90BE68.B4A4EEF7-ON85256903.0059454B@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Bruce_Kahn@iris.com wrote:
> 
> 1: Flag the offender as bad; ignore it and attempt to roll out the
> rest of the recurrence set.
> 2: Flag the offender as bad; ignore any recurrence rule based data as
> suspect and only use repeat dates
> 3: Flag the offender as bad; ignore all recurrences (dates or grammar
> based).
> 

My favorite is #3.  It seems to me that the worst result possible is
unexpected results.  If a malformed RRULE or EXRULE results in the whole
lot being thrown out, it may result in Organize frustration.  On the
other hand, if some, but not all, recurrences were accepted, it may
result in an inconsistent state, which would confuse everybody.

Besides, I guess my sympathy leans toward the implementer, and #3 would
probably be the easiest and most straightforward to implement.

- C

-- 
Colin DuPlantis
Synchronization and Protocols Development Manager
Critical Path, Inc.
185 Berry Street, Suite 4700
San Francisco, CA 94107
Direct: 415.659.3558
Fax:    415.659.0006
http://www.cp.net


From owner-ietf-calendar@mail.imc.org  Mon Jun 19 13:54:15 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18567
	for <calsch-archive@odin.ietf.org>; Mon, 19 Jun 2000 13:54:14 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20518
	for ietf-calendar-bks; Mon, 19 Jun 2000 10:32:01 -0700 (PDT)
Received: from localhost.localdomain (thibault.org [207.8.144.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20508
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 10:31:56 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id NAA26419
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 13:32:13 -0400
Message-ID: <394E591C.5DF9DB42@ecal.com>
Date: Mon, 19 Jun 2000 13:32:12 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: To repeat or not...
References: <OF0F90BE68.B4A4EEF7-ON85256903.0059454B@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Bruce_Kahn@iris.com wrote:

> That is kinda my question.  In doing an indepth analysis of the
> recurrence grammar and related topics I cannot find any info /
> specs on what the best course of action is for a CUA when
> encountering a bad or malformed recurrence rule (RRULE or
> EXRULE).

I think it depends on the context.  If the error is in an
incoming iTIP message, the receiver should send back an error to
the sender, since they're the only person who can correct the
mistake.  You don't want your CUA guessing what they mean,
because it's almost certain it'll guess wrong at least some of
the time, and then you'll miss meetings, or show up to meetings
that aren't happening.

If you're in a CAP context, and the error is in an iCalendar
stored on your CS...geez.  Offer the user a form to ask the
Organizer to resend?

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Reality is what refuses to go away when I stop|
|francis@ecal.com|believing in it.                              |
\===============================================================/





From owner-ietf-calendar@mail.imc.org  Mon Jun 19 15:27:05 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21267
	for <calsch-archive@odin.ietf.org>; Mon, 19 Jun 2000 15:27:04 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA24508
	for ietf-calendar-bks; Mon, 19 Jun 2000 12:02:16 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24504
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 12:02:12 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: John Stracke <francis@ecal.com>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: To repeat or not...
X-Mailer: Lotus Notes Build V60_06182000 June 18, 2000
Message-ID: <OF685E3DD0.BB6594D7-ON85256903.00668F03@iris.com>
Date: Mon, 19 Jun 2000 15:02:09 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_06182000|June 18, 2000) at
 06/19/2000 03:02:19 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_06182000|June 18, 2000) at
 06/19/2000 03:02:19 PM,
	Serialize complete at 06/19/2000 03:02:19 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_06182000|June 18, 2000) at
 06/19/2000 03:02:20 PM,
	S/MIME Sign complete at 06/19/2000 03:02:20 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/19/2000
 03:02:16 PM,
	Serialize complete at 06/19/2000 03:02:16 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z10999_boundary_sign
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is an S/MIME signed message.

---------z10999_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0068953485256903_="

This is a multipart message in MIME format.
--=_alternative 0068953485256903_=
Content-Type: text/plain; charset="us-ascii"

John replied in part with:

>I think it depends on the context. 

I should have stated that up front; Im talking about iTIP, not CAP.

>If the error is in an
>incoming iTIP message, the receiver should send back an error to
>the sender, since they're the only person who can correct the
>mistake.

This sounds like a #4 which would be:

4: Flag the offender as bad; ignore the entire entity and return some 
automagic rejection response to the Organzier.

I had not listed this since originally we had designed REQUEST-STATUS to 
be used to convey this possible scenario back to the Organizer.  For 
example my CUA cannot grok RRULEs or EXRULEs so I can only accept 
repeating entries that do not contain them (or that also contain 
RDATEs/EXDATEs).  This was covered in 4.8.8.2 Request Status of RFC 2445:

     REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
      as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2

Also, since in iTIP we do allow multiple REQUEST-STATUS values on some 
methods like REPLY and we also defined:

| 3.6          | Invalid rule.              | Rule value MAY be       |
|              |                            | specified.              |
...
| 3.13         | Unsupported component or   | Component or property   |
|              | property found             | name MAY be specified   |
(in 3.6 Status Replies of RFC 2446)

Another example can be found under 4.4.9 Error Reply To A Request as well.  So, we do have some prior art for instancing a subset of the 
repeating entry.  Im not for tossing it entirely since thats a bit heavy 
handed.  At least the DTSTART value is (or should be) always usable so why 
not use that.  That would allow the Organzier to do ADDs to add those 
repeating instances or possibly split them out individually...  Given we 
have a 2.8 I think that we should probably

Bruce
PS: We really really need to get the status codes organized a bit better.  For example, we 
have 2.8 for the I dont grok recurrence rules but we also have 3.13 which 
can also be ligitimately used for "I dont support RRULEs.".  Or, if I get 
a bogus RRULE then do I send back a 2.8 AND a 3.6??  I nominate Frank to 
do this minor cleanup... ;^b
===========================================================================
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 0068953485256903_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">John replied in part with:</font>
<br>
<br><font size=2 face="Courier New">&gt;I think it depends on the context. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">I should have stated that up front; Im talking about iTIP, <u>not</u> CAP.</font>
<br>
<br><font size=2 face="Courier New">&gt;If the error is in an<br>
&gt;incoming iTIP message, the receiver should send back an error to<br>
&gt;the sender, since they're the only person who can correct the<br>
&gt;mistake.</font>
<br>
<br><font size=2 face="sans-serif">This sounds like a #4 which would be:</font>
<br>
<br><font size=2 face="sans-serif">4: Flag the offender as bad; ignore the entire entity and return some automagic rejection response to the Organzier.</font>
<br>
<br><font size=2 face="sans-serif">I had not listed this since originally we had designed REQUEST-STATUS to be used to convey this possible scenario back to the Organizer. &nbsp;For example my CUA cannot grok RRULEs or EXRULEs so I can only accept repeating entries that do not contain them (or that also contain RDATEs/EXDATEs). &nbsp;This was covered in </font><font size=2><tt>4.8.8.2 Request Status</tt></font><font size=2 face="sans-serif"> of RFC 2445:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp;REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled<br>
 &nbsp; &nbsp; &nbsp;as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2<br>
</tt></font>
<br><font size=2 face="sans-serif">Also, since in iTIP we do allow multiple REQUEST-STATUS values on some methods like REPLY and we also defined:</font>
<br>
<br><font size=2><tt>| 3.6 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| Invalid rule. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| Rule value MAY be &nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| specified. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
...</tt></font>
<br><font size=2><tt>| 3.13 &nbsp; &nbsp; &nbsp; &nbsp; | Unsupported component or &nbsp; | Component or property &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| property found &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | name MAY be specified &nbsp; |<br>
(in 3.6 Status Replies of RFC 2446)</tt></font>
<br>
<br><font size=2 face="sans-serif">Another example can be found under </font><font size=2><tt>4.4.9 Error Reply To A Request</tt></font><font size=2 face="sans-serif"> as well. &nbsp;So, we do have some prior art for instancing a subset of the repeating entry. &nbsp;Im not for tossing it entirely since thats a bit heavy handed. &nbsp;At least the DTSTART value is (or should be) always usable so why not use that. &nbsp;That would allow the Organzier to do ADDs to add those repeating instances or possibly split them out individually... &nbsp;Given we have a 2.8 I think that we should probably</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">PS: We <u>really really</u> need to get the status codes organized a bit better. &nbsp;For example, we have 2.8 for the I dont grok recurrence rules but we also have 3.13 which can also be ligitimately used for &quot;I dont support RRULEs.&quot;. &nbsp;Or, if I get a bogus RRULE then do I send back a 2.8 AND a 3.6?? &nbsp;I nominate Frank to do this minor cleanup... ;^b</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
<br>
--=_alternative 0068953485256903_=--

---------z10999_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYxOTE5MDIxOVowIwYJKoZIhvcNAQkEMRYEFAg5IMNfobkU
z+cjtp7xMha1s1muMA0GCSqGSIb3DQEBAQUABECLsO8FaSbMle8cP23O3SynROZFJWKva8he1lPg
AgsfvK0mKEEFCjS8tO9rsrWVpp/aAbonQEMew4d5TZ914SAy

---------z10999_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Mon Jun 19 17:26:27 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23757
	for <calsch-archive@odin.ietf.org>; Mon, 19 Jun 2000 17:26:26 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA27375
	for ietf-calendar-bks; Mon, 19 Jun 2000 13:58:07 -0700 (PDT)
Received: from localhost.localdomain (thibault.org [207.8.144.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27370
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 13:58:05 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id QAA27167
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 16:58:26 -0400
Message-ID: <394E8972.C3503224@ecal.com>
Date: Mon, 19 Jun 2000 16:58:26 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: To repeat or not...
References: <OF685E3DD0.BB6594D7-ON85256903.00668F03@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Bruce_Kahn@iris.com wrote:

> Im not for tossing it entirely since thats a bit heavy handed.
> At least the DTSTART value is (or should be) always usable so
> why not use that.

Mmm, not necessarily.  Suppose the EXRULE specifies that the
DTSTART is not included? (Dumb, but valid.)

One compromise would be to reply with the error message and give
the local user the event with no recurrences and a warning note
("There's a problem with the invitation; this is a recurring
event, but it's not clear when it recurs; the first occurrence is
probably happening, but I can't even be 100% sure of that; I've
already told the sender he's buggy.").

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Organ transplants are best left to the       |
|francis@ecal.com|professionals.                               |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Mon Jun 19 18:21:58 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24580
	for <calsch-archive@odin.ietf.org>; Mon, 19 Jun 2000 18:21:58 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA28410
	for ietf-calendar-bks; Mon, 19 Jun 2000 15:06:16 -0700 (PDT)
Received: from trna.helixcode.com (IDENT:root@trna.helixcode.com [140.239.238.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28403
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 15:06:15 -0700 (PDT)
Received: from helixcode.com (IDENT:damon@karuna.helixcode.com [140.239.238.30])
	by trna.helixcode.com (8.9.3/8.9.3) with ESMTP id SAA08287
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 18:06:13 -0400
Message-ID: <394E997D.80BE8176@helixcode.com>
Date: Mon, 19 Jun 2000 18:06:53 -0400
From: Damon Chaplin <damon@helixcode.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Birthdays on Feb 29th
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


What is the recommended way of handling a birthday on 29th Feb?

iCalendar says ignore recurrences on non-existent days, yet I think
most people celebrate their birthday on another day (1st March I think).

Maybe a special case could be used, using the 60th day of the year.

Damon


From owner-ietf-calendar@mail.imc.org  Mon Jun 19 18:31:42 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24767
	for <calsch-archive@odin.ietf.org>; Mon, 19 Jun 2000 18:31:42 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id PAA28411
	for ietf-calendar-bks; Mon, 19 Jun 2000 15:06:17 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28402
	for <ietf-calendar@imc.org>; Mon, 19 Jun 2000 15:06:14 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: John Stracke <francis@ecal.com>
Cc: ietf-calendar@imc.org
Subject: Re: To repeat or not...
X-Mailer: Lotus Notes Build V60_06182000 June 18, 2000
Message-ID: <OF2AED0FDD.36462593-ON85256903.00776198@iris.com>
Date: Mon, 19 Jun 2000 18:06:07 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_06182000|June 18, 2000) at
 06/19/2000 06:06:17 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_06182000|June 18, 2000) at
 06/19/2000 06:06:18 PM,
	Serialize complete at 06/19/2000 06:06:18 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_06182000|June 18, 2000) at
 06/19/2000 06:06:18 PM,
	S/MIME Sign complete at 06/19/2000 06:06:18 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/19/2000
 06:06:17 PM,
	Serialize complete at 06/19/2000 06:06:17 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z7384_boundary_sign
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is an S/MIME signed message.

---------z7384_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00796D1185256903_="

This is a multipart message in MIME format.
--=_alternative 00796D1185256903_=
Content-Type: text/plain; charset="us-ascii"

John claimed:
>Suppose the EXRULE specifies that the
>DTSTART is not included? (Dumb, but valid.)

<DIGRESSION>
  We've been over this point before so I wont hammer it too hard again. 
The recurrence set is:

  DTSTART + ( RDATE + RRULE - EXDATE - EXRULE )

NOT

  DTSTART + RDATE + RRULE - EXDATE - EXRULE

  We argued over this in great detail before we RFC'd and there was no 
useful reason that the latter case should be allowed; otherwise you could 
entirely filter out an instance (ie: DTSTART and EXDATE w/the same 
values).  What do you have then??  A non-entity??

  I know that RFC 2445 has:

   The "EXDATE" property can be used to exclude the value specified in
   "DTSTART".

but it appears that our discussion we had waaay back in ~Nov '97 was not 
concluded according to any concensus we reached.  Check the thread titled 
"ical-04 Comments: Component Properties".  The two parts of 2445 under 4.8.5.1 Exception Date/Times and 4.8.5.2 Exception Rule also has contradictory text just above the above quote that says:

                       The "DTSTART" defines the first instance
   in the recurrence set.
...
                      The final recurrence set is generated by gathering
   all of the start date-times generated by any of the specified "RRULE"
   and "RDATE" properties, and excluding any start date and times which
   fall within the union of start date and times generated by any
   specified "EXRULE" and "EXDATE" properties.

  These contradictions need to be cleaned up in any errata we publish 
later on.  Frank???  Derik (maybe lurking??)?
</DIGRESSION>

  Im not going to willingly code any engine that allows me to 'nullify' an 
entity out by filtering it out using EXDATE/EXRULE.  There is no sound 
reason to allow it.  Ill involke the "Time to protect my users from 
nonsense." clause of my code before I buy into that.

  So, back to my original suggestions.  The RFCs already coded up the 
RESPONSE-STATUS:2.8 case for doing collapsing of repeating entries into a 
singular one.  John, are you suggesting we just ignore that option and 
reject the entire request using RESPONSE-STATUS:3.13 (or was that 3.6?)?? 

What do others think: Flatten to singular instance or reject it all out of 
hand?

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 00796D1185256903_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">John claimed:</font>
<br><font size=2 face="Courier New">&gt;Suppose the EXRULE specifies that the<br>
&gt;DTSTART is not included? (Dumb, but valid.)</font>
<br>
<br><font size=2 face="sans-serif">&lt;DIGRESSION&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; We've been over this point before so I wont hammer it too hard again. &nbsp;The recurrence set is:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; DTSTART + ( RDATE + RRULE - EXDATE - EXRULE )</font>
<br>
<br><font size=2 face="sans-serif">NOT</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; DTSTART + RDATE + RRULE - EXDATE - EXRULE</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; We argued over this in great detail before we RFC'd and there was no useful reason that the latter case should be allowed; otherwise you could entirely filter out an instance (ie: DTSTART and EXDATE w/the same values). &nbsp;What do you have then?? &nbsp;A non-entity??</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; I know that RFC 2445 has:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;The &quot;EXDATE&quot; property can be used to exclude the value specified in<br>
 &nbsp; &quot;DTSTART&quot;.</tt></font>
<br>
<br><font size=2 face="sans-serif">but it appears that our discussion we had waaay back in ~Nov '97 was not concluded according to any concensus we reached. &nbsp;Check the thread titled &quot;ical-04 Comments: Component Properties&quot;. &nbsp;The two parts of 2445 under </font><font size=2><tt>4.8.5.1 Exception Date/Times</tt></font><font size=2 face="sans-serif"> and </font><font size=2><tt>4.8.5.2 Exception Rule</tt></font><font size=2 face="sans-serif"> also has contradictory text just above the above quote that says:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The &quot;DTSTART&quot; defines the first instance<br>
 &nbsp; in the recurrence set.</tt></font>
<br><font size=2 face="sans-serif">...</font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The final recurrence set is generated by gathering<br>
 &nbsp; all of the start date-times generated by any of the specified &quot;RRULE&quot;<br>
 &nbsp; and &quot;RDATE&quot; properties, and excluding any start date and times which<br>
 &nbsp; fall within the union of start date and times generated by any<br>
 &nbsp; specified &quot;EXRULE&quot; and &quot;EXDATE&quot; properties.</tt></font>
<br>
<br><font size=2 face="sans-serif">&nbsp; These contradictions need to be cleaned up in any errata we publish later on. &nbsp;Frank??? &nbsp;Derik (maybe lurking??)?</font>
<br><font size=2 face="sans-serif">&lt;/DIGRESSION&gt;</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; Im not going to willingly code any engine that allows me to 'nullify' an entity out by filtering it out using EXDATE/EXRULE. &nbsp;There is no sound reason to allow it. &nbsp;Ill involke the &quot;Time to protect my users from nonsense.&quot; clause of my code before I buy into that.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; So, back to my original suggestions. &nbsp;The RFCs already coded up the RESPONSE-STATUS:2.8 case for doing collapsing of repeating entries into a singular one. &nbsp;John, are you suggesting we just ignore that option and reject the entire request using RESPONSE-STATUS:3.13 (or was that 3.6?)?? &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">What do others think: Flatten to singular instance or reject it all out of hand?</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 00796D1185256903_=--

---------z7384_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYxOTIyMDYxOFowIwYJKoZIhvcNAQkEMRYEFCxmXJW0LGj+
vPNLdS3CoCAe3KexMA0GCSqGSIb3DQEBAQUABECcN3wkrQ0yrdOtSIRGyd69yN75HD+qe1P8paL1
SaBQvhpGmf8PDrChwoGc7w9ViFjU55npxDQzbLmEXyQHVcyD

---------z7384_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Tue Jun 20 03:14:56 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14648
	for <calsch-archive@odin.ietf.org>; Tue, 20 Jun 2000 03:14:56 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06308
	for ietf-calendar-bks; Mon, 19 Jun 2000 23:56:55 -0700 (PDT)
Received: from ns.rbcsai.gr.jp (ns.rbcsai.gr.jp [210.163.93.226])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA06235;
	Mon, 19 Jun 2000 23:56:29 -0700 (PDT)
From: HomeLoans@zelez.fsnet.co.uk
Received: from 112 
          by ns.rbcsai.gr.jp (2.5 Build 2630 (Berkeley 8.8.6)/8.8.4) with SMTP
	  id PAA06576; Tue, 20 Jun 2000 15:48:24 +0900
Message-ID: <0000022869d7$0000233f$00006ef6@188>
To: <HomeLoans@zelez.fsnet.co.uk>
Subject: Home Loans & Refinancing Available 
Date: Tue, 20 Jun 2000 01:51:40 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: quoted-printable

<HTML>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META content=3D"text/html; charset=3Dwindows-1252" http-equiv=3DContent-T=
ype>
<STYLE fprolloverstyle>A:hover {
	COLOR: #ff0000
}
</STYLE>

<META content=3D"Microsoft FrontPage 4.0" name=3DGENERATOR></HEAD>
<BODY background=3D"" bgProperties=3Dfixed>
<P align=3Dcenter><FONT face=3DArial size=3D2 ptsize=3D"8">If you would li=
ke to be 
removed from future mailings, please reply with the word remove in the sub=
ject 
or call 888-418-2575.</FONT></P>
<HR>

<P align=3Dcenter><FONT face=3DArial><B><FONT color=3D#0000ff size=3D4 PTS=
IZE=3D"11">Let 
lenders compete for</FONT><FONT color=3D#000000 size=3D4 PTSIZE=3D"11"> 
<BR><I><U>your</I></U> </I></FONT><FONT color=3D#0000ff size=3D4 
PTSIZE=3D"11">business!</FONT></B> <FONT size=3D1 PTSIZE=3D"8"><FONT color=
=3D#000000 
size=3D4 PTSIZE=3D"11"><BR><BR><B><a href=3D"http://3455391533/members/tcs=
/?SP0619">Click 
Here</a></B></FONT><FONT face=3DArial lang=3D0 size=3D4 PTSIZE=3D"11" 
FAMILY=3D"SANSSERIF"><a href=3D"http://204048631/?SP0602"><BR></a><BR></FO=
NT></FONT><FONT color=3D#008080><B><FONT lang=3D0 
size=3D2 PTSIZE=3D"10" FAMILY=3D"SANSSERIF">Cash back refinances<BR>No Equ=
ity 2nd 
Trust Deeds<BR>Debt Consolidation<BR>No Income Verification<BR>The most 
competitive interest rates!</FONT></B><FONT size=3D2 PTSIZE=3D"11"><BR></F=
ONT><FONT 
color=3D#000000 size=3D4 PTSIZE=3D"11"><BR></FONT></FONT><B><FONT face=3DT=
ahoma size=3D2 
PTSIZE=3D"8">Fill in our quick <a href=3D"http://3455391533/members/tcs/?S=
P0619">pre-qualification 
form</a> and you <BR>will </FONT><FONT size=3D2 ptsize=3D"10">get competin=
g loan 
offers, often&nbsp;<BR>within minutes from up to</FONT><FONT face=3DTahoma=
 size=3D2 
PTSIZE=3D"8"> <U>three</U> lenders!</FONT></B><FONT face=3DTahoma size=3D2=
 
PTSIZE=3D"11"><BR></FONT><FONT size=3D4 PTSIZE=3D"11"><BR></FONT><B><FONT =
color=3D#000000 size=3D4 PTSIZE=3D"11"><a href=3D"http://3455391533/member=
s/tcs/?SP0619">Click 
Here</a></FONT></B><FONT face=3DArial lang=3D0 size=3D4 PTSIZE=3D"11" 
FAMILY=3D"SANSSERIF"><BR></FONT><FONT size=3D1 PTSIZE=3D"8"><B><FONT color=
=3D#008080 
size=3D3 PTSIZE=3D"10"><BR></FONT></B></FONT><B><FONT color=3D#008080 face=
=3DArial 
size=3D1 ptsize=3D"10">There is</FONT><FONT color=3D#000000 face=3DArial s=
ize=3D1 
ptsize=3D"10"> NEVER</FONT><FONT color=3D#008080 face=3DArial size=3D1 pts=
ize=3D"10"> any 
fee to consumers for using this service.</FONT></B> <FONT color=3D#000000 
face=3DTahoma PTSIZE=3D"11"><BR></FONT></FONT></P>
<P align=3Dcenter><FONT face=3DArial size=3D1>Copyright =FFFFFFA9 1999, 20=
00 eWorld Marketing, 
Inc.<BR>888-418-2575<BR></FONT><FONT face=3DArial size=3D1>This is not a 
solicitation or offer to lend money.&nbsp; <BR>eWorld Marketing is not a l=
ender, 
broker or <BR>other financial intermediary.&nbsp; We are a marketing compa=
ny 
<BR>that provides services to the mortgage industry.</FONT> </P></BODY></H=
TML>
</BODY></HTML>




From owner-ietf-calendar@mail.imc.org  Tue Jun 20 17:16:58 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04646
	for <calsch-archive@odin.ietf.org>; Tue, 20 Jun 2000 17:16:56 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA23731
	for ietf-calendar-bks; Tue, 20 Jun 2000 13:55:57 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23726
	for <ietf-calendar@imc.org>; Tue, 20 Jun 2000 13:55:52 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: Damon Chaplin <damon@helixcode.com>
Cc: ietf-calendar@imc.org
Subject: Re: Birthdays on Feb 29th
X-Mailer: Lotus Notes Build V60_06192000 June 19, 2000
Message-ID: <OF0BD12BF6.30C41594-ON85256904.007209F9@iris.com>
Date: Tue, 20 Jun 2000 16:52:41 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_06192000|June 19, 2000) at
 06/20/2000 04:55:57 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_06192000|June 19, 2000) at
 06/20/2000 04:55:57 PM,
	Serialize complete at 06/20/2000 04:55:57 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_06192000|June 19, 2000) at
 06/20/2000 04:55:58 PM,
	S/MIME Sign complete at 06/20/2000 04:55:58 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/20/2000
 04:56:04 PM,
	Serialize complete at 06/20/2000 04:56:04 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z6229_boundary_sign
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is an S/MIME signed message.

---------z6229_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0072FC7585256904_="

This is a multipart message in MIME format.
--=_alternative 0072FC7585256904_=
Content-Type: text/plain; charset="us-ascii"

Damon asked:
>What is the recommended way of handling a birthday on 29th Feb?

iCalendar can be used to represent this if you _just_ want 29-Feb:

DTSTART:20000229
RRULE:FREQ=YEARLY;INTERVAL=4;BYMO=2;BYDAY=29

or

DTSTART:20000229
RRULE:FREQ=YEARLY;INTERVAL=4;BYYEARDAY=59

>Maybe a special case could be used, using the 60th day of the year.

Sounds right to me:

DTSTART:20000229
RRULE:FREQ=YEARLY;INTERVAL=1;BYYEARDAY=60

This would make it 29-Feb or 1-Mar depending on the year.  If you wanted 
it on 29-Feb or 28-Feb then you need to get trickier w/the RRULEs...

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 0072FC7585256904_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Damon asked:</font>
<br><font size=2 face="Courier New">&gt;What is the recommended way of handling a birthday on 29th Feb?<br>
</font>
<br><font size=2 face="sans-serif">iCalendar can be used to represent this if you _just_ want 29-Feb:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART:20000229</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=YEARLY;INTERVAL=4;BYMO=2;BYDAY=29</font>
<br>
<br><font size=2 face="sans-serif">or</font>
<br>
<br><font size=2 face="sans-serif">DTSTART:20000229</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=YEARLY;INTERVAL=4;BYYEARDAY=59</font>
<br><font size=2 face="Courier New"><br>
&gt;Maybe a special case could be used, using the 60th day of the year.</font>
<br>
<br><font size=2 face="sans-serif">Sounds right to me:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART:20000229</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=YEARLY;INTERVAL=1;BYYEARDAY=60</font>
<br>
<br><font size=2 face="sans-serif">This would make it 29-Feb or 1-Mar depending on the year. &nbsp;If you wanted it on 29-Feb or 28-Feb then you need to get trickier w/the RRULEs...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0072FC7585256904_=--

---------z6229_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMDIwNTU1N1owIwYJKoZIhvcNAQkEMRYEFNkMQ+yxzBVr
E8fyGQhZqKHmlBfIMA0GCSqGSIb3DQEBAQUABEData6X29fOrHCS29l99YbCgntu1xGdOpVPlnG/
ET7hs6VqOqaAxw4B23l57FWc4AOEJ/fZKfBFodWV9zXD60Tm

---------z6229_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Tue Jun 20 17:40:08 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04999
	for <calsch-archive@odin.ietf.org>; Tue, 20 Jun 2000 17:40:08 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA24275
	for ietf-calendar-bks; Tue, 20 Jun 2000 14:22:07 -0700 (PDT)
Received: from localhost.localdomain ([216.52.68.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24271
	for <ietf-calendar@imc.org>; Tue, 20 Jun 2000 14:22:05 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id RAA30326
	for <ietf-calendar@imc.org>; Tue, 20 Jun 2000 17:23:01 -0400
Message-ID: <394FE0B5.EE79EEB7@ecal.com>
Date: Tue, 20 Jun 2000 17:23:01 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Birthdays on Feb 29th
References: <OF0BD12BF6.30C41594-ON85256904.007209F9@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Bruce_Kahn@iris.com wrote:

> iCalendar can be used to represent this if you _just_ want
> 29-Feb:
>
> DTSTART:20000229
> RRULE:FREQ=YEARLY;INTERVAL=4;BYMO=2;BYDAY=29

'Course, that doesn't usually work when you hit a century year.
:-)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Anyone who has a conditioned response        |
|francis@ecal.com|immediately thinks of Pavlov.                |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Wed Jun 21 15:30:26 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11545
	for <calsch-archive@odin.ietf.org>; Wed, 21 Jun 2000 15:30:26 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA28868
	for ietf-calendar-bks; Wed, 21 Jun 2000 12:06:08 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28864
	for <ietf-calendar@imc.org>; Wed, 21 Jun 2000 12:06:06 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: RFC 2445 & RECURRENCE-ID
X-Mailer: Lotus Notes Build V60_06192000 June 19, 2000
Message-ID: <OFD9AB0EE1.2863B771-ON85256905.00683F27@iris.com>
Date: Wed, 21 Jun 2000 15:06:02 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_06192000|June 19, 2000) at
 06/21/2000 03:06:18 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_06192000|June 19, 2000) at
 06/21/2000 03:06:18 PM,
	Serialize complete at 06/21/2000 03:06:18 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_06192000|June 19, 2000) at
 06/21/2000 03:06:19 PM,
	S/MIME Sign complete at 06/21/2000 03:06:19 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/21/2000
 03:09:36 PM,
	Serialize complete at 06/21/2000 03:09:36 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z19811_boundary_sign
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is an S/MIME signed message.

---------z19811_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0068F2B185256905_="

This is a multipart message in MIME format.
--=_alternative 0068F2B185256905_=
Content-Type: text/plain; charset="us-ascii"

In doing some serious brain frying on the recurrence subtlties Ive run 
across what I think is an oversight on our part when defining 
RECURRENCE-ID in RFC 2445:

   If the value of the "DTSTART" property is a DATE type value, then the
   value MUST be the calendar date for the recurrence instance.

is OK _if_ the RRULE contains no BYHOUR, BYMINUTE or BYSECOND when the DTSTART is a 
DATE only value.  If it did then we have no way to target a specific 
recurrence on that day!  There are 2 possible cases here:

1: It is "illegal" to have a DTSTART with a DATE value and then to have a 
time related BY* value on the RRULE or
2: If the RRULE does contain time limiter then RECURRENCE-ID is allowed to 
have a time component as well EVEN IF DTSTART does not.

#1 can be 'fixed' by further additions to the text defining recurrence 
rule data types.  Since Frank is already in that area for prior postings 
its not that big a deal.

#2 can be fixed by refining the quoted text slightly.

Thoughts?  Comments? Chip & hot sauce??

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 0068F2B185256905_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">In doing some serious brain frying on the recurrence subtlties Ive run across what I think is an oversight on our part when defining RECURRENCE-ID in RFC 2445:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;If the value of the &quot;DTSTART&quot; property is a DATE type value, then the<br>
 &nbsp; value MUST be the calendar date for the recurrence instance.<br>
</tt></font>
<br><font size=2 face="sans-serif">is OK _<u>if</u>_ the RRULE contains no BYHOUR, BYMINUTE or BYSECOND when the DTSTART is a DATE only value. &nbsp;If it did then we have no way to target a specific recurrence on that day! &nbsp;There are 2 possible cases here:</font>
<br>
<br><font size=2 face="sans-serif">1: It is &quot;illegal&quot; to have a DTSTART with a DATE value and then to have a time related BY* value on the RRULE or</font>
<br><font size=2 face="sans-serif">2: If the RRULE does contain time limiter then RECURRENCE-ID is allowed to have a time component as well EVEN IF DTSTART does not.</font>
<br>
<br><font size=2 face="sans-serif">#1 can be 'fixed' by further additions to the text defining recurrence rule data types. &nbsp;Since Frank is already in that area for prior postings its not that big a deal.</font>
<br>
<br><font size=2 face="sans-serif">#2 can be fixed by refining the quoted text slightly.</font>
<br>
<br><font size=2 face="sans-serif">Thoughts? &nbsp;Comments? Chip &amp; hot sauce??</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0068F2B185256905_=--

---------z19811_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMTE5MDYxOVowIwYJKoZIhvcNAQkEMRYEFFeznrUwNjZp
TdtC0RsQXqe6yI+nMA0GCSqGSIb3DQEBAQUABEDd+8WvyC097K8qvMGQ5quzlxsCSG93F/m2LG0Q
cgluhVeCT0CMGsLFG7J0G68mZZm0O/mX1b2RIfwWHAd6bsEp

---------z19811_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Thu Jun 22 11:35:15 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08568
	for <calsch-archive@odin.ietf.org>; Thu, 22 Jun 2000 11:35:14 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14861
	for ietf-calendar-bks; Thu, 22 Jun 2000 08:04:54 -0700 (PDT)
Received: from srv01.cas.org (srv01s4.cas.org [134.243.50.9])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14857
	for <ietf-calendar@imc.org>; Thu, 22 Jun 2000 08:04:53 -0700 (PDT)
Received: from cas.org (localhost [127.0.0.1])
	by lwv26awu.cas.org (8.8.8+Sun/8.8.8/CAS_CLIENT-1.11) with ESMTP id LAA25908
	for <ietf-calendar@imc.org>; Thu, 22 Jun 2000 11:04:34 -0400 (EDT)
Message-ID: <39522B02.66E292B6@cas.org>
Date: Thu, 22 Jun 2000 11:04:34 -0400
From: "Larry W. Virden" <lvirden@cas.org>
Reply-To: lvirden@cas.org
Organization: Nedriv Software and Shoe Shiners, Uninc.
X-Mailer: Mozilla 4.73 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en, x-ns1JWcDf23_NhQ, x-ns2r2c09OnmPe2
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Request for pointer to discussion group/web forum for discussing 
 calendar application _development_
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I'm hoping to find a pointer to some group or list where discussions
regarding heterogeneous calendar application development are not only
appropriate but taking place actively.

I've a need to purchase, locate and build, or design and develop several
specific tools relating to calendaring and scheduling.  I understand
this list is strictly for discussing the underlying standards - I'm
looking for the next level of discussion.
Could someone provide some pointers?

Thanks!


-- 
<URL: https://secure.paypal.com/refer/pal=lvirden%40yahoo.com>
<URL: mailto:lvirden@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
-><-


From owner-ietf-calendar@mail.imc.org  Sun Jun 25 03:20:57 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02384
	for <calsch-archive@odin.ietf.org>; Sun, 25 Jun 2000 03:20:56 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA22613
	for ietf-calendar-bks; Sat, 24 Jun 2000 23:59:48 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA22608
	for <ietf-calendar@imc.org>; Sat, 24 Jun 2000 23:59:46 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA21405
	for ietf-calendar@imc.org; Sun, 25 Jun 2000 00:00:03 -0700 (PDT)
Date: Sun, 25 Jun 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200006250700.AAA21405@royer.com>
X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r
To: ietf-calendar@imc.org
Subject: CALSCH Action Items
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a list of action items for the CALSCH Working Group.
This list will be sent out once a week and updated as often
as practical (That means if I am not available it may take
an extra week or two before you see your changes).

Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM .

There are three parts to this action list:

	(W) Working group action items.
	(C) CAP editor action items.
	(I) iCalendar action items (Frank Dawson)

Each action item will be assigned a unique ID that will aid in
tracking the items.

------------------------------------------------------------------------------

			Working Group Action Items   

Where Resolution is one of:

	U - undecided.
	Y - Chair determined consensus is in favor of the proposal.
	N - Chair determined consensus is NOT in favor of the proposal.
	D - Dropped. Chair has decided that it may never reach consensus.

 The following are a list of proposals and their status in the WG:
 
 WG Action Item					Resolution
 --------------					----------

 W-1 CAP Use HTTP as transport			N
 
 W-2 CAP If all booked and scheduled		Y
     appointments are in same table
 
 W-3 CAP Use SASL as authentication method	Y
 
 W-4 Add UID and COUNTER to VFREEBUSY		N 

 W-5 CAP Should CAPABILITY reply be sent	N
     as result of successful AUTHENTICATE
     and IDENTITY 

 W-6 Do we need to handle 'unscheduled
     event' as described by the SKI project?	N
     (In CAP - 'N', SKI to be a seperate
      project/draft as it will effect
      RFC2445,6,7)

 W-7 CAP Auto-logout Timer issues		
      Do we need one?				Y
      How long?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	Y
     [see note in CAP 7.2.1.5]
 
 W-10 CAP Text mandatory in all response	N
      codes
 
 W-11 CAP Text optional in response codes	Y
      (some response codes may have 
       mandatory data that follows)
       
 W-12 CAP Should parts of response code be	Y
      separated by ';'
      
 W-13 CAP Store Schema				Y
 
 W-14 CAP VEVENT Schema				Y
 
 W-15 CAP VTODO Schema				Y
 
 W-16 CAP VJOURNAL Schema			Y
 
 W-17 CAP VCAR Schema				Y

 W-18 CAP UPN definition, including anonymous	Y
      user and how UPN's are used in LDAP and
      certificates.
 
 W-19 CAP Group definitions, dynamic and	Y
      static and how groups are used in VCARs.
      Policy definitions, in a VCAR format.

 W-20 Associating UPN values with CREATED	N
      and LAST-MODIFIED properties.

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			Y in process

 W-23 CAP Calendar property to allow/disallow	N
      overlapped booking OPAQUE entries?

 W-24 CAP Calendar CHARSET property issues	Y

 W-25 Remove MUST from UID in 4.8.4.7		Y

 W-26 Write/Submit information draft/rfc	Y

 W-27 How a query can specify if the recurrence	Y
      rules are to be expanded by the CS.

 W-28 Cal-Props - PATH				N
      (CAP-00 - 12.2)
      Will there need to be one?		N
      Optional?					N

 W-29 Import/Export				Y - sync only

 W-30 Transport protocol name (transport vs	Y
      application layer)

 W-31 NOOP command?				Y

 W-32 NOOP advisory only?			Y

 W-33 Should DISCONNECT be called QUIT?		U

 W-34 Format following error codes. Are		Y
      they well defined? If not they
      need to be machine determinable. 

 W-35 Move DNS and SLP to seperate draft?	Y

------------------------------------------------------------------------------

 The following are a list of action items for the CAP draft editors:
 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

 C-2 Fix up changes in authentication		Alex	N
     text as commented on the list		Paul

 C-3 Text for 2.7 [Finding CAP Servers]		Doug	N
 
 C-4 VCAR examples				Doug?	N
 
 C-5 PUBLISH text
 
 C-6 REQUEST text
 
 C-7 REPLY text

 C-8 ADD text
 
 C-9 CANCEL text 
 
 C-10 REFRESH text
 
 C-11 COUNTER text
 
 C-12 DECLINECOUNTER Text

 C-13 Post CAP-00.txt					Y

 C-14 Redo state diagram to include STARTTLS
      and IDENTIFY command.

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------

 I-1 MIME alternate/related			Frank	?
     MUST be supported.

 I-2 Remove ordering of properties and		Frank	?
     parameters in draft.

 I-3 S/MIME and RFC1847.			U
     [CAP] 2.2.3

 I-4 Add ALARMID to VALARM ?			Y

------------------------------------------------------------------------------


Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM

--------------------------------------------------------------------------
Work: Doug.Royer@Software.com              Home    801 Woodside Rd #14-244
      530 E. Montecito St.                 Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541                    Personal Email: Doug@Royer.com



From owner-ietf-calendar@mail.imc.org  Tue Jun 27 12:14:42 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17199
	for <calsch-archive@odin.ietf.org>; Tue, 27 Jun 2000 12:14:42 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17434
	for ietf-calendar-bks; Tue, 27 Jun 2000 08:45:10 -0700 (PDT)
Received: from lotus.lotus.com (lotus.lotus.com [192.233.136.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17430
	for <ietf-calendar@imc.org>; Tue, 27 Jun 2000 08:45:09 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus.lotus.com (8.9.3/8.9.3) with ESMTP id LAA14936
	for <ietf-calendar@imc.org>; Tue, 27 Jun 2000 11:44:18 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA24956
	for <ietf-calendar@imc.org>; Tue, 27 Jun 2000 11:17:09 -0400 (EDT)
To: ietf-calendar@imc.org
Subject: Who Supports VJOURNAL?
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OF056698E9.212C1426-ON8525690B.0053B624@lotus.com>
Date: Tue, 27 Jun 2000 11:09:03 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 06/27/2000 11:09:07 AM,
	Serialize complete at 06/27/2000 11:09:07 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0053C6D38525690B_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0053C6D38525690B_=
Content-Type: text/plain; charset="us-ascii"

Just an inquiring minds wanting to know...
--=_alternative 0053C6D38525690B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Just an inquiring minds wanting to know...</font>
--=_alternative 0053C6D38525690B_=--


From owner-ietf-calendar@mail.imc.org  Thu Jun 29 01:58:45 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16321
	for <calsch-archive@odin.ietf.org>; Thu, 29 Jun 2000 01:58:44 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28519
	for ietf-calendar-bks; Wed, 28 Jun 2000 22:34:51 -0700 (PDT)
Received: from speechL. ([210.125.126.137])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA28494;
	Wed, 28 Jun 2000 22:34:27 -0700 (PDT)
From: HomeLoans@5pop.fsnet.co.uk
Received: from x130 by speechL. (SMI-8.6/SMI-SVR4)
	id OAA00323; Thu, 29 Jun 2000 14:20:27 +0900
Message-ID: <00004f953e94$00006405$00002926@x159>
To: <HomeLoans@5pop.fsnet.co.uk>
Subject: Home Loans & Refinancing Available 
Date: Wed, 28 Jun 2000 22:57:53 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: quoted-printable

<HTML>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META content=3D"text/html; charset=3Dwindows-1252" http-equiv=3DContent-T=
ype>
<STYLE fprolloverstyle>A:hover {
	COLOR: #ff0000
}
</STYLE>

<META content=3D"Microsoft FrontPage 4.0" name=3DGENERATOR></HEAD>
<BODY background=3D"" bgProperties=3Dfixed>
<P align=3Dcenter><FONT face=3DArial size=3D2 ptsize=3D"8">If you would li=
ke to be 
removed from future mailings, please reply with the word remove in the sub=
ject 
or call 888-418-2575.</FONT></P>
<HR>

<P align=3Dcenter><FONT face=3DArial><B><FONT color=3D#0000ff size=3D4 PTS=
IZE=3D"11">Let 
lenders compete for</FONT><FONT color=3D#000000 size=3D4 PTSIZE=3D"11"> 
<BR><I><U>your</I></U> </I></FONT><FONT color=3D#0000ff size=3D4 
PTSIZE=3D"11">business!</FONT></B> <FONT size=3D1 PTSIZE=3D"8"><FONT color=
=3D#000000 
size=3D4 PTSIZE=3D"11"><BR><BR><B><a href=3D"http://3518593971/bin/redirec=
tor2.cgi?http://63.103.91.203/mortgage/?SP0629">Click 
Here</a></B></FONT><FONT face=3DArial lang=3D0 size=3D4 PTSIZE=3D"11" 
FAMILY=3D"SANSSERIF"><BR><BR></FONT></FONT><FONT color=3D#008080><B><FONT =
lang=3D0 
size=3D2 PTSIZE=3D"10" FAMILY=3D"SANSSERIF">Cash back refinances<BR>No Equ=
ity 2nd 
Trust Deeds<BR>Debt Consolidation<BR>No Income Verification<BR>The most 
competitive interest rates!</FONT></B><FONT size=3D2 PTSIZE=3D"11"><BR></F=
ONT><FONT 
color=3D#000000 size=3D4 PTSIZE=3D"11"><BR></FONT></FONT><B><FONT face=3DT=
ahoma size=3D2 
PTSIZE=3D"8">Fill in our quick <a href=3D"http://3518593971/bin/redirector=
2.cgi?http://63.103.91.203/mortgage/?SP0629">pre-qualification 
form</a> and you <BR>will </FONT><FONT size=3D2 ptsize=3D"10">get competin=
g loan 
offers, often&nbsp;<BR>within minutes from up to</FONT><FONT face=3DTahoma=
 size=3D2 
PTSIZE=3D"8"> <U>three</U> lenders!</FONT></B><FONT face=3DTahoma size=3D2=
 
PTSIZE=3D"11"><BR></FONT><FONT size=3D4 PTSIZE=3D"11"><BR></FONT><B><FONT =
color=3D#000000 size=3D4 PTSIZE=3D"11"><a href=3D"http://3518593971/bin/re=
director2.cgi?http://63.103.91.203/mortgage/?SP0629">Click 
Here</a></FONT></B><FONT face=3DArial lang=3D0 size=3D4 PTSIZE=3D"11" 
FAMILY=3D"SANSSERIF"><BR></FONT><FONT size=3D1 PTSIZE=3D"8"><B><FONT color=
=3D#008080 
size=3D3 PTSIZE=3D"10"><BR></FONT></B></FONT><B><FONT color=3D#008080 face=
=3DArial 
size=3D1 ptsize=3D"10">There is</FONT><FONT color=3D#000000 face=3DArial s=
ize=3D1 
ptsize=3D"10"> NEVER</FONT><FONT color=3D#008080 face=3DArial size=3D1 pts=
ize=3D"10"> any 
fee to consumers for using this service.</FONT></B> <FONT color=3D#000000 
face=3DTahoma PTSIZE=3D"11"><BR></FONT></FONT></P>
<P align=3Dcenter><FONT face=3DArial size=3D1>Copyright =FFFFFFA9 1999, 20=
00 eWorld Marketing, 
Inc.<BR>888-418-2575<BR></FONT><FONT face=3DArial size=3D1>This is not a 
solicitation or offer to lend money.&nbsp; <BR>eWorld Marketing is not a l=
ender, 
broker or <BR>other financial intermediary.&nbsp; We are a marketing compa=
ny 
<BR>that provides services to the mortgage industry.</FONT> </P></BODY></H=
TML>
</BODY></HTML>




From owner-ietf-calendar@mail.imc.org  Fri Jun 30 11:09:55 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19119
	for <calsch-archive@odin.ietf.org>; Fri, 30 Jun 2000 11:09:54 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA05781
	for ietf-calendar-bks; Fri, 30 Jun 2000 07:33:11 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05777
	for <ietf-calendar@imc.org>; Fri, 30 Jun 2000 07:33:09 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: RFC 2445: UNTIL & TZID
X-Mailer: Lotus Notes Build V60_06262000 June 26, 2000
Message-ID: <OFE9570456.BE9F4849-ON8525690E.004A26E2@iris.com>
Date: Fri, 30 Jun 2000 10:37:20 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_06262000|June 26, 2000) at
 06/30/2000 10:34:30 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_06262000|June 26, 2000) at
 06/30/2000 10:34:30 AM,
	Serialize complete at 06/30/2000 10:34:30 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_06262000|June 26, 2000) at
 06/30/2000 10:34:30 AM,
	S/MIME Sign complete at 06/30/2000 10:34:30 AM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/30/2000
 10:34:07 AM,
	Serialize complete at 06/30/2000 10:34:07 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z42738_boundary_sign
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is an S/MIME signed message.

---------z42738_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0050100F8525690E_="

This is a multipart message in MIME format.
--=_alternative 0050100F8525690E_=
Content-Type: text/plain; charset="us-ascii"

Just wanted to get some group clarification about something in RFC 2445 
with respect to UNTILs on RRULE/EXRULEs.  According to RFC 2445:

     recur      = "FREQ"=freq *(

                ; either UNTIL or COUNT may appear in a 'recur',
                ; but UNTIL and COUNT MUST NOT occur in the same 'recur'

                ( ";" "UNTIL" "=" enddate ) /
...
     enddate    = date
     enddate    =/ date-time            ;An UTC value

and

   The UNTIL rule part defines a date-time value which bounds the
   recurrence rule in an inclusive manner. If the value specified by
   UNTIL is synchronized with the specified recurrence, this date or
   date-time becomes the last instance of the recurrence. If specified
   as a date-time value, then it MUST be specified in an UTC time
   format

This last bit is a bit at odds with the rest of the behaviour for a 
recurrence rule.  For other value parts, if they are not specified they 
are inherited from the DTSTART (ie: the start time, day and date, etc). It 
is perfectly acceptable to have:

DTSTART;TZID="US-Eastern":20000629T090000
RRULE:FREQ=Weekly;UNTIL=20001224T130000Z

but Im curious _why_ the following would not also be allowed:

DTSTART;TZID="US-Eastern":20000629T090000
RRULE:FREQ=Weekly;UNTIL=20001224T090000

IFF the DTSTART had a TZID that could be inherited??  Along the same vein, 
_why_ did we disallow:

DTSTART;TZID="US-Eastern":20000629T090000
RRULE;TZID="US-Eastern":FREQ=Weekly;UNTIL=20001224T090000

I dont see any discussion of this in our archives and its a bee in my 
bonnet as I dive deeper...  Anyone care to enlighten me or voice any 
opinion as to whether we should consider updating RFC 2445 to allow for 
TZID specification or inheritance?  (If there are no objections I move 
that we a change that Ill provide to the effect that it is allowed...)

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 0050100F8525690E_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Just wanted to get some group clarification about something in RFC 2445 with respect to UNTILs on RRULE/EXRULEs. &nbsp;According to RFC 2445:</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp;recur &nbsp; &nbsp; &nbsp;= &quot;FREQ&quot;=freq *(<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;; either UNTIL or COUNT may appear in a 'recur',<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;; but UNTIL and COUNT MUST NOT occur in the same 'recur'<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;( &quot;;&quot; &quot;UNTIL&quot; &quot;=&quot; enddate ) /<br>
</tt></font><font size=2 face="sans-serif">...</font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp;enddate &nbsp; &nbsp;= date<br>
 &nbsp; &nbsp; enddate &nbsp; &nbsp;=/ date-time &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;;An UTC value<br>
<br>
</tt></font><font size=2 face="sans-serif">and</font>
<br>
<br><font size=2><tt>&nbsp; &nbsp;The UNTIL rule part defines a date-time value which bounds the<br>
 &nbsp; recurrence rule in an inclusive manner. If the value specified by<br>
 &nbsp; UNTIL is synchronized with the specified recurrence, this date or<br>
 &nbsp; date-time becomes the last instance of the recurrence. If specified<br>
 &nbsp; as a date-time value, then it MUST be specified in an UTC time<br>
 &nbsp; format</tt></font>
<br>
<br><font size=2 face="sans-serif">This last bit is a bit at odds with the rest of the behaviour for a recurrence rule. &nbsp;For other value parts, if they are not specified they are inherited from the DTSTART (ie: the start time, day and date, etc). &nbsp;It is perfectly acceptable to have:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART;TZID=&quot;US-Eastern&quot;:20000629T090000</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=Weekly;UNTIL=20001224T130000Z</font>
<br>
<br><font size=2 face="sans-serif">but Im curious _<u>why</u>_ the following would not also be allowed:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART;TZID=&quot;US-Eastern&quot;:20000629T090000</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=Weekly;UNTIL=20001224T090000</font>
<br>
<br><font size=2 face="sans-serif">IFF the DTSTART had a TZID that could be inherited?? &nbsp;Along the same vein, _<u>why</u>_ did we disallow:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART;TZID=&quot;US-Eastern&quot;:20000629T090000</font>
<br><font size=2 face="sans-serif">RRULE;TZID=&quot;US-Eastern&quot;:FREQ=Weekly;UNTIL=20001224T090000</font>
<br>
<br><font size=2 face="sans-serif">I dont see any discussion of this in our archives and its a bee in my bonnet as I dive deeper... &nbsp;Anyone care to enlighten me or voice any opinion as to whether we should consider updating RFC 2445 to allow for TZID specification or inheritance? &nbsp;(If there are no objections I move that we a change that Ill provide to the effect that it is allowed...)</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0050100F8525690E_=--

---------z42738_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYzMDE0MzQzMFowIwYJKoZIhvcNAQkEMRYEFIjpaHorwAzs
OFCs82IFyQ63izTrMA0GCSqGSIb3DQEBAQUABEBJArPtOm4rFPOEbv++Br5e04QMxgp4KXbaEo9W
4XX3ZYKNTciBKRZ25rdsKqWntBnQfrh17sk5XTcRJxFQZZN2

---------z42738_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Fri Jun 30 11:48:31 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20044
	for <calsch-archive@odin.ietf.org>; Fri, 30 Jun 2000 11:48:30 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA07010
	for ietf-calendar-bks; Fri, 30 Jun 2000 08:21:49 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07006
	for <ietf-calendar@imc.org>; Fri, 30 Jun 2000 08:21:46 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Seeking RRULE evaluation guidance
X-Mailer: Lotus Notes Build V60_06262000 June 26, 2000
Message-ID: <OF14C5D90B.C5D94E8E-ON8525690E.005008A5@iris.com>
Date: Fri, 30 Jun 2000 11:13:06 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_06262000|June 26, 2000) at
 06/30/2000 11:10:16 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_06262000|June 26, 2000) at
 06/30/2000 11:10:16 AM,
	Serialize complete at 06/30/2000 11:10:16 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_06262000|June 26, 2000) at
 06/30/2000 11:10:17 AM,
	S/MIME Sign complete at 06/30/2000 11:10:17 AM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 06/30/2000
 11:22:43 AM,
	Serialize complete at 06/30/2000 11:22:43 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z53281_boundary_sign
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is an S/MIME signed message.

---------z53281_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0053562A8525690E_="

This is a multipart message in MIME format.
--=_alternative 0053562A8525690E_=
Content-Type: text/plain; charset="us-ascii"

Warning: This is a rather long posting in an effort to be as clear as I can on my 
quandry!!

  Ok, after trying to figure out how some seemingly simple RRULE cases 
should be handled Ive come to the opinion that the RFC is not clear enough 
on the topic of evaluation for some cases.  The RFC has some good examples 
(thanks again Derik & Frank) but it is unclear how a recurrence rule 
should be evaluated when the FREQUENCY value is less than a BY* value, the 
INTERVAL is > 1 and the BY* is _NOT_ contiguous.

  For example with the following contiguous BYMONTH, just what are the 
rolled out values for the following:

DTSTART;TZID=US-Eastern:20000628T09000
DTEND;TZID=US-Eastern:20000628T093000
RRULE:FREQ=DAILY;COUNT=5;INTERVAL=4;BYMONTH=6,7

Should it be:

2000 9:00 AM EDT June 28;
                 July 2, 6, 10, 14, 18

or should it be:

2000 9:00 AM EDT June 28;
                 July 1, 4, 8, 12, 16

I suspect everyone will say the former case is correct.  (Anyone vote for 
the latter??)

  What if the BYMONTH were not contiguous:

DTSTART;TZID=US-Eastern:20000628T09000
DTEND;TZID=US-Eastern:20000628T093000
RRULE:FREQ=DAILY;COUNT=5;INTERVAL=4;BYMONTH=6,8

Should it be:

2000 9:00 AM EDT June 28;
                 August 3, 7, 11, 15, 19

or should it be:

2000 9:00 AM EDT June 28;
                 August 1, 4, 8, 12, 16 (or perhaps 4, 8, 12, 16, 20?)

There are 31 days in July and Ive heard 2 different ways to evaluate this 
recurrence "over" the intervening monthy of July.  One suggestion was to 
evaluate the rule thru July but rule out any value as 'out of bounds'. 
This leads to the former set of values.  The other suggestion was to 
evalueate the rule on a value by value basis thus evaluating August from 
the start (1-Aug-2000)

I can see both philosphies but Im not sure what the 'proper' one is.  I 
know others out there have done some recurrence engine work (Eric, 
Microsoft, iPlanet/Netscape??) so Im looking for some agreement as to the 
proper behaviour.  Id like to get concensus so we dont have interop 
issues!!

The case that started this off was simple enough so Ill add it here in 
case there is some interest: I need to take my medicine every 8 hours, 
every other day for 6 dosages.  If I specify:

DTSTART;TZID=US-Eastern:20000626T10000
DTEND;TZID=US-Eastern:20000626T100500
RRULE:FREQ=HOURLY;COUNT=6;INTERVAL=8;BYDAY=MO,WE,FR

then just what at the times I should be taking the medicine:

June 26 2000; 10:00 AM, 6:00 PM;
June 28 2000; 02:00 AM, 10:00 AM, 6:00 PM;
June 30 2000; 02:00 AM, 10:00 AM

or would it be:

June 26 2000; 10:00 AM, 6:00 PM;
June 28 2000; 12:00 AM, 8:00 AM, 4:00 PM;
June 30 2000; 12:00 AM, 8:00 AM

(or something entirely different??!)  The former case is derived from 
rolling out the values 'thru' the intervening days and just ignoring them. 
 The latter case is derived from rolling out the rule on a day by day 
basis (ie: Start @ DTSTARTs time on WE and evaluate all of WE, Start @ 
DTSTARTs time on FR and evaluate all of FR, etc).  The case gets messier 
if you use an INTERVAL that is not an even divisor of the BY* component 
(ie: 8 hours = 1/3 of a day).  Retry the example using an INTERVAL=5 or 
9...

This initial case (that I wrote last) is something most folks do routinely 
but in a slightly different way than how programs may think.  When I have 
to, say, take medicine on a (semi-)regular timetable, I base it on the 
same times each day rather than on any 'roll over' from the previous day. 
As I try to model my own needs using RRULEs Im starting to notice that 
some of the depth we thought we had is not quite there yet (albeit this is 
a very very deep topic!).

Ok, time to wake up and provide some useful responses...  Poke, poke, 
poke.  Nudge, nudge!

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 0053562A8525690E_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif"><b>Warning: </b>This is a rather long posting in an effort to be as clear as I can on my quandry!!</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; Ok, after trying to figure out how some seemingly simple RRULE cases should be handled Ive come to the opinion that the RFC is not clear enough on the topic of evaluation for some cases. &nbsp;The RFC has some good examples (thanks again Derik &amp; Frank) but it is unclear how a recurrence rule should be evaluated when the FREQUENCY value is less than a BY* value, the INTERVAL is &gt; 1 and the BY* is _<b><u>NOT</u></b>_ contiguous.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; For example with the following contiguous BYMONTH, just what are the rolled out values for the following:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART;TZID=US-Eastern:20000628T09000</font>
<br><font size=2 face="sans-serif">DTEND;TZID=US-Eastern:20000628T093000</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=DAILY;COUNT=5;INTERVAL=4;BYMONTH=6,7</font>
<br>
<br><font size=2 face="sans-serif">Should it be:</font>
<br>
<br><font size=2><tt>2000 9:00 AM EDT June 28;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; July 2, 6, 10, 14, 18</tt></font>
<br>
<br><font size=2 face="sans-serif">or should it be:</font>
<br>
<br><font size=2><tt>2000 9:00 AM EDT June 28;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; July 1, 4, 8, 12, 16</tt></font>
<br>
<br><font size=2 face="sans-serif">I suspect everyone will say the former case is correct. &nbsp;(Anyone vote for the latter??)</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; What if the BYMONTH were not contiguous:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART;TZID=US-Eastern:20000628T09000</font>
<br><font size=2 face="sans-serif">DTEND;TZID=US-Eastern:20000628T093000</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=DAILY;COUNT=5;INTERVAL=4;BYMONTH=6,8</font>
<br>
<br><font size=2 face="sans-serif">Should it be:</font>
<br>
<br><font size=2><tt>2000 9:00 AM EDT June 28;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; August 3, 7, 11, 15, 19</tt></font>
<br>
<br><font size=2 face="sans-serif">or should it be:</font>
<br>
<br><font size=2><tt>2000 9:00 AM EDT June 28;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; August 1, 4, 8, 12, 16 (or perhaps 4, 8, 12, 16, 20?)</tt></font>
<br>
<br><font size=2 face="sans-serif">There are 31 days in July and Ive heard 2 different ways to evaluate this recurrence &quot;over&quot; the intervening monthy of July. &nbsp;One suggestion was to evaluate the rule thru July but rule out any value as 'out of bounds'. &nbsp;This leads to the former set of values. &nbsp;The other suggestion was to evalueate the rule on a value by value basis thus evaluating August from the start (1-Aug-2000)</font>
<br>
<br><font size=2 face="sans-serif">I can see both philosphies but Im not sure what the 'proper' one is. &nbsp;I know others out there have done some recurrence engine work (Eric, Microsoft, iPlanet/Netscape??) so Im looking for some agreement as to the proper behaviour. &nbsp;Id like to get concensus so we dont have interop issues!!</font>
<br>
<br><font size=2 face="sans-serif">The case that started this off was simple enough so Ill add it here in case there is some interest: I need to take my medicine every 8 hours, every other day for 6 dosages. &nbsp;If I specify:</font>
<br>
<br><font size=2 face="sans-serif">DTSTART;TZID=US-Eastern:20000626T10000</font>
<br><font size=2 face="sans-serif">DTEND;TZID=US-Eastern:20000626T100500</font>
<br><font size=2 face="sans-serif">RRULE:FREQ=HOURLY;COUNT=6;INTERVAL=8;BYDAY=MO,WE,FR</font>
<br>
<br><font size=2 face="sans-serif">then just what at the times I should be taking the medicine:</font>
<br>
<br><font size=2><tt>June 26 2000; 10:00 AM, 6:00 PM;<br>
June 28 2000; 02:00 AM, 10:00 AM, 6:00 PM;</tt></font>
<br><font size=2><tt>June 30 2000; 02:00 AM, 10:00 AM</tt></font>
<br>
<br><font size=2 face="sans-serif">or would it be:</font>
<br>
<br><font size=2><tt>June 26 2000; 10:00 AM, 6:00 PM;<br>
June 28 2000; 12:00 AM, 8:00 AM, 4:00 PM;</tt></font>
<br><font size=2><tt>June 30 2000; 12:00 AM, 8:00 AM</tt></font>
<br>
<br><font size=2 face="sans-serif">(or something entirely different??!) &nbsp;The former case is derived from rolling out the values 'thru' the intervening days and just ignoring them. &nbsp;The latter case is derived from rolling out the rule on a day by day basis (ie: Start @ DTSTARTs time on WE and evaluate all of WE, Start @ DTSTARTs time on FR and evaluate all of FR, etc). &nbsp;The case gets messier if you use an INTERVAL that is not an even divisor of the BY* component (ie: 8 hours = 1/3 of a day). &nbsp;Retry the example using an INTERVAL=5 or 9...</font>
<br>
<br><font size=2 face="sans-serif">This initial case (that I wrote last) is something most folks do routinely but in a slightly different way than how programs may think. &nbsp;When I have to, say, take medicine on a (semi-)regular timetable, I base it on the same times each day rather than on any 'roll over' from the previous day. &nbsp;As I try to model my own needs using RRULEs Im starting to notice that some of the depth we thought we had is not quite there yet (albeit this is a very very deep topic!).</font>
<br>
<br><font size=2 face="sans-serif">Ok, time to wake up and provide some useful responses... &nbsp;Poke, poke, poke. &nbsp;Nudge, nudge!</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0053562A8525690E_=--

---------z53281_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYzMDE1MTAxNlowIwYJKoZIhvcNAQkEMRYEFE2lq1Gpn+4W
d666nV/4afNdIkJSMA0GCSqGSIb3DQEBAQUABEC+IQ97yxz2yaWE+USBdQUlBrr/d7QL/E7fLF8y
nPxPgvAdmBHKl0TBHjaDGYriMupsX9S04jzKLTHvD7GBvFFM

---------z53281_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Fri Jun 30 14:01:10 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23248
	for <calsch-archive@odin.ietf.org>; Fri, 30 Jun 2000 14:01:09 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA14782
	for ietf-calendar-bks; Fri, 30 Jun 2000 10:42:42 -0700 (PDT)
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14778
	for <ietf-calendar@imc.org>; Fri, 30 Jun 2000 10:42:40 -0700 (PDT)
Received: from mary.bath.ac.uk
	([138.38.32.14] helo=bath.ac.uk ident=mmdf)
	by pat.bath.ac.uk with smtp (Exim 3.12 #1)
	id 1384kC-00030d-00; Fri, 30 Jun 2000 18:38:24 +0100
Date: Fri, 30 Jun 2000 18:36:34 +0100 (BST)
From: Jon Wilson <mapjpw@bath.ac.uk>
To: Bruce_Kahn@iris.com
cc: ietf-calendar@imc.org
Subject: Re: Seeking RRULE evaluation guidance
In-Reply-To: <OF14C5D90B.C5D94E8E-ON8525690E.005008A5@iris.com>
Message-ID: <Pine.GSO.4.04.10006301823350.23926-100000@mary.bath.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


On Fri, 30 Jun 2000 Bruce_Kahn@iris.com wrote:
> When I have to, say, take medicine on a (semi-)regular timetable, I
> base it on the same times each day rather than on any 'roll over' from
> the previous day.  

This interpretation of the rule conforms to the principle of least
surprise. 

However, consider the following situation. Imagine there is a job that
must be carried out every 4th day this year by a number of co-workers. We
agree that Jon shall carry out the task in month 1, Kevin shall do it
month 2, Laura in month 3, Jon again in month 4, and so on. This clearly
requires the other interpretation, with 'roll overs' for months where the
task is not scheduled and scheduling for an individual resuming with the
right interval from the previous enaction of the task by someone else.

(metric time anyone ... !)

--
Jon Wilson                                          mapjpw@bath.ac.uk
Dept. of Mathematical Sciences          http://www.bath.ac.uk/~mapjpw
University of Bath, UK                            Tel. (07776) 137939
"Never put off till tomorrow what you can put off till the day after"




From owner-ietf-calendar@mail.imc.org  Fri Jun 30 16:58:13 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26291
	for <calsch-archive@odin.ietf.org>; Fri, 30 Jun 2000 16:58:13 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18053
	for ietf-calendar-bks; Fri, 30 Jun 2000 13:42:33 -0700 (PDT)
Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18049
	for <ietf-calendar@imc.org>; Fri, 30 Jun 2000 13:42:32 -0700 (PDT)
Received: from kaipara.live.com ([204.254.26.159])
	by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id NAA04417;
	Fri, 30 Jun 2000 13:38:38 -0700 (PDT)
Message-Id: <4.3.1.1.20000630132457.00bdcc80@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 30 Jun 2000 13:35:06 -0700
To: Bruce_Kahn@iris.com
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Seeking RRULE evaluation guidance
Cc: ietf-calendar@imc.org
In-Reply-To: <OF14C5D90B.C5D94E8E-ON8525690E.005008A5@iris.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: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

(various examples deleted)

>The former case is derived from rolling out the values 'thru' the 
>intervening days and just ignoring them.  The latter case is derived from 
>rolling out the rule on a day by day basis

FWIW, I take the former interpretation in each case.  (At least, that's the 
way *I've* implemented it.)  If you want the latter interpretation, you can 
still do this using a second BY* for the smaller unit.

(One thing I noted about your examples, though, is that the number of 
occurrences you listed in each case was one more than the number specified 
in your COUNT - so perhaps you (or I) are misinterpreting what COUNT means??)

In any case, this is yet another illustration of the fact that the 
specification and description of RRULE is confusing, to say the 
least.  This also illustrates the perils of specifying something as a 
standard before it had been adequately implemented.  The IETF traditionally 
standardizes based on "rough consensus and running code".  In the case of 
RRULE, it seems that the second part of this was glossed over, if not 
omitted entirely.

         Ross.