Subject: RE: RECURRENCE-ID discussion

From: Satya Vempati <[email-masked]>
Date: Tue, 12 Aug 2003 16:43:09 -0700

On a related note, is there a part of the RFC that states that the
SEQUENCE number should always be incremented by 1? The RFC's talk of
incrementing, but as far as I can tell, the increments can vary.

If sequence number increments are not always 1, will the changing
RECURRENCE-ID model work?

-----Original Message-----
From: Michael Fair [mailto:[email-masked]]
Sent: Tuesday, August 12, 2003 4:02 PM
To: [email-masked]
Subject: Re: RECURRENCE-ID discussion

> Michael Fair wrote:
> > I don't know what this hangup on modification
> > versus new object is about?
>
>
> That idea does not work for all cases.

Assuming that we are still talking about Z-1 being
a recurring event and Z is an instance modify then
it does work.  It works very well.

I am so far the only one on this list who has potentially
shown a sequence of messages that _might_ cause an
inconsistency using the fixed-id model because there is
one circumstance under which the RECURRENCE-ID _might_ change.

And in fact, it happens to be the same sequence of messages
that causes the 'current-value' model to fall apart.

> Your CUA will be out of SYNC with the organizer view
> if iMIP objects that are sent as updates are interpreted
> as new objects - when received out of order via iMIP.

Why would it be out of sync?

The Z message is totally and completely a self contained
update with all information from the <Z message in regards
to that instance.

> You can pretend that out of order objects will not
> happen via iMIP all you want. It is not true.

It's good that we can agree on this.  Forever more neither
one of us has to prove that messages can arrive out of order,
it can just be accepted that they might.

Further, all of us will have to defend what our respective
models do when it receives messages out of order.

> Servers queue up outgoing email all of the time
> and for reasons of system load can send them out in an
> order that is random. Your CUA will call it a new
> item then ignore the SEQUENCE:x-1 object because
> it thinks it is older.

The fixed-id model doesn't ever need to see the SEQ:x-1
object to know that it has the latest version of the instance.

I think you believe that if X was recurrence instance modify,
and X-1 was a recurring event definition, that we would ignore
X-1 and that would be bad.

And if the fixed-id model did ignore it, you would be right,
it would be bad.

But it doesn't ignore it so you just misunderstand the model.

If we receive an instance update with UID:1/RID:1/SEQ:1 we
will put it on the caledar as a recurring event instance
with the primary key UID:1/RID:1.

If afterward we recieve a full blown recurring event
UID:1/SEQ:0 we will not ignore it because we haven't
seen a message for event UID:1/RID:NULL before.

We will process this new event message and add every instance
that we have not already seen (i.e. we will skip UID:1/RID:1
because we already have that object at a SEQ > 0).

The easiest way for you to think about this is using SQL.
An event in the iTIP model has a primary key of:
UID:  NOT NULL UNIQUE
RECURRENCE-ID: DEFAULT VALUE NULL
events primary key (UID, RECURRENCE-ID);

Note that in this definition RECURRENCE-ID could be NULL
and is NULL unless otherwise specified.

So in the iTIP model all events that do not have a
RECURRENCE-ID in them effectively have a RECURRENCE-ID
of NULL.

So when we recieve the first for message UID:1/RID:1 we look
in our calendar and don't find one.  We process it as a
new event and put that instance on the calendar using the
primary key UID:1/RID:1.

Then when we later receive a message for UID:1/RID:NULL
we look in our table and again don't find one.  We process
it as a new event and now put the entire series on our
calendar.  When we process the UID:1/RID:null series,
we don't clobber the UID:1/RID:1 we have as that would
be stupid.  UID:1/RID:1 is at SEQ:1 whereas UID:1/RID:NULL
is at SEQ:0.  As such, our SEQ:1 version of UID:1/RID:1
trumps UID:1/RID:NULL's implied SEQ:0 version of the
same event.  Same goes for DTSTAMP in case the SEQUENCE
values happen to match.

This is all very clear from reading 2.1.5.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 12 Aug 2003 17:24:59 -0700

> On a related note, is there a part of the RFC that states
> that the SEQUENCE number should always be incremented by 1?

There is nothing iTIP that says it.
And since messages can get lost there's no gaurantee that you
will see monotonic increments anyway.  So both models need
to handle that case.

But there is this from iCal (2445):

4.8.7.4 Sequence Number

   Property Name: SEQUENCE

   ...  It is monotonically incremented
   by the "Organizer's" CUA each time the "Organizer" makes a
   significant revision to the calendar component. ...

> RECURRENCE-ID model work?

Well it will be no more broken than it already is...

Not monotonically incrementing the SEQUENCE will simply
make recipient CUAs think they missed something and in
either model send a REFRESH.

Since there really wasn't any actual missed data just
a bad SEQUENCE jump the REFRESH is mostly a non-op.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 19:06:00 -0600

Satya Vempati wrote:
> SEQUENCE number should always be incremented by 1?

Yes - its in iCal where SEQUENCE is defined.

> The RFC's talk of

What an attendee sees can vary if they are or are not part
of versions of the object. If an ATTENDEE sees an update
to an instance and it is more than one behind the current
SEQUENCE number that ATTENDEE-CUA is going to have to do
a REFRESH in order to get the latest object in order to
apply the update.

The only exception is when the Bruces new model is used to invite
you to a single instance and when it is the first object you get
with that UID, then the ATTENDEE has to always do an REFRESH because they
broke the uniqueness of single instance updates and called it a
new invitation.

-- 

  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: Tue, 12 Aug 2003 19:34:33 -0700

> broke the uniqueness of single instance updates and called it a

First, we didn't break the uniqueness for a single instance.
    The instance is identified as UID:1/RID:1 (Section 2.1.5)
Second, it's not new it's been in iTIP the whole time (Section 3.2.2).
Third, we send a REFRESH because we think we might have missed
a message that involves the entire series, not because we need
it to understand what's going on with that instance.

I say we send a REFRESH because it's a nice thing to do,
not because we need it.  You could never allow the fixed-id
to send a REFRESH ever and the instance would stay totally
consistent with ORGANIZER's with respect to that instance.

I use the fact that the SEQUENCE for an update has jumped
more than 1 to indicate that we missed some message that
_might_ have had to do with the entire series so the
conservative and safe thing to do is to send a REFRESH.

As far as the instance for which we received the message
we are fully in sync and totally up to date.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Aug 2003 10:02:54 -0600

> First, we didn't break the uniqueness for a single instance.

Then why did you incorrectly guess if the sample I sent was
an update or a new invite to a single instance?

The correct answer = you can not tell as it breaks the uniqueness
for a single instance.

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 11:59:19 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> The correct answer = you can not tell as it breaks the uniqueness

It doesn't break the uniqueness for a single instance, prove to
me how there is a conflicting copy of UID:1/RID:1 somewhere in
the world different than the one I sent?

Again you have not yet proven in any way shape or form why I
need to know if what you sent was an update.  Besides, in another
post I even said we can call it an update if it makes you feel
better.  The CUA still treats it as the most recent version of
UID:1/RID:1 that it has seen.

And you still have yet to prove what's on the ORGANIZER's calendar
that's not on the ATTENDEE's calendar that makes your claim of
out of syncness justified.

The CUA ended up with the currect objects on its calendar and at
their correct versions.

If you'd like to debate whether a reference to UID:1/RID:1 can
ever be confused with a reference to UID:1/RID:NULL because they
share the same SEQUENCE track then let's talk about that.  That's
actually a productive line of conversation.  We have repeatedly
said that the SEQUENCE's for instances are independently tracked
because both section 2.1.5 and 3.7.1 say that they are.  Because
they are indepentently tracked when you look up the primary key
as per step 1 in 2.1.5 you must consider both UID and RID before
you move on to step two.

You either can't comprehend what we are saying and are therefore
justifying your assertions on a baseless claim that they share
the same SEQUENCE track, ignoring it because it makes your position
baseless act of crying wolf and you are too embarassed to admit it,
or just a bad conversationalist who can't talk about what's important
and instead tries to win the argument by repitition instead of proof
and dismantlement of the models in concert with quotations from the
text in question.  Please start either disagreeing with the
fundamental premises upon which our arguments are based, such as
independent versioning and UID/RID primary keys by quoting iTIP
sections which prrof that's not the case or providing examples
under which the model, exactly as presented, breaks iTIP mandates,
or at least start properly citing how the model works.

This back and forth of he said she said where you constantly
misrepresent the model is just plain tiresome and makes me
think you are just plain ignorant and unresponsive to constructive
criticism and unable to participate in a productive conversation.

I, on at least one occasion, have admitted where I misunderstood
the model you were presenting.  I didn't realize that when you
invite an ATTENDEE to a recurring instance you branch and fragment
the object with the UID in question.  Which I directly showed is
a violation of the UID uniqueness mandate because not all recipients
of the same UID share the same view of the object (with the exception
of potential version differences due to unseen messages).

You advocate that we violate the uniqueness factor because it
seemingly allows us to send fewer messages.  I then countered
you with both iTIP that says you can't do that, and an implentation
reality that if the CU's start passing those objects around to
each other they will get confused.  You have not defended your
model yet, you have not shown any iTIP that says you can/should
or must do that, and most importantly you have not shown why this
is not a problem for your model.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Aug 2003 14:38:54 -0600

Michael Fair wrote:
>>>>with that UID, then the ATTENDEE has to always do an REFRESH because
> 
> they
> 

--

---

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

> an update or a new invite to a single instance?

Why does it matter?

Show me why the CUA's calendar ends up inconsistent with the
ORGANIZER's and I'll discuss this with you further.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Aug 2003 20:49:04 -0600

>>an update or a new invite to a single instance?

Your assertion is above = "It doesn't break the uniqueness for a single 
instance...". Yet you were unable to tell the difference - both
can not be true.

--

---

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

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> instance...". Yet you were unable to tell the difference - both

I don't understand this assessment.

If you receive an event with UID: blahblahwoofwoof (whether
that be UID: blahblah/RID:woofwoof or UID:blahblahwoofwoof)
as long as there is only one blahblahwoofwoof in existence
and it is unique.

Why does it matter if the first time you saw blahblahwoofwoof
was an update or its orginal creation?

It is still blahblahwoofwoof, there is only one blahblahwoofwoof
and you end up with the latest copy of it on your calendar.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Aug 2003 22:29:44 -0600

> I don't understand this assessment.

I sent a BEGIN/END VCALENDAR object and asked you what it was.
Your guessed incorrectly. Why? Because you could NOT tell
if it was a NEW single instance invite OR an single instance
modification. Which is why I am still saying you are breaking
the iTIP flow if you invite NEW attendees that way.

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 22:44:50 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> the iTIP flow if you invite NEW attendees that way.

But you're missing the point.

The point isn't to make all users of the internet in following
some pedantic excercise of what really happened.  If that was
the case then every CUA would always have to get every message.
That way you would know that first it was this, and then it was
that, and then it turned here, and then it went there, etc.

The point is that you end up with the same object the ORGANIZER
has and you stay in sync with the same object the organizer has
sent in the most efficient and fast way possible.

That is what happens.
That is what I care about.
That is the whole point of being able to miss messages to begin with.
Whether it was an update and I treated it as a new invite, or it was
an actual invite is irrelevant.

The _only_ thing relevant is whether or not the CU ends up with
the right information on their calendar.

This is an engineering task force working group charged with what
is essentially is an exercise in distributed message passing using
an unreliable communication channel where ensuring that the most
recent copy of an object that has reached its intended destination
is processable and accurately sticks in their calendar is the most
important quality of the mechanism used.

Again, until you can say something about how the end result of what
actually ends up on the recipient's calendar is faulty there is no
use in continuing this discussion.

You sent a bunch of messages, I picked the right one and stuck it
on my calendar and sent you a REPLY giving you my attendence info.
That's what you care about, that's what I care about, that's what
the WG cares about, and most importantly that's what the CU cares
about.  Trying to design a protocol that unnecesarily aatempts to
clearly identify "what happened when" is pointless when the goal
is to end up at the most recent version and no additonal useful
information exists in prior versions.

I always am able to process all messages I receive, I always stick
the right information on my calendar, and my calendar is never
inconsistent with respect to the ORGANIZER's for all information
received.  This same is not true of the 'current-value' model and
until you can say why the information on the calendar is invalid,
why it violates iTIP, or why the 'current-value' holds up to the
same degree this conversation is over as there is no useful or
progressive converstaion being made.

You haven't done this yet, and in the one case where you did
make an attempt, I directly countered with a more important
and prior sequencing text from the exact same section which
trumped your assertion.  Face it Doug, the model is sound and
very defensible within the context of the RFC's save the one
line in iTIP that is error as it is contrary to many other
references to stated goals and intents from other sections
of the RFCs.

-- Michael --

---

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

> But you're missing the point.

So I was right, your not talking iTIP, your talking what you want.

--

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 14 Aug 2003 12:09:58 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> So I was right, your not talking iTIP, your talking what you want.

I am talking iTIP as iTIP is a protocol for distributing
calendar information.

You have yet to show where in iTIP it says that a CUA
must be able to distinguish between a new invite and
an update.

Let's take the case of a singleton.
If you get invited to X and the first object you see is X+1,
you treat it as a new invite - you can't distinguish there,
but you get the right thing on your calendar and you send an
appropriate REPLY.

Let's take the case of an entire recurring series.
If you get invited to X and the first object you see is X+1, you
treat it as a new invite - you can't distinguish there either,
but you get the right thing on your calendar and you send an
appropriate REPLY.

You Doug can't distinguish between a new invite and an update
on either of those messages yet you don't seem to assert that
anything is broken with them and they are iTIP.

Why should a recurring instance be any different?

The bottom line is that what iTIP concerns itself with
is that you get the right thing on your calendar and you
send an appropriate REPLY.  This is what happens and you
have yet to prove otherwise.

-- Michael --

---

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

Michael Fair wrote:
>>>>>>Your assertion is above = "It doesn't break the uniqueness for a
> 
> single
> 

So when *you* said ""It doesn't break the uniqueness for a..." (above)
But now you are saying, it does but you do not care?

So it looks to me as if you have not thought out the problem.

--

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 14 Aug 2003 16:26:49 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> So it looks to me as if you have not thought out the problem.

Actually I'm not saying that at all.

Let's recap shall we:
Michael: It doesn't break the uniqueness because there is only
         master _object_ in the universe and all replicas contain
         information about that master _object_.

Doug: But you couldn't tell if the _message_ was an invite or
      an update.

Michael: I don't care what the _message_ was - the point is to
         get the proper unique _object_ onto the calendar.
         You're missing the point about the _object and getting
         hung about the _message_.

Doug: So I was right you're not talking iTIP.

Michael: I am talking iTIP as iTIP is about passing around
         iCal objects and making sure the iCal objects on
         everybody's calendar remain up to date.

Doug: So originally you said the _message_ was unique and now
      you're saying it isn't.  Sounds like you haven't thought
      it through.

Michael: The single instance in question is an _object_.  It is
         passed around in a _message_ for purposes of getting
         the most up to date version of itself on to calendars.
         Section 2.1.5 describes how to treat the _message_
         given whether or not the _object_ already exists on
         the recipient's calendar.  A _message_ doesn't have to
         be uniquely identifiable.  An _object_ must be globally
         uniquely identifiable.  If you can't understand this,
         nor can you demonstrate how in any way shape or form
         how any of the calendar's end up with the wrong
         _object_ on them then I can't help you anymore.  I
         do not have the skills to put it any more plainly and
         you lack the comprehension and/or discussion skills
         of an 8th grader.

-- Michael --

---

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

>          information about that master _object_.

If you can not tell the difference, it is ambiguous.
Both can not be true. Ether you knew what it was by looking
at it, or you can not.

am.big.u.ous \am-'big-y*-w*s\ aj [L ambiguus, fr. ambigere to wander about,
    fr. ambi- + age]re to drive - more at AGENT 1: doubtful or uncertain esp.
    from obscurity or indistinctness; also : INEXPLICABLE 2: capable of being
    understood in two or more possible senses : EQUIVOCAL - am.big.u.ous.ly av

You could not tell - it is ambiguous.

--