Re: Does anyone still think that RECURRENCE-ID's do NOT change?

[email protected] wrote:

> 
> The _only_ place where a repeating rule is really necessary is for the 
> infinite case.  For a non-infinite set, the RRULE only saves some octets 
> in the iTIP message compared to sending RDATEs.  So, for large repeating 
> sets using a recurrence rule is an easy way to save space in the 
> iCalendar stream sent.   So the fragment:
> 
>      DTSTART:20030902T140000Z
>     RRULE:FREQ=DAILY;COUNT=10
> 
> is an alternative to this fragment:
> 
>     DTSTART:20030902T140000Z
>     RDATE:20030903T140000Z
>     RDATE:20030904T140000Z
>     RDATE:20030905T140000Z
>     RDATE:20030906T140000Z
>     RDATE:20030907T140000Z
>     RDATE:20030908T140000Z
>     RDATE:20030909T140000Z
>     RDATE:20030910T140000Z
>     RDATE:20030911T140000Z
> 
> It should be clear that once you reschedule a single instance then the 
> use of a recurrence rule becomes MUCH harder if not impossible (at least 
> solely).  For example, if I reschedule the 6th instance to a different 
> time then you cannot expect the RRULE:FREQ=DAILY;COUNT=10 to still be 
> usable when adding any new invitees!  You have a few possible ways of 
> sending this new set to a new invitee but using just a single RRULE is 
> NOT possible any more.

If the RRUE is easy or hard does not seem to be a qualification for
the definition of RECURRENCE-ID. Your point above is not relevant
to the point of whether the effective DTSTARTs you have above are
the same in the SEQUENCE:0 object as they are for the SEQUENEC:1 object.

> If I opt'd to send the REQUEST with RDATEs instead of an RRULE and then 
> I want to reschedule an instance, I would send nearly the same iCalendar 
> stream but the 6th instance would be different (reflecting the new 
> time).  If I didnt use an RRULE then there is no "pattern" to change. 
>  I'm guessing that some folks are focusing on that particular word (to 
> the exclusion of all the other author reponse) since only the recurrence 
> grammar is designed to express patterns in a compact way.  

Bruce - I find it hard to believe that you really believe that you
can exclude 'pattern' and 'change' in Derik's and Frank's email and
keep a straight face.

> People should not get hung up on the use of a pattern in the iTIP 
> messages; the pattern is simply what the recurrence grammar is designed 
> to encode.  As such, it cannot be used for entries that do not repeat on 
> some form of regular pattern. To do that you have to use RDATEs (or ugly 
> combinations of RRULEs/EXRULEs/EXDATEs).  Once you reschedule any single 
> instance, you no longer have a pattern to follow.

Pattern is the pattern of instances. No where in Frank's or Derik's email
do they define pattern to be the RRULE grammar. It is however used
in the paragraph that describes the 'instances'. And for that I read
that the RECURRENE-ID's are the effective start dates of the object.

> Another thing that I think some folks do not grok fully is that in order 
> for an RRULE to be used to generate a set of entry instances, there can 
> be NO differences between each instance apart from its start/end 
> date/times.  Every single property is _exactly_ the same: the same 
> ATTENDEE list, the same DESCRIPTION, the same ATTACHments, etc.  This 
> most commonly occurs only when the instances are first created.  After 
> that things typically change: ATTENDEE PARTSTATs vary, ATTACHments 
> change, DESCRIPTIONs (typically the Agendas) change, COMMENTS about the 
> instances vary, etc.  As such, its not possible to rely on a RRULE (or 
> group of RRULEs) in a single message to be usable when adding a new 
> invitee; the individual instances have different data.  They no longer 
> are near exact clones of each other.  

When you use the word 'instances' above in the last sentence you do not
mean the effective start date instance - Correct? You mean the copy
that one ATTENDEE sees with respect to another ATTENDEE may differ-
Correct? If so, I think we agree.

You are also not saying that all ATTENDEES need see the exact (byte
for byte) same object correct?

> If you do not focus just on the idea of a particular pattern and treat 
> the instances as a set that can move around then it should be clear why 
> the RECURRENCE-IDs do not change on a reschedule.  By keeping them fixed 
> missed changes (ie: lower SEQUENCE valued messages) are NOT a concern 
> since they are obsolete anyway.  ONLY with fixed RECURRENCE-IDs is it 
> possible to detect a missequenced iTIP message and deal with it properly.  


> Some folks seem to think that there is some mystical need to distinguish 
> an invitation from a reschedule from an update and are seemingly 
> deriving this from the presence of repeating information (or lack of 
> RECURRNECE-IDs). 

You do seem to get initial invitations crossed referenced with the
RECURRENCE-ID issue. I suspect it is for the same reason. Because
you have a legacy problem and not because it says so in ITIP (and
despite the 300-400 emails sent on this subject - there has not
been ONE that explains where in iTIP or iCAL or iMIP that says you
can send an instance update and call it an initial invitation.)

The myth as you call it is a section or two in iTIP. The real myth
is that you can selectively ignore parts of iTIP to satisfy your CUA
legacy requirements.

> This is an unnecessary distinction AND its NOT 
> described at all in the iTIP RFC.

What about the specific text in: "4.4.2 Modify A Recurring Instance" ?

>  The distinction is clearly described 
> in reference to the recipients calendar and NOT to the senders or the 
> iTIP message itself.   There is NO need to draw any distinctions; if the 
> entry is new to the recipient then its an Invitation, otherwise its a 
> reschedule or an update.  

Then why has EVERYONE  that thinks that you can invite someone
by sending them an instance update guessed incorrectly as to the
example I sent was an update or not? I copied the text verbatim
from iTIP itself. Its not a debate, it is not my opinion,
it was 'verbatim' from iTIP and yet you got the wrong answer.

The only response was when someone called it 'fishy' and somehow
the CUA would know that it is 'fishy' and do a REFRESH. Yet
you and they can not seem to reply or explain how the CUA would know
to do that REFRESH or how to know that it was 'fishy'.

> So you may ask why does Doug try to draw a distiction?  The answer is 
> simple: The need for a distinction derives from the delta models 
> inability to deal with lost or missequenced messages.  The recipient has 
> no way to differentiate a missed reschedule from a new instance 
> invitation.  Thus the only solution for the delta model is to stop all 
> workflow on ALL instances and ask the Organizer for a REFRESH of all 
> instances in question.  There are a couple notable problems w/this 
> design:  

No and please stop mis-quoting me.  The real answer is I copied
the example from ITIP and you guessed the wrong answer because
you could not tell by looking at the object. And you guessed
the wrong answer because you thought it was an initial invitation
to a single instance (Now that is something NOT described in iTIP
at all - that *is* a Bruce invention).

Your CUA and all persons that called the example I sent an initial
invitation to this day would have incorrect data in their CUA because
they did a REPLY to a INSTANCE update and never knew to do the REFRESH.
The objects did not look 'fishy' as someone called it because it
was byte for byte what you called an initial invitation, yet it was
not, it was an instance update copied straight from iTIP. You have been 
misleading people about this and I suspect it is again a legacy problem
you have in your implementation.

> 1: Until the Organizers 'nuke' REQUEST gets there the recipient can 
> perform NO workflow on ANY instance.  That means NO accepting, 
> declining, counter proposing or delegating; they can safely perform NO 
> action until they recreate all instances w/the correct current 
> RECURRENCE-IDs.  

False - as you can not confuse an initial invitation from an update
in the iTIP model, no such problem exists. Simply not true and
outrageous for your to make that up on the fly.

If you get an update you know you missed something. If you
get an update and you have not got a non-update object, do a REFRESH.

If you get a full object - nothing to miss as you are up to date.

In your model if you get an update you called it an initial invitation
and would have no way to know that it is an update so your
CUA would not know to do a REFRESH - your CU going to miss
meetings. You keep making assertions that that is not true, yet
you can not explain how your CUA would know it is 'fishy'.

Your assertions about workflow have not been posted about using
the iTIP model with distinct update and invitation, it mixed the
fixed model with the non-mixed model and declared that broken.
And yes that example sent was broken.

> 2: Because iTIP cannot guarantee delivery its possible that the 
> Organizers REQUEST never arrives thus the invitee can be indefinitely 
> stuck w/calendar entries that they cannot be sure are still real or not. 
>  Or its possible that the "full REFRESH" never gets to the Organzier so 
> they never have a clue that some invitee needs help...

Simply false and for the same reasons as above. Because the objects
are distinctly updates or distinctly new invitations, then 100% of the time
you can distinctly tell the difference the first object you get.

With your model you have still failed to explain how to tell if
it is 'fishy'.

> 3: Its possible that the recipient was only invited to a particular 
> instance.  As such the Organizer would only send a REQUEST with that 
> RECURRENCE-ID in it; not one with an RRULE or other repeating info in 
> it.

Again falsely representing the email that was sent.
Simply not what was said at all.

(1) Send them the object as they need to see it. Done.
(2) There is NO requirement and it HAS been discussed and IS in ITIP
     that you can send distinct objects to unique ATTENDEEs.

>  Sending a REQUEST without a RECURRENCE-ID is not semantically the 
> same as a REQUEST for a single instance;

Yet BYTE for BYTE they are 100% identical in your proposal.
Explain by what magic they are they not semantically the same
and how you your CUA can tell them apart, but on the WG list
you can not and did not know how to tell them apart when sent
samples.


? the recipient will treat it as
> a non-repeating entry when in fact its an instnace of a repeat set.   As
> such adding the invitee to other instances means destroying what they 
> think the UID is and having them recreate a new set of now repeating 
> instances.  This means that even though nothing may have changed about 
> the initial instnace they were invited to, the Organizer MUST resend all 
> the data for the unchanged instance just so the recipient can destroy 
> and recreate it in their calendar as a repeating instance now.  What a 
> waste of bandwidth and cycles!  Plus, iTIP clearly says that 
> RECURRENCE-ID MUST be on the REQUEST when it refers to an instance of a 
> repeat set (check the restriction table if in doubt).

(please submit a real draft so it can be debated)

So in your proposal you can only invite an ATTENDEE to ONE instance
at a time to an existing series? Why not just send them ONE object with all 
the instances they are requested to attend, tailored to that ATTENDEE?


> If you consider the correct usages for recurrence rules, the analysis of 
> the delta models shortcomings and the response from Derik/Frank I would 
> hope that it should be clear now exactly why the model is fixed and not 
> changing.  But Im not holding my breath just yet...

Bruce - you ether did not read the email that was sent, did not understand
it, or you are intentionally misrepresenting it. No matter what iTIP-next
concludes, there is NO way that a serious evaluation of what was sent
came from you in this email.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email protected]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards