Subject: RE: CAP draft - last call, etc.

From: Satya Vempati <[email-masked]>
Date: Tue, 01 Jul 2003 16:03:35 -0700

I might have misunderstood Bruce but I took it differently. Since
RECURRENCE-ID "never" changes in his model, SEQUENCE:0 is not really
required. All SEQUENCE numbers point to the same RECURRENCE-ID and there
is no need to "preserve" SEQUENCE:0.

-----Original Message-----
From: Doug Royer [mailto:[email-masked]]
Sent: Tuesday, July 01, 2003 3:25 PM
To: [email-masked]
Subject: Re: CAP draft - last call, etc.

Satya Vempati wrote:
>  From your mail to the news group on 6/19/03:
> "Fixating the recurrence-id to sequence zero
> prevents the recurrence rules from ever changing and will make CAP
> VCARs, NOTIFICATIONS, local CU VALARMs break in CAP. So I just do
> not see how that will work."

As in they get DELETED if the UID changes. Not the same as breaking
the CAP protocol.

> Additionally, from the CAP draft 10:
> -----------
> 6.1.1.17 Query by Date-Time range
> This query selects the entire content of every booked "VEVENT"
> component that has an instance greater than or equal to July 1st,
> 2000 00:00:00 UTC and less than or equal to July 31st, 2000 23:59:59
> UTC. This includes single instance "VEVENT" components that do no
> explicitly contain a "RECURRENCE-ID" property.
> BEGIN:VQUERY
> EXPAND:TRUE
> QUERY:SELECT * FROM VEVENT
> WHERE RECURRENCE-ID >= '20000801T000000Z'
> AND RECURRENCE-ID <= '20000831T235959Z'
> AND STATE() = 'BOOKED'
> END:VQUERY
> ---------------
> If RECURRENCE-IDs stay rooted at their instantiated values, the query as 
> formulated above will return erroneous results.
> I haven't seen an email in which Bruce Kahn conceded that RECURRENCE-IDs 
> should change.

In Bruces email dated: June 26 3:55PM

  ...The other way I described it also works but could mistakenly make some
  think that the CUA must preserve both the SEQUENCE:0 definition and then
  all the current ones and thats not necessary.  Both ways will achieve
  the same effect. ...

So, no.

-- 

  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: Tue, 01 Jul 2003 18:16:38 -0600

> is no need to "preserve" SEQUENCE:0.

Ether way, it may break iTIP clients, but not the CAP protocol.

And his belief is contrary to the text in iCAL/iTIP, he is simply
telling people how he wants it, not how it is.

Plus, the CUA can do a full REFRESH and ignore that rule anyway.

--

---

From: Doug Royer <[email-masked]>
Date: Tue, 01 Jul 2003 21:50:52 -0600

Bruce - you are a friend - but in this debate I think
you may be lost :-)

> is no need to "preserve" SEQUENCE:0.

His model is not iCAL or iTIP it is a NEW proposal for the
next version of iCAL or iTIP.

In iTIP:

    Hence, CUAs must persist the following component properties: "UID",
    "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP".  Furthermore, for each
    "ATTENDEE" property of a component CUAs must persist the "SEQUENCE"
    and "DTSTAMP" property values associated with the "Attendee's"
    response.

And what about the "ADD" method:

   4.4.6 Add A New Instance To A Recurring Event

    This example adds a one-time additional instance to the recurring
    event.  "Organizer" adds a second July meeting on the 15th.

The text and examples CLEARLY show the SEQUENCE number being bumped
and the new SEQUENCE has at least one instance in it that is NOT
in SEQUENCE:0. Thus NO ONE CAN JOIN if you follow Burce's model
and Bruce agrees. Then Bruce made a NEW assertion - that you MUST
throw away the UID and start over. Sorry but his model is just
not thought out.

And what about:

  4.4.7 Add A New Series of Instances To A Recurring Event

   ...
    Alternatively, if the "Organizer" is not concerned with per-instance
    updates, the entire event can be rescheduled using a "REQUEST". This
    is done by using the "UID" of the event to reschedule and including
    the modified "RRULE". Note, that since this is an entire rescheduling
    of the event, any instance-specific information will be lost.
                                                            ^^^^^
    ...

It does not say, 'Throw away the UID', it says 'reschedule'
using the 'UID' and 'any instance-specific information will be lost.'.
Why is that confusing to anyone?

If you follow the debate from the start by reading the archives
I think you will agree that it started from an assertion that
a specific vendor does it incorrectly and Bruce wanted to be
compatible. For which I reply - you can be - ISSUE a full REFRESH
and you are back in sync with that vendor. You do NOT need
to re-issue an iTIP RFC removing MULTIPLE paragraphs saying you
CAN reschedule. If that vendor throws away the UID - so what?
It does not effect iTIP. It only effects those users who
loose data - a point NOT disputed at all. My testing shows
that that vendor CAN reschedule to an entirely different
set of recurrence rules. No proof is provided from Bruce,
just another assertion that if we break iTIP in this
way it works in some new way and other things that were
not busted are newly busted.

Bruce has NOT shown any thing busted. He simply says that
if you do something that is not documented (in a way that
looks to me to be a way not to have to follow iTIP and
bump the sequence number), then the undocumented way does
not work. So what? Do it the documented way.

This debate reminds me of a class project where you
would get an 'A+' if you could so confuse a truth
to make it appear to be a problem. Bruce gets an 'A++'.
It is NOT busted! DO A REFRESH - AND the text in ITIP
tells you HOW and WHEN to detect you need to do that
REFRESH and for EXACTLY the reasons in this debate.
Yet Burce has NEVER debated that fact.

Bruce - you are a friend - but in this debate I think
you may be lost :-)

--