Subject: RE: Uniquness of 4.4.2 Modify A Recurring Instance

From: Satya Vempati <[email-masked]>
Date: Mon, 18 Aug 2003 12:32:13 -0700

I cannot see how the current-value-recurrence-id model and the
fixed-recurrence-id model can interoperate. If you (as an attendee) ask
for a REFRESH for a UID and RECURRENCE-ID from the
current-value-recurrence-id model, your recurrence-id does not match
anything that the organizer (who follows the fixed-recurrence-id model)
has.

How can you do a REFRESH with a UID+RECURRENCE-ID (i.e. one instance of a
recurring event)?

-----Original Message-----
From: Doug Royer [mailto:[email-masked]]
Sent: Sunday, August 17, 2003 9:32 AM
To: [email-masked]
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance

Satya Vempati wrote:
>>From my point of view, this discussion is academic. Since all major
> implementations use the fixed recurrence model, anyone who wants to
> interoperate with the likes of Exchange, Notes etc. will need to use the
> fixed recurrence-id model. Will you implement systems that work with 95%
> of the market or the other 5% (even if it is right)?

The nice thing about the model in iTIP - it works with both.
Thas has been one of my points over and over. The only thing
that causes confusion is Brurce's propisal that inviting someone
and making it look like an instance modificaiton. That independently
breaks both models.

The assertion that Exchange does not work with the iTIP model
is bogus. I have no idea why anone thinks that - I can not get
it to fail using the iTIP model.

-- 

  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: Mon, 18 Aug 2003 13:55:53 -0600

> How can you do a REFRESH with a UID+RECURRENCE-ID (i.e. one instance of a

It's ugly, but if the CUA only asks for full REFRESH, then they
can always go back into sync.

The only time a CUA should need to do a REFRESH is when the
(as Michael put it) CUA gets a 'fishy' object.

And the uniqueness of an invitation VS the RECURRENCE_ID issue
(the subject of your email) are orthogonal. That is Bruces
proposal to invite an ATTENDEE with an instance modification
is independent of the RECURRENCE-ID model used.

I will now unconditionally do a full REFRESH if given a RECURENCE-ID
in a REQUEST for a UID that I do not have. Again ugly but if
people are going to use instance modification for invitation
I do not know of any other fix.

--

---

From: [email-masked]
Date: Mon, 18 Aug 2003 16:14:11 -0400

But a Full refresh response would be all the events with their 
Recurrence-ids
_____________________
Note: new email address

[email-masked]

Doug Royer <[email-masked]> 
Sent by: [email-masked]
08/18/2003 03:55 PM
Please respond to
"[email-masked]" <[email-masked]>

To
"[email-masked]" <[email-masked]>
cc

Subject
Re: Uniquness of 4.4.2 Modify A Recurring Instance

--

---

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

> But a Full refresh response would be all the events with their 

If I get an INSTANCE modification to an instance that does not exist,
then I'll do a REFRESH.

What do you do when you get a modification to an instance
that does not exist in your calendar?

	Blindly accept it and accept there is never any
	way to get the original and never know what to do with
	future updates that may change that same RECURRENCE-ID
	you do not have?

	Wait for an object that may never arrive with a lower
         sequence number?

	Do a REFRESH just for that instance that you do not have
	because it is in the SEQUENCE:0 object you do not have?

	Do a REFRESH with the same RECURRENCE-ID you just got?
	Which is a modification to an object you do not have.

What do you do with the second instance modification to a UID
you do not have? Loop forever?

How will you ever know if you missed the original?

You use REFRESH by ATTENDEEs of 'existing' events, not new
invitations:

    The "REFRESH" method in a "VEVENT" calendar component is used by
    "Attendees" of an existing event to request an updated description
    from the event "Organizer". The "REFRESH" method must specify the
    "UID" property of the event to update. A recurrence instance of an
    event may be requested by specifying the "RECURRENCE-ID" property
    corresponding to the associated event. The "Organizer" responds with
    the latest description and version of the event.

--

---

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

Doug,

In theory I think the whole refresh idea might work.
As in the set described by the base object will always
describe reccurence ids that are in hte update instance
components of the message. However, won't the CUA using
the current-value model as you described have a problem
when with REFRESH when it comes to the SEQUENCE values?

In the fixed-id model, as we've been discussing it,
the "base" event has a SEQUENCE N whereas each instance
has N+MOD where MOD is the number of significant
modifications that instance has undergone.

The current-value model has based everything on one
instance value for the whole object.

So the REFRESH will work the first time, but the CUA
using a current-value model will take the largest
N+MOD in the entire set and use that as the SEQUENCE
it's looking for.

Since the base object will be at <N+MOD the CUA will
throw out the REFRESH response as old info and thereby
never be able to resync the recurrence-ids to something
that the instance update objects will understand.

Since you can't differentiate a reponse to a REFRESH
from an out of sequence delivery I don't see how the
CUA once it has processed a message where SEQUENCE
was >N it could ever "go back" and reset the recurrence
set description to what it was originally.

-- Michael --

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

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Aug 2003 08:40:03 -0600

> when with REFRESH when it comes to the SEQUENCE values?

No, as they will contain the current state of the object.
You toss the old ones.

> set description to what it was originally.

You do not care about old SEQUENCE data, it is obsolete.

When the REFRESH is sent the object that caused the REFRESH
to be sent will be at SEQUENCE:X. So any objects that
arrive will be (< X), (== X), (> X). So for each
object that arrives:

If they are (< X), toss them as they are obsolete and
the REFRESH reply will update you. They can not be
the reply you are waiting for as they are old objects
that arrived out of order.

If they are (== X) it may be the reply you are waiting for.
Use the object.

If they are (> X) toss everything else and start from
that new SEQUENCE number it may be the reply you want.

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 19 Aug 2003 12:35:45 -0700

I don't think you're hearing what I'm saying.

Maybe you're thinking of yourself as the ORGANIZER and
the fixed-id as the recipient CUA.  I'm thinking the
other way around.  Your CUA is trying to interop with
a fixed-id based ORGANIZER.

So let's step through this shall we:
1) I send recurring event E at SEQEUNCE N.
2) I send instance reschedule E1 at N+1 - Process just fine.
  -- CUA now thinks SEQUENCE for E is N+1.
  -- Redefines recurrence set of E to exclude DTSTART at N
     and to include DTSTART at N+1
3) I send instance reschedule E1' at N+2 - Can't process - wrong RID.
4) You send for a REFRESH.

So I send back a single REQUEST response containing:
E   at N
E1' at N+2

You throw out the object E because you think it's old.
You believe that the SEQUENCE to E is now N+1.
You started thinking that as soon as you saw E1.

E1' has a great SEQUENCE (bigger is better) but you still can't find
it on the calendar - wrong RID.

You send for a REFRESH.

Cycle. Rinse. Repeat.

Did that help - or just confuse things more?
The primary thing is to work it out on paper.
Figure out what messages you are going to receive and what
that will do to your calendar and how you will process them.
While it might work for a fixed-id model to be on the recipient
end of an ORGANIZER who is using a current-value model by
virtue of lots of REFRESH requests.  The converse is definitely
not true.

-- Michael --

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

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Aug 2003 14:29:47 -0600

Michael Fair wrote:
> the fixed-id as the recipient CUA.

No because the ORGANIZE never sends a REFRESH to itself.

>  I'm thinking the

There is NO such thing as a single REQUEST invitation. Simply
send the object back.

There is NO example or text in iCAL, iTIP, or iMIP that
says that there is a special REQUEST type that you
describe. Someone made it up and it is NOT iTIP.
iTIP compliant applications send objects described in iTIP
and no such object is described.

Can you point to ANY text in ANY RFC to backup your view?

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 19 Aug 2003 15:04:05 -0700

Let me try this again.

There are two things that a current-value CUA must deal with:
First - it must be able to send message to other CUAs with
        the events it creates.
Second - it must be able to receive events based on messages
         from other CUAs.

I'm specifically addressing issues with the second model.

It seems that from my analysis, (which is just a rehash
of Bruce's in a slightly modified form) the current-value
CUA cannot participate in any recurring event for which
the ORGANIZER uses a fixed-id CUA.

From your analysis, the current-value CUA can act as an
ORGANIZER's CUA if we just accept that the fixed-id CUAs
will simply be sending lots of REFRESH requests.

These are two totally separate items.
In my analysis, the fixed-id CUA is the ORGANIZER.
In your analysis, the current-value CUA is the ORGANIZER.
In your analysis, the fixed-id CUA is the recipient.
In my analysis, the current-value CUA is the recipient.

> No because the ORGANIZE never sends a REFRESH to itself.

I don't know where in what I said you ever thought I was
trying to say that.  Just makes it clear your not hearing what
I'm saying again.  I was saying that perhaps you are only
thinking about the first model which is only half the battle
towards interoperability.  Not once have I ever suggested
the ORGANIZER send a REFRESH to itself.

> There is NO such thing as a single REQUEST invitation. Simply

Once again we get into this whole message versus object dilemma.
There is one and only one message.
That message is a REQUEST message.
That message contains multiple event components.
One of those components is E - the original description of the
recurring event.
The other of those components is E' - the second modification
to one of the instances of that recurring event.

The ORGANIZER is a fixed-id ORGANIZER.
That's how it sends the object back.

> and no such object is described.

There is, but I'm expecting that once what I'm describing
is clarified it will be obvious to you.

If you however are still not clear, make your request for
RFC citations and I will provide them (Somewhere there
is a response to a REFRESH request just after an instance add).

> Can you point to ANY text in ANY RFC to backup your view?

I can probably point to several sections.
I can also point to archives where you even agreed it would be
the way I describe it.  I can also point to past disccusions in
recent threads where you also agreed it would take multiple
components to fully describe a recurring event where the
instance modifications contained more than just simply date/time
deviations from the base event (like comments etc).

Again, I'm expecting that you just aren't fully fleshing out
what would happen to a current-value CUA trying to interoperate
with a fixed-id CUA.  There are two scenarios:
1) The current-value CUA is the ORGANIZER
2) The fixed-id CUA is the ORGANIZER

In (1) it kind of works with lots of refreshes because what
the current-value calls an instance update, to the fixed-id
model is actually a rescheduling of the entire recurrence set
and it takes a REFRESH to figure it out.

In (2) the current-value CUA gets stuck in an endless loop
of REFRESH/REQUEST once it has received any updates to an
instance for which it triggers a REFRESH.

Does that make it any clearer to you yet?

-- Michael --

---

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

> the ORGANIZER uses a fixed-id CUA.

I disagree.

> will simply be sending lots of REFRESH requests.

Not what I said.

> In my analysis, the current-value CUA is the recipient.

I disagree.

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 19 Aug 2003 16:41:28 -0700

Ok cool.  Progress at least we are talking about the
same model where a fixed-id CUA is sending a current-value
CUA messages.

So why doesn't it happen like I said?

Since I know you don't like reading older posts I'll
repeat it for you here:

Fixed-id CUA ORGANIZER sends:
    Recurring event at SEQUENCE N.
    Instance update E1 at SEQUENCE N+1.
    Instance update E1' at SEQUENCE N+2.

Current-value CUA recipient receives:
    Recurring event at SEQUENCE N.
    Instance update E1 at N+1.
    Instance update E1' at N+2.

As a result of receiving E1, the current-value CUA
incremented the SEQUENCE value of E to N+1.

As a result of receiving E1, the current-value CUA
modified the recurrence rules of E to exclude the
prior DTSTART, and include the new DTSTART.

For the current-value CUA to not do these two things
opens it to all sort of other craziness.  If you'd like
to disagree that it does these two things that's fine.
Just tell me what it does do and I'll shoulder the
burden of proving why it breaks even worse.

It now receives E1' it can't find the RECURRENCE-ID
which has now been excluded from the set.

It sends for a REFRESH and throws the E1' message away.

The REQUEST response message arrives.
It contains two components:
    Event E with SEQUENCE N.
    Event E1' with SEQUENCE N+2 and an RID as generated by E.

The current-value CUA throws away the object
describing E as it thinks it's old (SEQUENCE <N+1).

The current-value CUA still can't find the RECURRENCE-ID
listed for E1' so it sends for a REFRESH and throws the
message for E1' away.

cycle. rinse. repeat.

What am I missing that allows the current-value CUA
to do something other than this?

-- Michael --

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

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Aug 2003 18:14:27 -0600

> same model where a fixed-id CUA is sending a current-value

I said no such thing.

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 19 Aug 2003 17:53:11 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> > same model where a fixed-id CUA is sending a current-value

Nice of you to clarify your own confusion about this.

Now that you know you aren't disagreeing with what I was
talking about but are instead disagreeing with your own
misinterpretation of whatever it was you thought I said,
perhaps you can reread my original description of the
problem of why your interoperability assertment that
the current-value model works with both fixed-id and
current-value CUAs is broke and can formulate a more
intelligible response.

The current-value model cannot interoperate with fixed-id
CUAs.  It gets into an infinite REFRESH request loop when a
fixed-id ORGANIZER reschedules the same instance more than
once.  It probably happens other times as well, but this
is the most easily demonstrated.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Aug 2003 19:34:55 -0600

> Nice of you to clarify your own confusion about this.

I also said no such thing.

--

---

From: Tim Hare <[email-masked]>
Date: Tue, 19 Aug 2003 22:07:25 -0400

In a message, Michael Fair included the following:

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

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

Perhaps I'm mistaken, but I DON'T think that the CUA  should/would
update the SEQUENCE value for the entire UID (recurrence set) when passed
an update for just one UID/RID combination. In fact, I believe that the
sender of the "updated" information MUST send an update to an
instance with the same SEQUENCE as the entire recurrence set, for any of
this to make sense. I don't know if that is in iTIP, I'm reasoning here -
I will look it up in iTIP but for now bear with me.

I will use this notation, which helps me think about this whole
recurrence set thing (and is borrowed/modified from set notation, so it's
sort of natural):

Calendar item = UID = [SEQUENCE,RID1,RID2,... RID] for 1 to n
recurrence components. This general term includes non-recurring items
since n can be 1. Note that SEQUENCE is an attribute of the calendar item
and not of each recurrence instance (as I read/interpret iCal).

A calendar store contains a set of items {A,B,C,D,E} - using letters to
match up with Michael's example. For this discussion we will append the
sequence number to each item {A0,B2,C7,D0,E9). Sequence values chosen at
random, since they don't all have to be in lockstep of course.

If we want to change anything about a calendar item as a whole, we
increment SEQUENCE and send an update. For example, {A0,B2,C7,D0,E9}
=> {A1,B2,C7,D0,E9) when we update item A. In this example, of course,
the RIDs stay the same. If A consists of [RID1,RID2,RID3] then the set
can be expanded to:
{[RID1,RID2,RID3],B2,C7,D0,E9}.  According to iTIP this SEQUENCE
update MUST be done for a change to one of the following fields: DTSTART,
DTEND, DUE, RDATE, RRULE, EXDATE, EXRULE, STATUS. These are fields which
in essence change the whole item A0 - note that RDATE or RRULE in essence
perform a replace operation on [RID1,RID2, RID3]. SEQUENCE does NOT need
to be updated if you are updating a part of the set A0. And it is my
contention, that you should NOT update the sequence number as in
Michael's example above, or you DO end up with the problems he states.

Updating something about one instance of A0, such as changing the time of
RID1 by itself does not require a SEQUENCE update according to iTIP
(and I think it shouldn't have one, either). It does require that we send
an update and identify the specific instance, i.e. A[RID1].

In the fixed-recurrence-ID model, all of the fields which can be updated
in RID1 are _independent_ of the RID. The CUA sends the update with the
fixed RID, and updates its local store as well I assume. Everyone agrees
on what RID1 is because the ID is independent of the fields, and is equal
to the DTSTART of the instance of RID1 at SEQUENCE 0 (when it was
created).

In the changing-recurrence-ID model, the DTSTART field and the ID of RID1
are interdependent, because DTSTART is used as the ID and whenever it
changes, the RID changes. The CUA sends an update, updates its local
store, and in the process changed RID1's ID to RIDx because of the
DTSTART change. If the other end is ALSO using the changing-recurrence-ID
model, the recipient does much the same and both ends are in agreement.

However, interoperability doesn't work well if the ends are one of each
type - one end will change the ID and one will not, and from that point
forward, no one can agree about which instance of the event we're talking
about purely through RID - even though we can at least agree on the UID
we're talking about - to go back to the sets, we know that we want to
update an instance in A0 of {A0,B2,C7,D0,E9} but we with just RID we
can't agree on which of [RID1,RID2,RID3,RIDx] we're talking about.

One of Michael's suggestions during this discussion was to send the
recurrence set definition with every update (I think?) - but identifying
the item by UID and SEQUENCE is enough, since they uniquely identify the
item, and the recurrence definition is "just" a property of the
item. Where it comes in handy is if you are sent one instance of A - say,
A0[RID1] - and you want your local CUA to be smart enough to retain the
recurrence set even though only invited to one instance. This still
doesn't solve interoperability between the two different types of CUAs,
since it does you no good to know the recurrence set when what you want
to know is the specific RID.

Again thinking logically and not referencing iTIP for specifics, I think
that one way to ensure interoperability is to allow RIDs to be _internal_
to each end, so that either model can be implemented at the endpoints,
and for updates to _one_ instance to require the DTSTART/DTEND or
DTSTART/DURATION of that particular instance. The beginning and end (or
length) of the instance are something that both ends can agree on,
whether or not they agree on the RID. If one follows the
"recommended practices" in iCal/iTIP then muliple instances
with the same start time and duration would be collapsed into one
instance anyway, so there should not be, within A, multiple RIDs with the
same start time and duration.

To summarize and maybe clarify:

If you update a non-recurring item or the entire recurrence set, you
identify by UID and use SEQUENCE to identify versioning.

If you update one instance of a recurrence set, you identify by UID and
use the time properties of the instance to identify it.

If you send an update with a sequence less than the sequence at the other
end, the "normal" methods for informing you that you're out of
date apply, and you refresh the entire item, not just one instance, since
SEQUENCE applies to an item and not to an instance of a recurrence set.

Hopefully this may provide a way forward from this point. If you want to
consider an alternate proposal, my other idea involves modification to
iCal to redefine RECURRENCE-ID to be the concatenation of DTSTART and
DTEND of the instance - the same effect as above, but requires us to go
back and change iCAL rather than redefining how iTIP works to match
recurrence-set instances.

Tim Hare

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 19 Aug 2003 22:55:09 -0700

"Tim Hare" <[email-masked]> wrote in message
news:[email-masked]...
> --------------------------------------------------------------------------
------------------------------------------------------------------
> 4) You send for a REFRESH.

Doug has been asserting for a while now that his current-value model
interoperates with both fixed-id and current-value models.
This discussion has mostly been about proving him to be inaccurate
in those beliefs.

Part of Doug's model is that the object is a single recurring event
and that the set definition and all instances share the same
SEQUENCE value.  This most recent (rather one sided) discussion has
been about me pointing out flaws in Doug's interoperability assertions
and him picking out implications I've suggested to which his response
is merely that he has said no such thing and saying nothing to either
refute or confirm what I've presented.

In truth, I say you're right, the SEQUENCE value for a recurring
event only updates when the set gets redefined.  This latest post
from Derik and Frank implicitly concurs with that assumption
because you need to track the base set definition and then
the instance modifications somewhat separately from each other.

Doug has different ideas and defends them rather vehemently.
Since the text isn't clear enough to definitely say one way
or another (but I think we're finally getting some clarity on
this) I've chosen to defend the model I believe iCal/iTIP
presents and bring forth flaws in the model Doug presents as
a matter of workflow discourse.  At each stage I ask him to
confirm or deny that's what his model would do and he has
thus far refuted nothing leaving me with that his model is
broken in several very serious ways as presented.

I had no investment either way about which model was right.
I even started out thinking the current-value model was the
right model.  However, through Bruce's well articulated
messages about the workflow flaws, I flipped sides.  My own
further investigation into this has uncovered different
and varied flaws throughout.  One of Doug's last remaining
assertions is that his model works with both models - but
it doesn't.  I'm attempting to engage him in a conversation
over these issues and thus far his pride has been bigger
than his brains.  I ordinarily wouldn't make such a discussion
this personal, but his complete disregard for respect of his
intelligence and his own abilities to confirm or deny the
workflow discourses presented combined with his propensity
to continue to flout his patently false assertions will
only continue to confuse people.  I suspect that his views
will also color any drafts he comes in contact with in regards
to how the SEQUENCE and RECURRENCE-ID properties come into
play which will make it a further headache for the working
group to constantly have to battle it out with him over
his wildly different views.

> to the DTSTART of the instance of RID1 at SEQUENCE 0 (when it was

Not quite true.
It is the DTSTART as defined at SEQUENCE N, where N is the last
time the set was defined.  Adding instances, and redescribing
the series are two things that redefine the set causing a SEQUENCE
jump.  If you change all Mondays to be all Fridays instead, there
is no longer any DTSTART that is the same as what it was at
SEQUENCE 0 and by consequence there is no longer any object with
an RID that is the same as what it was at SEQUENCE 0.
Minor difference but has huge implications in terms of tracking
and storage.

> recurrence set definition with every update (I think?)

This is limited to only the case where the CU is invited to a
subset of instances from the series and not the series itself.
Since it will not have the series description itself, it will
not have the ability to confirm the validity of an RID.

This is problematic if the entire series gets redescribed
(that whole Mondays to Fridays thing) because the RID in
the new series won't always match the RID from the old
series and the CU will have no way to tell that the object
it just received is an update to an existing event with an
old RID and not a new invite to a new instance with a
new RID.

This is the only time I suggested inclusion of the recurrence
set description because it's the only time a CUA would need
to be able to verify an RID without the presence of the base
event description.

Doug had proposed a model where you branched the UID into
multiple versions for each recipient depending on what set
that recipient was invited to.  This recommendation breaks
horribly if CUs invited to two different subsets of the same
UID try to forward or delegate to each other.  I've asked
Doug, or anyone else ot explain how these CUs can process
these request messages but have not yet seen any responses.

> recurrence-set instances.

Maintaining compatibility between the two models is not
something worth pursuing.  The fixed-id model as described in
iCal works exceedingly well in all cases save one small subcase
(where a CU is invited to a subset of instances only and the RIDs
change) which I'm sure has a resolution that I'm just not aware
of yet.

Doug just hasn't figured out how broke his assertions are yet,
or he just has too much pride to acknowledge he was wrong.

Either way, every assertion that Doug has put forth about
the workability of the current-value model, tracking SEQUENCE
as one value for all instances plus the base object, and how
to invite people to a particular instance are seriously flawed
in one way or another.

If he, or anyone else would like to have an intelligent
and reasonable discussion over the topics I'm all for it.
At every stage of the conversation I have been careful to
ensure that Doug's right to speak for his model has been
preserved and to ensure that I give him very clear and
specific workflows to work with.  I have cited iTIP and
iCal when appropriate to defend my claims and even given
him latitude to bend the rules a little as long as he can
bend them in such a way that all CUAs can be programmed to
get the right thing on the calendar and send the right
responses that can be matched up with the right events.

At some point though the conversation needs to stop and
the consensus needs to be reached.  I think it's pretty
evident by now that a current-value model and/or tracking
only one SEQUENCE for an entire recurring series are just
problematic in the environments that iCal/iTIP are committed
to working in.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 20 Aug 2003 09:15:52 -0600

Michael Fair wrote:

> ... I'm attempting to engage him in a conversation
> than his brains. 

It has to do with the fact that you keep mis-quoting me
which makes it not a debate, but a temper tantrum by
you when I will not participate in discussion that is
based on your outrageous mis-quotes.

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 20 Aug 2003 10:30:16 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> based on your outrageous mis-quotes.

I have merely stated that you have thus far refused to respond
to the workflows presented.  The intelligent person would just
give the requestor the response they are looking for to shut
them up about crying "flaw" where none exists.  If indeed there
was a flaw where the intelligent person had not seen one before,
they would acknowledge the flaw and look for ways to resolve it
if possible.  If there were no ways to resolve it they would
simply declare the model broken and deal with any cleanup of
existing documentation or implementations as best they could
and try and change the model to something stronger moving
forward.  The prideful person would feel disdain for the messenger,
refuse to address the issues, and try to ignore it.  The prideful
person would be too embarassed to acknowledge any kind of flaw
and would thus try and hide from the issues.

Thus far, you have refused to provide one scrap of defense
for the current-value model in any of the most recent flaws
about the current-value model where I have directly asked you
if this is what it would actually do.  You either have no
respect for me and my questions and thus do not feel any
compulsion to answer them (in which case I've shown you more
respect by giving you the opportunity to prove me wrong), or
you don't want to publicly admit that you've been wrong for
what is most likely years now and got deeply entrenched on
the losing side of an issue where you were the only real
defender of your side.

If I am misquoting you then it because I expect that your
responses are to the text I've actually presented on not
something off-topic from the problems I presented.

I presented the problem three times, you misunderstood it,
or are ignoring it and trying to focus on something else.

Once you start responding to the issues presented I won't
confuse your side-tangent answers with something that's
actually on-topic.  Once you start responding to the issues
you'll shut me up pretty quickly assuming you actually
present a consistent workflow.

If I'm misquoting you it's because I'm trying to relate the
answers you're giving with the context of the conversation
and trying to make sense of it.  I can stop that and just
start calling your answers senseless if you would prefer.

I'll ask again lest I be accused of being difficult.

You said that the current-value model interoperates with
both fixed-id and current-value CUAs.  I said no it doesn't
interoperate with fixed-id CUAs and here's proof.  A fixed-id
ORGANIZER will send these messages to your current-value CUA.
Your current-value CUA will process it in this manner resulting
in an infinite loop.

I've asked you three times to clarify what in your model
would prevent it from doing so and you have yet to respond.
Here's a fourth.  Doug what prevents the current-value CUA
from getting into an infinite loop when a fixed-id ORGANIZER
sends the messages I listed in my earlier posts?

Until we see a post from you with some meaningful content
in response to that you are simply trying to fantasize
that the problem doesn't exist or trying to ignore the
messenger as someone you just don't like.  The problem
isn't with me Doug, it's your model.  It's broke unless
you can somehow show us otherwise.

I'd truly like to believe that the current-value model can
interoperate.  I am very serious about that.

If it can, then we can just end this thread here and now and
let it be an implementor's decision.  But I can't because it
isn't.  Fixed-id is as close to being declared king as I think
this WG can get.  Current-value does not interoperate.  Therefore
it's not an implementor's choice and the sooner everyone here,
and this includes you Doug, gets on the same page about that
the sooner we can rest assured the confusion is going to get
cleaned up and the faster we can all agree on text to fix 2446.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 20 Aug 2003 12:10:24 -0600

Michael Fair wrote:
> to the workflows presented. 

Now your mis-quoting your self.

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 20 Aug 2003 13:12:57 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> Now your mis-quoting your self.

Prove it.  You can provide the proof right alongside the one
that doesn't put any CUA using your model in an infinite loop
once a fixed-id ORGANIZER moves the date of an instance for
the second time.  If you can prove it, I'll be happy to take
it back and stand corrected by you so long as you include it
with the important issues too.

<Waste of time and attention>
Here's my defense for my quote:
I stated that you have thus far refused to respond to the
workflows presented, which is congruant with you having
pride bigger than your brains.
Until you provide something contrary to that - the argument
stands as posted.  This part of our argument is a waste of
disk space and more importantly a waste of the WG's time
and attention.
</Waste of time and attention>

Why don't you just answer the question Doug?
What stops a CUA in your model from hitting an infinite loop?

I want you to be right about this.  I don't mind getting egg all
over my face for being wrong about this.  But most importantly
I want to stop wasting the working group's time and attention
and get an answer from that either confirms or refutes that
this is the actual behavior given your model interoperating
with a fixed-id model.

If you are so incompetent at reasonable argumentation that you
cannot send a response to this message that talks about
reccuring events, the current-value model CUA interoperating
with the fixed-id model, and infinite loops then please send
it to me personally and spare the list the agony of having
their time and attention wasted on your refusal to discuss the
issues as presented.  If you can only continue talking about
who's misquoting who I'll be happy to do it, just take it
offline and send it to me personally.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 20 Aug 2003 14:46:46 -0600

Michael Fair wrote:

> Prove it. 

no

I have added your email address to my spam filter. If anyone cares
about why I will no longer notice or respond to any of your emails to this
list.

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 20 Aug 2003 15:55:20 -0700

For the archives sake, it should be noted that Doug
has chosen to neither prove why I was misquoting
myself nor why his model is not interoperable and
results in an infinite loop.

He has instead chosen to ignore the messenger who
was simply trying to get him to focus on the issues
and respond to the workflows as posted.

While his decision is unfortunately not the kind of
closure we all hope for.  I am only left with that he
simply did not like me pressing him for an answer
because he felt I was not worth his time nor his
energy to share what should have been a simple
request, or that he was unable to comply with my
request and rather than admit he was wrong he
decided to ignore me instead.  His version of the
story would probably be that I was constantly
misqouting him.  I leave it to the readers of the
archives to decide.

Given the amount of careful consideration that
went in to formulating the request and that I
really wanted his model to be interoperable for
everyone's sake, I am more inclined to believe
that he simply could not provide any alternative
processing means to what I described and thereby
his CUA ends up in an infinite loop on the second
reschedule of an instance to a recurring event if
the ORGANIZER of that event is using a fixed-id
CUA to schedule the event thereby totally invalidating
any claims of interoperability between the two models.

And with that, I declare the discussion closed.

-- Michael --

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