Subject: Re: Attendee clarification

From: [email-masked]
Date: Fri, 11 May 2001 18:30:04 -0400

John replied on 05/11/2001 06:00:43 PM:
> I think that's what I meant.  My position is just that those
> vendors are not doing scheduling, and a scheduling protocol does
> not need to accommodate them.

Thats true for RFC 2446/2447 & CAP but not for RFC 2445.  iCalendar is NOT 
a scheduling protocol.  Its a canonical data format for representing 
calendar entries/tasks/journals/busytime/timezones/etc.  iTIP is the 
scheduling protocol.  As such, it may not belong in iTIP but it certainly 
does belong in iCalendar (it conveys the ability of the system or the 
desire of the Organizer or at least it was supposed to).

> My point below was that there is no real difference between a
> typo update and any other update.  The Organizer may guess that
> something is a trivial change, but they have no way of knowing
> whether I agree--and, if I don't, then sending RSVP=FALSE is a
> mistake, because it means I SHOULD NOT respond, even though my
> response is different now.

We already define 2 'classes' of update: Those that trigger 
rescheduling/renegotion automatically and those that do not.  There are 
most defitely differences between them.

Your response about "SHOULD NOT" is not as strong as it should be.  The 
originally desired (and I think still desired) text was "MUST NOT". 

As for cases where FALSE is desireable: I can see building a kind of 
'private calendar list' mechanism on it where events (et al) are REQUESTed 
from a central/coordinating Organizer but no response is desired.  This 
would allow for ATTENDEEs to see who else may be involved and interact 
with them in some way (ie: "Bob & Paul & I are all invited to the BostonPM 
Reefknot presentation so maybe I can arrange to meet them for eats before 
hand!").  PUBLISH prohibits ATTENDEEs so using PUBLISH would never work to 
build this.  (I told you guys back then that we should have kept ATTENDEEs 
in PUBLISHs for stuff like this!).

Ok, I really am going home 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: John Stracke <[email-masked]>
Date: Mon, 14 May 2001 14:03:38 -0400

[email-masked] wrote:

> Thats true for RFC 2446/2447 & CAP but not for RFC 2445.
> iCalendar is NOT a scheduling protocol.  Its a canonical data
> format for representing calendar
> entries/tasks/journals/busytime/timezones/etc.

Then why does it define RSVP at all? RSVP is clearly for use in
scheduling.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"And bring the search warrant." "You mean the|
[email-masked]|sledgehammer, sir?" "Yes."                   |
\==============================================================/

---

From: [email-masked] (Steve Mansour)
Date: Mon, 14 May 2001 20:07:27 -0700

> Then why does it define RSVP at all? RSVP is clearly for use in

The model we have been working with is that iCalendar defines a common
schema, but that the protocols define usage semantics. So, in this case,
ITIP needs to define what RSVP means in the case of scheduling REQUEST
operations.

-Steve