Subject: Uniquness of 4.4.2 Modify A Recurring Instance

From: Doug Royer <[email-masked]>
Date: Thu, 14 Aug 2003 14:23:39 -0600

It has been two days, your CUA sill misinterpreted the
object that was sent in e-mail to this list.

How long do you wait before sending the REFRESH?

Does anyone really believe that any CUA that got
that object and thought it was an initial invitation
has the correct data for the CU?

-- 

  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: "Michael Fair" <[email-masked]>
Date: Thu, 14 Aug 2003 16:34:28 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> has the correct data for the CU?

You know Doug, you are really an ungenerous troll.
You can't take a few moments to try and explain
the issues you are pointing out and then say we
are ignoring them when we can't figure them out.

I _think_, based on what I know of your logic skills
thus far and your propensity for ignoring posts, that
I know what you are trying to say is a problem.

Let me see if I got this straight.

You believe that using our model:
The recipient receives:
UID:1
RID:1
SEQ:3

Puts it on its calendar as a new invite.

and then the CUA receives:
UID:1
SEQ:0

and per 2.1.5 throws it away.

Is this right?

-- Michael --

---

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

> You know Doug, you are really an ungenerous troll.

You send out email that says section 4 of iTIP is 'nothing'
and you expect me to just take your word for it that
you know that section 4 is 'nothing'.

Your logic is busted and you can not figure it out
or you are too stubborn to admit it.

Your declare that it is unambiguous - then when I prove
it is, your declare that it does not matter. When I show
that it matters, you declare it is unambiguous.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Aug 2003 18:13:12 -0600

> You believe that using our model:

I really do not care about your model. I am talking iTIP.

> and then the CUA receives:

You still missing the point.

1) What if that packet is lost - as I said in the email?
    "...oops it got mis mailed.." or something like that.

    OR

    What if that sequence:0 arrive AFTER an instance in
    SEQUENCE:0? Per iTIP your CUA could tell so it could
    then do a REFRESH. Now as the objects look EXACTLY
    like each other - some want it to be an invite. No
    you busted iTIP.

2) The CUA will NEVER know it if SEQUENCE:0 is lost and
    you act on SEQUNCE:1 as if it were an invite.

3) It used to be able to tell that it should of had SEQUENCE:0,
    now you can not because Bruce has proposed that a modification
    to an instance update looks *exactly* like a invite.

The CUA can not tell because the invite looks EXACTLY like
an update to an existing instance. Your CUA is out of sync
and your iMIP CUA/CU will never know.

> and per 2.1.5 throws it away.

And yes, after you book SEQUENCE:N then per iTIP
all objects with a SEQUENCE less than N are obsolete.

So you booked SEQUENCE:1 because Bruce wants it to be
an invite. Then you get SEQUNCE:0 that is by definition
older and obsolete.

--

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 14 Aug 2003 18:14:26 -0700

Yay!!!  Finally something that we can actually respond
to (yet again).

Since I'm too lazy to go digging through the archives
to figure in which 4 or 5 posts I explained this I'll
just do it again, and given the intensity I expect
that you will read it all the way through.

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> I really do not care about your model. I am talking iTIP.

Fair enough.  So am I.
Let's proceed.

>     "...oops it got mis mailed.." or something like that.

At the moment the CUA receives the first message, it notices
that the object is keyed off the UID/RID.  It knows this
because of the presence of the RID.

It first looks up the UID/RID pair to see if the SEQ
of that object matches that of the existing UID/RID.

As part of that search, when it can't find the specific
object it's looking for, it also looks up the UID only
object to see if the RID listed is a member of the
current set of valid recurrences.  This is the same
in both models.

Since it was also unable to find the object using the UID only
it notices that something is fishy and sends a REFRESH request
for the UID only object because it should, not because it needs
the contents of that response to process the message.

It asks the CU if they want to attend the instance and then
sends the appropriate REPLY.

It will then receive the second message (response to the REFRESH
request) which contains the UID only (RID:NULL in my terminology)
along with the UID/RID instance specific update and try to do
a lookup on the UID only object.

It will not find UID:1/RID:NULL and therefore will treat it
as a new request.  It will look for any existing instances
of the UID that are not contained in the set described by
the object to remove them.  Since both objects are at SEQ:0
then the RID of the instance that the CUA already has will
be in the set.

It will find that instance when it does that lookup, it will
compare the SEQUENCE values and see they are the same and then
it will compare the DTSTAMP fields.  It will notice that the
DTSTAMP field is greater than the instance's DTSTAMP and know
that it needs to update the instance.

It being a smart CUA, will look through the rest of the response
to see if there is any per instance object associated with the
instance it needs to update in the message.  It will find that
object in the message and check the SEQ/DTSTAMP against that
of the UID only object.  It will find the DTSTAMP of the
instance only object in the message is the same or greater and
in either case it will choose the instance specific version
or the UID only version to use for the updated of the object
on its calendar.

If it weren't a smart CUA it would first update the object
on its calendar to be that as the UID only object described
(again DTSTAMP is greater) and then update it again when it
finishes processing the message as it comes across the instance
specific version with the same or greater DTSTAMP.

In the end it will have sent the REFRESH, received the
response, and correctly applied all objects to the calendar.

The Doug model of redefining the recurrence set won't help
you reduce the amount of processing because you updated
something about the instance to cause the SEQ:0 update to
happen in the first place.  Since you will want to keep
whatever data that was, you will have to include a per
instance object in the REFRESH response message.

If you had reshceudled the instance, which is the only
change that sometimes might result in less processing,
then you would have had to increase the SEQUENCE value
of the instance and therefore the instance would not
have been at SEQUENCE 0.

>     like each other - some want it to be an invite. No

Since they are about two distinct objects there will be no
confusion.  It will process the instance at SEQ:0 as above
which will trigger a REFRESH.

It will then receive the second message which contains the
UID only (RID:NULL in my terminology) and try to do a lookup.

It will proceed pretty much as above when the above received
the REFRESH response except this time it won't update the
instance at all because the DTSTAMP will be older than above.

It then may or may not receive the response to the REFRESH.
Assuming it does, it will repeat the above and update all
the objects since the DTSTAMP field of the response is
more recent than what's on the calendar.

>     you act on SEQUNCE:1 as if it were an invite.

Sure it does, as I described above it notices that it has
received an invite to an object with an RID for a recurring
event which it has no prior knowledge of.  It can't verify
whether or not the RID is valid and thereby sends a REFRESH
because that is what it should do as per 6.7.2.

>     to an instance update looks *exactly* like a invite.

You're repating this point again.  So just ditto from above.
It knows to send a REFRESH.

> an invite. Then you get SEQUNCE:0 that is by definition

If they were referring to the same objects (which they
aren't) you'd be right.

By your definition the 'current-value' model is then in
serious trouble because it can't move if any instance
update is ever missequenced because it needs to reset
based on the REFRESH response.

I mean let's think about an update to four separate
instances SEQ:1,2,3,4 respectively and then say that
because of some mishap SEQ:4 arrived first.  It has to
queue it and wait for a REFRESH that may never come.
Then it receives SEQ:3, again queue and wait.
Then it receives SEQ:2, again queue and wait.
And things get really bad if SEQ:1 just got lost.

Your model cannot continue until it receives a REQUEST
that is either exactly at SEQ:1 or includes the entire
set for the series (response to a REFRESH).

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Aug 2003 08:20:06 -0600

> the contents of that response to process the message.

Noting is fishy at all, the object I sent 3 days ago was a
copy/paste straight for iTIP. I made up nothing.
Is all the CUA had to do was implement iTIP straight
from the text.

Now Bruces proposal to invite someone forces a valid object to
be ambiguous. With Bruces proposal 100% of the time an invitation
to a single instance causes (5) round trip packets to be sent (so
it does not look 'fishy' as you call it). And an update to a single
instance causes (5) round trip packets to be sent (because it is
exactly the same 'fishy' packet). What is the justification for this
when (1) set would have worked?

If you implement iTIP as written, exactly (1) set will be
needed to update a single instance.

If you implement iTIP as written, exactly (1) set will be
needed to invite an ATTENDEE.

--

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 15 Aug 2003 12:18:28 -0700

Ok Doug,

since you haven't answered the question yet, I'm going
to ask it again.

I send out a recurring event series, I then sent out an
instance modification.  What does your CUA do if the
instance gets there first?

If my guess is right - it sends a REFRESH and then holds it.
Is that right?

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 15 Aug 2003 13:12:14 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> Is all the CUA had to do was implement iTIP straight

Something is totally fishy.
The CUA has just received a new reccuring event instance for
which it has no set description.  Thereby triggering a REFRESH.

In fact every reference to a recurring instance in iTIP
blatantly assumes that the reipient already has a copy of
the recurring series on its calendar.  I challenge you to
find one example or one scrap of prose that ever talks
about receiving a message that refers to an instance when
the recipient CUA does not yet have a copy of the recurring
series on its calendar.  Every example has at least one
line before the example that talks about what the recipient
already has on its calendar.  We have proven that this is
not a valid assumption, yet the text never addresses it.
Show me I'm wrong by citing something from iTIP that doesn't
have an explicit piece of text saying that the recipient
CUA already has some version of the event on its calendar.

Further, we are not talking about a case where the CUA has
a copy of the recurring series on its calendar.  We are talking
about either a new invite or a missed message.  In iTIPs model,
contrary to everything in your proposals, it wants the instance
update it receives to be both processable, and refer to a
globally unique object.  Both your models of development,
the 'current-value', and per-set-UID, break each (respectively).

Now, if as I have proposed in a separate thread, the ORGANIZER
sends a description of the recurrence set (RRULE/RDATA/etc) as
part of the message to an individual invite then there would be
no ambiguity at all because it would be able to verify that the
RID specified is indeed in the recurrence set.

However without that info, the CUA should send a REFRESH.

> when (1) set would have worked?

Because the (1) set that you have proposed cannot be forwarded or
delegated to any CU that is part of a different set of instances.

However, the (1) set that I have proposed (which is an addition
to iTIP to include an extra MUST for this particular case) which
says to include both a recurrence set description and the RID
they are invited to is also totally unambiguous and instantly
verifiable.  No REFRESH would be needed.

Additionaly, it doesn't cause 5 round trips.
The first round trip of receiving the instance message and its
reply doesn't count as every model has to do at least that.
(Well except for those models that can't even process it and
 are stuck waiting for more info)

The second round trip where it receives the whole set and
its reply is also ignored because it either didn't happen
or all models have to do it as well.

The third round trip is the REFRESH and REQUEST response
that got triggered by the inital instance message.  Your
per-set-UID model does manage to avoid this particular
round trip, but it breaks forwarding and delegation to
other CUs that have a different UID-set.  My recommendation
to include the complete recurrence set description as part
of the invite message also avoids this round trip, but my
suggestion does not break when CUs forward or delegate to
anyone as my objects are still unique.

That's it.  There are three potential round trips consisting
of 4 to 6 messages (4 using my suggestion or your broken
suggestion, 5 if you can't process the initial instance
message AND your REPLY is the same as the parent UID,
otherwise it is 6 regardless of the model chosen).

If we say the ORGANIZER's CUA MUST include the recurrence set
description in the message along with the RID when we are
inviting a CU to an instance as I've suggested, then the
REFRESH becomes unnecassary, but as it stands now iTIP makes
no such demand so it cannot be relied on.

> needed to update a single instance.

In the presence of missed messages there will be at least
three sets (as described above) regardless of the model
chosen (unless it's broken, or not in iTIP).  If all messages
are received in order, then there is always exactly 1 message
to update an instance.

> needed to invite an ATTENDEE.

I'm assuming that you are saying that iTIP "exactly as written"
somehow justifies splintering the UID for the various invite
sets of different CUs.  This is broken when CUs are allowed to
pass events around for purposes of FORWARDing and DELEGATing.
(If it's not broken neither you nor Chris have proven otherwise.)

In your suggested model they can't forward, and they can't
delegate unamibiguously in all cases, and therefore the
model you have proposed is not iTIP and is bankrupt.

If you are inviting an end user to a single instance of a
recurring series and we are not applying my suggestion that
we include the recurrence set for purposes of verification
of the RID then there is exactly 2 sets, and no problems
when the CUs forward or delegate the messages around.

The conversation for a single instance invite goes something like:
(Round trip one)
S: "You're invited to an instance in a recurring series."
C: "Great, here's my REPLY."

(Round trip two)
C: "Are you sure it's only one instance, I can't verify
    the RID.  Did I miss something?"
S: "Nope."

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Aug 2003 14:59:14 -0600

> which it has no set description.  Thereby triggering a REFRESH.

Correct - and that is all that it should mean. The only thing
fishy is forcing the CUA to do a REFRESH to find out if
it is an invitation or an update is what is fishy.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Aug 2003 15:45:01 -0600

> instance gets there first?

[I assume you meant the modification gets there before the
initial invitation?]

Quickly looking through my code it looks as if this is
what I do (+/- a step or two):

What I do with unknown an UID that arrives in (iTIP 4.4.2)
instance modifications:

(I) ORGANIZER is mailto url OR object arrived via iMIP:

    (I.a) Inform the user and then ask the user:

        (I.a.1) Request full copy?

                If selected - send full REFRESH via iMIP
                and toss the update object.

        (I.a.2) Toss it (you have waited xx-times [after refresh sent])?

                If selected - Toss the object.

        (I.a.3) Wait for the initial invitation to arrive?

                If selected - Hold it.

(II) ORGANIZER is CAP url and ATTENDEE has CAP access to ORGANIZER csid
      and object came from ATTENDEEs CAP unprocessed queue.

         (II.a) Do query on ORGANIZER csid and get the object.

         (II.b) If ATTENDEE had permission and the query returned empty:

             Assume that the ORGANIZER *may* be in the process of
             depositing the objects and wait a few minutes and retry
             (II.a) once. Then if the initial invitation does not arrive
             and it is not on the ORGANIZERS csid, go to (II.d).

         (II.c) If ATTENDEE did NOT have permission to query ORGANIZER csid
                go to (II.d).

         (II.d) Deposit full REFRESH in ORGANIZER csid.

         (II.e) If ATTENDEE did not have permission for (II.d), go to (III.a)

(III) ORGANIZER is CAP url and ATTENDEE does NOT have CAP access to
       ORGANIZER csid and object came from ATTENDEEs CAP unprocessed queue.

       (III.a) ATTENDEE has ORGANIZER iMIP address via other means:
               Go to (I.a)

       (III.b) Does NOT have the ORGANIZER iMIP address:
               Toss it as there is no way to inform ORGANIZER.

> If my guess is right - it sends a REFRESH and then holds it.

No point in holding it most of the time as you can do a full
(not instance) REFRESH. So instance modifications that arrive
before the initial invitation get tossed unless the user
wants to wait.

--

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 15 Aug 2003 15:35:44 -0700

The CUA should put the instance it received on the calendar.

It should not have to wait for a "trigger message" before
making that message processable.

Putting it on the calendar as the latest version of an
event that it has seen is a very iTIP thing to do.
Throwing away or not acting upon good information isn't.
It is also specifically in violation of 3.2.2 which
explicitly says that it should be treated as a new request.

Since you should put it on the calendar AND you should
send a REFRESH there is little harm done.

Further I've proposed a solution to the need to send
a refresh and that is to always include the recurrence
set description along with the RID when inviting an
individual CU.  This would unambiguously identify
the message as a verifiable invite to that
particular instance.

This proposal is totally consistent with all of iTIP,
save the new MUST when dealing with this case, and it
doesn't break any of the CUs abilities.  Contrary to
your model which breaks a CUs ability to forward the
invite to another CU or delegate to another CU if that
CU is aware of a different set of instances.

My recommendation is questionable based on whether or
not it is desirable.  Your recommendation must be thrown
out as it is ill-conceived with respect to CUs forwarding
information around to each other.

-- Michael --

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

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 15 Aug 2003 16:24:43 -0700

Since it's fairly obvious that we are at a stand still
and could argue this back and forth till we're blue in
the face with this conversation I am going to appeal to
the others on the list to chime in with a vote.

I say that it against the spirit of iTIP to hold or
throw away any event update message.  I say this
because iTIP agressively tries to do as much as it
can with each message received since it considers
the communication channel unreliable and to rely
on a "trigger message" to reeastablish workflow
is not what the authors seemed to have in mind.

I believe that the authors intended every message
to be processable and, assuming it was a more
recent message, to immediately update the calendar
to the degree that the message allows for.

I've proposed what I consider a simpler solution to
Doug's "ambiguity problem", which while I consider the
superfluous REFRESH cycle acceptable overhead, solves
Doug's ambiguity problem and doesn't break the CUs
ability to FORWARD or DELEGATE like Doug's model does.

Whether or not you consider the extra REFRESH a severe
detraction, Doug's model is just broken and is not
an acceptable solution lest we declare that people
can't invite or delegate other CUs when dealing with
a recurring event which I find even more unacceptable.

I'll give Doug this, under iTIP as written, there is
the possibility of a superfluous REFRESH cycle.  Why
Doug has decided this is a problem I can't tell because
the his model is totally broken without them.

Given iTIP with one additional clause that says
something like:
"When inviting a CU to a particular instance of an event
the ORGANIZER's CUA MUST include the recurrence descriptors
and the RECURRENCE-ID the CU is invited to so that the
reipient can validate the RECURRENCE-ID.  For all other
instance modifications the ORGANIZER's CUA SHOULD not
include the reccurence descriptors."

We get a totally identifiable set of messages and eliminate
any potential confusion about which RIDs are in and not
in the set.  This is useful when a CU is invited to one or
more instances where the RID in question has changed.
Since it doesn't have the base event to work off of (since
it wasn't invited to that event) it can use the recurrence
set to validate the existing instances it has on its calendar.

Both Doug's proposal and mine rely on things that are
not currently in iTIP.  I have an implied must and he
has to know who the message came from (which is error
prone when CUs can pass the events around, and not
even gauranteed over certain communication channels).
Not implementing my proposal just means there's an
extra REFRESH cycle.  Not implementing Doug's proposal
means you can't ever invite a CU just to a single
instance and you must invite them to the whole event.

Further, Doug seems to think that iTIP believes the
communication channel is mostly reliable, and
that it, for the most part, is not an issue to
throw away a message.  He must assume that the
REFRESH request and its corresponding REQUEST
response will always make it through the channel.

I think we can all agree that iTIP considers the
channel unreliable and that it's totally possible
for a REFRESH or its REPONSE to just disappear.

I'm fairly certain that no one on this list, save
Doug and Chris believe this is the preferred behavior.

Chris Olds, as the other proponent of Doug's model,
have you solved the CU forwarding and delegation problem?
Do you find the 'toss it away or hold it' model is the
desirable of the two knowing that there is a model which
can perform better then that?

Is there anyone else on the list aside from myself,
Doug, Bruce, Satya, and Chris who has an opinion one
way or the other?

Without a vote, or a voice, there will be nothing in the
archives to say what the outcome of the WG's consensus was.

I'm not aware of any WG dispute resolution procedures...
Doug has every right to continue to push his model in this
forum until a clear majority has spoken for/against it.

As for me, it's pretty obvious that Doug's model has two
very undesirable side effects.  The first being the inability
to apply the most recent information about instances when
it arrives out of order, and the second he breaks the CUs
ability to delegate and forward messages to CUs who are
aware of a different set.

-- Michael --

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

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Aug 2003 17:51:05 -0600

> information around to each other.

You know your are ether stupid or a trouble maker that
feels they have to insult everyone one this WG list
and the authors of iCAL and iTIP who if you read the archives
disagree with you. These topics WERE covered on this WG list.

Do you really think that this WG has passed iTIP just
to annoy you? Do you really think that everyone can
not do iTIP and you have the solution?

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Aug 2003 17:52:45 -0600

> the others on the list to chime in with a vote.

There is NO vote - there is NO proposal, there has
been NO draft submitted. And even if there was a draft,
the IETF does NOT vote.

--

---

From: "Michael Fair" <[email-masked]>
Date: Sat, 16 Aug 2003 03:01:02 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> feels they have to insult everyone one this WG list

Perhaps I am, I don't believe either of those about myself,
either way, it doesn't fix your model.  The comment remains
as posted until proven otherwise.  I tried to make your
model work - I even invented really smart CUAs - the
messages are still unprocessable and highly ambiguous.
You haven't provided a description otherwise even
after I expressly requested it from you three times.

I don't think you're stupid, you just didn't work it out
beforehand to account for all the possibilities.  You
just omitted the part where CUs could forward things
around without the ORGANIZER.  This is very apparent
because you think the ORGANIZER is always the dispensor
of information about the given event.  It's not, and as
a result, your invite model is broke.

> disagree with you. These topics WERE covered on this WG list.

I have some issues with the authors and editors that we ended
up in this conversation to begin with, but I think they took
on an extraordinary task and managed to trail blaze an incredible
foundation which is extremely elegant.  I actually have a
great respect for them.  But how you and Bruce can end up on
such opposite sides of this issue - seeing that both your names
are listed in the contributors section just furthers the
evidence that not everybody was on the same page when the
draft was last called.  Bruce makes very sound arguments
which you have thus far not refuted.  I similarly brought
up some arguments (which Bruce probably already pointed
out as well) which you also, thus far, have not refuted.

Considering the complexity of the problem, I find it very
reasonable for them to have not caught every nuance of
dealing with recurring instances.  In fact looking through
the archives Bruce on several occasions brought up problems
that were simply ignored oftentimes relating to this
very issue.

Plus, I have been searching the archives in hopes that I might
find a solution since you so vehemently defend your position and
since you have decided to be extraordinarily difficult in gifting
the requested information in terms of what the CUAs will do in
the situations described and I have yet to find anything.
I have yet to find any hard core decision in regards to this
particular issue, for which the issues we are discussing now
were clearly distinguished.  The July 2003 thread is the first
thread to detail out the problems with the shifting reccurence-id.
For the most part I've seen lots of posts confirming that the text
is just plain inconsistent in areas.

In my search:
I saw the July 1999 thread that Bruce refers to where the
general statement was that a response to a REFRESH would
most likely contain multiple components.  First would be
the base at SEQUNCE N, and then would be the instance revs
at SEQUNCE >N.  That thread didn't account for updates in
which the SEQUENCE doesn't rev as it was only discussing
updates which did rev the SEQUENCE.

I saw where you and Frank got into the entire reccurence set
is a single object discussion and all share the same SEQUENCE
value back in Feb 2000.  This was counter to what was discussed
in July 1999 (just 8 months before).  Seems people weren't
exactly sure what the answer on that one was supposed to be.
There was no thread I found between July and Feb that could
account for this "flip".

The implications of such an action were never addressed until
much later where you said handle the attendees smartly during
this latest July 2003 thread.
But you never answered Robert's declaration that there's a
problem with this model becaues you'd be forced to ignore any
REPLY's that came in because they were for an old SEQUENCE
number.  (You had revved the SEQUENCE internally and not told
anyone quietly updating their attendance status based on
whatever value you happend to have prior).  I tried to handle
them smartly, but unless I constantly tracked what changed
between the SEQUENCE they had and the SEQUENCE I currently
have to determine if sufficient information was the same I'd
have to send them a new copy of the whole event to get them
to the right SEQUENCE number before I could accept any REPLY
they sent.  This just can't be acceptable.  I agree with
Robert (Tom) that it's easier just to cancel their event
without revving the SEQUENCE number to remove them as an
ATTENDEE for an event.

I found the thread where you and Bruce talked about needing
to change Delegation text in Feb 2002 and you brought up per
ATTENDEE objects as the (2) for how ORGANIZER's solve problems
like this, but the background of that conversation was that
the same primary key info was present and that you weren't
changing any workflow defining properties.  Here you're saying
spin a unique version with different workflow properties just
for that attendee and that's where my problem lies because
that object can and will get passed around.

I found where you originally got into this argument with Graham
and it finished without much resolution.  I found where Bruce
attempted to explain to you the advantages of the fixed-id model
which you either can't grasp or are unwilling to consider.

I see lots of history with no real thoughtful discussion of
the issues we are covering now.  I actually see no interop
discussions where the fixed-id or current-value models were
declared king.

I take issue with one and only one part of your invitation
model.  Two CUs invited to different subsets of the same
recurring series will always incorrectly process a forward
or delegation.  I have posted the scenario at least three
times, I have posted what iTIP says the CUAs will do, and
I have requested that you prove otherwise.  I haven't found
it in RFC 2446, I haven't found it in the archives (doesn't
mean it's not there - I know - but I've invested a few hours
into it), and I haven't seen you post it here.  Chris tried
to respond to my post thinking I was asserting he couldn't
change values based on the ATTENDEE - I'm not saying this
at all.  I'm saying change whatever you want except for
UID/RID/SEQUENCE/reccurence set descriptors because once
you start messing with those CUAs will get confused when
the CUs pass the info around without going through the
original ORGANIZER.

Until otherwise addressed, your model is broke.

As for the current-value model in general I take issue
with the fact that it cannot process messages in the
presence of missed messages.  However I do not agree
that Bruce's fixed at event creation model is the right
solution howver I can probably be convinced.

> not do iTIP and you have the solution?

Nope.
I don't believe any of the above.

I believe that Bruce for a long time now has been the
most vocal on issues concerning reccuring events and
workflow with them and it seems has largely been ignored
(he has a lot of posts requesting feedback that never
shows up).

I believe that the current-value model is against the
spirit of iTIP, and as Satya points out, is actually
mute given the existing major vendors doing it the
fixed-id way.

I believe that the proposals I've presented were in
response to what you claim were flaws in the fixed-id
model and cinch it up enough as to be workable.
It has fewer sensitivities than the 'current-value'
model and can handle event reschedules such that none
of the prior recurrence-ids are in the new set, without
suggesting a new UID should be provided, and it can
unambiguously identify the distinction between an
invite to a particular instance against a missed
message regarding the entire series which you made
such a huge issue out of (despite it was only a single
superfluous REFRESH which you always require).

I believe lots of people can implement iTIP, but none
before last month have really sat down and hammered
on this whole recurrence-id, instance invite, forward
and delegate instances issue and I say that as someone
who has spent several hours reading the archives clear
back to the end of 1998.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Sun, 17 Aug 2003 10:27:03 -0600

Michael Fair wrote:
> either way, it doesn't fix your model.  

I have proposed no model. Is everything you say as inaccurate?

--