Subject: RE: RECURRENCE-ID discussion

From: Satya Vempati <[email-masked]>
Date: Thu, 07 Aug 2003 18:16:16 +0000

Doug Royer wrote:

<<You can't create that VEVENT. You do not create a VEVENT
with a RECURRENCE-ID.>>

Unless I am missing something, from the ABNF of VEVENT, VEVENT can have a
recurid.

-------------------------------------------
eventprop = *(
; the following are optional,
; but MUST NOT occur more than once
class / created / description / dtstart / geo /
last-mod / location / organizer / priority /
dtstamp / seq / status / summary / transp /
uid / url / recurid / 
; either ’dtend’ or ’duration’ may appear in
; a ’eventprop’, but ’dtend’ and ’duration’
; MUST NOT occur in the same ’eventprop’
dtend / duration /
; the following are optional,
; and MAY occur more than once
attach / attendee / categories / comment /
contact / exdate / exrule / rstatus / related /
resources / rdate / rrule / x-prop
)

-----Original Message-----
From: Doug Royer [mailto:[email-masked]]
Sent: Thursday, August 07, 2003 5:34 PM
To: [email-masked]
Subject: Re: RECURRENCE-ID discussion

Michael Fair wrote:

> If we followed the logic as either Bruce or Doug put it forth
> we find it impossible to get a changing RECURRENCE-ID:
> 
> I first create an event:
> 
> UID: 1
> SEQUENCE: 0
> RECURRENCE-ID: 20030805T180000Z
> DTSTART: 20030805T180000Z

You can't create that VEVENT. You do not create a VEVENT
with a RECURRENCE-ID. Now assuming that you meant that
you created a VEVENT with that DTSTART, then later
you wanted to refer to that instance of that VEVENT,
then that would be the RECURRENCE-ID you would use
to refer to that instance.

The RECURRENCE-ID is use to refer to an existing instance.

> Now to update this I have to reference it, no one here
> disagrees that the RECURRENCE-ID used in the SEQUENCE: 1
> message will be identical to the SEQUENCE: 0 message.
> 
> UID: 1
> SEQUENCE: 1
> RECURRENCE-ID: 20030805T180000Z
> DTSTART: 20030806T150000Z
> 
> [For readability sake I'm going to drop the date part of
> the IDs becuase only times are significant.]
> 
> So now we go to update it again.  If we look at the objects
> themselves.  I specified that SEQUENCE: 1 of UID: 1,
> RECURRENCE-ID: ...T180000Z would DTSTART at ...T150000Z.
> Note that no where in this object did I ever say, "oh and
> by the way here's a new RECURRENCE-ID".  So now we go
> to move it again.  Here's where the disagreement is.

You do not need to say 'oh and by the way here's a new RECURRENCE-ID'
because iCAL says:

    Purpose: This property is used in conjunction with the "UID" and
    "SEQUENCE" property to identify a specific instance of a recurring
    "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
    value is the effective value of the "DTSTART" property of the
    recurrence instance.

So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID
for that single instance object SEQUENCE:1 is the effective value
of the "DTSTART" property - ...T150000Z and not ..T180000Z.

So after that point if you do an update to RECURRENEC-ID ..T180000Z,
there would be no object with that effective DTSTART date and
thus no RECURRENCE-ID to match.

In Bruces model you can NEVER add someone to the series
of recurring VEVENT after any change that effects the
effective  DTSTART value of any instance as they could never
be able to resolve the RECURRENCE-ID because they never
had SEQUENCE:0.

For a single VEVENT REQUEST with three instance (COUNT=3
in a RRULE). It has three RECURRENCE-ID's none of which
were ever explicitly created.

So if the original REQUEST looks like this:

	METHOD:REQUEST
	SEQUENCE:0
	DTSTART:20030805T180000Z
	RRULE:FREQ=HOURLY;COUNT=3
	LOCATION:A

Would have 3 RECURRENCE-ID's:

	...T180000Z  1st instance (effective DTSTART)
	...T190000Z  2nd instance (effective DTSTART)
	...T200000Z  3rd instance (effective DTSTART)

So now the ORGANIZER wants to change the 2nd instance to ..T193000Z.
So per iTIP they could send a new REQUEST SEQUENCE:1 :

	METHOD:REQUEST
	SEQUENCE:1
	DTSTART:..T193000Z
	RECURRNCE-ID:..T190000Z

So once the CUA accepts the new SEQUENCE:1 object, the object
still has three RECURRENCE-ID's:

	...T180000Z  1st instance (effective DTSTART)
	...T193000Z  2nd instance (effective DTSTART)
	...T200000Z  3rd instance (effective DTSTART)

As the RECURRENCE-ID is the effective DTSTART value
of the instance.

Now change the 3rd instance of the SEQUENCE:1 object to ...T190000Z
and move its LOCATION to 'B'.

	METHOD:REQUEST
	SEQUENCE:2
	DTSTART:..T200000Z
	RECURRNCE-ID:..T190000Z
	LOCATION:B

So once the CUA accepts the new SEQUENCE:2 object, the object
still has three RECURRENCE-ID's (new effective DTSTART times):

	...T180000Z  1st instance (effective DTSTART)
	...T190000Z  2nd instance (effective DTSTART)
                      (used to be the 3rd instance)
	...T193000Z  3rd instance (effective DTSTART)
		     (used to be the 2nd instance)

Now change the SEQUENCE:2 2nd instance to ...T200000Z:

	METHOD:REQUEST
	SEQUENCE:3
	DTSTART:..T190000Z
	RECURRNCE-ID:..T200000Z

Now in Bruce's model, your broken because you just moved
the SEQUENCE:0, LOCATION:A meeting to ...T200000Z to LOCATION:A.
When in fact the move was to move the LOCAION:B meeting.

Bruce's reply is to throw the object away and start over
because its impossible to resolve.

 > Now I think this means that Doug is trying to say that
 > the RECURRENCE-ID is set to the original value of the instance
 > being modified which with a changing RECURRENCE-ID could be
 > different.  But I find it impossible for Doug to support
 > this claim because as far as I can see there is no where in
 > the text that allows one to set a before and after RECURRENCE-ID.
 > So the only way to get a differing RECURRENCE-ID is for CS/CUA
 > to proactively change it on its own accord which the message
 > never specifies to do.

You do not change RECURRENCE-ID's directly. You update the object
in ways that alter the effective DTSTART value for an instance.
And as its effective DTSTART value is changed, thus its RECRRENCE-ID
changes to match its effective DTSTART value. And:

    (iTIP)
    An instance of a recurring event is assigned a unique identification,
    "RECURRENCE-ID" property, when that instance is renegotiated.
    Negotiation may be necessary when a substantive change to the event
    or to-do has be made (such as changing the start time, end time, due
    date or location). The "Organizer" can identify a specific recurrence
    instance using the "RECURRENCE-ID" property. The property value is
    equal to the date/time of the instance. If the "Organizer" wishes to
    change the "DTSTART", the original "DTSTART" value is used for
    "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
    reflect the change.  Note that after the change has occurred, the
    "RECURRENCE-ID" has changed to the new "DTSTART" value.

You do not 'set' the 'before' and 'after' RECURRENCE-ID, you
alter the effective DTSTART directly by updating one or more
instances and the RECURRENCE-ID is defined to match the
new effective DSTART.

Another way to change the RECURRENCE-ID's is to alter the times
an existing VEVENT. So if the SEQUENCE:0 object were:

	METHOD:REQUEST
	SEQUENCE:0
	DTSTART:20030805T180000Z
	RRULE:FREQ=HOURLY;COUNT=3
	LOCATION:A

Would have 3 RECURRENCE-ID's:

	...T180000Z  1st instance (effective DTSTART)
	...T190000Z  2nd instance (effective DTSTART)
	...T200000Z  3rd instance (effective DTSTART)

If the ORGANIZER sent a SEQUENCE:1 :

	METHOD:REQUEST
	SEQUENCE:1
	DTSTART:20030805T180000Z (same as the SEQUENCE:0 value)
	RRULE:FREQ=HOURLY;COUNT=3;INTERVAL=2
	LOCATION:A

The SEQUENCE:1 object would 3 RECURRENCE-ID's 2 of which
are different than the SEQUENEC:0 object:

	...T180000Z  1st instance (effective DTSTART)
	...T200000Z  2nd instance (effective DTSTART)
	...T220000Z  3rd instance (effective DTSTART)

The ORGANIZER moved two instances and their effective
DTSTART values (RECURRENCE-ID).

-- 

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

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 13:42:08 -0600

Satya Vempati wrote:
> recurid. ....

Yes and if it were not in the ABNF, you could never use RECURRENCE-ID
in a VEVENT. The ABNF does not mean that all options are always valid. The
iTIP restriction table for a PUBLISH and REQUEST says:

      RECURRENCE-ID  0 or 1  only if referring to an instance of a
                             recurring calendar component.  Otherwise
                             it MUST NOT be present.

So, when creating a new VEVENT you can not be referring to an instance
that does not yet exist. As soon as the object exists it has an
implied RECURRENCE-ID for each effective DTSTART of each instance.

The RECURRENCE-ID property is used to indicate which instance
in a recurring set the object is referring.

The only times that RECURRENCE-ID can exist in a VEVENT is:

    When REPLYing to an existing instance and if present indicates
    that the sender is only replying to that named instance.

    Updating an existing instance in an existing recurrence set.

    CANCELing an instance in an existing recurrence set.

--

---

From: [email-masked]
Date: Thu, 7 Aug 2003 16:17:24 -0400

> implied RECURRENCE-ID for each effective DTSTART of each instance.

And so after Ive created it in my calendar (at SEQUENCE:0) I can then 
invite Satay to a particular instance only by using its RECURRENCE-ID in 
the REQUEST.

>     CANCELing an instance in an existing recurrence set.

Umm, you forgot inviting someone initially to an instance of a recurrence 
set.  REPLY is them responding to it, not my initial REQUEST where its 
perfectly valid (and necessary).

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: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 14:52:42 -0600

> invite Satay to a particular instance only by using its RECURRENCE-ID in 

Only after his CUA has replied to SEQUENCE:0, will he know
what the RECURRENCE-ID for SEQUENCE:0 is. So the first invitation
to him can not contain both a RECRURRENE-ID and DTSTART, else
it looks *exactly* like an iTIP modification to an instance to an
existing VEVENT for which he does not have. As that is how you
modify an existing VEVENT instance - supply the RECURRENCE-ID
and DTSTART properties in a REQUEST - per iTIP.

If it did not contain a RECURRENCE-ID, then as he did not have
that UID it would look like a new REQUEST for a new object. But the fact
that you add RECURRENCE-ID is how you say iTIP modify.

> Umm, you forgot inviting someone initially to an instance of a 
> recurrence set.  REPLY is them responding to it, not my initial REQUEST 
> where its perfectly valid (and necessary).

You forgot that iTIP an iCAL have no such concept in the way you have
presented it. You keep sending out iTIP modify objects and calling
them a new invitation for an ATTENDEE. That may be how your product
does it, it is not in iTIP or iCAL.

If you want to invite someone to an instance of a VEVENT that the you
have in your calendar, create a VEVENT REQUEST object and send it to them.
No RECURRENCE-ID needed.

--

---

From: [email-masked]
Date: Thu, 7 Aug 2003 18:41:47 -0400

Doug thought on 08/07/2003 04:52:42 PM:
> existing VEVENT for which he does not have.

Wrong.  You clearly do not understand iTIP Section 3.2.2 REQUEST and the 
relevant subsections.  Section 3.2.2 tells you how to distinguish betweeen 
a new invitation and an update/reschedule.  That text that does is:

   The "UID" and "SEQUENCE" properties are used to distinguish the
   various uses of the "REQUEST" method. If the "UID" property value in
   the "REQUEST" is not found on the recipient's calendar, then the
   "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
   property value is found on the recipient's calendar, then the
   "REQUEST" is for a rescheduling, an update, or a reconfirm of the
   "VEVENT" calendar component.

So, if Satays CUA does not find UID / RECURRENCE-ID pair then by the 2nd 
sentence it will treat it like an invitation (or as iTIP says the 
""REQUEST" is for a new "VEVENT" calendar component"; aka an invitation). 
Had it found the UID / RECURRENCE-ID pair then by the last line it would 
treat it like an update.   This case is further detailed in iTIP Section 
3.2.2.1 Rescheduling an Event.

>                                            As that is how you

That is also how you invite someone to the particular instance.  Thats why 
we have:

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.

in the REQUEST restriction table.  Since Im inviting Satay to a particular 
instance only, the RECURRENCE-ID value must be there.  Otherwise its 
referring to the entire set of instances which Satay was NOT invited to. 

> that you add RECURRENCE-ID is how you say iTIP modify.

Nowhere in iTIP does it say that RECURRENCE-ID is ONLY allowed when 
'modifying' (or updating to use the iTIP terminology) an instance.  The 
REQUEST is used for both the invite and the update/reschedule.  This 
overloading of REQUEST was a WG decision and as such it means that the 
meaning on the recipients side depends on the sequence the messages arrive 
in.

If I send 2 REQUESTs and they arrive in reverse order then the 1st one 
that arrives looks like the 'invitation' and the 2nd one looks like a 
stale message (after Ive processed the 1st to arrive that was actually the 
reschedule) even though thats now how they appeared to someone who 
receives them in the order sent.

With a fixed model, its no big deal.  With a delta model its grounds for 
confusion (and thus the need to carpet bomb all instances, see other 
post).

In any case, nowhere in iTIP did we ever say that you do not send 
RECURRENCE-ID on an initial invitation.  Besides, you have to send it if 
you only intend to invite them to the instance, thats what the restriction 
table say.  Ahh, you dont see "MUST if referring to an instnace..." so you 
think its not supposed to be there on the invite??...

> does it, it is not in iTIP or iCAL.

Thats how you try to confuse others here by misinterpreting things but 
thats not the way things work in iCalendar or iTIP (or several 
implementations).

I case you haven't seen iTIP Section 3.2.2 REQUEST, let me try to help 
explain the use of the iTIP REQUEST method.  It says, in part:

   The "REQUEST" method in a "VEVENT" component provides the following
   scheduling functions:

     .  Invite "Attendees" to an event;
     .  Reschedule an existing event;
     .  Response to a REFRESH request;
     .  Update the details of an existing event, without rescheduling it;
     .  Update the status of "Attendees" of an existing event, without
        rescheduling it;
     .  Reconfirm an existing event, without rescheduling it;

as such, the REQUEST I send may be the initial invitation and the a 
reschedule from my POV.  However, the recipent POV may interpret the 
reschedule as the initial invitation and the missequenced invitation as an 
obsolete message.  Its all in how the messages arrive at the recipients 
side.  Thats why we created Section 2.1.5 Message Sequencing and why we 
added the subsections of 3.2.2.[1..7].

> have in your calendar, create a VEVENT REQUEST object and send it to 
them.

If its for an instance of a recurrence set then absolutely its needed. 
Otherwise you are referring to the entire set and NOT to an instance. This 
is also how you can do separate instance invitations to the same ATTENDEE 
at different times and NOT have to 'carpet bomb' their version and cause 
C&S workflow thrashing with other ATTENDEEs.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 17:28:18 -0600

[email-masked] wrote:
> relevant subsections.  Section 3.2.2 tells you how to distinguish 
> betweeen a new invitation and an update/reschedule.  That text that does 
> is:
> 

And your still ignoring the part of iTIP that says to modify
an event add the RECURRENCE-ID.

So if you add a RECURRENCE-ID and then it looks *exactly* like
an iTIP modification there is NO way to tell if you missed something.
That model will not work.

Is there ANY text in iCAL or iTIP that says there are two
ways to invite someone, one that works all of the time including
for single instance (without a RECURRECE-ID) that the one
you keep asserting is your way? I anyone can send a REQUEST
to an ATTENDEE for ANY time, why do you insist that RECURRECE-ID
need be added?

--

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 8 Aug 2003 01:54:47 -0700

> I anyone can send a REQUEST

I can't see how not using a RECURRENCE-ID is unambiguous.

I mean let's take my now infamous UID: 1
Let's use the 3 recurrences that have come up,
Jan-3, Jan-4, and Jan-5

Let's say that nothing has changed about the recurrence
set, and these are the original SEQUENCE: 0 instance dates.

Satay gets to be our venerable outsider.

Let's say we want to invite Satay to the Jan-5 instance.

Without the RECURRENCE-ID property as you've suggested,
it would contain:
UID: 1
SEQUENCE: 0
DTSTART: Jan-5

To which his reply I assume must contain:
UID: 1
SEQUENCE: 0

How does this unambiguosly tell me which instance he's
responding to.

This is especially important if I also want to invite
Satay the Jan-4 instance as well:
UID: 1
SEQUENCE: 0
DTSTART: Jan-4

What is his CUA to do?
Following the rules of iTip:
UID: 1 already exists at SEQUENCE: 0
So it falls back to the DTSTAMP field to disambiguate.

As a result, without the RECURRENCE-ID Satay can only
be invited to one ambiguosly referenced instance of
the recurring event.  His reply to both will look
identical to me save the DTSTAMP field, and not
referencing any particular RECURRENCE-ID I will have
no way to figure out which instance the two responses
goes with.

What if anything is missing?

If I was to invite Satay to these instances I would
send him messages that contain the RECURRENCE-ID I
was inviting him to.  He would treat them as an
invite and send a REPLY that contained the RECURRENCE-ID.

In fact this is the only workable method of inviting
him to two instances of the same recurring event I
can envision.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Aug 2003 10:18:33 -0600

> How does this unambiguosly tell me which instance he's

All of them that he was invited to attend. Your thinking
of exactly one instance at a time. What if I want someone
to attend instances 3,6,14? If you add the RECURRENCE-ID
you have to to send 3 REQUESTs and get 3 REPLYs. It is
not needed. Just send that ATTENDEE a single REQUEST with
the dates/times they are requested to attend. (see how
to disambiguate below)

I can't believe that any CUA that allows the CU to invite
an attendee to one or more specific instances is going
to rely on the REPLY's coming back from the ATTENDEE to
tell the ORGANIZER when the ATTENDEEs are invited. The ORGANIZER-CUA
is going to already know who they invited to what instances.
The ORGANIZERs CUA is already going to have to track objects
sent that are waiting replies. Match them up which is what
you are going to have to do anyway in order to clean up
the CUAs pending things to care about queue.

Send an iTIP REQUEST and process an iTIP REPLY. No new
method needed. No need to confuse a new invitation
with a modification to an existing instance.

> the recurring event.

With the RECURRENCE-ID you can only specify exactly
one instance of a recurring event. Did you say that
backwards?

> His reply to both will look

iTIP already covers this, send them a new REQUEST/VEVENT
with the newest dates they are requested to attend.
The newer object overrides the older. No need to invent
another method to do the same thing. That's why DTSTAMP
is in the object. To disambiguate exactly these kind
of cases.

Another option is to track the SEQUENCE per recurrence-rule-set
per UID. There is NO requirement that all ATTENDEEs see the same objects.
Then just bump the SEQUENCE number for each unique ATTENDEE
recurrence-rule=set sent - them map them back on REPLYs in the
CUA.

Another bug is that iTIP already says that if you add RECURRECE-ID
you are telling them to MODIFY the instance. Your adding
an ambiguity. If they do not have that UID, then they
could only make one conclusion, they missed the original because
they now have a modification. Now they have to guess, did I miss
the original that this is an update to?; or is this a new invitation?

If there does need to be a new way to invite someone (And I have
not seen any that are not already covered in iTIP), make
up a method that can not be confused with an instance
modification to a missed object.

> invite and send a REPLY that contained the RECURRENCE-ID.

This is new method of inviting someone that has not beep proposed
but has been declared as a solution to a problem that already
had a solution.

> him to two instances of the same recurring event I

Simply send him a REQUEST/VEVENT with the dates that
he is requested to attend and process the replies.
Ether by issuing a new multi-instance (contains recurrence
rules) REQUEST/VEVENT with a new DTSTAMP, or map the
SEQUENCE/UID/recurrence-rule-sets and map the replies
at the CUA.

--

---

From: "Michael Fair" <[email-masked]>
Date: Sat, 9 Aug 2003 00:55:17 -0700

> > Let's say we want to invite Satya to the Jan-5 instance.
> >
> > How does this unambiguosly tell me which instance Satya
> > is responding to.
>
> All of them that he was invited to attend.

This is totally ambiguous I invited him to two instances.
Let's say he accepted Jan-4 and declined Jan-5.
How does Satya specify a message that says that?

In the model I presented, Satya receives two components that
each contain a RECURRENCE-ID and none that contain a UID
only.  I receive a separate REPLY to each.  Each REPLY
contains a RECURRENCE-ID which exactly identifies what
the attendence status for each instance will be.
Because they happen to be for the same UID they can both
be put in the same iCal object.

In the model you just presented Satya receives 1 message
which contains each instance he's invitied too... Which
maens... that you are making a special new version of the
event, which is also a recurring event, but contains only
those two instances?

Where in the RFCs does it ever say that MUST, SHOULD, or
even MAY ever occur?!

UIDs are defined to uniquely and globally identify a component.
These new UIDs you are sending are only unique in the context
of the recipient's CUA, and are clearly ambiguous in your local
calendar store.

> Your thinking
> you have to to send 3 REQUESTs and get 3 REPLYs.

Right, you're inviting them to three instances of the event
each of which have an indepentent attendence status.
Satya will have to send multiple replies if there are mixed
accept/decline/counter responses anyways.

> It is

> tell the ORGANIZER when the ATTENDEEs are invited.

It doesn't.  It sets the fact that it invited the user at the
time it sent the REQUEST in its local copy of the instance by
setting the ATTENDEE partstat for Satya to "NEEDS-ACTION".
It places this ANTENDEE field on the unique calendar component
of the UID/RECURRENCE-ID it already has in the local store.

It does however rely on the REPLY's coming back from the
ATTENDEE to tell the ORGANIZER whether or not the ATTENDEE
has ACCEPT/DECLINE/COUNTER obviously.

> The ORGANIZER-CUA

Right.  As I said it adds them as an ANTENDEE to the calendar
component that represents those instances (the one with the
RECURRENCE-ID).  It has one copy of that instance component
that it shares with all attendees involved.

> the CUAs pending things to care about queue.

Wrong.  I can't see anything in the RFCs that says you have
to track objects sent.  The CUA just has to do two things.
Keep the most recent state of objects it has seen come through
its queue, and process messages as it comes through the queue.
It does not have to track which messages are in transit or
match up anything to what's in its queue.  It has one master
calendar store that it keeps all objects in, and it has one
or more methods through which it sends/receives messages.

A message comes in, that message references a unique object
in the store, that message gets processed and then discarded.

Any message that it sends out, it optimistically assumes it
reached its destination.  This is especially true given
several of the iTip references to missed messages, but this
one from 2.1.3 Component Revisions seems especially telling.

   In some circumstances the "Organizer" may not have received
   responses to the final revision sent out. In this situation,
   the "Organizer" may wish to send an update "REQUEST", and
   set "RSVP=TRUE" for all "Attendees", so that current
   responses can be collected.

The "Organizer" knows which people it believes haven't
responded (either because they never saw the response or
it was never sent) because the ATTENDEE partstat field is
set to "NEEDS-ACTION".

> with a modification to an existing instance.

There's nothing confusing about it as iTip spefically
states exactly how to do intrepret the message to figure
out if its an invitation or an update.  In fact it's
really simple.  If you have the UID in your store it's
an update, and if you don't, it's an invite.
AKA if you've ever seen that UID/RECURRENCE-ID before
this message is an update (SEQUENCE/DTSTAMP permitting),
otherwise it's a new invite.

This is simply Sending an iTIP REQUEST and processing an
iTIP REPLY and it confuses nothing.

< Example stuff leading up to this part snipped>

> > As a result, without the RECURRENCE-ID Satya can only

No, I need to specify exactly one instance, and I need
to specify one twice.

I also misrepresented your model.  I was not aware that
you were spawning off a new version of the UID to act as
a "Satya's version" of the same UID.  I thought you were
sending a single non-recurring event with the same UID
and SEQUENCE but different DTSTART.  Under this assumption
the UID ambiguously referenced the same two instances
because the RECURRENCE-ID was not present.

However, doing what you suggest is ta direct violation of iTIP.

This model demands a fragementation of the store to
track one special version of UID: 1 just for Satya
along with at least one other version of the UID for
the other ATTENDEES who got the original description
with the three instances.

This means that to identify a particular REPLY you
have to look at UID / SEQUENCE and ATTENDEE to figure
out which object in the store you are looking at which
is clearly not what the RFCs say.

For instance what if Satya wanted to COUNTER the invite?
Satya would send a message that used UID: 1 and no
RECURRENCE-ID which would ambiguously reference both the
UID: 1 that the original people received with three instances,
and the version of UID: 1 that Satya received with just two.

Further, to back up exactly why doing this fragmentation
is a violation of the RFCs, we have:

Property Name: UID

   Purpose: This property defines the persistent, globally unique
   identifier for the calendar component.

Your UIDs are not globally UNIQUE - you have different
versions of the same UID for different ATTENDEES in your
local store.  Further the UIDs on the ATTENDEES calendar
are also not globally unique, they are only locally unique.

It also does not say "This property used in conjunction with
ATTENDEE defines ..." as you are suggesting to use.

Then we also have:
   Property Name: RECURRENCE-ID

   Purpose: This property is used in conjunction with the "UID" and
   "SEQUENCE" property to identify a specific instance of a recurring
   "VEVENT", "VTODO" or "VJOURNAL" calendar component.

It does not say UID, SEQUENCE, and ATTENDEE to figure out which
instance.  It says UID and SEQUENCE only.  In your model the
SEQUENCE numbers for the various versions get out of sync any
time there's a rechedule that does affect every possible ATTENDEE
to any instance of the reccuring set.

For instance, if we add a Jan-6 instance to UID: 1.
Since Satya isn't invited to that instance there's no
need to rev Satya's version of the UID.  But there is
for any of the other ATTENDEE's, so UID: 1 is now at
SEQUENCE: 0 for Satya, and SEQUENCE: 1 for the others.
If Satya should send a REPLY at this point trying to
updating the attendance status for
UID: 1/RECCURENCE-ID: Jan-4, as per iTIP processing
rules Satya's message would be dropped since Satya is
reposnding at a SEQUENCE: 0 component version.

So to prevent this either you have to rev the version of
Satya's component to, which sends Satya a reschedule but
nothing has actaully changed, or you have to also use the
ATTENDEE property in conjunction with SEQUENCE and UID
property to find out if the message is valid.

And we also have:
   Property Name: ATTENDEE

   Purpose: The property defines an "Attendee" within a calendar
   component.

No where there does it say "and is also used to disambiguate
REPLYs to different versions of a UID created especially for
that ATTENDEE".

I'm sure I could go on, but I'll stop there for now.

> per UID. There is NO requirement that all ATTENDEEs see the
> same objects.  Then just bump the SEQUENCE number for each
> unique ATTENDEE recurrence-rule=set sent - them map them back
> on REPLYs in the CUA.

The binding of a SEQUENCE on a UID to the recurrence rule
set is exactly what iTIP and iCal call for, but it is a
global binding, identical for all CU, not tracked on a
per ATTENDEE basis.  Further, it is absolutely a requirement
that all ATTENDEES see the same objects as an implicit
extension that the UID used to create that component be
globally unique.  I'm sure there are other implicit
reasons which by extension demand global uniqueness....
The "Party Crasher" comes to mind since the REPLY does
not contain any ATTENDEE for which you have a record
of which version you actually sent them, nor is that
information necessarily in the REPLY - it might be -
but it's not required to be.

> the original that this is an update to?; or is this a new invitation?

No iTIP doesn't say this that is your misintrepretation of
something in the prose.  I request you find any supporting
evidence for this argument or cease with this assertion.
(I'd actually demand it, but there's little point in
 demanding anything online.)

iTIP is very clear on "If they do not have that UID" it
explicitly and undeniably states that's it's a REQUEST
"for a new VEVENT calendar component".

Eating my own requests, here are the relevant texts to back
up my argument, on both that a new UID with a SEQUNCE > 0
is for a new request AND that any such request can and MUST
include a RECURRENCE-ID if referencing a recurring instance.

From the iTIP sources:

3.2.2 REQUEST
    ... If the "UID" property value in

No where in there does it ever say anything at all about how
to use SEQUENCE,  nor does it say anyhing at all about
RECURRENCE-ID.  It just says "If the UID property value is
not found ... a new VEVENT ... "
(There is a single reference to SEQUENCE which just says that
 it is used as part of determining what a particular REQUEST
 message is, but SEQUENCE's use only occurs in later sections.)

So if I send a REQUEST with a UID/RECURRENCE-ID and the CUA
has not seen that UID before it's an invite.  However now we
could get a bit ambiguous because if I send a similar invite
to a different instance the CUA will have seen the UID as per
the first invite to the first instance.

This MIGHT lead someone to believe that this behavior would
work the first time but not the next.  As the next would then
specify some kind of update.  But the text specifically talks
about "a new VEVENT calendar component".  VEVENT calendar
components have very strict rules for figuring out exactly
which component on the calendar the message is addressing,
and those rules clearly state:

2.1.5 Message Sequencing
   1.  The primary key for referencing a particular iCalendar component
       is the "UID" property value. To reference an instance of a
       recurring component, the primary key is composed of the "UID" and
       the "RECURRENCE-ID" properties.

So therefore, to invite someone to "an instance of a recurring
component" (which happens to be a separate component in its own
right) you use its primary key.  Its primary key is the
UID/RECURRENCE-ID pair.

And therefore, the reference to "UID" in section 3.2.2, by
extension of being a reference to the primary key for the
calendar component being addressed (which may happen to be a
recurrence instance), maes it is pretty clear that the text for
section 3.2.2 and the others just like it should have either
read "the primary key property" or something along the lines
of "the UID (and if present RECURRENCE-ID) property".

Now in case that still wasn't enough to convince you.

We skip down to the sections that talk about updating an
event which is what you seem to think we would be doing:

3.2.2.2 Updating or Reconfirmation of an Event
   ...  If the recipient CUA of a "REQUEST"
   method finds that the "UID" property value already exists on the
   calendar and that the "SEQUENCE" property value in the "REQUEST" is
   the same as the value for the existing event, then the "REQUEST"
   method describes an update of the event details, but no rescheduling
   of the event.

Again it talks about if "the UID property value already exists"
and further that "the SEQUENCE property value is the same" then
it's an update.

So in this case it very clearly states that CUA MUST already have
the exact same UID _and_ SEQUENCE from the message on its calendar
in order for the REQUEST message to be treated as an update.

In the case that is has never seen that component before,
regardless of whatever the SEQUENCE value happens to be in
the message, it cannot consider it an update.

This leaves the only other possible operation the REQUEST
message could be:
3.2.2.1 Rescheduling an Event

   ... If the recipient CUA of a "REQUEST" method finds that
   the "UID" property value already exists on the calendar, but that the
   "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
   greater than the value for the existing event, then the "REQUEST"
   method describes a rescheduling of the event.

So in this case the CUA MUST have _some version_ of the UID
already on its calendar in order for the REQUEST message to be
treated like a reschedule.

Since it has never seen this component before it is impossible
for it to be on its calendar and therefore it is impossible
for the CUA to treat this REQUEST as a reschedule.

Neither 3.2.2.1 nor 3.2.2.2 tell the CUA what to do if the
supplied UID is not on its calendar.  And if it's never seen
the component before, then it is impossible for the component
to be on the calendar and therefore it is impossible to
treat a REQUEST message for a component they've never
seen before as any kind of an update, reconfirmation, or
reschedule by virtue of these two sections.  Since no other
sections in iTIP talk about how a REQUEST message can be
treated as an update, reconfirmation, or reschedule, it
is absolutely impossible for one to claim that a REQUEST
message, which contains a UID (and by proof above, inclusive
of possible RECURRENCE-ID) that the CUA has never seen before
can ever be considered an update, reconfirmation, or reschedule.

Cease possibly confusing people by claiming that it is a
modification or back it up with several corroberating
sections as I have done.

Further, since sections 3.2.2.1 and 3.2.2.2 do not say what
to do if the UID (and, by extension of being a possible
primary key component, the RECURRENCE-ID) is absent from
the calendar, you have to look somewhere else.

Only section 3.2.2 talks about this and it very explicitly
states that if the CUA has never seen the UID (which by
virtue of being a referrence to a unique calendar component
should actually have been either "primary key" or made a
reference to the possible RECURRENCE-ID that might required
to specify the component) then it is absolutely and without
question a REQUEST for a new VEVENT calendar component.

No where in the prose either implicitly or explicitly
does it ever say that a new VEVENT is only created when the
SEQUENCE is 0.  Further, it says _absolutely nothing_ about
what to do about the SEQUENCE property if it's never seen
the component.  If it's never seen the component specified
in the message, iTIP says one and only thing, it's a REQUEST
for a new VEVENT component.  If the SEQUENCE should happen to
be larger than 0, the VEVENT component just gets created at
the large SEQUENCE value and sections 3.2.2, 3.2.2.1 and
3.2.2.2 consistently, cleanly, elegantly, and harmoniously
define what to do in every valid message received.

> but has been declared as a solution to a problem that already

Not really, this is the existing method defined as I have
very explicitly described above.  Your method of tracking
different versions of UID is just a plain violation of
the RFC.  I'm not going to say it won't work as it just
might given that you fragment your calendar to keep track
of separate versions of the same UID for separate
individuals which allows you to keep a consistent
converstation which each person which will create the
illusion of a single object respective of each of the
ATTENDEES.  But if they ever share the same UID between
them without going through you first a whole lotta
trouble could occur.

> SEQUENCE/UID/recurrence-rule-sets and map the replies

As I said earlier this fragments my calendar to create
multiple versions of the same UID and adds ATTENDEE as
a new primary key to a VEVENT component which is a clear
a deliberate violation of both iTIP and iCal.

I will _simply_ do no such thing and purport that it
is an implementation of iTIP.  It would merely be a
proprietary implementation that happened to work with
iTIP a lot of the time.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Sat, 09 Aug 2003 09:38:55 -0600

> be put in the same iCal object.

Your ignoring the fact that is what you really sent in your
proposal was a modification to an existing iTIP object.
See iTIP "4.4.2 Modify A Recurring Instance"

You did not send out a new invitation, you sent out
a modification. Your not removing any ambiguity, your
adding one.

You could have copy/paste right from that section
and it was mostly your example.

--

---

From: "Michael Fair" <[email-masked]>
Date: Sun, 10 Aug 2003 01:42:07 -0700

> a modification. Your not removing any ambiguity, your

As we have repeatedly said, we are not ignoring that.
Why did you cut out the part of my post that explained
this?  Why didn't you respond to sections 3.2.2, 3.2.2.1,
and 3.2.2.2 where it describes in very clear detail what's
an update and what's not?

Let's take this again from the top in a simple
agree disagree method:

[For simplicitly sake we shall assume that only persons
who are ATTENDEES will receive copies of events.
Further, we assume that any changes, regardless of how
minor trigger a message to all listed ATTENDEES of the
event on which the change occured.]

1) You can create a VEVENT to describe a recurring event.
Agree/Disagree?

2) Whomever we invited to that recurring event receives
   a copy, and whoever we didn't invite doesn't get a copy.
  [as per the assumptions]
Agree/Disagree?

3) If we modify a particular instance of an event than
   the SEQUENCE number to reference that event is now 1.
   [This is true in either of our models.]
Agree/Disagree?

4) Adding a new ATTENDEE to that particular instance is
   a minor change which would trigger a message to all
   listed ATTENDEES which now includes or new invitee.
   [As per the assumptions]
Agree/Disagree?

5) The new invitee receives a "REQUEST" message for a
   VEVENT object.
Agree/Disagree?

6) The invitee's CUA (being iTIP compliant) must use
   section 3.2.2 of iTIP to determine what type of
   REQUEST message this is since that is the section
   that talks about how to determine what type of
   REQUEST a message is for VEVENT objects.
Agree/Disagree?

7) The REQUEST message the new invitee received, lists
   a VEVENT object with a UID that is not on its calendar
   since the CU has never been invited to this or any
   other version of this event before (regardless of whether
   or not SEQUENCE is 0 or there is a RECURRENCE-ID present).
   [As per the assumptions.]
Agree/Disagree?

8) Only section 3.2.2 itself, and none of its subsections
   talk about what a CUA should do if it receives a REQUEST
   message for an object which has a UID which it does not
   find on its calendar.  And further, both subsections
   3.2.2.1 and 3.2.2.2, which are explicitly about updates,
   contain the clause:

       If the recipient CUA of a "REQUEST" method finds that
       the "UID" property value already exists on the calendar

Agree/Disagree?

I'll wait for your response before drawing any conclusions.
-- Michael --

---

From: "Chris Olds" <[email-masked]>
Date: Sun, 10 Aug 2003 04:48:25 -0700

This side discussion of whether a new UID with a RECURRENCE-ID is an update or
a new request is obscuring the essential problem:

Using RECURRENCE-ID values fixed at SEQ:0 requires that CUAs track an
additional piece of data for each recurrence of an event that is not required
in the so-called 'delta' model (which I think of as a 'current-value' model,
because that's all a CUA needs to track in order to get things right).

Furthermore, the restriction on the number of RECURRENCE-IDs in a single
message means that many more messages must be sent (and recieved!) if the
responding CUA is to discover the SEQ:0 :: current-value mapping.  If my CUA
sees a SEQ value more than 1 more than any previous value it has for that UID,
I would hope it would send a REFRESH request to the organizing CUA - there
could have been arbitrary changes that I might want to know about, unless the
new object has no RECURRENCE-ID (in which case, it represents the entire
current state of the EVENT at that SEQ value, and is the same as what I would
expect to recieve as a reply to my REFRESH request).

So, which model requires more complicated bookkeeping?  RECURRENCE-ID fixed at
the initial value for the instance.  Which requires more messages to keep the
attndee's CUA in sync with the organizer?  Fixed.  If an attendee CUA is to
keep its SEQ:0 :: current-value mapping up to date, it must process one VEVENT
object per instance that has a current time different from the DTSTART it was
initially scheduled with.  These updates are problematic, since there is no
way to request that the organizer's CUA send such a set of objects that does
not risk missing new exceptions; furthermore, since different instances can be
scheduled to the same date & time in the fixed model, an attendee CUA may not
be able to ask for a refresh of an instance at a particular date and time (as
soon as there are more active RECURRENCE-IDs than distinct instance DTSTART
values, any RECURRENCE-ID could refer to any DTSTART, so while it may be
unlikely that a CUA won't get the data it wants, there is no way to be
certain).  The fixed RECURRENCE-ID model sure seems to me like both the model
that generates the most traffic and one most sensitive to missed messages -
the worst of both worlds!

All of this complicated bookkeeping and ambiguity can be avoided if the CUA
only has to keep track of the current valid DTSTART values for the event.  Any
object with a SEQ value equal to or only 1 more than the greatest value seen
can be processed without any more messages passing.  If no RECURRENCE-ID is
specified, the object is complete, and can be processed how much greater the
SEQ value is; the SEQ is more than 1 more than previously seen and a
RECURRENCE-ID is specified, then reqest a REFRESH from the organizer and
process the result.  Since this is a likely action for this case in either
model, it certainly does not imply extra message traffic, or a more fragile
pattern.

In an email previous to the one I'm responding to, Michael seems to be
proposing a third model, which I would call 'SEQ-per-instance'; since there
seems to be no way to determine what SEQ to use to send a complete object that
had some events updated (esp. updated different numbers of times), I don't
think it is workable within the context of RFC 2445 objects, and haven't
discussed it.

As for the ambiguity of a CUA seeing a VEVENT with a previously-unseen UID and
a RECURRENCE-ID, I think that a conservative CUA would probably process it as
a new request, but send a REQUEST to the organizer for the full event, so as
to be sure it wasn't missing important information.  This means that I agree
with all of the questions Michael asked (except #4: 'does adding an attendee
trigger messages to all Attendees?', where my answer is "Don't care.  This
seems like a matter between an Organizer and her CUA"), but overall, I think
that Doug is right and a CUA that gets such an object should assume it missed
a REQUEST VEVENT and ask for a REFRESH of the entire object.

    /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)

---

From: Doug Royer <[email-masked]>
Date: Sun, 10 Aug 2003 10:42:30 -0600

Michael Fair wrote:
> this?

Again - because you altered the example to ignore the problem.

--

---

From: Doug Royer <[email-masked]>
Date: Sun, 10 Aug 2003 11:45:10 -0600

>    [This is true in either of our models.]

Assume you have only created one VEVENT.

There is one VEVENT. That VEVENT can change over time.
Each distributed version of that one VEVENT is identified
by a CUA by its:

	UID/SEQUENCE/DTSTAMP

If that VEVENT has a recurrence rule, then each instance
of that one VEVENT is identified by a CUA by its:

	 UID/SEQUENCE/DTSTAMP/RECURRENCE-ID

>    listed ATTENDEES which now includes or new invitee.

Disagree. It is optional. Not all ATTENDEEs need
see the entire ATTENDEE list.

Think of a public event like a concert. Each ATTENDEE
would not need to know who else is attending. It is
optional.

Its not a protocol issue, its an application issue.
Some applications will need to send it to everyone.
Some will not.

> 5) The new invitee receives a "REQUEST" message for a

Agree.

>    REQUEST a message is for VEVENT objects.

Agree.

>    [As per the assumptions.]

As long as you do not make it look like a modification
to an existing VEVENT - agree.

>        the "UID" property value already exists on the calendar

Which is why you just send them a EVENT/REQUEST/UID with the
SEQUENCE number equal to the booked item SEQUENCE number.
Bruces 'new add attendee' method that looks like a modification
to an existing VEVENT is an unneeded and ambiguous addition
to the protocol. Just send them the vEVENT in a REQUEST.
Send them the current booked UID/SEQUENCE and timestamp
it with DTSTAMP to say this version of this one VEVENT.

Option 1:
  You may elect to send that same object (with the SAME SEQUENCE
  number as the other ATTENDEES have) with an updated DTSTAMP
  to ALL attendees.

    The "Organizer" of an event may also send unsolicited "REQUEST"
    methods.  The unsolicited "REQUEST" methods may be used to update the
    details of the event without rescheduling it, to update the
    "partstat" parameter of "Attendees", or to reconfirm the event.

Option 2:
  Only send the new ATTENDEE the new object.

If you do not want that flurry of REPLYs, don't send them to ATTENDEEs
that do not need to know about other ATTENDEEs.

If you want the other ATTENDEEs to know about all ATTENDEEs then
you are going to get a flurry of REPLYs for huge events. iCal/iTIP
were designed to work with unreliable (from the protocols point of view)
transports like e-mail where the ORGANIZER can not know if the recipient
got the message until the REPLY arrives. That *is* the protocol.

If someone feels there is a need to invite an attendee some new way,
then propose it. And make it unambiguous to the existing protocol.
So far no one has demonstrated or explained why they feel they need
that or why the current method does not work.

--

---

From: "Michael Fair" <[email-masked]>
Date: Sun, 10 Aug 2003 12:41:39 -0700

> to an existing VEVENT - agree.

Just because it might look like a modification to you doesn't
mean that it is one?  Sections 3.2.2.1 and 3.2.2.2 define the
only times a message can be a modification and the only times
a message can ever be a modification is when the CUA has the
existing UID on its calendar.

You are putting the cart before the horse.
i.e. You are putting the example before the definition.

Section 4.4.2 is an EXAMPLE of how to modify a recurring
instance.  It is not the definition of how to detect whether
or not a message is a modification of a recurring instance.

The definition of how to detect if a message is a modification
comes from section 3.2.2 we can't move on until we've resolved
this point as its critical to the proper interpretation of the
REQUEST message.

You assert that just because something looks like the
object in 4.4.2 it is a modification.  This is not true.

Anything that happens to actually be a modification will
look like 4.4.2.  But if it happens to be something else
it might look like 4.4.2 too.  A reconfirmation, a response
to a REFRESH, and a new invite will all look like 4.4.2.

Just because a message happens to look like it could be a
modification because it shares similar values to 4.4.2
doesn't mean that it is.  There are only two things that
can tell you if a request message is a modification of some
sort.  One is section 3.2.2.1 and the other is section 3.2.2.2
and neither of them are applicable if the CUA has does not
find the UID in question on its calendar.

Let me put this yet another way.  All of section 4 is examples.

As such they are theoretically not needed because the prose
above actually dictates what those examples will say. Right?

The examples are useful for creating some clarity around
what the text says sometimes, but it is not in any way shape
or form any kind of actual definition.  The examples are just
instances of the above sections.  In this case, example 4.4.2
happens to be an instance of section 3.2.2.1.

Section 3.2.2.1 is only valid "If the recipient CUA of a
"REQUEST" method finds that the "UID" property value already
 exists on the calendar".

If you send a REQUEST method to a CU and the CUA does
not have the corresponding UID on its calendar neither
section 3.2.2.1 nor 3.2.2.2 can be applied and therefore
the message cannot be a modification, reconfirmation, or
reschedule regardlesss of how much it looks like 4.4.2.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Sun, 10 Aug 2003 14:26:46 -0600

> instance.  It is not the definition of how to detect whether

So, is this a modifcation and you missed the original?
Or a new object?

    BEGIN:VCALENDAR
    METHOD:REQUEST
    PRODID:-//RDU Software//NONSGML HandCal//EN
    VERSION:2.0
    BEGIN:VEVENT
    UID:guid-1@host1com
    RECURRENCE-ID:19970701T210000Z
    SEQUENCE:1
    ORGANIZER:Mailto:[email-masked]
    ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:[email-masked]
    ATTENDEE:Mailto:[email-masked]
    ATTENDEE:Mailto:[email-masked]
    ATTENDEE:Mailto:[email-masked]
    DESCRIPTION:IETF-C&S Conference Call
    CLASS:PUBLIC
    SUMMARY:IETF Calendaring Working Group Meeting
    DTSTART:19970703T210000Z
    DTEND:19970703T220000Z
    LOCATION:Conference Call
    DTSTAMP:19970626T093000Z
    STATUS:CONFIRMED
    END:VEVENT
    END:VCALENDAR

--

---

From: Doug Royer <[email-masked]>
Date: Sun, 10 Aug 2003 14:26:22 -0600

> instance.  It is not the definition of how to detect whether

So, is this a modifcation? Or a new object?

    BEGIN:VCALENDAR
    METHOD:REQUEST

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 01:27:07 -0700

>     SUMMARY:IETF Calendaring Working Group Meeting

It could be any number of things depending on whether or
not I have an an object on my calendar with:
UID:guid-1@host1com

You have to go through the Nessage Sequencing rules of 2.1.5
and the REQUEST VEVENT rules of 3.2.2 to find out.

So I'll just do that and see where we end up:

   1.  The primary key for referencing a particular iCalendar
       component is the "UID" property value. To reference an
       instance of a recurring component, the primary key is
       composed of the "UID" and the "RECURRENCE-ID" properties.

So applying that, this message is referencing object:
UID:guid-1@host1com
RECURRENCE-ID:19970701T210000Z

The object being referenced is an instance of a recurring event.

   2.  The secondary key for referencing a component is the "SEQUENCE"
       property value.  For components where the "UID" is the same, the
       component with the highest numeric value for the "SEQUENCE"
       property obsoletes all other revisions of the component with
       lower values.

This object references the SEQUENCE:1 version of this component.

  3. ...
[ Point 3 applies to "REPLY" messages and is therefore skipped ]

  4. ...
[ Point 4 won't apply in this particular instance since we won't
  have the problem of matching SEQUENCE numbers in this case.
  but it is somewhat relevant to the overall converstaion. ]

--------------------------------
Ok so given that, we now exactly what object this is talking
about and where it fits in the overall order of messages.

UID:guid-1@host1com

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

So now we go to section 3.2.2 about VEVENT REQUESTS:

The CUA then references its Calendar looking for UID referenced
and it doesn't find it.  Therefore this request is for a new
VEVENT calendar component.  Specifically it's a new request
for component:

UID:guid-1@host1com

The answer to your question stops there.  It's a new object.

The fact there's a SEQUENCE jump of more than one (null to 1)
only clues the CUA in to the _possibility_ that it _might_
have missed something.  After its processed the new request,
including any REPLYs it might send in response, it SHOULD
move on to dealing with the possibly missed message but it
is not required to.

----

So what should the CUA do about this inconsistency.
I'll make a stab at what a highly intellingent CUA might do
pulling from the RFC to figure out what the CUA's options are
and then make some intelligent(?) suggestions.

First, all sections that I have found which give the CUA clues
about how to handle the fact that something has been missed are
marked MAY or SHOULD.  So anything I come up with are not demands
just suggestions.  In the sections below I pull from all
over iTIP.  I'll try to keep it to just the relevant bits.

Conclusion:
There is nothing that explicitly handles our case but I believe
there is enough implications to say that the CUA must put the
object it received onto the calendar exactly as is, and it
should send a REFRESH to the ORGANIZER for the UID without the
RECURRENCE-ID.

Support:
As you will see, in our example case, where the CU has only
been invited to one instance of the recurring event, it will
never actually receive a response to the master event for
which it sent a REFRESH request.  If it receives any response
at all, it will merely be a duplicate of what it already had.
The CUA will be left with only that one instance.

This is good actually, because that's what was intended.
But it doesn't change the fact that the CUA should still
send the REFRESH request.

All that being said.... where to begin....

How about why it should place the object exactly as is,
as one instance of a recurring event for which it has no
set description yet, on the calendar.

I pull that from three sections really:

First we have:

    2.1.5 Message Sequencing
        Hence, CUAs must persist the following component properties:
        "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP".

This implies that every component has a RECURRENCE-ID.
In the cases where it is absent, that RECURRENCE-ID is null.
But this does make it very explicit that the authors clearly
intended the CUA to do bookkeeping that included the tracking
of a recurrence-id on the components.  This mandate makes
it possible to even consider doing such a thing.

and the second section:

    3.7.1 Working With Recurrence Instances
        ...
        the protocol is designed so that each recurring instance
        may be both referenced and versioned.
        ...

This makes it pretty clear that the authors intended a
calendar component with a RECURRENCE-ID has its own independent
SEQUENCE value and that tracks an independent version for just
that instance.  This makes it even clearer that the instances
have a SEQUENCE all their own and have independent versioning.

And lastly, the third section:

5.2.1 Cancellation of an Unknown Calendar Component.

   When a "CANCEL" method is received before the original "REQUEST"
   method the calendar will be unable to correlate the "UID" property of
   the cancellation with an existing calendar component. It is suggested
   that messages that can not be correlated that also contain non-zero
   sequence numbers be held and not discarded. Implementations MAY age
   them out if no other messages arrive with the same "UID" property
   value and a lower sequence number.

This talks about not being able to correlate objects on the
calendar with the object in the message.  This of course is
about cancellations which we aren't doing, but it does suggest
something interesting to us:

   It is suggested that messages that can not be correlated
   that also contain non-zero sequence numbers be held and
   not discarded.

This suggestion implies that a CUA should expect to do something
useful with the message.  So the implication I draw from here
is that CUA in effect should assume that this is an update to
an instance of an event for which it has not yet received the
parent description object and the message should have an action
take equivalent to the message being "held and not discarded".

This however means there are two options.  Hold it and don't
put it on the calendar.  Or put it on the calendar and discard
the message.  The problem with not putting it on the calendar
is that the CUA may never receive the base event because the
CU was not invited to it or the transport mechanism may have
just lost it.  Further, if the CUA puts it on the calendar,
then the message can just be discarded which lowers its burden.

But one thing is clear about this example, the authors want
the CUA to take optimistic action in regards to the messages
it receives.

As a result of all those texts being present makes it pretty
clear to me that an instance of a recurring event is intended
to be treated as a first class citizen component equal in
treatment to any other singleton event.

Special provisions have been made that allow a CUA to avoid
actually taking up bits on the disk for each instance unless
that instance is renegotiated.  This makes sense.  Why take
up disk space for an event if you don't have to.  If there
is no per instance data/differences to track for the event,
then the parent object is totally sufficient to describe that
instance and thus there is no missing info.

However, in this case, the CUA doesn't have the parent object
so there is no existing instance to update.

This component is still a first class event and the CUA should
take optimistic action on the message.  Therefore it should be
placed on the calendar, and its version set to SEQUENCE:1.

It should be treated like a singleton whose primary key is:
UID:guid-1@host1com
RECURRENCE-ID:19970701T210000Z

------

But, the fact that we did not receive a SEQUENCE:0 of
this indicates that the CUA possibly missed something.

If this was just an ordinary singleton we wouldn't care.
We'd assume that we had the latest version and just move on.
And respective of the singleton instance that this object
is, that's exactly what we do.  We won't be sending a REFRESH
request for the instance (i.e. UID/RECURRENCE-ID pair).

But being that this is an instance of a recurring event
and that we have no prior SEQUENCE for that event we
should do something.

We can draw some inferences for what do from:

4.7.2 Bad RECURRENCE-ID

   Component instances are identified by the combination of "UID",
   "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request
   to an "Attendee", there are three cases in which an instance cannot
   be found.  They are:

   1.  The component with the referenced "UID" and "RECURRENCE-ID" has
       been found but the "SEQUENCE" number in the calendar store does
       not match that of the ITIP message.

<snip>

   In case (1) ... If the "SEQUENCE" number of the "Attendee's"
   instance is smaller, then the "Organizer" is sending out a newer
   version of the component and the "Attendee's" version needs to be
   updated.  Since one or more updates have been missed, the
   "Attendee" SHOULD send a "REFRESH" ...

In reality there are at least four cases, and ours is the one
missing.  This example section only addresses cases where the
UID has been found which in our case it isn't.

But case (1) is similar if we optimisticly assume that the CUA
should have received the parent object and further assume
that the instance actaully exists (a fairly safe assumption),
then case (1) says we should send a "REFRESH" to the "ORGANIZER"
to get the latest copy of the event.

This request will be a request for the parent event and not
the instance, and as such will not contain a RECURRENCE-ID.

But consideration must be taken as to what will actually
happen when the ORGANIZER receives that REFRESH request.

Section 6.1.7 says:
6.1.7 Unauthorized REFRESH Requests

   It is possible for an "Organizer" to receive a "REFRESH"
   request from someone who is not an "Attendee" of an event
   or to-do. Only "Attendee's" of an event or to-do are
   authorized to receive replies to "REFRESH" requests.
   Replying to such requests to anyone who is not an
   "Attendee" may be a security problem.

Since the sender is an ATTENDEE of the instance component
only, it is only authorized to receive replies for that
singleton component.  As a consequence, the ORGANIZER's
CUA should not send the requested response.  It should
go through the recurrence set and send a reply for all
instances that the ATTENDEE has been invited to, but
this will be one iTIP message with multiple VEVENT
components that each have a RECURRENCE-ID.  Not one
component with a UID that matches the original component
that the ATTENDEE was not invited to and no RECURRENCE-ID.

-- Michael --

---

From: "Chris Olds" <[email-masked]>
Date: Mon, 11 Aug 2003 02:52:45 -0700

On Mon, 11 Aug 2003 01:27:07 -0700, Michael Fair wrote
> not I have an an object on my calendar with:

and then goes on to show, with good support, that a CUA receiving this should
a) place it in the calendar (or do whatever it does for REQUEST VEVENT objects
w/o a RECURRENCE-ID and
b) send a REFRESH request to the Organizer.

However, at the very end, there is an unsupported statement:

> CUA should not send the requested response.

This is not supported by the RFC paragraph quoted.  6.1.7 talks about a
REFRESH request from someone not an attendee to the event.  If an event
consists of multiple instances, the fact that an attendee is invited to only
one of them does not exclude her from the set of attendees!  An Organizing CUA
that is capable of sending a single instance of an event to an attendee
without generating a new UID (which it could easily do), is surely capable of
forming a response that only includes those instances to which that attendee
is invited.

>  It should

Why not?  This should be simple enough to do, since the Organizing CUA has all
of the pertinent data, including the identity of the requesting CUA.  Nothing
in the RFCs I've read suggest that this is what MUST happen, nor even that it
SHOULD.  This seems like a lot of trouble to go to, and while it may be
necessary to send such a set of VEVENT objects if one subscribes to the
'RECURRENCE-ID fixed at SEQ:0' dogma, it is not necessary in the
'current-value' interpretation, and both would require that a VEVENT object be
sent w/o a RECURRENCE-ID at some point, or the cycle will continue
indefinitely (since each REQUEST VEVENT with a RECURRENCE-ID to an attendee
will, as Michael has shown, result in a REFRESH being sent back to the
Organizer w/o a RECURRENCE-ID, if the Organizer responds by sending back N
VEVENT objects with RECURRENCE-IDs, it will recieve between 1 and N additional
REFRESH requests, and so on, and so on...  this seems Very Bad Indeed...).

Again, 'RECURRENCE-ID fixed at SEQ:0' causes more messages; by Michael's
interpretation, it might even cause an exponential growth in messages, with no
end at hand!

'current-value' semantics for RECURRENCE-ID are simple, consistent,
error-reistant, and require less bookkeeping and fewer messages.  The fact
that reading the RFCs and using common definitions for 'original' and 'change'
supports this view is just gravy, IMHO.

    /cco

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 10:01:38 -0600

So, what't the answer? Was the orgignal missed or not?

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 10:12:59 -0600

> b) send a REFRESH request to the Organizer.

Correct - you unconditionally have to do a REFRESH if some use
it as a way to add an attendee, because if it looks like it might
be a modification and it is used for both purposes. You will
never know.

So if we allow this to be used for both purposes then each
receiving ATTENDEE will have to do a REFRESH and it will generate
5 packets per ATTENDEE:

	(1)The original (ORGANIZER -> ATTENDEEs)
	(2)Its REPLY    (ATTENDEEs -> ORGANIZER)
	(3)A REFRESH    (ATTENDEEs -> ORGANZIER)
	(4)A full-object REQUEST (ORGANIZER -> ATTENDEEs)
	(5)REPLY.       (ATTENDEEs -> ORGANZIER)

So lets not use it for that purpose.

If the ORGANZER sends a full-REQUEST to effected (or all)
ATTENDEEs:

	(1) The origanal (ORGANZIER -> ATTTENDEEs)
         (2) Its REPLY    (ATTENDEEs -> ORGANZER)

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 09:57:43 -0700

No the original was not missed.

The ATTENDEE is not invited to the original so the
ATTENDEE was never sent it and therefore did not
miss it.

-- Michael --

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

---

From: [email-masked]
Date: Mon, 11 Aug 2003 12:51:52 -0400

> an event add the RECURRENCE-ID.

Please show me any iTIP text or restriction table that says RECURRENCE-ID 
is only for a modify!  In the mean time I suggest you mull over the text 
above and how Section 2.1.5 factors in with it.

> That model will not work.

Not in your implimentation but it works fine as a general model.  Ive 
shown exactly how it works just fine on Friday but you seemed to have 
missed that posting.

> you keep asserting is your way? 

Sure, there are 2 bits of iTIP that come to mind.  Section 2.1.5 Message 
Sequencting:

and Section 3.2.2 REQUESTs restriction table:

The 0 is for non-repeating components, the 1 is for "referring to an 
instance of a recurring calendar component" which I think an invitation to 
a specific instance qualifies for. 

The Section 2.1.5 text says that if the iTIP method is for an instance of 
a recurrence set then the RECURRENCE-ID is used along w/the UID.  If its 
NOT there then you are not referring to an instance (or range of 
instances), you are referring to the entire set w/that UID.

> to an ATTENDEE for ANY time, why do you insist that RECURRECE-ID

Because the REQUEST is for a particular instance, thats why.  If I were 
referring to the set then Id just use UID, otherwise I MUST use 
RECURRENCE-ID to identify the instance the REQUEST is referring to.   Are 
you suggesting that a REQUEST with no RECURRENCE-ID is actually referring 
to an instance of a repeating set by the omission of the property?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 11:18:59 -0600

> No the original was not missed.

Yes - it was. Your CUA is now out of sync.

> ATTENDEE was never sent it and therefore did not

Perhaps I mis e-mailed the original to this list, I guess that is
why you miss-guessed and thought it was a new ATTENDEE.

--

---

From: [email-masked]
Date: Mon, 11 Aug 2003 14:42:12 -0400

> All of them that he was invited to attend. 

So your answer is that he cannot do this??  Michael asked how does Satay 
differentiate the instance he is REPLYing to and you say that he responds 
to "all of them that he was invited to". 

This is another drawback to the changing RECURRENCE-ID model over the 
fixed model.  With a fixed model Satay can easily and unambiguously 
identify the specific instance in question.

Another thing that Im not sure if Michale noted was that in order for 
Satay to be added to the 4-Jan case the REQUEST MUST be crafted such that 
Satay will destroy his current version of the UID and recreate it with 
just the information in the REQUEST.  All this even if his 5-Jan 
participation has not changed.  (Plus this assumes that the 4-Jan and 
5-Jan instances share the same data).

> Your thinking
> of exactly one instance at a time. 

Thats because the REQUEST was regarding the 4-Jan instance, not all or a 
subset of them.

>                                     What if I want someone

Wrong.  Go recheck iTIP Section 3.2.2 REQUEST:

   For the "REQUEST" method, multiple "VEVENT" components in a single
   iCalendar object are only permitted when for components with the same
   "UID" property.  That is, a series of recurring events may have
   instance-specific information.  In this case, multiple "VEVENT"
   components are needed to express the entire series.

so a single REQUEST is all thats necessary; it can contain the definitions 
of the individual instances as they currently are.  Since the REPLY is 
either for an instance, contiguous subset of instances (RANGEs)  or the 
entire set you will need to send back the proper number of respones. 
However it can be done in 1 iCalendar stream of data and does not need to 
be in 3 separate actual, say, emails.  In addtion the data in the REPLY is 
considerably less that whats in the REQUEST (just the ATTENDEE, DTSTAMP, 
ORGANIZER, RECURRENCE-ID, UID and SEQUENCE properites) its not as great a 
demand or impact as you imply.

> the dates/times they are requested to attend. (see how

This does not always work as you claim, see my other postings on this 
matter and on the implicit assumptions you make.

> tell the ORGANIZER when the ATTENDEEs are invited. 

Its NOT just a matter of saying what instances they were invited to, its a 
matter of matching their responses to the correct instance defintions. 

> sent that are waiting replies. 

You dont wait for REPLYs, they can be sent at any time by the invitees for 
any reason they choose.  The Organizer tracks their participation status 
based on the REPLYs they send as it matches it to the correct instance in 
questions.  Ive repeatedly shown that it only takes 5 steps to make this 
matching 100% guesswork and you have yet to disprove this.

>                                 Match them up which is what

You have totally omitted factoring in message missequencing or message 
loss in transit.

> with a modification to an existing instance.

Your interpreation has NO way to distinguish a new invitation from a 
missequenced reschedule.  You may be thinking of some pure CAP 
implemenation that processes the users pending queue but this is iTIP we 
are talking about now and NOT some CAP implementation you did.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 13:37:14 -0600

[email-masked] wrote:
> So your answer is that he cannot do this??

No. I said the he would REPLY to all of them he
was invited to attend.

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 14:15:00 -0700

For an analysis of why the fixed-id does not create an infinite
loop see the end of the post.

> REFRESH request from someone not an attendee to the event.
> If an event consists of multiple instances, the fact that an
> attendee is invited to only one of them does not exclude her
> from the set of attendees!  An Organizing CUA that is capable
> of sending a single instance of an event to an attendee
> without generating a new UID (which it could easily do), is
> surely capable of forming a response that only includes those
> instances to which that attendee is invited.

First, UID is one event, UID/RECURRENCE-ID is a different event.

In the UID only properties of the event the CU is not list as an
ATTENDEE and can never be listed as an ATTENDEE lest they be
invited to all instances of the recurring event.  So therefore
6.1.7 stands as used.  The ORGANIZER receives a REFRESH
request for UID only.  The CU isn't an ATTENDEE of that event.

The only way this might be possible if you fragment the event
to make two versions of the same UID, one for the ATTENDEE and
another for every one else.  Which leads me to second, this
violates the mandate that a UID be globally unique.  You now
have two objects of different forms with the same UID and no
other iTIP compliant disambiguating values.

As just an example of one case where this is a sever issue,
let's say that the ATTENDEE sent a COUNTER response.

In your model they will have received an object with a UID and
no RECURRENCE-ID.  At best it will be a recurring event with
only one RDATE, at worst it will just be a singleton.
Using the best case scenario the CUA might send a COUNTER
to just the individual instance in which case you lucked out.
Also using the best case scenario the CUA might detect that
the CU wants to reschedule every instance of the event (since
there is only one instance described in the event) and send
a COUNTER to the UID only component with a new RDATE.  Using
the worst case scenario, the CUA will send a COUNTER message
to the UID only event trying to turn it into a singleton at
a new time.

In anything but the best case scenario with some luck, they
will be sending a COUNTER message that attempts to redefine
the original recurring event.  No where in the RFCs does it
ever instruct an ORGANIZER's CUA to track independent versions
of the same event for different ATTENDEES.  And in fact it
actually says in both iCal and iTIP that you can't do that.
They say this both explicitly and implicitly every time they
talk about global uniqueness, updating a master copy (not
copies) over which only the ORGANIZER has rights to, and
that they expect CUs will pass these objects around to each
other for purposes of delegation and FYI (as indicated by
the reference to a "Party Crasher" which the ORGANIZER
never invited).

As two other examples of where your model breaks apart we
have 3.2.2.3 Delegating to another CU and 3.2.2.6 Forwarding
to an uninvited CU.  Let's use two different people, A and B,
who are invited to separate instances of a recurring event.
In your model, they each will have received an object with
no RECURRENCE-ID which describes a single different date
and time.  If B decides they can't make it, and wants to
delegate to A, or they decide they think A should be invited
as well, A's CUA will be totally confused about the message.
The message from B describes an event which it has on its
calendar, but has a different primary key.  It will have to
apply the message SEQUENCING rules and if the SEQUENCE number
doesn't catch the DTSTAMP value will certainly place the
incoming message as either an old message or one that looks
like an update that didn't come from the ORGANIZER.

Assuming that A's CUA was ultra brilliant and managed to
figure out what was going on it now has the responsibility
of sending a REPLY to the ORGANIZER.  How will the ORGANIZER
unambiguously know what's going on?

In the case of delegation, because B has to send a REPLY to
the organizer as well as A, it will be possible for the
ORGANIZER's CUA to figure out that it should be expecting
something from A that has an event which is actually B's
event merged with A's event (where in the RFC's does _ever_
talk about merging events), _if_ it magically on its own
accord receiving no instruction from the RFCs also treats
the ATTENDEE as part of the primary key for an event.

In the case of B just extending the invite to A, A's reply
when put through the message sequencing rules is just going
to look very strange.  First, just following the iTIP rules
there should only be one version of the same object at any
given time, your model extends the primary key to include
the ATTENDEE, but even then how is the ORGANIZER's CUA
supposed to figure out what just happened.  It's totally
ambiguous as to what the content of the REPLY is actually
going to be...  A had an original version of the UID object,
B invited A to a different version of the same object which
rather than throwing it out as a missequenced message or an
update from someone other than the organizer it decided to
treat as an invite to a separate instance of a recurring
event (why and how it did this I have no clue, I'm just
trying to make your model fit the reality of what needs
to happen here).
At this point A must formluate a reply to the ORGANIZER,
but I can't for the life of me figure out what it should be.

"A" might have two singleton events with differing versions
which it now merges  (despite all the confusion this causes),
to construct a single recurring event with two instances. I
guess it sets the SEQUENCE and DTSTAMP fields to the values
from the "most recent" singleton and just prays that's the
right answer....

"A" might have two recurring event descriptions which
each describe a different single instance which it again
must merge (despite all the glaring violations this causes
especially of 6.1.7).  Again, I guess the SEQUENCE and
DTSTAMP should just be set to the values of the
"most recent" object.

This model gets so convulated when the messages get passed
around because it is in total violation of the assumption
of the authors.  That there would be _one_, globally unique,
uniquely identifiable object that could be distributed
across the Internet without confusion.  The only thing
they then had to do was figure out how to version the
objects so that CUAs could figure out if what they were
looking at was an older or more recent version of the
event which brought about SEQUENCE and DTSTAMP.  They
then associated different semantics to each.

Updating SEQUENCE means something that would violate the
partstat field of the ATTENDEES and DTSTAMP was any for
any other non-triggering update.

So assuming you're still reading at this point, I'll go on.

> Why not?

Because to do it any other way would either violate the global
uniqueness of the UID or imply the CU was invited to event
instances that it wasn't.

> Nothing
> in the RFCs I've read suggest that this is what MUST happen,
> nor even that it SHOULD.

You're right.  There is nothing in the RFCs that talks directly
about this.  There is no example of inviting an ATTENDEE to a
single instance.  There is only the document that should be
internally consistent enough to indicate how this should be
done.  Sadly, it unfortunately isn't, as we both have enough
evidence from the text to defend two very different standpoints.
We have to resort to figuring what the chain of messages in
each model will be to figure out which one holds more water
within the text as a whole.

I also never implied that it MUST do this.  In fact, I very
explicitly said that it had every right just to drop the
message on the floor.  The original recurring event is a
globally unique entity in its own right as must be each
instance of it.  Otherwise CUs passing around messages to
each other (which they are explicitly granted the right to
do) will confuse both each other's and the ORGANIZER's CUA.

I simply said that the most useful interpretation of that
REQUEST is to send a response that included all instances
of the event that the CU was invited to and therefore that's
what the ORGANIZER's CUA should do.

> This seems like a lot of trouble to go to, and while it may be
> necessary to send such a set of VEVENT objects if one subscribes
> to the 'RECURRENCE-ID fixed at SEQ:0' dogma, it is not necessary
> in the 'current-value' interpretation, and both would require
> that a VEVENT object be sent w/o a RECURRENCE-ID at some point,

This last part isn't actually true.  The fixed-id model never
requires a UID without a RECURRENCE-ID object to be consistent.

I will finish out what the CUA does with the response it gets
from the intelligent ORGANIZER which contained a copy of every
instance it was invited to with all objects containing a
RECURREINCE-ID and no object without one.

The recipient CUA would follow the rules as outlined in
2.1.5 Message Sequencing, and 3.2.2 REQUEST for each object.
As such it would go through each instance one by one, and
assuming that it had not missed any other messages it would
find that it found every object referenced and all the
SEQUENCE numbers for each object matched.

At this point it stops.

It processed the entire message and had no problems identifying
any of the objects being referenced.  If it had missed any
messages, then at least one of the SEQUENCE numbers would be
wrong, and section 4.7.2 Bad RECURRENCE-ID would apply which
for the dumb recurring event CUA would cause one last REFRESH
cycle (which I agree is wasteful).

For the smarter CUA it could use the fact that it has already
sent a REFRESH once, it has received a message that conatins
objects of which it found every one and would assume that it
was not invited to the base UID onnly event and not do the
REFRESH cycle again.

This creates the following semantics:

The CUA will send a REFRESH to the ORGANIZER only when it
receives a message for an object with a UID that it cannot
find or the SEQUENCE for any particular instance jumps more
than 1 point.  This means that it will only send a REFRESH
the first time it is invited to its first instance of that
recurring event, or when one of the instances jumps more
than one SEQUENCE number.

This will at worst cause one and only one REFRESH/REQUEST
cycle, lest more missed messages are introduced into
the queue.

> error-reistant, and require less bookkeeping and fewer messages.
> The fact that reading the RFCs and using common definitions for
> 'original' and 'change' supports this view is just gravy, IMHO.

Ok, let's try and follow that "error resistant" train.
First, from above I've shown you why it is a total violation
of the intent of global uniqueness, and the real world problems
with versioning a UID per ATTENDEE.

Now let's talk about the presence of missed messages.

First, let's just say we're talking about very normal
activity where we invite everyone to every meeting.

Let's call SEQ:0 "every Monday for this year".

Every responds in the affirmative that they will attend.
The ORGANIZER, just being nice, sends an update to inform
everyone of the new ATTENDEE status changes.

Now let's say we add a comment to the first instance.
For arguments sake we'll say it says '1st instance'.
This forces the CUA to track some per instance info
for this event which it must persist.
This sends an update to the attendees with RID:1st Monday
and SEQUENCE:0 that sets the comment.  No big deal.

So now we move the 1st instance to Tuesday due to some
major failure the message gets delayed and no one receives
it and the ORGANIZER isn't aware so doesn't resend it.

In the 'current-value' model the official SEQUENCE on
the ORGANIZER's calendar is now 1 and the official RID
is now "1st Tuesday".  There is an inconsistency on
the CUs calendar as they have SEQUENCE:0 and RID:1st Monday.

So now we move the same instance again to Wednesday.
This RID:1st Tuesday and SEQUENCE:2

There is no failure and everybody gets this message.

Everybody now receives a message for RID:1st Tuesday which
none of them have, to now be 1st Wednesday.  Given sections
2.1.5 and 3.2.2 the CUA must put this on the calendar
as a new invitation.
This means they now have two meetings scheduled.
The original Monday version at SEQUENCE:0 and
the new Wednesday version at SEQUENCE:2.
There is nothing in the RFC that says they have to do
anything further at this point.

Dumb CUAs will just let it sit there.  Smarter CUAs
will notice the inconsistency and ask for a REFRESH.
This is what the CUA should do, but it doesn't have to.

Let's say that before the REFRESH answer arrives, the
delayed message shows up.

Since in this model there is only one SEQUENCE  value
that all instances share, and it's lower than the most
recent value we've seen for that UID.  We throw the
update out.  It's old and no longer valid.

If however the 'current-value' model concedes that
each instance tracks its own SEQUENCE as section 3.7.1
dictates, then it process the message as an update
to the 1st Monday instance.

This still creates the wrong situation where there are
two events in the first week, one now on either Monday
or Tuesday depending on whether or not you processed the
message and one on Wednesday.

So now the response to the REFRESH shows up.  The only
valid response it could be in this model is one where
it has rescheduled the set to be every Monday this year,
except the 1st Monday, and an RDATE of 1st Wednesday
with the SEQUENCE set to "2".

This makes the CUA touch every instance of the recurring
event for which it has per instance data and update the
persisted SEQUENCE value to 2.

Finally it has this now bogus event on its calendar at
Monday or Tuesday depending on how you processed it and
so it must delete it since it's not listed in the master
UID object.

In the presence of missed or delayed messages the
'current-value' model must live with invalid calendars
until a full copy of the most recent information arrives.

In the fixed-id model missed messages only result in
dealing with older, but at one time valid data.

Redoing this same example with the fixed-id model
we get the following:
1) Schedule every Monday, accept it, add the comment.
   (no big deal)
2) Miss the Tuesday move
   Again CUs end up with same calendar as above.

3) Receive the Wednesday move.
   Since the fixed RID is still set to '1st Monday'
   The CUA correctly moves the Monday instance to
   Wednesday and updates its SEQUENCE to 2.

At this point dumb CUAs who don't do anything have
and keep a consistent calendar with all info they
have seen to date and nothing is inconsistent with
the actual view the ORGANIZER has.
Smart CUAs will detect the 0 to 2 jump and ask for
a REFRESH.

The old "move to Tuesday" message will show up and
the CUA will accurately identify it as a reference
to the fixed-id '1st Monday' but with SEQUENCE:1
which is less than the 2 it currently has for that
component and discard it.

The response to the refresh will show up and the
data it has on its calendar will exactly match
what's in the message, it will do nothing and
stop there.

This is only a mild example of what can get screwed
up using a 'current-value' model.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 16:35:22 -0600

> other iTIP compliant disambiguating values.

Only UID/SEQUENCE/DTSTAMP or UID/SEQUENCE/DTSTAP/RECURRECE-ID
is globally unique in content, not UID by itself. And yes each
of unique SEQUENCE and DTSTAMP for a UID are going to be different
anyway as that is how you differentiate between the different versions
of objects representing the same UID. Why would you think that
the ATTENDEE property should be an exception to that?

> to the UID only event trying to turn it into a singleton at

The ORGANIZER CUA can tell because the ATTENDEE sends what
they want DIFFERENT than what they were sent. If the ATTENDEE
does not include (because they did not get) an recurrence rule.
No problem. Then they are COUNTERing the one instance.

If an ATTENDEE removed any recurrence rule it is sent then
the ATTENDEE would be telling the ORGANIZER they wish
to remove the additional instances.

No conflict.

> of the same event for different ATTENDEES. 

The ORGANIZER CUA will already have to know what each ATTENDEE was
invited to - simply compare what they were invited to attend
with what they send, mask out what they were not invited to
and any difference is their COUNTER proposal. In my experience
there are always going to be exceptions to invitations. Customers
cancel meeting and reschedule them all of the time. Reservations
are continually changed and canceled. I would hate to think
that 100% of all attendees would need to see all of the changes
for 100% of all of the other attendees. And as they are not
all required to see all of the other attendees, there ARE
unique to ATTENDEE packets. Yes - there is going
to have to be attendee specific packets sent.

And because iTIP says:

    Hence, CUAs must persist the following component properties: "UID",
    "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP".  Furthermore, for each
    "ATTENDEE" property of a component CUAs must persist the "SEQUENCE"
    and "DTSTAMP" property values associated with the "Attendee's"
    response.

And as the ORGANIZER CUA *will* know what they were invited to and
what they REPLYed to and could be countering.

I do not see a problem.

> And in fact it

> the reference to a "Party Crasher" which the ORGANIZER

The over the wire protocol is not the same as the object
itself. The object itself is undefined because of the different
models for calendaring and scheduling. What works for a car
rental agency will not work for a massive company. iCAl/iTIP
specify how to transfer the data, they are not the booked
object itself.

> as well, A's CUA will be totally confused about the message.

Why?

> calendar, but has a different primary key.

Why? Will the UID/SEQUENCE/DTSTART be changed before forwarding
to 'B'? No, so where is the problem?

> It will have to

Who cares where it came from? It is valid or not.
If your are the delegatee, then process it.

> unambiguously know what's going on?

Because of 'SENT-BY', 'DELEGATED-FROM', 'DELEGATED-TO' and
perhaps more. The object will be tagged (if compliant)
and the ORGANIZER will parse the object sent from B.

The ORGANIZER matches them up to what the ORGANZIER sent
to 'DELEGATED-TO' as recieved from the original ATTENDEE.

And from iTIP:

Cut from iTIP, A == ORGANIZER, 'C' = ATTENDEE delegator
  and 'E' == delegatee, my comments in ().

"C" got a REQUEST from "A".

  "C" sends a REPLY to "A" with the ATTENDEE. "partstat" parameter set
  to "delegated" and with a new "ATTENDEE" property for "E".
  "E's" ATTENDEE delegated-from" param is set to "C".

(that how ORGANIZER knows)

  "delegated-from" param is set to "C". "C's" ATTENDEE "delegated-to"
  param is set to "E". "C" sends REQUEST message to "E" with the original
  meeting request information. The "partstat" property parameter for "C"
  is set to "delegated" and the "delegated-to" parameter is set to
  the address of "E". An "ATTENDEE" property is added for "E" and the
  "delegated-from" parameter is set to the address of "C".
  ...

 > ...cut... (I'll respond to the other points in separate email)

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 17:04:59 -0600

> instances that it wasn't.

IUD's are only unique to the booked object. IUD's are
not unique over the wire by themselves.

> within the text as a whole.

So whoever invented a way that breaks single instance modifications?
No. I do not think it is going to make it into iCal-verion-next.

> RECURREINCE-ID and no object without one.

It't not relevant if it is indistinguishable from a single
instance update. And so far NO ONE has supplied any reason
or need to make add attendee look like a single instance update.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 17:29:02 -0600

Michael Fair wrote:

> single instance. 

iTIP 3.2.2 REQUEST

It gives instruction on how to invite an attendee and it is
not restricted to single or multiple instances.

And the example in "4.2.1 A Group Event Request" is for
a SINGLE instance VEVENT. Why do you think what the initial
SEQUENCE number is when an ATTENDEE is invited matters?
It does not matter.

An ATTENDEE could be delegated-to a single meeting
at SEQUENCE:30. It makes not difference.

The ORGANIZER-CU and/or DELEGATED-FROM-CU does not need to tell
every ATTENDEE about every meeting they will not be attending in
a series of meetings. That is often good business practice.

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 16:34:55 -0700

All I can say Doug is show me the code.

Please show me the chain of messages that go between
the different CUA's and what in iTIP tells each CUA
how to process these messages.

Here's the task.

Given the following event with you as the ORGANIZER:
UID:1
SEQUENCE:0
DTSTART:Friday, Jan 3rd, 2003 at 6pm UTC
DTEND:Friday, Jan 3rd, 2003 at 7pm UTC
RRULE:FREQ=WEEKLY
ORAGANIZER;PARTSTAT=ACCEPTED:Doug

Invite user A to the 1st instance (RID: 1st Friday).
Invite user B to the 2nd instance (RID: 2nd Friday).

Now have B forward the invite to A and tell me why
(citing iTIP) A's CUA doesn't get confused.
What the REPLY that "A" send you to accept looks like.
And how (again using iTIP) your CUA knows what is
going on.

You can use "O", "A", and "B" to reference the given parties.
I will make efforts to understand shortcuts like "SEQ" for
SEQUENCE, and "RID" for "RECURRENCE-ID" and others as long
as its not confusing.  In fact, if you're right, you won't
use a single RECURRENCE-ID property in the whole sequence
of messages.

You provided no evidence or messages or even message
fragments you simply said to "process the message".

I'm telling you that a CUA can't process the message
because the messages it is getting are borked respective
to the message sequence rules and REQUEST processing
rules of iTIP.

I'm assuming you're thinking I'm just dense and maybe
I am, I'm willing to admit when I've made a mistake,
even one as big as the lengthy thread we've got going.

So here's your chance to prove it.  You show me why
using iTIP processing rules you can get away with
what you are suggesting.  There are still other
things to sort out, but I can at least withdraw my
argument that this is impossible to do within iTIP
using the methods you've described.

(Note: At no point in iTIP does it ever say anything
       about a CUA tracking which ATTENDEES it has
       sent which messages.  It only talks about
       tracking responses in relationship to a given
       event.  A given event is only identified by
       its UID/RECURRENCE-ID (in which the RID may
       be null).  The SEQUENCE and DTSTAMP properties
       or only used to figure out which versions of
       two identically identified events is most recent.
       So any argument that relies on knowing which
       version was sent to an ATTENDEE is violating
       the RFC and will have no support.
       Further, you claim that all ATTENDEES do not
       have to be kept abreast of the current state
       of things.  However they absolutely can be
       if the implementors chose such a path.  So
       your model must support that.  If it does not
       it is also in violation of the RFC demands.)

-- Michael --

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 16:38:32 -0700

You're out of context.

a "single instance" is not a singleton event.  It
was a short form of "single instance of a recurring
event" which I figured would be understood since that's
what this entire conversation has been about.

I'm sorry if I confused you.

-- Michael --

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 18:38:14 -0600

> I'm sorry if I confused you.

No confusion as there is no difference to the ATTENDEE
receiving a VEVENT with  no recurrence rules who would
not and perhaps should not have any idea if the ORGANIZER had
invited others to that booked UID. So if they get part or
the entire copy of the booked VEVENT makes no difference
to them as they could not tell anyway.

And that is my point. iTIP already tells you how to
invite an ATTENDEE. And the ORGANIZER is already
going to have to track ATTENDEE instance attendance.

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 18:11:44 -0700

> going to have to track ATTENDEE instance attendance.

They track the instance attendence in the components
referenced by the UID/RID.

Let's assume a world where everyone always got all
information.  I know it's not how you work, but it
is allowed by the RFC and I think it makes things
easier because you just know that everyone always
gets everything (no intellignece needed).

If I do a "REFRESH" on a UID/RID I'm asking for
the latest version of that component which, in our
transparent world of pretend for the moment, will
include the attendence status for each of the
attendees of that instance.

If I do a "REFRESH" on just a UID that references
a recurring event I am asking for the latest version
of that component which, in our transparent world of
pretend for the moment, will include not only the
base attendence list for the master component, but
will also include the attendence status for each
and every attendee in every instance where something
is different.

That is why the recurrence instances can be
separately "referenced and versioned".

However doing this does not mean that the ATTENDEE
property in any way, shape, or form is ever even
considered when attempting to identify how to
process the event, or which component of the
calendar the message is referencing.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 19:26:29 -0600

> how to process these messages.

Here is the answer: Read iTIP the example is in iTIP.
It goes through great pains to explain that process.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 20:06:11 -0600

> referenced by the UID/RID.

iTIP:

And as it says **Attendee's response** it is talking about the
ORGANIZER CUA.

> attendees of that instance.

No, it will include the attendee status of at least
yourself and MAY include other attendees. It could
be a massive security problem at public events.
Lets see if the president is attending, at which game.

We covered this before. Do you disagree?

> and every attendee in every instance where something

No. As explained above.

If it did, then it still does not mean that the object
sent to that attendee contains instances where that attendee
does not need to know about and for the reasons explained above.

There is no reason that an attendee need to know who is
attending or when other meeting are taking place.

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 20:59:22 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> It goes through great pains to explain that process.

I read it.
It's not there.
Prove it.
Tell me which sections to read.
The section does not exist.
If you cannot cite me a section number(s) I will take
that to mean that you are just bull headed and cannot
admit when you're wrong.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 21:28:36 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> And as it says **Attendee's response** it is talking about the

Now what I think you meant here is that the values of "SEQUENCE"
and "DTSTAMP" associated with the "REPLY" from an Attendee are
stored in the Organizer's CUA, I totally agree with.

The Attendee's responses must be stored on the ORGANIZER's CUA
which contains the master copy of the event and any responses
different to that of the master are stored in the instance
component that represents the instance.

This is so that the ORGANIZER's CUA can figure out whether
or not a REPLY is more or less recent than the one it already
has.  No where does iTIP say that information stored with
the Attendee's response can or should be be used to
disambiguate an event component when you have multiple
copies of it floating around.  It even says you can't
have multiple copies of the same UID (except for different
SEQUENCE/DTSTAMP values).

That section of iTIP is so that the ORGANIZER's CUA can
figure out whether or not an Attendee has responded to
the latest version of an event, and whether or not the
REPLY is has just received is newer or older then the
one it already has.

> We covered this before. Do you disagree?

Yes I disagree.  And the last time we covered it was
under the same circumstance.  I laid out certain
assumptions (valid within the RFC) that defined the
behavior of the RFC.  I identified when I was using
the assumption to dictate certain values that would
be contained in the response.

I said the CUA will always send all information.
Therefore it will always send all information.
It's my CUA to dictate that with.  This CUA is not
in violation of the RFCs and that is the behavior
I requested.  If you believe that the behavior
violates the RFC in some way the say so, point out
where it says that it is in violation, and assuming
I read it to be in violation as well I will alter
the assumption or concede the argument (if the
assumption was the foundation of the argument).

If you can't operate in the context of assumptions
for the purposes of establishing common ground then
this conversation is going to be longer than I thought.

> > and every attendee in every instance where something

Yes. As explained above.
(This conversation goes nowhere really fast)

> does not need to know about and for the reasons explained above.

I said that was the behavior of the CUA and therefore it must
send out all information.  That behavior does not violate the
RFC.  It matters not that the behavior isn't required, it's
the behavior I defined for the purposes of the conversation.

> attending or when other meeting are taking place.

First, all Attendees are attending all meetings because that's
what I said so they do need to know about all meetings.  Or
don't you understand what a declared assumption is?  Or do
I need to put it in some other format so that you can
understand it?

Or are you just afraid that if I was actually allowed to
demonstrate the points you'll find out I was right and
your model will fall apart?

I say let the models defend themselves, we just describe
the appropriate behavior that model will take and decide
if it is desirable/acceptable.

If you have an example where you think the fixed-id model
breaks down please let us know and we can discuss it and
hey, you might even be right about it.  We will simply
represent the fixed-id model as best we can and use iTIP
and iCal to defend why that behavior is the correct one.
We will also put the 'current-value' model under the same
microscope and see each performs.  The answer should be
in the results of running the models through trials not
bickering back and forth.

-- Michael --

---

From: [email-masked]
Date: Tue, 12 Aug 2003 10:13:26 -0400

> a modification. Your not removing any ambiguity, your

Doug is having a big problem trying to distinguish an invitation from a 
reschedule from an update given the existing iTIP text and trying to 
factor in message missequencing or loss.  He has repeatedly asked 
questions like "How do you disambiguate that from an update to a missed 
object?" or inaccurately said things like " you are proposing a new way to 
invite ATTENDEEs."

Tom (Robert) and I have repeatedly pointed to the exact text in iTIP that 
says how you differentiate the overloaded REQUEST method.  iTIP Section 
3.2.2 REQUEST says:

                                   If the "UID" property value in
   the "REQUEST" is not found on the recipient's calendar, then the
   "REQUEST" is for a new "VEVENT" calendar component.

and since we are dealing with a repeating instance the key value (per iTIP 
Section 2.1.5) is UID / RECURRENCE-ID and not just UID alone.  iTIP 
Section 3.2.2.1 Rescheduling an Event describes detecting a reschedule as:

and again since we are dealing with a repeating instance the key value to 
use is UID / RECURRENCE-ID instead of just UID.  iTIP Section 3.2.2.2 
Updating or Reconfirmation of an Event describes a non-reschedule update 
as:

                               If the recipient CUA of a "REQUEST"

and the same UID / RECURRENCE-ID primary key would be used here since we 
are referring to a repeating instance.

This is NOT a new proposal as Doug suggests; its merely reading and 
understanding the existing iTIP text. 

So why does Doug not understand these distinctions?  The answer is because 
this does not work for his delta RECURRENCE-ID model. 

The texts above CANNOT be used with a model where the key used to first 
identify the instance in question changes on each reschedule!  Why you may 
ask?  Simple, because if you cannot follow the chain of reschedules for 
each instance, you cannot accurately match the UID / RECURRENCE-ID value 
in the REQUEST with the correct instance you have.  Even Doug has agreeded 
(albeit tacitly) that the ONLY way to handle this case is to destroy ALL 
instances the recipient has and to ask the Organzier to recreate them all 
using a "full REFRESH".

If you understand the fixed RECURRENCE-ID model, you would see that this 
is NEVER EVER necessary; lost or missequenced messages are NEVER a problem 
because you can easily match the REQUEST to the correct instance.

Despite Dougs wishes to the contrary, missed REQUESTS (invitations OR 
reschedules OR updates) to any instance are never a concern in the fixed 
RECURRENCE-ID model since the newer (ie: higher valued SEQUENCE) REQUEST 
is a full snapshot of that instance and as such NOTHING in the obsoleted 
(missed or recieved) REQUESTs matters.  If you rely on Dougs delta 
RECURRENCE-ID model then you will find that each REQUEST does rely on 
items in previous REQUESTS: DTSTART, RECURRENCE-ID and SEQUENCE.  This is 
not a fault tolerant design and thats exactly why we moved away from them 
before we passed Last Call.  (If you can find the early iCalendar / iTIP 
drafts you will see we did use a delta model for a while and then we ran 
into fault tolerance concerns for iTIP and we changed the design).

Doug has also persisted in claiming that iTIP says that no RECURRENCE-IDs 
are in an invitation.  This is patently false.  There is not shred of text 
or restriction table in iTIP that even remotely says this.  Does anyone 
see text to this effect in the citations above?  I didnt think so.  If you 
check the restriction tables it makes NO mention of this.  Not even the 
examples in the back of iTIP that Doug is designing to say this!   So 
where does this idea come from?

Simple, it derives from the delta models need to get the repeat instances 
information to the invitees BEFORE any workflow can proceed.  Otherwise 
the invitee has no way to start the process!  However even that is a 
failed assumption because it is perfectly legal and legit to NEVER 
reschedule the instances and to later add someone.  Lets see how...

For example, Bob, Pat and Doug agree to have a daily conference call each 
day this week on the remaining CAP issues.  They decide on the times 
during the last call (or they play phone tag) and then Pat sends out the 
REQUEST to Bob and Doug confirming it.  Bob REPLYs his acceptance and adds 
a COMMENT:I think Steve should be on the last one for final agreement. Pat 
agrees and she sends Steve the following invitation:

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1com
   RECURRENCE-ID:20030815T210000Z
   SEQUENCE:0
   ORGANIZER:Mailto:[email-masked]
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:[email-masked]
   ATTENDEE;ROLE=REQ-PARTICIPANT;PARSTAT=ACCEPTED:Mailto:[email-masked]
   ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:[email-masked]
   ATTENDEE;ROLE=OPT-PARTICIPANT:Mailto:[email-masked]
   DESCRIPTION:IETF-CnS Conference Call on CAP issues.  Lets review
    the issues left on the table\, what to do with them\, and the
    solutions to the issues we solved.
   CLASS:PUBLIC
   SUMMARY:IETF CalSch Conf Call - CAP Issues
   DTSTART:20030815T210000Z
   DTEND:20030815T220000Z
   LOCATION:Conference Call: 800.555.1212\, Call 12345
   DTSTAMP:20030812T093000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

According to Dougs version of the iTIP model, Pat would NOT send a 
RECURRENCE-ID on the REQUEST since its the invitation.  However this is 
semantically wrong: no RECURRENCE-ID means the entry is non-repeating (or 
you are referring to the entire set of instances if it is).  iTIP clearly 
shows RECURRENCE-ID in its restriction table:

and it sounds as if Doug does not grasp the meaning/use correctly.  Since 
Pat is only inviting Steve to a single instance, the REQUEST is therefore 
referring to a particular one and as such needs to have the RECURRENCE-ID 
in it.  The reason that Doug says this is how he woudl send it is because 
thats the only way he can send it in the delta RECURRENCE-ID model; he has 
to first send Steve the definition of the instances before he can do ANY 
workflow on them.

However this is NEVER described in iTIP nor is it needed if you look at 
iTIP with iCalendars fixed RECURRENCE-ID model.  Since each instance can 
be distinctly referenced no matter its SEQUENCE (and thus no matter if 
iTIP messages are missequenced or lost), there is no need to first send a 
defintion and then send other REQUESTS.

If Pat needed to reschedule the Friday instance for some reason then she 
can send a reschedule to everyone that looks like:

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1com
   RECURRENCE-ID:20030815T210000Z
   SEQUENCE:1
   ORGANIZER:Mailto:[email-masked]
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:[email-masked]
   ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:[email-masked]
   ATTENDEE;ROLE=REQ-PARTICIPANT:Mailto:[email-masked]
   ATTENDEE;ROLE=OPT-PARTICIPANT:Mailto:[email-masked]
   DESCRIPTION:IETF-CnS Conference Call on CAP issues.  Lets review
    the issues left on the table\, what to do with them\, and the
    solutions to the issues we solved.
   CLASS:PUBLIC
   SUMMARY:IETF CalSch Conf Call - CAP Issues
   COMMENT:Some of us cannot make that time so Im moving it back an
    hour since that worked before.
   DTSTART:20030815T220000Z
   DTEND:20030815T221000Z
   LOCATION:Conference Call\: 800.555.1212\, Call 12345
   DTSTAMP:20030812T093000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

That assumes of course you dont ignore the iCalendar paragraph that 
exactly matches this example: the RECURRENCE-ID stays at the original 
Friday date/time. 

If you look at misordering of the delivery for these 2 to Steve (or say 
the 1st REQUEST got lost) using Dougs delta RECURRENCE-ID model then Steve 
has NO way to know if this is an update or a reschedule to an instance he 
should know about or if this is Pats invitation to him.  Now, depending if 
you correctly apply iTIP Sections 2.1.5 and 3.2.2 Steve would treat this 
like an invitation (correct behaviour; incorrect potential results though) 
or not (incorrect behaviour; potential results are unknown).

Under the delta RECURRENCE-ID model, since Steve cannot distinguish 
between a missequenced reschedule REQUEST and an invitation REQUEST, the 
only thing he could do would be to throw it away and ask Pat to resend a 
REQUEST with no-RECURRENCE-IDs in it.

Hmm, an interesting idea but since REFRESH allows for ATTENDEEs to ask for 
REFESHs on particular RECURRENCE-IDs (check iTIP) I have to wonder why 
this is in iTIP if RECURRENCE-ID values can change on each reschedule. 
There would be NO certain way for the Organzier to correctly determine 
exactly which RECURRENCE-ID the ATTENDEE is referring to since there is NO 
SEQUENCE property on the REFRESH. 

Why does it matter you ask?  Simple, if the models intent was to be able 
to refresh a particular instance (_exactly_ what iTIP 3.2.6 says) then 
there is no need for SEQUENCE since the REFRESH was targeted at a 
particular instance.  This works ONLY for a fixed RECURRENCE-ID model 
since its unambiguous which instance the REFRESH with RECURRENCE-ID  is 
referring to.  Otherwise the Organzier has NO way to know which actual 
instance the RECURRENCE-ID refers to!

If you follow the above 2 REQUESTs to Steve using iCalendars fixed 
RECURRENCE-ID model then you will see that missequencing or loss is NOT a 
problem and Steve can easily deal with it with out any back and forth full 
REFRESHs.  After all, if one REQUEST can get lost, so can the "full 
REFRESH" REQUEST that Pat sends.

I seemed to added more than intended here but I have done so in the hope 
that it would be clear to folks (maybe even Doug) that:

1: NONE of my analysis are "new proposals" as Doug would have everyone 
think; I was simply analyzing how iTIP would perform using Dougs delta 
RECURRENCE-ID model and the iCalendar fixed RECURRENCE-ID model.
2: The iTIP process is only fault tolerant if the RECURRENCE-ID model is a 
fixed one; a delta RECURRENCE-ID model is fault prone and hard to recover 
from completely (no guarantees there even).
3: Doug is adding new semantics that simply do NOT exist in iTIP for 
determining invitation from other meanings of REQUEST (ie: SEQUENCE cannot 
be 0 or RECURRENCE-ID cannot be on the invitation) are simply NOT in iTIP 
no matter how much one wishes for 'em.  These are all artifacts of how 
iTIP _needs_ to function if you adopt a RECURRENCE-ID model, its not how 
iTIP is currently written.

Bruce
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 10:00:27 -0600

[email-masked] wrote:
> object?" or inaccurately said things like " you are proposing a new way 
> to invite ATTENDEEs."

Bruce is having a hard time understanding that his proposed model
does not work.  And yes Bruce if you want I'll keep asking the
question:

    How do you disambiguate your new proposal for inviting an
    attendee from an update to to a missed object?

And:

    What is your justification for the need to invent another method
    to invite attendees?

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 11:37:39 -0600

[email-masked] wrote:

> 
> So why does Doug not understand these distinctions?  The answer is 
> because this does not work for his delta RECURRENCE-ID model.  

Why does Burce ignore all facts that show that it makes the object
indistigushable from an object with a missed original?

> 
> Doug has also persisted in claiming that iTIP says that no 
> RECURRENCE-IDs are in an invitation. 

I can also show *LOTS* of examples of when it will work.

Why will Bruce not debat the case when it does not work?

Did Bruce already implement his application and its too late?

--

---

From: [email-masked]
Date: Tue, 12 Aug 2003 13:56:52 -0400

Doug pondered on 08/12/2003 12:00:27 PM:
> does not work. 

Once again you must have a different dictionary than the rest of us.  My 
postings you consider proposals for some model have been clearly labeled 
and formatted as an analsysis.  Ill just chalk this as another dictionary 
discrepancy like 'original'.

>And yes Bruce if you want I'll keep asking the
> question:
> 

Once again Ill point you to iTIP Sections 3.2.2 REQUEST, 3.2.2.1 
Rescheduling an Event and 3.2.2.2 Updating or Reconfirmation of an Event. 
3.2.2 says:

and for repeating instances the value used to see if the instance can be 
found "on the recipient's calendar" is UID / RECURRENCE-ID.  That is, if 
you understand iTIP Section 2.1.5.  If not, you use the wrong key to see 
if the instance in question exists. 

>     What is your justification for the need to invent another method

If the instance exists then you use SEQUENCE (and DTSTAMP) to determine if 
the REQUEST is a reschedule (3.2.2.1) or not (3.2.2.2).  A reschedule is 
determined by:

and an update is determined by:

and if you correctly apply iTIP Section 2.1.5 your CUA would use UID and 
RECURRENCE-ID for the lookup to make this determination before applying 
SEQUENCE (and DTSTAMP) checking.

Doug is trying to create some new semantics that are not currently in 
iTIP.  iTIP defines semantics for interpreting a REQUEST on the recipients 
side NOT the senders; no matter how you want them to.  Thats why the 
phrase "on the recipients calendar" is used often; because how its 
interpreted depends on what you have on your calendar so far.   If you can 
consistanly and accuratly identify the instance in question then a missed 
invitation is no problem; the 'reschedule' that gets sent becomes the 
invitation and workflow is restored, well only for the fixed RECURRENCE-ID 
model. 

This 'recipient centric' phrasing in REQUEST is _only_ a problem if you 
have a model where you cannot consistanly identify the instance in 
question of a repeating set.  The delta RECURRENCE-ID model Doug promotes 
is such a model as my analysis (not proposal Doug) on Friday showed.  It 
should start becoming clear that a fixed RECURRENCE-ID is the model in 
iCalendar and iTIP given all the faults inherent in the use of a changing 
RECURRENCE-ID model.  After all, how can bullet 1 of Section 4.7.2 in iTIP 
work if the RECURRENCE-ID changes?  The UID and RECURRENCE-ID values could 
not match the correct instnace at different SEQUENCE values if the value 
changed every time...

Bruce

---

From: [email-masked]
Date: Tue, 12 Aug 2003 14:22:03 -0400

> indistigushable from an object with a missed original?

The problem of distiction is ONLY an issue for your delta model Doug.  Its 
NOT a problem for a fixed RECURRENCE-ID model as Ive already shown.

In case its not clear still, since any later REQUEST obsoletes the 
pervious ones (per iTIP 2.1.5) then SO WHAT if you missed fixing a typo 
and a change in LOCATION?!?  The new REQUEST has an even more current 
LOCATION than the missed REQUEST!  Since each REQUEST is a full snapshot 
of the instance then if you get a "more recent version" (higher 
SEQUENCE/DTSTAMP) before you get an "older version" (lower 
SEQUENCE/DTSTAMP) then no big deal; you simply add it to your calendar and 
things are back on track.  Well, you can ONLY safely do that with the 
fixed RECURRENCE-ID model and NOT with Dougs delta model.  This is why he 
still has a problem differentiating. 

In order for this to work for Dougs model, you MUST get each REQUEST in 
order.  There is NO fault tolerance here as Ive shown because Doug cant 
match the RECURRENCE-ID to the instance the Organzier was referring to. If 
you use iCalendars fixed RECURRENCE-IDs then it is fault tolerant and 
errors are easily recovered from.

> I can also show *LOTS* of examples of when it will work.

You have yet to show 1 analysis where the delta RECURRENCE-ID model works 
and recovers from missequenced or lost messages.  If you could, you would 
have shown them in response to my analysis on Friday.  Still, Im 
interested to see where you the analysis from Friday was mistaken given 
the current text in iTIP.

> Did Bruce already implement his application and its too late?

Several vendors have implemented iTIP this way and with good reason.  Its 
FAULT TOLERANT and EASILY RECOVERABLE.  Your prescious delta model falls 
far short in these areas as Ive readily demonstrated.

PLUS we did NOT try to impart any new semantics based on NON-EXISTANT iTIP 
prose like "Invitations cannot be at SEQUENCE:0" (where the heck did you 
read that??) or "RECURRENCE-IDs cannot be in an invitation" (again, where 
the hell did you get that????)  We simply implemented whats in iTIP as it 
stands now (correctly understanding Section 2.1.5 even).

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 13:05:19 -0600

[email-masked] wrote:
> Once again you must have a different dictionary than the rest of us.

Once again you ignore the faulty case in your model. Why?

--

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 13:04:39 -0600

[email-masked] wrote:
> The problem of distiction is ONLY an issue for your delta model Doug. 
>  Its NOT a problem for a fixed RECURRENCE-ID model as Ive already shown.

Once again you ignore the problem in your model - why?

You simply ignore email that shows the bug. Then you repeat
the cases where it works.

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 12 Aug 2003 14:20:03 -0700

> Once again you ignore the problem in your model - why?

Aside from the fact that you seem to be doing the same thing.
I'll try and answer the question.

We have responded to every suggested fault you have chosen
to submit.  We have shown in every case why the fixed-id model
supports what you claim it does not.

When you have told us that we are ignoring it, we have asked
you to either provide a pointer or to repeat yourself which
you have not done.

I'm asking you now Doug.
What error or shortcoming are we ignoring?
I promise to respond to it in the followup post to yours.
At the end of the email I will either admit there's a
problem or declare that your assertion is wrong.  Further
I will put the 'current-value' model through the same test.

Since I am obviously, in your eyes, an incompetent reader who
can't grasp what you are saying please treat me as someone
who needs to be led by the bit to what you want me to see
about this particular failure you seem to say we are ignoring.

> the cases where it works.

The only case that I can recall where you purported a bug
in the fixed-id model was the case where you said it had
a problem with overlapping DTSTARTs of different events.

Assuming that you need this answer repeated to you I will
demonstrate using the fixed-id model how we can take a
recurring event of 4 instances, reassign them all to start
at the exact same DTSTART in different locations, and then
put them all back where they were.

I will use SEQ for SEQUENCE and RID for RECURRENCE-ID
please don't let slight modification confuse you.

Step 1 the recurring event:
BEGIN:VCALENDAR
METHOD:REQUEST
BEGIN:VEVENT
UID:1
SEQ:0
RDATE:Jan-3
RDATE:Jan-4
RDATE:Jan-5
RDATE:Jan-6
Location:A
END:VEVENT
END:VCALENDAR

Now for those of who would like a summary of every component
that this object has, this is what it looks like:
UID:1/SEQ:0/RDATE:Jan-3/.../RDATE:Jan-6/DTSTART:Jan-3/Location:A
UID:1/RID:Jan-3/SEQ:0/DTSTART:Jan-3/Location:A
UID:1/RID:Jan-4/SEQ:0/DTSTART:Jan-4/Location:A
UID:1/RID:Jan-5/SEQ:0/DTSTART:Jan-5/Location:A
UID:1/RID:Jan-6/SEQ:0/DTSTART:Jan-6/Location:A

Step 2 move the Jan-4/5/6 instance's DTSTART time
to Jan-3 and put them in a separate location:

BEGIN:VCALENDAR
METHOD:REQUEST

BEGIN:VEVENT
UID:1
RID:Jan-4
SEQ:1
DTSTART:Jan-3
Location:B
END:VEVENT

BEGIN:VEVENT
UID:1
RID:Jan-5
SEQ:1
DTSTART:Jan-3
Location:C
END:VEVENT

BEGIN:VEVENT
UID:1
RID:Jan-6
SEQ:1
DTSTART:Jan-3
Location:D
END:VEVENT

END:VCALENDAR

Now for those of you still reading a summarized description
of each component in this state would be the following:

UID:1/SEQ:0/RDATE:Jan-3/.../RDATE:Jan-6/DTSTART:Jan-3/Location:A
UID:1/RID:Jan-3/SEQ:0/DTSTART:Jan-3/Location:A
UID:1/RID:Jan-4/SEQ:1/DTSTART:Jan-3/Location:B
UID:1/RID:Jan-5/SEQ:1/DTSTART:Jan-3/Location:C
UID:1/RID:Jan-6/SEQ:1/DTSTART:Jan-3/Location:D

Now again, to put them all back:

BEGIN:VCALENDAR
METHOD:REQUEST

BEGIN:VEVENT
UID:1
RID:Jan-4
SEQ:2
DTSTART:Jan-4
Location:A
END:VEVENT

BEGIN:VEVENT
UID:1
RID:Jan-5
SEQ:2
DTSTART:Jan-5
Location:A
END:VEVENT

BEGIN:VEVENT
UID:1
RID:Jan-6
SEQ:2
DTSTART:Jan-6
Location:A
END:VEVENT

END:VCALENDAR

Done. That's it.

Here's the final state summary of each component:
UID:1/SEQ:0/RDATE:Jan-3/.../RDATE:Jan-6/DTSTART:Jan-3/Location:A
UID:1/RID:Jan-3/SEQ:0/DTSTART:Jan-3/Location:A
UID:1/RID:Jan-4/SEQ:2/DTSTART:Jan-4/Location:A
UID:1/RID:Jan-5/SEQ:2/DTSTART:Jan-5/Location:A
UID:1/RID:Jan-6/SEQ:2/DTSTART:Jan-6/Location:A

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

Ok Doug, your turn.  Please show me how to do this
same example using your 'current-value' model.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 16:13:19 -0600

>>Once again you ignore the problem in your model - why?

I showed you the problem. Your responded to it. And
you still pretend I did not explain it.

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 12 Aug 2003 15:38:43 -0700

When did you show me the problem?
What email?