Subject: DTSTART for recurrence instances

From: "Craig Johnson" <[email-masked]>
Date: Mon, 01 Dec 2003 18:07:59 -0700

In the thread "Re: list of items (recur-id is not CAP)", 
Doug wrote (on 11/25/03):
 
> When expanding an existing recurring object, you do not
> modify the DTSTART value...
(i.e. the DTSTART value of a recurrance instance is the
DTSTART value of the recurrence 'master'.)
 
Unless I have misunderstood, this seems contrary to common 
practice.  Some clarification regarding DTSTART value for 
recurrence instances would be helpful.
 
Suppose we have a recurring event for every Monday in January:
 
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040105T100000Z
DTEND:20040105T110000Z
UID:A-Unique-ID
RRULE:FREQ=WEEKLY;UNTIL=20040131T170000Z;
 INTERVAL=1;BYDAY=MO;WKST=SU
...
END:VEVENT
 
Now suppose we SEARCH for that event with Expand:TRUE:
 
BEGIN:VQUERY
EXPAND:TRUE
QUERY: SELECT * from VEVENT
  WHERE UID = 'A-Unique-ID'
END:VQUERY
 
What will be returned in the query?  Will the DTSTART 
(and DTEND) of each recurrence instance be the same as 
the 'master' (as in column 1 below)?  Or will DTSTART and 
DTEND have the 'effective' value for the recurrence instance 
(as in column 2 below)?  Note: The first instance in each 
column is the same; subsequent instances begin to differ.
 
For each instance -              For each instance -
DTSTART is same as the master    DTSTART has 'effective' value
(DTSTART not modified).          for the recurrence instance.
*-----------------------------   *-----------------------------
BEGIN:VEVENT                     BEGIN:VEVENT
DTSTART:      20040105T100000Z   DTSTART:      20040105T100000Z
DTEND:        20040105T110000Z   DTEND:        20040105T110000Z
RECURRENCE-ID:20040105T100000Z   RECURRENCE-ID:20040105T100000Z
...                              ...
BEGIN:VEVENT                     BEGIN:VEVENT
DTSTART:      20040105T100000Z   DTSTART:      20040112T100000Z
DTEND:        20040105T110000Z   DTEND:        20040112T110000Z
RECURRENCE-ID:20040112T100000Z   RECURRENCE-ID:20040112T100000Z
...                              ...
BEGIN:VEVENT                     BEGIN:VEVENT
DTSTART:      20040105T100000Z   DTSTART:      20040119T100000Z
DTEND:        20040105T110000Z   DTEND:        20040119T110000Z
RECURRENCE-ID:20040119T100000Z   RECURRENCE-ID:20040119T100000Z
...                              ...
BEGIN:VEVENT                     BEGIN:VEVENT
DTSTART:      20040105T100000Z   DTSTART:      20040126T100000Z
DTEND:        20040105T110000Z   DTEND:        20040126T110000Z
RECURRENCE-ID:20040126T100000Z   RECURRENCE-ID:20040126T100000Z
...                              ...

The expected result, intuitively and instinctively, is Column 2.
The prior discussion thread implied that Column 1 is correct 
(along with some discussion explaining that this is why DTSTART 
is not always suitable for use in QUERYs, whereas RECURRENCE-ID
is more suitable).
 
This is a fundamental issue that impacts interoperability.  
I'd like to hear others view on this issue: 
What is the value of DTSTART for recurrence instances?
  - DTSTART is the same as the 'master'.
  - DTSTART is the 'effective' value for the instance.
 
Thanks.
Craig J.

---

From: Doug Royer <[email-masked]>
Date: Mon, 01 Dec 2003 19:14:53 -0700

Craig Johnson wrote:

> the 'master' (as in column 1 below)?

Yes. And each object returned will have a RECURRENCE-ID property
added with its value set to the effective start time of that instance of 
the component.
All objects returned will have the same DTSTART /  [ DTEND | DURATION ]

IN 2445 (EXDATE) (a similar section for EXRULE also exists):

   The "EXDATE" property can be used to exclude the value specified in
   "DTSTART". However, in such cases the original "DTSTART" date MUST
   still be maintained by the calendaring and scheduling system because
   the original "DTSTART" value has inherent usage dependencies by other
   properties such as the "RECURRENCE-ID".

The only time the DTSTART is not the same as the master is when
specifying a change to a single instance as described in iTIP 3.7.1
and 4.4.2 . Then the master is not altered, just the specifc object
declaring the change details.

> Or will DTSTART and
> (as in column 2 below)? 

No. Why would there need to be a new property (RECURRENCE-ID)?
It could be done with a boolean (this is a single instance) to DTSTART
if that were true.

> is not always suitable for use in QUERYs, whereas RECURRENCE-ID

DTSTART is a fixed value for any specific revision of a UID.
RECURRENCE-ID is calculated only when the object is expanded.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards

---

From: Olivier Gutknecht <[email-masked]>
Date: Tue, 2 Dec 2003 15:06:10 +0100

On 2 déc. 03, at 03:14, Doug Royer wrote:
> added with its value set to the effective start time of that instance 
> of the component.

2445 and 2446 mention RECURRENCE-ID as a way to actually identify 
component instance more than for actual date for the event. For 
example, in RFC 2445, sect 4.2.7:
	 'Component instances are identified by the combination of "UID", 
"RECURRENCE-ID", and "SEQUENCE"

Or: RFC 2445, sect 4.8.4.4
	The full range of calendar components specified by a
    recurrence set is referenced by referring to just the "UID" property
    value corresponding to the calendar component. The "RECURRENCE-ID"
    property allows the reference to an individual instance within the
    recurrence set.

RFC 2446, sect 2.1.5
	To reference an instance of a recurring component, the primary key is 
composed of the "UID" and
     the "RECURRENCE-ID" properties.

There is also a note in 2445 4.8.4.4 about DATE value type that 
actually tells something about DTSTART semantics in a RECURRENCE-ID 
based component:

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

The definition here is for the -recurrence instance- and is a MUST.

>   properties such as the "RECURRENCE-ID".

This is coherent in that case: making an exception on original DTSTART 
with an EXDATE must not change the other, unrelated component instances 
in the recurrence, as the RECURRENCE-ID is using the date where an 
occurrence should happen in the recurrence. The recurrence definition 
must not change for this to be possible, this include the RRULE of 
course, and the original DTSTART.  This has been corroborated by Frank 
Dawson and Derik Stenerson recently:

	" a) the value for RECURRENCE-ID was agreed to be the date/time  value 
of the original recurrence instance. This value remains unchanged for 
as  long as the base recurrence set (or pattern) exists. A rescheduling 
of an  individual recurrence instance did not cause creation of new 
base recurrence  set, but only moved the start/end of the specified 
recurrence instance.   "

RFC 2445 in 4.8.5.1 also mentions:
	The "DTSTART" property defines the first instance in the recurrence 
set.
But note that this is in the context of a component definining the 
recurrence (RRULE, EXDATE, RDATE, EXDATE, ...), not in the context of a 
RECURRENCE-ID identified component instance. Actually, DTSTART 
definition (4.8.4.2) only refer to the VEVENT component:
	Description: Within the "VEVENT" calendar component, this property
    defines the start date and time for the event.

So it seems somewhat unrelated to the DTSTART issue within a 
RECURRENCE-ID identified component from Craig's example.

> declaring the change details.

I think the issue comes from ambiguities like:

RFC 2445 - 4.8.2.3 Date/Time Due
	 Description: The value MUST be a date/time equal to or after the 
DTSTART value, if specified.
RFC 2446 - 4.5.7.2 Calculating due dates in recurring VTODOs
    The due date in a recurring "VTODO" calendar component is either a
    fixed interval specified in the "REQUEST" method or specified using
    the "RECURRENCE-ID" property. The former is calculated by applying
    the difference between "DTSTART" and "DUE" properties and applying it
    to each of the start of each recurring instance. Hence, if the
    initial "VTODO" calendar component specifies a "DTSTART" property
    value of "19970701T190000Z" and a "DUE" property value of
    "19970801T190000Z" the interval of one day which is applied to each
    recurring instance of the "VTODO" calendar component to determine the
    "DUE" date of the instance.

Even if the text mention the original DTSTART as the reference point, 
it does not mention the actual value of the DTSTART/DUE values in an 
identified recurrence instance. The section is actually quite clear 
when it differentiates the 'recurring instance' and the initial VTODO 
component.

And also:

RFC 2245 - 4.6.6 Alarm Component
	In an alarm set to trigger on the "START" of an event or to-do, the
    "DTSTART" property MUST be present in the associated event or to-do.
RFC 2445 - 4.8.6.3 Trigger
   	If the trigger is set relative to START, then the "DTSTART" property
    MUST be present in the associated "VEVENT" or "VTODO" calendar
    component.

In all these cases, the property is defined relative to the DTSTART (or 
DTEND) of the associated component. If we assume that the DTSTART is 
the DTSTART of the original event, how can we express an iTIP ADD 
("especially useful if there are instance-specific properties to be 
preserved in a recurring "VEVENT"" -  idem for VTODO) or COUNTER and 
referring to actual DTSTART instance in that case and to global DTSTART 
in another case ?

>> Or will DTSTART and DTEND have the 'effective' value for the 
>> recurrence instance
>> (as in column 2 below)?

Why introducing a new parameter if the existing model is sufficient ?

> DTSTART is a fixed value for any specific revision of a UID.

I can't see anything in 2445/2446 that explicitly states that.

> RECURRENCE-ID is calculated only when the object is expanded.

I agree with that.
However (DUE case above), if the returned DTSTART is the original 
DTSTART, I assume that means that a DUE property will also be the 
original component DUE value ? If find that worrying for two reasons
- EXPAND=TRUE is convenient for CUA that don't want or can't handle the 
complete recurrence model (PDA or cell phones were cited in earlier 
discussions). That means that the query results will not be immediately 
usable. I'm also worried with the case of a original event having an 
alarm and a specific instance having a  different alarm (a case likely 
to be related to the ALARMID/SEQUENCE discussion).
- Semantics of the returned VEVENT/VTODO recurrence instances seem to 
be conflicting with many parts of the RFC 2445 texts that mentions 
recurrence instances as 'self sufficient' components (see above, 
4.8.4.1, 4.8.4.4).

>>  This is a fundamental issue that impacts interoperability. I'd like 
>> to hear others view on this issue:

I also understand it as the effective value for the instance, instance 
which is identified through UID/RECURRENCE-ID/SEQUENCE properties.

Ol.

---

From: Doug Royer <[email-masked]>
Date: Tue, 02 Dec 2003 12:01:33 -0700

Olivier Gutknecht wrote:

 > ....

Because you mixed without quoting the author of the comments, I can not
figure out which comment your are asking about or commenting on in
your reply.

Perhaps your GUI processes leading spaces/tabs differently than mine.

--

---

From: Olivier Gutknecht <[email-masked]>
Date: Wed, 3 Dec 2003 10:41:34 +0100

> Perhaps your GUI processes leading spaces/tabs differently than mine.

Sorry, I copied some rich text and forgot to reforce everything in 
plain text.
Here is a repost.

RFC 2446, sect 2.1.5
     To reference an instance of a recurring component, the primary key 
is composed of the "UID" and
     the "RECURRENCE-ID" properties.

      The "DTSTART" property defines the first instance in the 

And also:

> DTSTART is a fixed value for any specific revision of a UID.

I can't see anything in 2445/2446 that explicitly states that (see 
comments above about recurrence instances).

> RECURRENCE-ID is calculated only when the object is expanded.

I agree with that.
However (DUE case above), if in the query result the returned DTSTART 
is the original DTSTART, I assume that means that a DUE property will 
also be the original component DUE value ? If find that worrying for 
two reasons:
    - EXPAND=TRUE is convenient for CUA that don't want or can't handle 
the complete recurrence model (PDA or cell phones were cited in earlier 
discussions). That means that the query results will not be immediately 
usable. I'm also worried with the case of a original event having an 
alarm and a specific instance having a  different alarm (a case likely 
to be related to the ALARMID/SEQUENCE discussion).
    - Semantics of the returned VEVENT/VTODO recurrence instances seem 
to be debatable, because of the parts of RFC 2445  that mentions 
recurrence instances as 'self sufficient' components (see above, 
4.8.4.1, 4.8.4.4).

>>   - DTSTART is the 'effective' value for the instance.

I admit I also understand it as the effective value for the instance 
component, instance which is identified through 
UID/RECURRENCE-ID/SEQUENCE properties.

Ol.

---

From: Doug Royer <[email-masked]>
Date: Wed, 03 Dec 2003 13:55:35 -0700

> The definition here is for the -recurrence instance- and is a MUST. 

Yes and as the section and subject of that text is  'Recurrence ID', as in :

    If the value of the "DTSTART" property is a DATE type value, then the
     value [of RECURRENCE-ID] MUST be the calendar date for the 
recurrence instance

> with an EXDATE must not change the other, unrelated component 
> instances in the recurrence, as the RECURRENCE-ID is using the date 
> where an occurrence should happen in the recurrence. The recurrence 
> definition must not change for this to be possible, this include the 
> RRULE of course, and the original DTSTART.  This has been corroborated 
> by Frank Dawson and Derik Stenerson recently:
>
>     " a) the value for RECURRENCE-ID was agreed to be the date/time 
>  value of the original recurrence instance. This value remains 
> unchanged for as  long as the base recurrence set (or pattern) exists. 
> A rescheduling of an  individual recurrence instance did not cause 
> creation of new base recurrence  set, but only moved the start/end of 
> the specified recurrence instance.   

> But note that this is in the context of a component defining the 
> recurrence (RRULE, EXDATE, RDATE, EXDATE, ...), not in the context of 
> a RECURRENCE-ID identified component instance. Actually, DTSTART 

My point was that it can not be both ways. It has to change or it never 
changes.

>> and 4.4.2 . Then the master is not altered, just the specific object

I do no know why that would be ambiguous, for the 1st or Nth entry that 
would
be true no matter if DTSTART was changed or not.

> when it differentiates the 'recurring instance' and the initial VTODO 

So you are saying that the DUE date must change in each expanded instance
of a recurring VTODO?

If so I disagree as it says to calculate the due date from the DTSTART 
and DUE
dates to get the offset and apply it to RECURRENCE-ID (which would have to
be different or it would be pointless).

 this-instance-due = ( DUE - DTSTART) + RECURRENCE-ID

 Where DUE must be >= DTSTART as defined in 2445 in your quote above.

>    "DTSTART" property MUST be present in the associated event or to-do. 

If DTSTART were the same as RECURRENCE-ID or not, that would be true
as START is defined to be relative to the 'start' of the component, and 
not DTSTART.

If DTSTART were not present then recurring or not, you can not use
any time relative to the 'start' (or 'DTSTART').

For a recurring instance the effective start of an instance
is defined in 2445 to be the RECURRENCE-ID.

So for an expanded component (With RECURRENCE-ID):

    component-start-time = RECURRENCE-ID
 
    alarm-start-time = component-start-time + 'START'

    component-end-time =   RECURRENCE-ID + DURATION

      -or-
 
     component-end-time =  RECURRENCE-ID + ( DTEND - DTSTART)

     alarm-end-time = component-end-time + 'END'

> In all these cases, the property is defined relative to the DTSTART 
> (or DTEND) of the associated component. If we assume that the DTSTART 
> is the DTSTART of the original event, how can we express an iTIP ADD 
> referring to actual DTSTART instance in that case and to global 
> DTSTART in another case ? 

No.

The text says that "START" is relative to the "start" of a component,
it does NOT say START is relative to 'DTSTART'.

And "END"  is defined to be relative to the "end" of a component,
it does NOT say END is relative to 'DTEND' or 'DURATION'

See "4.2.14 Alarm Trigger Relationship"

> Why introducing a new parameter if the existing model is sufficient ? 

I agree.

I am not proposing  new parameter. I am saying that defining DTSTART to
be the same as RECURRENCE-ID in an expanded instance is pointless
and the fact that RECURRENCE-ID exists is an argument for that fact it
needs to be different (when instance > 1st). Else why was it invented when a
boolean parameter would have worked?

> comments above about recurrence instances). 

See "4.8.7.4 Sequence Number", if DTSTART changes, the SEQUENCE MUST change.
Thus the specific revisions of the UID is not the same.

I used the words 'specific revision'  to mean 'pattern' as you quoted 
from Derik/Frank above.

So restated:

    DTSTART is a fixed value for any specific pattern  of a UID.
    Expanding the instances does not alter the DTSTART.

> also be the original component DUE value ? If find that worrying for 

Yes that is what I mean.

> the complete recurrence model (PDA or cell phones were cited in 
> earlier discussions). That means that the query results will not be 
> immediately usable. I'm also worried with the case of a original event 
> having an alarm and a specific instance having a  different alarm (a 
> case likely to be related to the ALARMID/SEQUENCE discussion).

Doing date math is really simple even in a cell phone.

--

---

From: [email-masked]
Date: Fri, 5 Dec 2003 14:17:04 -0500

> > when it differentiates the 'recurring instance' and the initial VTODO 

It should be noted that there is no text regarding the latter case 
described ("specified using the "RECURRENCE-ID" property").  I suspect 
that the reason for this is the change of design of RECURRENCE-ID from 
delta to fixed midway thru iCalendar development.  The editors simply 
missed that line but they removed any text that would describe "the 
latter" case, probably its own paragraph that simply got removed.

Had we stayed with the delta RECURRENCE-ID model then the latter case 
above would be relevant since it would be the instances previous DTSTART 
value thus you could derive the new DUE value.  With the fixed 
RECURRENCE-ID model, you wind up sending the DUE value (or DURATION) so 
that both the recipient and the Organizer have the same view of the VTODO 
(coupled with the fact that the iTIP reschedule would be a full snapshot, 
it would also logically have a specific DUE (or DURATION) value in it for 
the recipient to use)..

> be different or it would be pointless).

The text says NOTHING how to _apply_ RECURRENCE-ID to get the DUE value. 
It only says:

   The due date in a recurring "VTODO" calendar component is either a
   fixed interval specified in the "REQUEST" method or specified using
   the "RECURRENCE-ID" property. 

If the RECURRENCE-ID were changing each reschedule then you could use it 
to calculate a new DUE value.  However as its been noted ad naseum here 
(and supported by the original authors), the RECURRENCE-ID value does not 
change.  As such, a reschedule needs to provide the DUE (or DURATION) 
value since the reschedule is a full snapshot of the Organziers copy (and 
not vulnerable to sequencing problems).

> as START is defined to be relative to the 'start' of the component, and 

Huh??  Each instance has its own DTSTART value thats different from its 
peers.  Each instance has its own VALARMs who TRIGGER relative to that 
instances DTSTART value.  There is no concept of VALARMs being ALL 
relative to the set defintion (aka the 1st instance of the set).

> any time relative to the 'start' (or 'DTSTART').

I agree.  The same goes for for entries that have no DTEND / DUE / 
DURATION too.  In fact thats spelled on in 2445:

   In an alarm set to trigger on the "START" of an event or to-do, the
   "DTSTART" property MUST be present in the associated event or to-do.
   In an alarm in a "VEVENT" calendar component set to trigger on the
   "END" of the event, either the "DTEND" property MUST be present, or
   the "DTSTART" and "DURATION" properties MUST both be present.

> is defined in 2445 to be the RECURRENCE-ID.

No, the effective start of the instance is the DTSTART value. 
RECURRENCE-ID is strictly used to identify the instance and is ONLY the 
same value (for sure) when the instance is first created.  (Thats the 
"original value" bit in Section 4.8.4.4) 

The reason "effective" is used is because you have to consider timezone 
shifts, etc when you roll out repeating grammars to determine each 
instances startting date/time.  If we just used RDATEs then no shifting 
factors would be involved and the phrase "effective" would not be 
necssary.

> it does NOT say END is relative to 'DTEND' or 'DURATION'

I hope you are referring to the DTSTART / DTEND of a particular instance 
of a component and not the 1st instance (the one that is used to make 
copys at all the specified repeating dates that come after it).

If not, you would have ALL alarms for all instances trigger at the exact 
same time and NOT per instance and thats hardly the intent anyone would 
have.  Right?  (Talking about particular property [ie DTSTART] on a 
component [ie VEVENT] is somewhat problematic when the component is 
defined as a repeating one since its unclear which instance you are 
referring to.)

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Fri, 5 Dec 2003 14:39:31 -0500

Craig wrote on 12/01/2003 08:07:59 PM:
> What will be returned in the query? 

Per the CAP 12-e text, ALL instances will be returned and as individual 
VEVENTs.  So the returned data should look something like:

BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040105T100000Z
DTEND:20040105T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040105T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040112T100000Z
DTEND:20040112T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040112T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040119T100000Z
DTEND:20040119T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040119T100000Z
...
END:VEVENT
BEGIN:VEVENT
SUMMARY:Every Monday in January
DTSTART:20040126T100000Z
DTEND:20040126T110000Z
UID:A-Unique-ID
RECURRENCE-ID:20040126T100000Z
...
END:VEVENT

>                                             Will the DTSTART 

No.  (Please be careful using 'master' as it introduces a new term w/o 
defining it.  I take it to mean the initial instance defined by your 
original VEVENT (sans repeating and exclusion grammar or RDATE / EXDATEs) 
but I could be slightly wrong.)

> DTEND have the 'effective' value for the recurrence instance 

Yes

> is not always suitable for use in QUERYs, whereas RECURRENCE-ID

I havent been able to keep on WG threads lately so I didnt see that. 

The interpretation depends on how you read the property defintions in 
2445.  From my catchup attempts on this thread (bottom up) it appears as 
if some grok the difference between instance identifier (UID and 
RECURRENCE-ID) and instance starting time (DTSTART) and some may not.   By 
correctly using each property as its defined,  I dont see how one would 
say Column 1 (omitted) is the correct answer but Ill go back and see if I 
missed something.

Essentially, the CUA needs to be smart about when it uses EXPAND:TRUE in a 
VQUERY.  It depends on what the CUA is attempting to do.

If you want to find a particular instance of a component (ie: 
UID:A-Unique-ID) then you would include RECURRENCE-ID to find it no matter 
where in time it exists and not use EXPAND (or use EXPAND:FALSE). 

If you want to find all instances of a component (ie: UID:A-Unique-ID) 
then you would omit any RECURRENCE-ID and use EXPAND:TRUE.

If you want to find any entires during a particular time range, say the 
work week starting 5-Jan-2004, (even those NOT with UDI:A-Unique-ID) you 
would omit any UID or RECURRENCE-ID and not use EXPAND (or use 
EXPAND:FALSE).

Its somewhat problematic if you do the latter AND include EXPAND:TRUE as 
the results returned would violate the WHERE constraints of the query.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Mon, 08 Dec 2003 12:19:39 -0700

[email-masked] wrote:

> defining it. 

Yet again you failed to know iCalendar - 'master' is in 2446
no one made it up.

> I havent been able to keep on WG threads lately so I didnt see that.

It seem amasing to me that you could keep posting to this list that
you do not follow the the topics, yet in your very NEXT email you
yet again promote your self as being on topic.

---

From: [email-masked]
Date: Tue, 9 Dec 2003 10:52:05 -0500

> Yet again you failed to know iCalendar - 'master' is in 2446

Lets be clear about this shall we.  The phrase "master" is used in iTIP 
Section 2.1 Application Protocol to describe the copy of the entry that 
exists in the Organziers calendar.  That is, invitees see their own copy 
and work on it, NOT the 'master' copy that exists solely in the Organziers 
calendar.  That is not the same context that it appeared to be used in 
Craigs posting.  Craigs usage may have been referring to that but the way 
he used it implied it was referring to the VEVENT in the REQUEST that had 
the RRULE on it.

Its was not clear and after the entire "full REFRESH" thing with Doug I 
prefer to make sure terms are properly defined so we are all on the same 
page so we can be more productive.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Tue, 09 Dec 2003 11:38:30 -0700

[email-masked] wrote:
> Lets be clear about this shall we.  The phrase "master" is used in
> iTIP Section 2.1 Application Protocol to describe the copy of the
> entry that exists in the Organziers calendar. 

No apology for AGAIN sending false information to this list?

> Its was not clear and after the entire "full REFRESH" thing with Doug
> I prefer to make sure terms are properly defined so we are all on the
> same page so we can be more productive.

Yet again - NOT the topic.

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 9 Dec 2003 14:27:27 -0800

Mark, if you are going to waste our time beating up on Bruce,
correct him if you think he is lying.

He asserted a definition and context for the term "master" for
the sake of creating clarity.  If you disagree, then you have an
obligation (in the context of being productive) to explain your
understanding of said terms.  Bruce may be lying (I happen to
agree with his side of this), but he is making an earnest effort
to create clarity.  Please (hopefully starting with this last
email), if you think Bruce is lying to us, correct him so that
either you or he can adjust their views, or at worst at least
understand what each other is saying.

-- Michael --

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...

---

From: Mark Smith <[email-masked]>
Date: Tue, 09 Dec 2003 16:00:13 -0700

Michael Fair wrote:

He said 'master' introduces a new term. No it did not.

It has nothing to do with clarity, it has to do with shooting
from the hip yet again and backpedaling and not checking to
see if he sent was accurate.

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 9 Dec 2003 15:57:45 -0800

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...
> He said 'master' introduces a new term. No it did not.

Do you have a differing or counter definition for the term 'master' or
do you simply have a personal gripe with posts initiating from Bruce?

In the context of Craig's post, Bruce found the use of the term
master sloppy and called it a new term.  He might have been mistaken
about that (people make mistakes), but he offered us the definition
of 'master' that he was going to use for the context of that email.

The appropriate response to that would have been to cite the definition
of the term 'master' from iTip _AND_ cite whether or not you agreed
that Craig's use of the term 'master' followed with Bruce's definition.

Instead you simply called Bruce a liar and made a passing reference to iTip
thereby making us all duplicate the lookup work and reread the posts to
see if the usage was consistent with the real definition or with Craig's.

Please don't do that, it doesn't help me interpret what you believe, nor
give any meaningful correction to Bruce's purported misdirection.

Do you have a different definition for the term 'master' for use in Bruce's
response to Craig?  If so, I request you assert it.

I believe Bruce made an accurate assessment of Craig's usage despite the
differing definition in iTIP.  I believe that Craig's usage meant the copy
in the CU's storage.  For the context of Bruce's response to Craig, and
for that thread only or at least only that message, do you have a
differing interpretation that would prevent us from moving forward on
that discussion?

This is an extemely sensitive topic capable of creating thousands of
unproductive lines of text and we aren't off to a great start.

I request that we all give each other a little more way leeway than is
usual until we start getting some traction on the topic (which still hasn't
even been clearly identified).  And that really means _all_ of us (except
of course the chairs, they can and should be able to crack down whenever
they
feel things are getting out of hand).

Trying to reach understanding so that we may then try and move toward
consensus,
-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Tue, 09 Dec 2003 17:18:58 -0700

> do you simply have a personal gripe with posts initiating from Bruce?

As already posted. And I did post the location of the definition.

---

From: [email-masked]
Date: Wed, 10 Dec 2003 13:22:15 -0500

In the interest of moving this along, can we get back to the matters at 
hand.  If anyone is going to reply to the list, it should be with 
constructive opinions/ideas/thoughts and not personality attacks.  That 
goes for everyone that participates on this list.

Mark Smith <[email-masked]> 
Sent by: [email-masked]
12/09/2003 18:00

To
[email-masked]
cc

Subject
Re: DTSTART for recurrence instances

Michael Fair wrote:

---

From: Mark Smith <[email-masked]>
Date: Wed, 10 Dec 2003 11:58:52 -0700

[email-masked] wrote:
> 
> In the interest of moving this along, can we get back to the matters
> at hand.  If anyone is going to reply to the list, it should be with
> constructive opinions/ideas/thoughts and not personality attacks.
>  That goes for everyone that participates on this list.

I have said this on this list before and I will say it again, this
time to Bob.

Could you add a rule something like:

  Please read the drafts before posting and make sure that what you
  are about to say is true before posting. Some people make what
  seems to many to be an authoritative statement and after reading
  the RFC's or submitted drafts, they seem to have ignored specific
  parts of the text or declare it as (not valid). So such topics
  need to be tagged as 'iCal-next', 'itip-next' or whatever so they
  do not get confused with a discussion about what has actually been
  submitted.

And can there be some sort of suspension from the list when someone
repeatedly posts incorrect information to this list? I for one am
getting REAL tired of having to re-read the specs only to find out
that almost verbatim text exists in submitted text when others say
no such topic or item exists.

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 15 Dec 2003 01:41:51 -0800

>   do not get confused with a discussion about what has actually been

While I agree that we should all read the drafts before posting, the
drafts are HUGE and remember every detail all the time is not something
I consider reasonable.  Further, it takes a while for most of us to
understand what the drafts are really trying to say.  I believe that
many people are fully capable of being involved and being constructive
without having read every word of the drafts.

The main problem I have with this is that many of us have the ability
to read the exact same things and understand them completely differently,
it shuts down the engagement of debate that leads to understanding
and compromise through the threat of upsetting the incumbents, and
most oftentimes one doesn't know they are talking about iCal next
or untruths until after they have been told _and_ shown such (they
are trying to understand and make sense of what they've already read
and just saying they have it wrong isn't always enough).

Further, there is also the topic of hotly debated issues, like the ones
surrounding RECURRENCE-IDs and whether or not each instance tracks its
own SEQUENCE.  We still, as far as I can see, don't have complete agreement
on those issues, and we each have read the drafts and interpretted
them differently.  Further, from what I gather, the most consensus is
actually towards an interpretation that must call a particular section
of iTIP invalid.  This wasn't arrived at lightly.  But the ability to
invalidate a section of an RFC is a right we must reserve and use when
necessary.  I'm not saying that we should just invalidate a section
whenever it helps our argument.  I am saying that discussing and then
upon serious reflections choosing to invalidate a section of the RFC
must be protected on this WG list.

Also, if someone posts information that you believe to be false then you
have
an obligation to correct them above and beyond just saying they are wrong.
If you are not able to correct them, but know they are wrong, then you are
obligated to say as much in the interest of moving the conversation forward.

Those of us who engage in that practice more often than not are able
to clean up misunderstanding in a message or two.  Unless there is a
clear point of confusion or disagreement, and then it becomes important
to identify it and come to consensus.

How are we going to know what goes into iCal-next if we don't pursue the
conversations that will make it better?  Besides who would decide what is
false information or when someone has posted enough of it to be kicked out?
On most occasions, information that you have called false I have determined
to be true...  I believe that each of our opinions carries equal weight and
therefore we are at a stalemate...  In addition, throwing people out just
seems wrought with political woe as people take sides on whether or not it
should have been done.

The WG process depends upon the participants being reasonable and pursuing
conversations that lead to forward progress.  It depends on the pursuit
of training people to be to be stewards for progress and to send each
email with the idea of forwarding a conversation not stonewalling it or
taking personal joy in trying to stick it to the other party.

It requires respect that others may understand things differently than
ourselves, and any one of us may have the more workable ideas.  Therefore,
it becomes paramount to understand each other, and clearly state when
there seems to be a misunderstanding.

As much as possible we must all consider ourselves on the same team,
working toward the same goal.  If someone truly is just here to be a
troll, then most of us will just ignore that person.  If people are in
agreement with that person, then perhaps they have something worth saying
or are touting a common misunderstanding (which will forever need to be
corrected on the list).  If that person truly is touting false information
and people are buying it, then creating consensus _is_ the most important
thing.  Sending well constructed emails built on the foundations of the
RFCs and demonstrations (non-)workability (if needed) must ensue.

-- Michael --