Subject: Re: iTIP updates

From: [email-masked]
Date: Wed, 15 Nov 2000 12:38:06 -0500

You should add the iTIP / DUE / Repeat issue I raised back on ~5-Sep-00 
titled "iTIP & Repeat/DUE/Duration restrictions".  The change was already 
proposed so its just a matter of adding to the list (unless you are only 
listing 'new' issues).

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: [email-masked]
Date: Thu, 30 Nov 2000 17:21:52 -0500

I got a BIG backlog of msgs from the past 2 days so if this is a rehash of 
others response then mea culpa...

Steve kindly responded:
>>I fail to see _why_ if I add a new ATTENDEE that I must rev SEQUENCE and 
thus invalidate the 
>>responses from _ALL_ other ATTENDEEs?  If I have a standing weekly team 
meeting that I need 
>>to add a new ATTENDEE to, I have to invalidate everyone elses 
acceptances/declines??  Not 
>>because of any time or (possibly) LOCATION change but just for a new 
ATTENDEE.  Thats not 
>>cool.
>It just seems wrong to me that you and I can have an event with the same 
UID / RID / SEQ  and 
>your version has one list of attendees and my list has a different list. 

Ok, besides the obvious "Its gonna happen because email is not 100%" kind 
of answer Ill reiterate my original response in a different way to be 
clearer.  I (still) see no compelling reason to rev SEQUENCE for this (and 
restart the workflow process) when sending out a message with a newer 
DTSTAMP will achieve the desired results.  Simply put, if Pat and I have 
an ongoing weekly meeting we both have accepted and I want to add Steve to 
it; why do I have to invalidate Pats current status and make her reACCEPT 
all the affected entries when I can simply send her a message w/the same 
UID / RID / SEQUENCE and a newer DTSTAMP (ie the date/time I added 
Steve)??  That way Pat gets told of the new ATTENDEE and we do not have to 
redo the entire workflow process...  This is the exact same mechanism that 
we use for typo updates or 'non-rescheduling' updates.  If it works in 
those cases, why wont it work in the "adding a new ATTENDEE" case?? 

Im REALLY against big changs like new methods that have new SEQUENCE 
reving rules (and as such are not 2.0 compatible!!) when I think what 
Steve wants can already be done today...

Bruce

---

From: [email-masked]
Date: Thu, 30 Nov 2000 17:53:44 -0500

Appologies to those that may have gotten my last msg early.  My client 
crashed and burned w/a Virtual Memory fault (Thanks NT!).

Steve also replied:
>Yes, this works. That's why I did not insert my preference in the iTIP 
text :-)  It just seems weird to have different attendee lists for events 
with the same UID / RID / SEQ. 

Well, 'wierd' or not its gonna happen that different (UID, SEQUENCE, 
RECURRENCE-ID, DTSTAMP) sets will have different data in them.  So Im back 
to asking about the general case for CONFIRM.  Do we really need it?  Yes, 
I think that having to derive the Organizers meaning from doing a 'diff' 
is painful (Im coding an engine so I share the pain!) and yes I would like 
some easier way to convey more 'logical' intent like "Im confirming that 
we will meet" or "Here is your concert ticket confirmation" but Im not 
convinced that CONFIRM does the job...

Hmm, perhaps we could add a new property called INTENT and use it only 
when the SEQUENCE is NOT being rev'd on a REQUEST...

Bruce