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

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 13:17:57 -0600

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

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 4 Sep 2003 13:26:20 -0700

Since the "changing recurrence id" model is not
consistent with neither iCal, nor the goals of
iTIP in a message lossy environment, since it can
get itself into an infinite loop if trying to
interoperate with a fixed-id ORGANIZER (unavoidable),
and since the only reason this document even exists
is because Doug (after some hundreds of messages)
still hasn't been able understand a fixed-id model
(by his own admission) I see no purpose in making
anything interoperable between the two as such
interoperability is both unwarranted and untennable.

Further, I see no benefit to this since only two
people have expressed a desire to implement a
changing recurrence-id model and the rest of the WG
seems to have aligned on a fixed ID model.  Not to
forget that all existing major implementations use
the fixed ID model.  So strange that given the years
of his participation Doug still doesn't understand a
fixed ID model.

We have yet to here Pat's declaration on this and
until we hear that she says they should interoperate,
pursuing such interoperability will be a waste of time.

The draft also talks about the various invite models,
and cites there is no proof about problems with his model
for delegations/forwarding (despite at least 5 repitions
of such proof) and then holds firm to his idea no one
needs to have the same version of the same UID becuase
of his false understanding that it only needs to be
internally unique to the recipient.  These two
concepts of only internal uniqueness and
delegation/forwarding are directly contradictory and
only Doug seems to fail to understand this.
Further his ignorance of the proof he cites as
missing gives me no confidence in his abilities
to compose this summary, even if it were needed,
which at this time it isn't.

Lastly, his document makes no attempt to address how
each camp has declared how recoveries from missed
or missequenced messages are made which is a critical
link to understanding the various strengths and
weaknesses of each model.

I fear that any attempt to organize such thoughts,
especially since I'm being ignored by the author,
will unnecesarily exclude me from fully participating
in the discussion, and further, given that the author
has yet to understand both models fully given the
hundreds of messages already posted, gives me no hope
that trying to summarize it in a draft written by the
same author is going to make one bit of a difference
in this argument over how it should be done.

Pat has already said that she is going to post a
summary of the hundreds of messages, it's a shame
that Doug couldn't wait for her to do that.

I do believe that a draft going into more detail about
dealing with recurring events, or text intended to
replace/augment the current sections of iCal/iTIP to
better define how to deal with recurring events is
certainly warranted.  Such text should not try to
include both models, including both models just makes
it more complicated to implement for no significant
benefit to either the existing CUAs (which will now
be incompatible no matter what we do) nor future CUAs
(which will have added complexity for no good reason).

-- Michael --

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

---

From: [email-masked]
Date: Thu, 4 Sep 2003 17:00:47 -0400

Just for the record I agree with Michael Fairs assessment.

"Michael Fair" <[email-masked]> 
Sent by: [email-masked]
09/04/2003 04:26 PM

To
[email-masked]
cc

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

-- Michael --

---

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

> Just for the record I agree with Michael Fairs assessment.

Have you looked closly at the examples and comments by
those in the 'fixed' camp? They are not all compatible
with each other.

Plus the draft throws in the how to invite to a single instance
issue - which seems related but ether model can do or
not do that independent of fixed or not-fixed.

And there is also the CANCEL issue with respect to
instances - not everyone agrees yet. And again this
seems to be independent of fixed vs non-fixed.

And not everyone agrees that SEQUENCE:0 plus X updates
is the same object as a full replacement sent as SEQUENCE:X
(or would that be X+1). And again this seems to be independent
of fixed vs non-fixed.

Not everyone agrees that you can send unique objects
to unique ATTENDEES. And again this seems to be independent
of fixed vs non-fixed.

This issue was ignored at iCAL and iTIP time because it was
controversial, it still is. As are other issues that relate
to RECURRENCE-ID.

If nothing else when the draft is done, it will allow
the next reader to not have to guess.

--