Subject: Fw: Correct handling of Recurrence-id

From: [email-masked]
Date: Tue, 24 Jun 2003 12:57:27 -0400

opps  auto-reply did not go to correct address
_____________________
Note: new email address

[email-masked]
----- Forwarded by Robert Ransdell/Westford/IBM on 06/24/2003 12:53 PM 
-----

Robert Ransdell/Westford/IBM
06/24/2003 10:51 AM

To
"Chris Olds" <[email-masked]>@LOTUS
cc

Subject
Re: Fw: Correct handling of Recurrence-id

Chris Olds wrote
>> None of the CUAs I have expose the ability to do this (send invite to 
an instance)....

The two largest commercial calendar systems in the world, Lotus Notes and 
Microsoft Outlook,  both have the ability to  only invited to an instance. 
 Both use fixed RECURRENCE-ID's as described in the iCalendar 
specification when sending to the internet.

Chris Olds wrote
>>It wouldn't surprise me if many other people held this view, but arent'
>>saying anything because of the tenor of many of Bruce's messages.

You got to be kidding.  Doug is not talking about redefining some minor 
properties of iCalendar.  He is talking about redefining the basic keys 
upon which iCalendar is based.  He is talking about killing iCalendar as a 
viable internet standard.  Bruce has patiently explained with examples why 
Doug's definition of RECURRENCE-ID's can not work and why a REQUEST in 
response to a Refresh request when the invitee is only invited to a subset 
of the repeat meetings can not work unless the RECURRENCE-ID's are fixed. 
Doug on the other hand has never supplied any complete examples of his 
model.  He just keeps saying the mantra REFRESH.   Now I ask you which one 
who is annoying?

_____________________
Note: new email address

[email-masked]

"Chris Olds" <[email-masked]> 
Sent by: [email-masked]
06/23/2003 01:37 PM

To
[email-masked]
cc

Subject
Re: Fw: Correct handling of Recurrence-id

On Mon, 23 Jun 2003 11:15:45 -0400, Bruce_Kahn wrote
> Arnaud wrote on 06/20/2003 08:34:28 PM:
> > Maybe there is some misunderstanding here.  My guess is that Doug 
means 
> > "Do a REFRESH with just the UID" when you seem to think "REFRESH with 
> > UID/RECURRENCE-ID".
> 
> My examples have been how do I resync a particular UID/RECURRENCE-ID 
> all along.  Thats what "If Im only invited to an instance (or subset 
> of instances) then would you send me the entire set now in response 
> to my REFRESH?" means. 

None of the CUAs I have expose the ability to do this, but I would expect 
that
any CUA capable of inviting someone to a subset of a set of meetings
(recurring or otherwise) would be able to keep track of this.  As a 
result,
the organizer's CUA would be able to send the current state of the subset 
I
had been invited to (in reality, for privacy reasons, I would expect that 
it
would completely conceal from me that I was only invited to a subset).

> As I noted in my last posting, if Doug sends me a REQUEST for the 
> entire sequence then all of a sudden Im invited to all instances and 
> not just 1. Thats NOT the proper action to take clearly is it??
> 
> Sending a REFRESH that describes the entire UID does not work for 
> someone whose only coming to a particular instance or a subset of 
> the entire set. Cant no matter how ya slice it. 

The (modest) additional complexity of making this work must be implemented 
in
the organizer's CUA, but it works just fine.  Pegging the RECURRANCE-ID to 
the
values of SEQ=0 is the more brittle mode - how can I add instances to a 
set
w/o issuing a new UID in that case?  This is clearly an anticipated 
action,
but it breaks SEQ=0 semantics by adding an instance that cannot be 
addressed
by RECURRENCE-ID if those values are fixed at SEQ=0.  Forcing a new UID to 
be
allocated is contrary to the described workflows, and would reqire 
cancelling
the sequence and issuing a new REQUEST with the new UID in order to work 
at all.

Making RECURRENCE-ID depend on the UID and SEQUENCE is not a delta model.
Since the current state of the REQUEST can always be obtained via REFRESH, 
any
attendee CUA that finds itself out of synch can recover with one pair of 
messages.

Pinning RECURRENCE-ID values to SEQUENCE 0 requires attendee CUAs to do
complex tracking of the mapping of RECURRENCE-IDs to instances as the 
event
evolves, and what I think of when I hear the term 'delta model'.  It is 
easy
to find series of updates that make RECURRENCE_IDs ambiguous, and easy to 
have
instances with no valid (according to this model) RECURRENCE-ID.

While this view appears to agree with Doug, it is based on my own reading 
of
iTIP.  It wouldn't surprise me if many other people held this view, but 
arent'
saying anything because of the tenor of many of Bruce's messages.

    /cco

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

---

From: Doug Royer <[email-masked]>
Date: Tue, 24 Jun 2003 13:26:24 -0600

[email-masked] wrote:

> upon which iCalendar is based.

I have been polite. I am  talking about you actually reading the specs
and stopping the self proclaimed declarations and whining by you and Bruce
that it is not the way you want things to be done. iCal is clear,
the RECURRENCE-ID is tied to the UID/SEQUENCE set. That *IS* what
the text if iCal says and you simply refuse to debate the facts.
Your or Bruce have never shown it does not work. You simply have
stated that you do not want to do it that way. There is NO
such need to do it that way. Do it the documented way and it works.
And it works with other vendors. Declaring that YOU must throw
away a UID because some recurrence rule changes is a bug in your
code not in ours.

> He is talking about killing iCalendar as 
> a viable internet standard.

Simply bogus. A HUGE percentage of my income is based on several
IETF standards including CALSCH and proposed standards. Your or Bruce's
proclamations I see as vendor specific requirements not interested
in CALSCH, but in making the world unable to update recurrence rules
and I suspect because your product can not do that without your
implementation issuing a new UID. Guess what, I can not find
any major vendors product that has that limitation.

> Bruce has patiently explained with examples 
> why Doug's definition of RECURRENCE-ID's can not work and why a REQUEST 
> in response to a Refresh request when the invitee is only invited to a 
> subset of the repeat meetings can not work unless the RECURRENCE-ID's 
> are fixed.

No he has not. He has simply shown that his examples of doing
it that way does not work. And as far as I can tell it is simply
a way to not have to update the sequence number. He has NOT shown
that iCal or iTIP is broken. Just that the way he (and you?) want
to do it does not work. You and he repeatedly refused to reply
to factual comments about the text within iCal or iTIP. You simply
declare that because your product does not interact with another
product when doing it as documented (perhaps because your product
can not?), that it is busted. No it is not, my code works and I suspect
other have code that works. Simply update you code or use the work
around I provided that I also tested and it works.

>  Doug on the other hand has never supplied any complete 
> examples of his model.  He just keeps saying the mantra REFRESH.   Now I 
> ask you which one who is annoying?

I do not have to supply any examples, simply read the text in
iCAL and iTIP as THAT is the way of doing it.

Bruce admits his examples do not work past SEQUENCE:0. And you and
Bruce keep ignoring the text within iCal and iTIP. Yes I believe
you, your code is not compliant to iCal if in fact you do it that
way.

Simply because you or Bruce declare things as true does not make
them true. Recurrence-ID works as documented.

And I will say it again - DO A REFRESH
and if you get partial update with a new sequence number == DO A REFRESH.
IT works - it *IS* tested. Debate that fact.

-- 

  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, 24 Jun 2003 20:17:13 -0600

[email-masked] wrote:
> ...Both use fixed RECURRENCE-ID's as described in the iCalendar 

Which RFC are you claming says that? You have never cited any
such text. You simply declare that you *think* that one sentence
means that and you disregard ALL opposing text in iCAL and iTIP
which when you combine obviously can NOT mean that all recurrence
id's are tied to sequence zero - no such text exists.

It is NOT in 2445, 2446, 2447, CAP-draft, or any CALSCH or individual
draft that I can find.

--