Subject: Re: iTIP updates

From: [email-masked]
Date: Mon, 27 Nov 2000 15:07:19 -0500

I can see that this is gonna take some group bandwidth again...  Im on a 
timeline before San Diego so Ill try to keep my points short and sweet 
(stop chuckling!!)

Steve replied:
>>The word CONFIRM has a pretty clear definition; the sender is confirming 
something.
>so, how does that conflict with its mission?

The act of confirming the entry is not the same as expressed in the 
original (a) and (b) cases.  See my last msg on this.

>Not bumping the sequence number is bothering me. I was going to bring this 
up in San Diego. 

ARRRRGH!  Isnt this the 15th time we've gone over reving SEQUENCE??? 
Before going down that rat hole, can you please explain _why_ the Organizer _needs_ to rev SEQUENCE when they are simply indicating to 
invitees "Yes, we are going to meet tomorrow AM"??  Doing so would 
invalidate any REPLYs that come in after that when NOTHING has changed?? 

Now, if this is an internal architecture issue for your engine thats a 
different matter than a problem in the RFC.  (Recall that MSFT was going 
to rev SEQUENCE on every notice sent out even typo changes in a SUMMARY 
and that IS OK, it just increases their message traffic.)

>>As such I would NOT see it as the logical name to use on a "reply to 
>>a REFRESH" (case (a) from above) or to send out 'non-rescheduling 
>>updates' as in case
>hmmm... "confirm" seems fine to me in this case.  You have a better verb? 

Reread my original comments again please.  If the Organzier is just fixing 
a typo in SUMMARY (ie: the (b) or "non-rescheduling update' case) then how 
is it a CONFIRMation in the sense that I confirm we are going to meet?? 
Its not the same.  I said that my disagreement is partly w/the choice of 
words for the given objective. 

>I think people wanted some command to reflect "non-substantive" changes to 
an event and everyone wants to minimize the number of commands. 

Currently this is done by using the  (UID, SEQUENCE, DTSTAMP) tuple and 
sending 'full snapshots' of the entry in question.  If, for the given UID, 
the SEQUENCE is the same as the recipients but the DTSTAMP is 'newer' then 
its a non-rescheduling update.  The _exact_ kind of update is not clear (ie: STATUS:TENTATIVE -> STATUS:CONFIRMED 
means the entry was "confirmed", new ATTENDEEs means new folks were added, 
etc.) and I think this is what you are trying to 'fix' with a new method. 
This is change in methodology and not a simple semantic change!!

If, for the given UID, the SEQUENCE is smaller then the recipients then 
its a stale update/request and is to be ignored.  If, for the given UID, 
the SEQUENCE is higher than the recipients then the message is a 
rescheduling update of some kind.  That is NOT to preclude that the real 
difference between the recipients copy and the new one is simply a typo 
change for, say, SUMMARY but any REPLYs that the recipient sends to the 
Organizer w/the older SEQUENCE value will be ignored (and possibly trigger 
a new REQUEST to be sent out).

>>Although this change would kind of special case REQUESTs as being only 
>>when rescheduling is necessary and that is what we defined SEQUENCE 
>>changes for... Argh!   I do NOT want to revisit that entire discussion 
>>again...
>I think we're going to have to open it up again. I think there are too 
many ambiguities with not bumping the sequence number as we modify the 
attendee list. 

Well Hoss, I think this should top our Agenda for San Diego then.  This 
kind of change is definitely non-trivial and a non-backwards compat. 
change for reasons that have not been clearly given yet.  In order for 
there to be some productive coverage of this I would strongly suggest you 
post to the list your motivation for such a change.

>>WRT the "reply to a REFRESH" case, I would view this as the case where 
>>the process needs to be resync'd and can be done so by sending a new 
>>REQUEST to the requesting ATTENDEE.  I am not convinced that 
>>REQUEST->REFRESH->REQUEST is not functioning and needs some fix. 
>>Perhaps someone can enlighten me.
>It works just fine. 

Well that was the (a) case for having CONFIRM added.  If the process works 
as it stands, case (a) is not a valid case for the change.

>yea.  ugh!  I like fewer methods. 

At least I can end on a point of agreement. :^)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Steve Mansour <[email-masked]>
Date: Mon, 27 Nov 2000 14:48:30 -0800

[email-masked] wrote:

> I can see that this is gonna take some group bandwidth again...  Im on
> a timeline before San Diego so Ill try to keep my points short and
> sweet (stop chuckling!!)
>
> Steve replied:
> >>The word CONFIRM has a pretty clear definition; the sender is
> confirming something.
> >Not bumping the sequence number is bothering me. I was going to bring
> this up in San Diego.
>
> Before going down that rat hole, can you please explain _why_ the
> Organizer _needs_ to rev SEQUENCE when they are simply indicating to
> different matter than a problem in the RFC.  (Recall that MSFT was
> going to rev SEQUENCE on every notice sent out even typo changes in a
> SUMMARY and that IS OK, it just increases their message traffic.)

No, I'm referring specifically to the change where we add people to or
remove them from the recipient list. If we don't bump the sequence
number, then you and I can have an event with the same UID and the same
SEQUENCE but different attendee lists. That just seems wrong.

> Reread my original comments again please.  If the Organzier is just
> fixing a typo in SUMMARY (ie: the (b) or "non-rescheduling update'
> case) then how is it a CONFIRMation in the sense that I confirm we are
> going to meet??  Its not the same.  I said that my disagreement is
> partly w/the choice of words for the given objective.

I'm not worried about the case where we're just fixing a typo in the
SUMMARY.

> >I think people wanted some command to reflect "non-substantive"
> changes to an event and everyone wants to minimize the number of
> commands.
>
> Currently this is done by using the  (UID, SEQUENCE, DTSTAMP) tuple
> and sending 'full snapshots' of the entry in question.  If, for the
> given UID, the SEQUENCE is the same as the recipients but the DTSTAMP
> is 'newer' then its a non-rescheduling update.  The _exact_ kind of
> update is not clear (ie: STATUS:TENTATIVE -> STATUS:CONFIRMED means
> the entry was "confirmed", new ATTENDEEs means new folks were added,
> etc.) and I think this is what you are trying to 'fix' with a new
> method.  This is change in methodology and not a simple semantic
> change!!

For typos, I agree. When the attendee list changes it seems like a
different deal. I don't think throwing in the DTSTAMP helps my concern
in this case. Because that value is generated at the time a message is
sent. Messages can be sent for a variety of reasons, including REFRESH.
So, the DTSTAMP time can potentially different for everyone in the
event. The UID and SEQUENCE number seem like the things to rely on for
determining if we're all talking about the same meeting.

Maybe the problem just comes from where we draw the line on  what
constitutes a substantive change. I agree with you on typos.  I'm not so
sure about a change to the attendee list.

-Steve