Subject: RE: Is there anybody out there supporting Doug's model?

From: Satya Vempati <[email-masked]>
Date: Wed, 13 Aug 2003 17:15:45 -0700

<<The current-value model never needs more than a REFRESH request and its
response to get back in synch.  The fixed model can need an arbitrary
(think
possibly large N) number of additional messages in order to establish the
RID:0 :: DTSTART set mapping in addition to the REFRESH and its response,
and
the Attendee CUA must retain all of that data.>>

Could you provide an example.

-----Original Message-----
From: Chris Olds [mailto:[email-masked]]
Sent: Wednesday, August 13, 2003 4:32 PM
To: [email-masked]
Subject: RE: Is there anybody out there supporting Doug's model?

On Wed, 13 Aug 2003 14:43:42 -0700, Anil SRIVASTAVA wrote
> Not me and I think it is time to put get out of endless cycle we are
> currently in.  Logic, reason are being ignored.

Me.

I agree that logic is being ignored, but I suspect my reasoning is
different
than Anil's.

The current-value model never needs more than a REFRESH request and its
response to get back in synch.  The fixed model can need an arbitrary
(think
possibly large N) number of additional messages in order to establish the
RID:0 :: DTSTART set mapping in addition to the REFRESH and its response,
and
the Attendee CUA must retain all of that data.  The only advantage the
fixed-ID camp has put forward is the ability to schedule multiple
instances of
a recurring event to the same DTSTART value, which doesn't really strike
me as
a big win.
The disadvantages (more complex CUA logic, more data to persist, more
VEVENT
objects to send and recieve) seem large to me too.

Contrary to Bruce's repeated assertions, when one gets a new version of a
VEVENT, complete with it's current recurrence set, there is no obligation
to
(nor any sense to) throw out the current scheduled instances for that
event. 
If the instance was previously scheduled, it can remain scheduled.  If it
wasn't there before, it needs to be added.  Nothing new here, no reason to
say
EEK! we must dispose of all data for that UID because we got a new VEVENT
with
the same UID.  iTIP describes, in detail, exactly what one should do with
this
data, and I don't see anywhere that doing the least useful thing one can
think
of is even suggested, much less required.

As far as Michael's reading of iTIP to allow versioning each instance of a
recurrence set independently (i.e., having it's own SEQ value), I can find
no
support for it in either normative nor example text, and so I think we
should
stop talking about it (because it is contrary to RFC 2446 and therefore
out of
scope).

    /cco

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