Subject: RE: Uniquness of 4.4.2 Modify A Recurring Instance

From: Satya Vempati <[email-masked]>
Date: Fri, 15 Aug 2003 19:24:12 -0700

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)?

It is like designing chairs for people with their knees in the back.

At this stage it is clear (at least to me) that we need to rewrite iTip to
be unambiguously in sync with most of its implementations. Any other
approach defies common sense.

Doug seems to be going by the letter of iTip rather than the spirit, and
in that sense he may be right. But we should find a way to move forward
given the fact that the majority of implementations are against his model.

Does anyone know how to take this forward and resolve a contentious issue
such as this one? What is the normal IETF process?

-----Original Message-----
From: Michael Fair [mailto:[email-masked]]
Sent: Friday, August 15, 2003 4:25 PM
To: [email-masked]
Subject: Re: Uniquness of 4.4.2 Modify A Recurring Instance

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]...
>
>
> Michael Fair wrote:
> > 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?
>
> [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.
> > Is that right?
>
> 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.
>
> -- 
>
>   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: Sun, 17 Aug 2003 10:31:55 -0600

> 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.

--