Re: Uniquness of 4.4.2 Modify A Recurring Instance

["Michael Fair" <michael@xxxxxxxxxxxxxxx>]

"Doug Royer" <Doug@xxxxxxxxx> wrote in message
news:3F3CEC16.6010405@xxxxxxxxxxxx
>
>
> Michael Fair wrote:
>
> >>1) What if that packet is lost - as I said in the email?
> >>    "...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.
>
> 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.

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.


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

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.


> If you implement iTIP as written, exactly (1) set will be
> 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.


> If you implement iTIP as written, exactly (1) set will be
> 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 --