[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




Just for the record I agree with Michael Fairs assessment.



"Michael Fair" <michael@xxxxxxxxxxxxxxx>
Sent by: owner-ietf-calendar@xxxxxxxxxxxx

09/04/2003 04:26 PM

To
ietf-calendar@xxxxxxx
cc
Subject
Re: I-D ACTION:draft-royer-rid-ical-00.txt]







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" <Doug@xxxxxxxxx> wrote in message
news:3F578FE5.2050305@xxxxxxxxxxxx
>
> 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: Internet-Drafts@xxxxxxxx
> Reply-To: Internet-Drafts@xxxxxxxx
> 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:
> mailserv@xxxxxxxxx
> 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
>   -------------------------------|-----------------------------
>   Doug@xxxxxxxxx                 | Office: (208)612-INET
>   http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                  |   Cell: (208)520-4044
>
>                  We Do Standards - You Need Standards
>