Subject: Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]

From: [email-masked]
Date: Thu, 4 Sep 2003 16:40:30 -0400

Doug, from what I read on Frank and Derik's replies and on other peoples
comments on the list, I see a pattern evolving.  People are coding their
applications using more of a fixed model.  Why do we have to have a
complicated draft when all we need to do is remove the one sentence in
3.7.1, change examples to reflect that change and resubmit the draft.

So, my question to everyone on the list that has been active on the
Recurrence-ID issue - does this sound like too simplistic an approach?  Am
I missing something.  The arguments seem to lean towards Bruce's comments
and attempt at a model.  His borad summary
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

                      Doug Royer                                                                                          
                      <[email-masked]>             To:       "[email-masked]" <[email-masked]>,             
                      Sent by:                      "[email-masked]" <[email-masked]>                       
                      owner-ietf-calendar@m        cc:                                                                    
                      ail.imc.org                  Subject:  [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]                

                      09/04/2003 03:17 PM                                                                                 

This is an attempt to start documenting all of the RECURRENCE-ID issues.
In -00 I did not represent the 'FIXED' camp very well as I do
not fully understand it and so it is missing examples.

I hope this will evolve into a document that describes ways
that different models will interact and how to make them
interact in useful ways. I also hope this will evolve
into how to migrate to some workable common usage.

As it states in the first part of the draft, I expect it
to get blasted. But the intent is to gather information
so that it can be documented.

-------- Original Message --------
Subject: I-D ACTION:draft-royer-rid-ical-00.txt
Date: Thu, 04 Sep 2003 10:39:08 -0400
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

 Title            : RECURRENCE-ID in iCal
 Author(s)  : D. Royer
 Filename   : draft-royer-rid-ical-00.txt
 Pages            : 10
 Date       : 2003-9-4

The initial version of this draft are going to be controversial.  The
idea is to develope ways to make the various ways of using the [iCAL]
and [iTIP] 'RECURRENCE-ID' property work between vendors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-royer-rid-ical-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
 "get draft-royer-rid-ical-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
 [email-masked].
In the body type:
 "FILE /internet-drafts/draft-royer-rid-ical-00.txt".

NOTE: The mail server at ietf.org can return the document in
 MIME-encoded form by using the "mpack" utility.  To use this
 feature, insert the command "ENCODING mime" before the "FILE"
 command.  To decode the response(s), you will need "munpack" or
 a MIME-compliant mail reader.  Different MIME-compliant mail readers
 exhibit different behavior, especially when dealing with
 "multipart" MIME messages (i.e. documents which have been split
 up into multiple messages), so check your local documentation on
 how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--

  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

(See attached file: draft-royer-rid-ical-00.txt)
(See attached file: smime.p7s)

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 14:48:15 -0600

> and attempt at a model.  His borad summary

When you read what I put in the draft, not all of the 'fixed' camp agree
on all of the details.  And they are NOT compatible with each other.

I have a list that I am not confident to send out yet as I re-read
the examples sent. It looks as if there are 4 distinct models and
not 2. This list will be included in the next rev of that draft.

Its not as simple as 'fixed' vs. 'non-fixed' which is one of the
points of the draft.

--

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 4 Sep 2003 15:28:40 -0700

> > Recurrence-ID issue - does this sound like too simplistic an approach?
> > Am I missing something.  The arguments seem to lean towards Bruce's
> > comments and attempt at a model.

That is certainly a step in the right direction and would clear
up the blatant conflicts.

However there are other areas too.
Off the top of my head:

"Bad Recurrence-ID" needs to be expanded to include a fourth
possibility; that it has never seen neither the base UID nor
the RECURRENCE-ID before.

The "may be" in "so that each instance may be both sequence
and versioned" needs to be changed to "is" I don't recall the
section offhand.  This needs to make it explcit that the
SEQUENCE value for each instance is tracked independently
and that they do not share a common SEQUENCE counter.

Somehow it needs to be made clear that every relevant reference
to "UID" throughout the document really means something more
along the lines of "primary key" which could include UID,
RECURRENCE-ID, and RANGE to accurately identify which events
are being referred to.  Much of the confusion here has been
as a result of interpretting "UID" to not mean all of those.

Any place where dealing with recurring instances (or sets of
them via RANGE) is not appropriate should be explicitly
mentioned that such use is inappropriate.  I cannot think
of any such cases at the moment.

Making it clear that when canceling an event for a particular
user the SEQUENCE value should not be incremented (or at least
more discussion on what it should do).

I'm sure there are others.  If there is a new list thread started
after some definite declaration that the changing recurrence-id
model is dead and should be eliminated from iTIP and perhaps we
should look at making iCal even more clear I'll be happy to provide
more direct textual recommendations with section numbers.

Of course these are just my initial thoughts and I'd be happy to
hear others either confirm, disagree, or add to these.

> Its not as simple as 'fixed' vs. 'non-fixed' which is one of the

At one point in time it appeared as if there was more than
1 fixed-id model.

But I think that the split perceived was actaully a consequence
of limiting the scope of the conversation in attempt to create
clarity since it was getting harder and harder to put together
sentences that Doug would understand.

Doug's two fixed-id models as hes explained so far are thus:
1) A recurrence-id is created at the time the instance is
   first born into existence and is fixed from then on
   forever regardless of any other changes to the event.

2) A recurrence-id is fixed from the last "rescheduling"
   of the base event.

Rescheduling means a SEQUENCE bump with the UID and no
RECURRENCE-ID (in many cases the recurrence-ids actually
stay the same, but not all).

"Add" is officially a rescheduling, but it has no destructive
powers over any existing RECURRENCE-ID.

It's not entirely clear to me at this time if canceling an
instance (and I mean truly canceling it) is a rescheduling
of the base event or an update to just the instances involved.
I leave this to someone else with more clarity on this issue
to clarify for us.

Model (1) has been obsolete since Derik and Frank's post and
I'm not event clear that it was ever believed that model (1)
was ever the totality of how to deal with recurring events.

I'm fairly confident that regardless of what might have been
flying around at the beginning of the conversations, the
fixed-id camp has all come to using model (2).

There was a time in the conversation when the discussion
was explicitly trying to exclude reschedules of the base
event from the conversation.  When such an exclusion is made,
recurrence-ids are indeed permanently fixed from SEQUENCE:0
and model (1) is actually the truth in that context.

Doug never seemed to grasp this part of the conversation.

Doug also hasn't understood per instance sequence numbers,
or at least has never been able to represent the model
accurately to demonsrate any sort of competence in using it,
and as a result he may be seeing more models than we've
actually been talking about.

I can absolutely gaurantee that Doug's list is obsolete
regardless of what's on it.  There are not 4 models
flying around.  He's just seeing 4 models.

What Doug also might have on his list came from differences in
opinion about how rescheduling all instances would have occured.

After hashing it out, we discovered that there are two ways
to reschedule every instance in a series, and we initially were
talking about our respective methods which caused confusion.

One way is to reschedule the entire series, the other is to
provide the first RECURRENCE-ID in the series and use the
RANGE:THISANDFUTURE.  These two methods result in slightly
different objects on the calendar though the displayed results
to the CU are the same.

That has since been resolved and we are in agreement that
each of us was always saying the right thing given their view.

-- Michael --

---

From: [email-masked]
Date: Fri, 5 Sep 2003 14:55:18 -0400

> the RECURRENCE-ID before.

Isn't that already covered by:

                                 If the "UID" property value in
   the "REQUEST" is not found on the recipient's calendar, then the
   "REQUEST" is for a new "VEVENT" calendar component.

(factoring in Section 2.1.5 says that UID / RECURRENCE-ID are used in 
place of UID when dealing with recurring instances per Section 2.1.5)? 

> as a result of interpretting "UID" to not mean all of those.

Ok, so some text added to 2.1.5 to this effect (expanding on bullet 1's 
meaning) would be useful? 

> more discussion on what it should do).

While this is a good change, exactly how to do it is another matter.  The 
problem is that this change is that it will effect all implementations 
already out there that follow that text from Section 2.1.4.  Just making 
the change could mean interoperability issues w/existing implementations 
and no way to detect it.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 5 Sep 2003 13:21:03 -0700

> place of UID when dealing with recurring instances per Section 2.1.5)?

What to do is handled, but it's the actual text of 4.7.2 that
bothers me.

Section 4.7.2 Bad RECURRENCE-ID says:
 ... there are three cases in which an instance cannot be found. ...

It then talks about finding the "UID" but then either not
finding the RID or having problems with the SEQUENCE value.

This isn't true.  There are four cases.  The fourth case being
that neither the UID nor the RID have ever been seen before.
A simple reference to "Do what 2.1.5 says" would suffice, but
the declaration that there are only three cases can be confusing.

> meaning) would be useful?

Yes, that would be best, I fear putting it in a different section
like Convenentions used in this document would be to easily missed.

> the change could mean interoperability issues w/existing implementations

Well is there any _real_ problem that develops if we do this?

There's 4 scenarios I can think of, of which only 2 might be
an issue:

1) Old sends a cancel to Old
No problem they do what they always did

2) New sends a cancel to New
No problem they both expect the new behavior

3) Old sends a cancel to New
No problem, SEQUENCE value has been incremented New just prcesses it.
If Old wants to reinvite New it will do whatever it has always done
in the past when it did such things.

4) New sends a cancel to Old
Not sure what happens here since it seems to be implementation specific.
I suspect that it will actually still work since DTSTAMP will be
greater than what it has, but some CUAs might try to enforce the
RFC MUST and ignore a CANCEL if the SEQUENCE isn't greater.
I guess the question is are there any CUAs we know of that will
fail to CANCEL an event if the SEQUENCE is the same?

Assuming that the CUAs will indeed cancel the event, will they
reschedule it if they receive a request at the same SEQUENCE
but greater DTSTAMP.

--------------------------------------
There might be another approach.
Rather than try and prevent SEQUENCE from being incremented,
define rules for exceptions to invalidating the ATTENDENCE status.

For instance, if an update is sent with a greater SEQUENCE and
ALL fields except Comments are identical, then no REPLY is required
and ORGANIZERS should simply transfer the attendence status.

This way, cancelling an ATTENDEE with cause a SEQUENCE bump,
and reinviting an ATTENDEE will also cause a SEQUENCE bump,
however, those bumps will have no impact on the existing attendees.

Old CUAs will simply go through the extra effort of processing
the replies and New CUAs might be sent an RSVP=true for the
higher SEQUENCE value because it failed to respond.
However, in any case, the right things end up on the calendar.

-- Michael --