Subject: Is there anybody out there supporting Doug's skewed model of iCalendar besides Doug

From: [email-masked]
Date: Wed, 13 Aug 2003 17:13:44 -0400

_____________________
Note: new email address

[email-masked]

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Wed, 13 Aug 2003 14:43:42 -0700

Not me and I think it is time to put get out of endless cycle we are
currently in.  Logic, reason are being ignored.

________
Anil SRIVASTAVA
[email-masked]

SunNetwork 2003 Conference and Pavilion
Sept 16-18, 2003, San Francisco.
Register at: http://www.sun.com/sunnetwork

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, August 13, 2003 2:14 PM
To: [email-masked]
Subject: Is there anybody out there supporting Doug's skewed model of
iCalendar besides Doug

_____________________
Note: new email address

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 14:53:17 -0700

Doh! How much effort we all could have saved.

Please people, don't keep silent on this one.

If there is anyone out there besides Doug who still
believes that Doug's model is the appropriate model
(even if you don't think you are up to defending it),
let the list know.

If Doug is the only one then it can just be written
off as a rouge implementation.  Otherwise it is
important to get consensus on how the texts are to
be implemented and iCal-version-next can clarify
what the list decides.

-- Michael --

---

From: "Chris Olds" <[email-masked]>
Date: Wed, 13 Aug 2003 16:32:16 -0700

On Wed, 13 Aug 2003 14:43:42 -0700, Anil SRIVASTAVA wrote
> currently in.  Logic, reason are being ignored.

Me.

I agree that logic is being ignored, but I suspect my reasoning is different
than Anil's.

The current-value model never needs more than a REFRESH request and its
response to get back in synch.  The fixed model can need an arbitrary (think
possibly large N) number of additional messages in order to establish the
RID:0 :: DTSTART set mapping in addition to the REFRESH and its response, and
the Attendee CUA must retain all of that data.  The only advantage the
fixed-ID camp has put forward is the ability to schedule multiple instances of
a recurring event to the same DTSTART value, which doesn't really strike me as
a big win.
The disadvantages (more complex CUA logic, more data to persist, more VEVENT
objects to send and recieve) seem large to me too.

Contrary to Bruce's repeated assertions, when one gets a new version of a
VEVENT, complete with it's current recurrence set, there is no obligation to
(nor any sense to) throw out the current scheduled instances for that event. 
If the instance was previously scheduled, it can remain scheduled.  If it
wasn't there before, it needs to be added.  Nothing new here, no reason to say
EEK! we must dispose of all data for that UID because we got a new VEVENT with
the same UID.  iTIP describes, in detail, exactly what one should do with this
data, and I don't see anywhere that doing the least useful thing one can think
of is even suggested, much less required.

As far as Michael's reading of iTIP to allow versioning each instance of a
recurrence set independently (i.e., having it's own SEQ value), I can find no
support for it in either normative nor example text, and so I think we should
stop talking about it (because it is contrary to RFC 2446 and therefore out of
scope).

    /cco

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

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 17:48:10 -0700

Hey Chris,

I was wondering what had become of you.  :)

> response to get back in synch.  The fixed model can need an arbitrary
>(think possibly large N) number of additional messages in order to
> establish the RID:0 :: DTSTART set mapping in addition to the
> REFRESH and its response, and the Attendee CUA must retain all of
> that data.

I'll admit that I don't exactly follow what it is you are implying
must be tracked since there is never a time where the 'fixed-id'
model needs all messages back to the SEQ:0 DTSTART.

But I can assure that in the general case of a REFRESH, the
response messages of both the 'fixed-id' and 'current-value'
models should be virtually identical.  Both contain the
description of the base set of instances, and both contain
follow-up objects that describe per instance differences,
and both send one, and only one message to get the recipient
fully in sync.  Further in the 'fixed-id' model there are
fewer cases where being out of sync is even possible and
thus oftentimes the REFRESH results in a noop for the CUA.

From the examples, section 4.4.7 talks about what a REFRESH
reponse looks like.
One sentence in particular stands out:
   ...
   To convey all instance-specific
   changes, the "Organizer" must provide the latest event description
   and the relevant instances.
   ...

Sure in, the 'current-value' model described in the other
discussion where every 'instance reschedule' is actually a
'rescheduling of the entire set' where most RID's end up
matching at the end, it's _possible_ to get a smaller message,
but highly unlikely.

You are assuming that the only data that will ever be associated
with an instance is defined in the base recurring event.
There will be no comments, no attatchements, no attendance
differences, no per instance URL, no descriptions, no summaries,
and that every instance will always be at the same location and
use the same resources.

In the event that you ever want to convey any of the above to
the recipients (which I think you would) you have to do it in
a per instance object.  This is the same regardless of the
model chosen.

You are also assuming that your reschedules of the instances
merely changed the date and did not change the start time.
Once you change the start time of an instance you MUST provide
an independent instance object ot convey that info.

However, I will grant you that in the very isolated case that
all you did was change the date, and only the date, of a
particular instance(s) and you do not wish to convey any other
per instance data (which I just find hard to believe) you are
correct.  The 'current-value' model saves a few bytes on the
wire.  On the flip side it take the ORGANIZER's CUA the same
or more CPU cycles to construct the new recurrence set, and
takes about the same or more number of CPU cycles on the
recipient's side.  The primary distinction is that to say
"use this pattern, except this, except that" usually takes
more CPU cycles than to say "use this pattern, now update
this instance, update that instance" and in the case you
want to convey per instance info you have to say the even
more complicated "use this pattern, except this, except that,
now update this instance, update that instance".

> The only advantage the
> fixed-ID camp has put forward is the ability to schedule
> multiple instances of a recurring event to the same DTSTART
> value, which doesn't really strike me as a big win.

Granted.  It was a pedantic exercise to shut up Doug's
insistence that the fixed-id model had some problem
with this.  Not to mention at the end of that message
I said that I could receive those messages in any order
concocted and would still end up with the same results
which further demonstrated the robustness of the model
not just its ablility to handle silly things.

> The disadvantages:

> (more complex CUA logic,

I don't see how it's any more complex that what the CUA
already has, it already needs to look for the presence of
both UID/RID on every message, and it already has to be
prepared to reschedule a particular instance.  In fact
I see the logic as being very simple.
Every object in a message refers to one and exactly one
object in the store and if it can't find that object it
creates it, if it can it updates it.
In the case of updating a recurring series it does the
same amount of bookkeeping the 'current-value' model
needs to do.

> more data to persist
This is just false.
Last paragraph of section 2.1.5 expressly states that CUA's
must track the RID of property of a component.  Unless you
want to redefine persist, add a missing "may", or call the
paragraph an error.

> more VEVENT objects to send and recieve)
When you are dealing with differences between individual
instances the fact is there just are more objects to
pass around.  See my description above about REFRESH
to see how in practice there aren't any more objects
to send and receive as the few cases where the
'current-value' can save a few bytes are very extraordinary.

In fact, if the 'fixed-id' model wanted to, it could actually
use those same semantics to get those exact same results
if the CUA bothered to be smart enough to detect them.
(The semantics being treat the reschedule of an instance
 as a reschedule of the entire series.)

> Contrary to Bruce's repeated assertions, when one gets a new
> version of a VEVENT, complete with it's current recurrence
> set, there is no obligation to (nor any sense to) throw out
> the current scheduled instances for that event.

You are assuming that all instance updates contain the entire
recurrence set.  There is only one example in all of iTIP that
uses those semantics and no where in the prose that says it
is even recommended to do so.  So the majority of implementations
will not include the recurrence set in an instance update.

Imagine a situation where a CUA gets every other message.
There is an instance A that gets moved 6 times.  The CUA
will only see three of moves (the even ones) and it will
miss three of those moves (the odd ones).  Since each
message uses an RID of the DTSTART of the message before
it, all messages will have a different RID and the CUA
will never have an object in its calendar to match the
object trying to be addressed.  Therefore it will send
out three REFRESH requests.

No one in the 'current-value' camp has said exactly what
the 'current-value' model CUA should do in the case where
it receives a message for an instance of a recurring
series for which it can find no existing object and the
sequence value is larger than anything it has seen before.

I've held that if it follows iTIP 2.1.5 it will add it to
its calendar and as per 4.7.2 send a REFRESH request.  This
means that anytime the 'current-value' misses an update,
the next instance update it sees will create a new
duplicate event.  This situation is only resolvable when
the new REFRESH response shows up to say which instances
are and are not in the set.  The CUA can then wipe out
all the instances that aren't in the set and be in sync
once again.  Hopefully to not miss any more instance
update messages.

Doug, in one or two posts, implied that it will hold the
messages until it receives the messages with the proper
sequence number in it.

> As far as Michael's reading of iTIP to allow versioning each
> instance of a recurrence set independently (i.e., having it's
> own SEQ value), I can find no support for it in either normative
> nor example text, and so I think we should stop talking about
> it (because it is contrary to RFC 2446 and therefore out of
> scope).

If I am indeed misreading the text then I must be corrected.

In section 3.7.1 Working With Recurrence Instances the first
thing it talks about is how different CUAs might or might not
support recurring events.  The very first sentence of page 57
(Second paragraph of 3.7.1) says:

   Since implementations may elect to store recurring events
   as either a single event object or a collection of discreet,
   related event objects, the protocol is designed so that
   each recurring instance may be both referenced and versioned.

How do you read that sentence in respect to saying that
each recurring instance can be versioned?

In fact if we cut it down to just the important and
applicable text it says:

   The protocol is designed so that each recurring
   instance may be versioned.

Regardless of how you interpret the "may" part, and I
can think of a few, the end result is that a CUA can
and therefore some will track independent versions
of each instance in a recurring event.

Or do you have an interpretation of that sentence that
doesn't allow for the existence of per instance versions?

You might just call it an error in the RFC.  I can respect
that.  I have to respect that since there is at least one
other sentence in iTIP that the 'fixed-id' model says is
an error.

-- Michael --

---

From: "Chris Olds" <[email-masked]>
Date: Thu, 14 Aug 2003 03:55:59 -0700

On Wed, 13 Aug 2003 17:48:10 -0700, Michael Fair wrote
> I was wondering what had become of you.  :)

I'm still here, I just have a job now, so I can't spend all day on iCAL/CAP :)

> model needs all messages back to the SEQ:0 DTSTART.

It's not that you need to see all of the intermediate messages (it took me a
long time to come to that conclusion), but that you need to see all of the
RECURRENCE-IDs in order to be sure you're establishing the correct mapping.

> fully in sync.  

Yes, but the message in the fixed-id model must contain a VEVENT with a
RECURRENCE-ID for every instance that has been rescheduled from the original
set, regardless of whether or not there was any other instance-specific data.
 This includes instances (for example) way in the future, that would otherwise
use the default values, if a meeting was moved from Friday to Sunday.  I'm not
saying this is the right way to make this kind of change, but if you do, this
is the implication of the fixed-id model.  In the current-value model,
instances w/o any other data are 'free' (gratis), since they can ride on the
base definition.

> Further in the 'fixed-id' model there are

I don't believe this is true.  They may be the same, but I don't see how
current-value can be worse.  The cases that don't require a REFRESH in the
fixed-id cases shouldn't require one in the current-value model.

>    and the relevant instances.

<snip/>
> This is the same regardless of the model chosen.

Agreed.

> an independent instance object ot convey that info.

RDATE values can include times, so I can reschedule a (n otherwise generic) 
instance by adding to the RDATE or building an RRULE to cover that date & time
(possibly along with EXDATE/EXRULE additions too).  If the location changed 
too, then I need to add a VENVENT to the message, with the RID set to the 
current (in this case, rescheduled) date and time.

> now update this instance, update that instance".

No.  The base event object (the one w/o any RID) will always say "use these 
dates/times, these patterns, except these dates, these patterns".  Any VEVENT 
objects included in the same message should have the same SEQ and an RID 
matching a date/time in the current set as defined in the base event object.

> not just its ablility to handle silly things.

Except for the detail that once all the events are folded onto the same date 
they become a single instance, current-value is just as able to handle 
ordering issues.

> same amount of bookkeeping the 'current-value' model

I call the requirement that a CUA be able to fold a series of events together 
and then be able to unfold them more complex than tracking the current state 
of the series.  Regardless of whether or not the Organizer is the only one 
that has to do it, it's still more complex.

> want to redefine persist, add a missing "may", or call the

In the current-value model, all I need to do is track the recurrence set; 
their start date/times are the RIDs.  Fixed-ID requires that I be able to 
keep track of another recurrence set, and the mapping from that set to the 
current set.  There is no assurance that a CUA won't end up mapping the 
sequences back to front (the first date in the RID sequence maps to the last 
date in the current sequence...the last date in the current sequence maps to 
the first date in the RID (SEQ:0) sequence), and while that would be a stupid 
thing to do, it would have to be allowed for.

> 'current-value' can save a few bytes are very extraordinary.

I guess my problems aren't with the best case, or even the expected case.  I 
worry about being able to write code that can deal with stupidity like I 
described in my previous paragraph.  In the current-value model, there is no 
mapping to keep track of, so I _never_ have to write code to handle the 
mapping.  If no code is needed, I don't have to worry about pathological 
cases or buggy code (I hate writing code with bugs, but it happens...).

>  as a reschedule of the entire series.)

I think you're describing what I would call a change to the recurrence set.  
I see that as different than a reschedule of the entire series; I would use 
that term to describe a reschedule of every item, not of a single one.

> will not include the recurrence set in an instance update.

<rfc2446>
3.2.6 REFRESH

   The "REFRESH" method in a "VEVENT" calendar component is used by
   "Attendees" of an existing event to request an updated description
   from the event "Organizer". The "REFRESH" method must specify the
   "UID" property of the event to update. A recurrence instance of an
   event may be requested by specifying the "RECURRENCE-ID" property
   corresponding to the associated event. The "Organizer" responds with
   the latest description and version of the event.
</rfc2446>

I don't see where an Organizer is allowed to respond with less than the 
complete event if no RECURRENCE-ID is specified.  If no RID is present, I 
would call a CUA that didn't send this attendee's complete view of the event 
broke.  I would expect all implementations to send the current 
RRULE/RDATE/EXRULE/EXDATE values for this attendee.  [[ side note: if 
Organizers are not expected to send different values based on the identity of 
the attendee, then why is ATTENDEE a required property for a REFRESH? ]]

> out three REFRESH requests.

Yep.  And after a single response message, it will be up to date. iTIP 4.7.2 
says a CUA SHOULD send a refresh request in this case, so current-value 
semantics do not imply any extra messages.

> sequence value is larger than anything it has seen before.

There is no need to.  4.2.7 describes that situation _exactly_.

> once again.  Hopefully to not miss any more instance

This is why Doug objects to your interpretation of 2.1.5.  The more I think 
about it, the more I tend to agree with him.  This is a case where I 
certainly wouldn't want my CUA to book the time, and unless I told it I 
wanted to bother with messages it thought might be bogus and expected to be 
confirmed or denied Real Soon Now, I don't want to hear about it or see it in 
my calendar.

> messages until it receives the messages with the proper

Which will be the response to the REFRESH (or a successor to that object), 
and all will be right with the world.

> of each instance in a recurring event.

This is all good stuff, and my interpretation is, I think, very close to 
yours.  The difference comes when we ask if the versions of instances are 
independent of each other, and how they relate to the value of SEQ.  Since 
the latter question is really the important one, I'll address that first.

If one increases SEQ any time an instance is rescheduled, then you can talk 
unambiguously about the value of an instance at a particular value of SEQ.  A 
CUA that sees all of the updates (an Organizer, or a fortunate CU's CUA) will 
be able to track these versions without error.  There is nothing that says 
that a given value of SEQ for an object cannot be correlated with several 
instance changes, and there is nothing I can find that even implies that the 
SEQ value for a REQUEST with an RID is independent of the SEQ values seen for 
the entire event (and 4.2.7 is directly in conflict with that idea).

> doesn't allow for the existence of per instance versions?

No, if you want per-instance versions, by all means go ahead.  That doesn't 
mean that instances have SEQ values independent the base event or other 
instances.  It's consistent with all the text you quoted to increment the per-
base-event SEQ value on each instance change, or each time a set of instance 
changes are sent to Attendees.
 
> other sentence in iTIP that the 'fixed-id' model says is

That's because the fixed-id model _is_ an error.

    /cco

---

From: [email-masked]
Date: Thu, 14 Aug 2003 11:28:35 -0400

Chris wrote on 08/13/2003 07:32:16 PM:
> response to get back in synch. 

The iCalendar model does not need the REFRESH that the Dougs model does. 
Plus, there is no guarantee that the REFRESH will get thru or that the 
'nuke' REQUEST that it triggers will get back either so the Attendee can 
do nothing until it does. 

The iCalendar model never needs the REFRESH since its unambiguious if the 
missequenced REQUEST is really an invitation to a new instance or a 
reschedule/update of an existing instance. 

This all should have been clear from the analysis I posted on Friday where 
the REQUESTS were missequenced.  Even if some of the messages in the 
analysis were lost, the fixed model recoveres cleanly w/o any need for 
REFRESHing and waiting (or thrashing).

>                                 The fixed model can need an arbitrary 
(think
> RID:0 :: DTSTART set mapping in addition to the REFRESH and its 
response, 

Umm Im not sure where you got this impression.  There is NO arbitrary 
number of messages needed, its simply done in 1 REQUEST.  In addition, 
there is NO need for the REFRESH in the fixed model since if you follow 
iTIP, if the instance is NOT found on your calendar its an invitation 
otherwise its a reschedule/update. 

Only Dougs model actually needs the REFRESH because it cannot 
differentiate between an invitation to a new instance from a subsequent 
reschedule to a missed or lost earlier reschedule.  The fixed 
RECURRENCE-ID model does not fail to uniquely identify the instance in 
question in the case of missequenced or lost message so it has no reliance 
on the REFRESH mechanism to recover and function.

> and
> the Attendee CUA must retain all of that data. 

You have to maintain the current copy anyways (X- properties aside I 
think) for handling delegation correctly.  However you dont have to 
maintain the SEQUENCE:0 properties PLUS the latest SEQUENCE level 
properties if thats what you are thinking.  The properties at SEQUENCE:10 
obsolete those from SEQUENCEs 0 thru 9 and as such they are replace them. 

Maintaining a fixed RECURRENCE-ID per instnace is no great burden unless 
you code poorly since you already have to maintain the UID for each 
instance.

> a recurring event to the same DTSTART value, which doesn't really strike 
me as

Chris, go reread my analysis from Friday.  That was for a single instance 
and dealing with missequenced iTIP messages. 

It shows exactly why a fixed RECURRENCE-ID is much more beneficial than 
Dougs model.  The ability to deal with workflow fault tolerance and 
recovery is a big factor in the why a fixed RECURRENCE-ID is desirable. 
There is no confusion like Doug has over "Is this an invitation or a 
reschedule?", etc.

There has been no demonstrable benefit to Dougs model, especially where 
workflow robustness is concerned.  However if I overlooked something Im 
sure someone can point to it.

> objects to send and recieve) seem large to me too.

Where does this extra complexity come from?  Maintaining both a UID AND a 
RECURRENCE-ID per instance??  Thats no big burden that I see. 

What extra data to persist?  You do not have to save the SEQUENCE:0 data 
PLUS the current data...  If you thought that, you were mistaken.

What extra VEVENTs are you thinking must be saved or sent?  Just each 
instance is all you need and you only send whats necessary.  If you 
convolute the reading of iTIP then you need to add all kinds of extra 
checks and the like.  If you base your design on the last line of 3.7.1 
and not on the rest of iCalendar and iTIP then I cant help you except to 
suggest try taking another read of the analysis of both the fixed and 
delta models and see if you think the same.

> (nor any sense to) throw out the current scheduled instances for that 
event. 

Wrong.  If the REQUEST has a RECURRENCE-ID then it wont have 
RRULEs/RDATEs/etc since its talking about an instance.  If the REQUEST has 
a UID and RDATEs/RRULEs/etc then its defining a set of repeating 
instances.  As such the recipient MUST throw away all existing instances 
of that UID and recreate the repeat set using whats in the REQUEST 
(assuming its not "obsolete").  If they do not then they have both 
stale/incorrect instances and the new instances and this defeats the 
purpose of the REQUEST.

This is EXACTLY what Dougs "full REFRESH" is.  Its the ONLY way for Dougs 
model to get both the invitee and the Organizer back in sync.  So now you 
say that Dougs "full REFRESH" wont do what he says it will?

> If the instance was previously scheduled, it can remain scheduled.

Then Dougs "full REFRESH" wont achieve anything and the invitees calendar 
gets cluttered with 'orphaned' or 'defunct' entries now.  This is even 
worse than before...

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: Doug Royer <[email-masked]>
Date: Thu, 14 Aug 2003 10:07:19 -0600

> do nothing until it does.  

You keep ignoring the fact that you made the single instance invite
look like an instance update. Each and every time they are going
to have to do a REFRESH because they will not know which it is.

-- 

  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: [email-masked]
Date: Thu, 14 Aug 2003 12:54:19 -0400

No   you do not understand.....   ITip says we do not care... If it is not 
on your calendar it is an invitation.  uid/rid are unique.  I never have 
to do a refresh, I can accept the new data as is.
_____________________
Note: new email address

Doug Royer <[email-masked]> 
Sent by: [email-masked]
08/14/2003 12:07 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: Is there anybody out there supporting Doug's model?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Aug 2003 11:13:37 -0600

[email-masked] wrote:
> 
> No   you do not understand..... 

Then answer the question which should be easy to answer below.

> ITip says we do not care... 

No *you* say it does not matter. No such text exists in iTIP.

> If it is 
> not on your calendar it is an invitation.  uid/rid are unique.  I never 
> have to do a refresh, I can accept the new data as is.

If that is all that is needed then answer the question:

	(a) Was that object I sent a new invitation?
       or
         (b) An update to an instance with a missed original?

--

---

From: Dan Winship <[email-masked]>
Date: Thu, 14 Aug 2003 14:59:29 -0400

>          (b) An update to an instance with a missed original?

People aren't saying that the question is easy to answer, they're saying
that a conforming CUA *has no reason to care* what the answer is. The
icalendar workflow that would need to happen in case (a) would be
*exactly* the same as the icalendar workflow that would need to happen
in case (b). So why should the CUA care which case it is?

You might as well ask "What color are the organizer's eyes?" It's
exactly the same situation; the CUA is able to do its job 100% correctly
without needing to know the answer.

-- Dan

---

From: [email-masked]
Date: Thu, 14 Aug 2003 15:03:29 -0400

It does not matter and the receiver does not care WHAT the chair actually 
thinks it is.  SEE ITIP sections 3.2.2.1 and 3.2.2.2
If the receiver does not have the new REQUEST on his/her calendar than it 
is an invitation to them no mater what it was to the chair.
If the receiver does have the new REQUEST on their calendar than they 
check the seq number of the new REQUEST against what they have.
If the new REQUEST has a higher sequence number than it is a RESCHEDULE to 
the receiver no mater what it was to the CHAIR.
if the new REQUEST has a lower sequence number,  than the receiver IGNORES 
the post since it is stale - IGNORE.
if the new REQUEST has the same sequence number and the posted date is 
greater than the one they currently have than it is an UPDATE
if the new REQUEST has the same sequence number but the posted date is 
less or equal to the one on their calendar than it is sale - IGNORE
_____________________
Note: new email address

08/14/2003 01:13 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Aug 2003 13:47:13 -0600

Dan Winship wrote:
> that a conforming CUA *has no reason to care* what the answer is.

That is simply incorrect for the reasons I have posted. How long
to you wait before knowing you guessed incorrectly?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Aug 2003 13:52:42 -0600

[email-masked] wrote:
> 
> It does not matter and the receiver does not care WHAT the chair 
> actually thinks it is. 

Yes it does, else the CUA is going to incorrectly process the
data. Does it wait 1 minute before guessing, 1 hour, 1 day?
And as the new SEQUENCE obsolete the old ones, once you
have booked the object you will not have a clue when
the now ignored old SEQUENCE arrives.

At least this is going forward, at least now you guys are
acknowledging that they are in fact ambiguous.

--

---

From: [email-masked]
Date: Thu, 14 Aug 2003 16:02:24 -0400

RECEIVER  DOES NOT HAVE TO WAIT.... THE CHAIR IS SUPPOSE TO SEND A CURRENT 
SNAP SHOT OF THE DATA... YOU IMMEDIATELY ACCEPT/DECLINE/DELEGATE, ETC.
_____________________
Note: new email address

08/14/2003 03:52 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Aug 2003 14:50:09 -0600

[email-masked] wrote:
> 
> RECEIVER  DOES NOT HAVE TO WAIT.... THE CHAIR IS SUPPOSE TO SEND A 
> CURRENT SNAP SHOT OF THE DATA... YOU IMMEDIATELY 
> ACCEPT/DECLINE/DELEGATE, ETC.

You still are ether not seeing or ignoring the issue.
Because you can not tell, your CUA will NEVER know it missed the
original. Your CUA is now out of SYNC with the ORGANIZER.

--

---

From: [email-masked]
Date: Thu, 14 Aug 2003 17:28:42 -0400

No I am NOT.   The chair sent me the correct UNID/RID/SEQ.  The chair does 
not change these again unless he/she does another reschedule for that 
item.  Therefor when I respond with the same UNDI/RID/SEQ I am in sync.
_____________________
Note: new email address

08/14/2003 04:50 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Aug 2003 16:42:27 -0600

[email-masked] wrote:
> No I am NOT.  

It has been two days, your CUA sill misinterpreted the
object that was sent in e-mail to this list.

How long do you wait before sending the REFRESH?

Does anyone really believe that any CUA that got
that object and thought it was an initial invitation
has the correct data for the CU?

--