Subject: Re: iTIP updates

From: [email-masked]
Date: Mon, 27 Nov 2000 12:04:03 -0500

In going over the proposals from Steve again (thanks to a long weekend to 
decompress a bit) Im not so sure I like this one as it is described:

Problem: Currently, the REQUEST method is used for invite, reschedule, 
update, confirm, reply to refresh. A reschedule and/or update are 
semantically different than a confirm or a reply to REFRESH. 

Proposal: Add a new method: CONFIRM. It would be used to (a) reply to a 
REFRESH and (b) notify participants of any changes to ATTENDEE or 
ORGANIZER. All other "reschedule" or "update" changes MUST use REQUEST 
method.

The rub for me is partly in the new method name (CONFIRM) and in its use. 
The word CONFIRM has a pretty clear definition; the sender is confirming 
something.  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 (b).  I would expect it to be used 
as a special kind of notification to indicate that the Organizer is 
"confirming the entry" (ie: Pat confirms that the WG is meeting on Wed in 
San Diego).

I also do not see why "All other [snip] "update" changes MUST use REQUEST" 
when CONFIRM exists (under a different name please) for that kind of need. 
 Perhaps what we need some kind of "non-rescheduling update" method that 
we can send 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... 

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.

 (Back when we first started this METHOD definition process I had a list 
of about 18-20 distinct values to use and they all got boiled down into 
the handfull we have now with meaning 'inferred from the content'.  The 
pendulum seems to be swinging back now.) 

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] (Steve Mansour)
Date: Mon, 27 Nov 2000 09:26:10 -0800

[email-masked] wrote:

> In going over the proposals from Steve again (thanks to a long weekend
> to decompress a bit) Im not so sure I like this one as it is
> described:
>
> Proposal: Add a new method: CONFIRM. It would be used to (a) reply to
> a REFRESH and (b) notify participants of any changes to ATTENDEE or
> The rub for me is partly in the new method name (CONFIRM) and in its
> use.  The word CONFIRM has a pretty clear definition; the sender is
> confirming something.

so, how does that conflict with its mission?  Is it bothering you that
the attendees can change and we're calling it a CONFIRM?  Or that we
don't bump the sequence number.

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

> 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?

> (b).  I would expect it to be used as a special kind of notification
> to indicate that the Organizer is "confirming the entry" (ie: Pat
> confirms that the WG is meeting on Wed in San Diego).

> I also do not see why "All other [snip] "update" changes MUST use
> REQUEST" when CONFIRM exists (under a different name please) for that
> kind of need.  Perhaps what we need some kind of "non-rescheduling
> update" method that we can send out.

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

> 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.

> 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.

I think people just wanted more insight as to the nature of the message.
With REQUEST it could be rescheduled to a different time, etc.  It could
easily be argued that even a "CONFIRM" can result in the same sort of
rescheduling -- for example if the attendee is a few revisions behind
when they send the REFRESH -- the event start date/time could easily
have been changed in one of the revisions they missed. So, there are
certainly circumstances where CONFIRM must be handled like REFRESH.

>  (Back when we first started this METHOD definition process I had a
> list of about 18-20 distinct values to use and they all got boiled
> down into the handfull we have now with meaning 'inferred from the
> content'.  The pendulum seems to be swinging back now.)

yea.  ugh!  I like fewer methods.

-Steve

---

From: John Stracke <[email-masked]>
Date: Mon, 27 Nov 2000 12:58:52 -0500

Steve Mansour wrote:

>> 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.

[...]

> yea.  ugh!  I like fewer methods.

So maybe all we need to do is widen the cases where we increase
the sequence number, but not add new methods?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Excuse me. I've been dead lately & my brain  |
[email-masked]|isn't working too well. --Miles Vorkosigan   |
\==============================================================/

---

From: Steve Mansour <[email-masked]>
Date: Mon, 27 Nov 2000 11:06:41 -0800

> the sequence number, but not add new methods?

could those who pushed for the "CONFIRM" method please chime in here and
help us understand the need better.  Here is what I recall:

   * people felt the REQUEST method was inappropriate for an organizer
     sending out an updated version of an event with people's attendee
     status updated
   * people felt that REQUEST was not a good verb to use as a response
     to a REFRESH

I'm probably not representing everything here.

-Steve