RE: CounterOffer issue

[Vinod Seraphin/CAM/Lotus <Vinod_Seraphin/CAM/Lotus.LOTUS@xxxxxxxxxxxxx>]

>You bring up a good point, and that is that counter offer and tasks 
>were not included in the draft.  The reasoning behind this is that it 
>is very challenging to get everyone to reach concensus on a particular 
>draft.  The larger the draft, the more contentious points there will be 
>and the longer it will take to turn the draft into a standard.    By 
>breaking the problem into smaller pieces, we can get agreement on the 
>very basic stuff (sending and responding to meeting requests), and then 
>we can move onto the less important issues (tasks, counter offer, etc) 
>while people can start shipping products based on the very basic stuff. 
> This is good for customers since they will have a useable, 
>interoperable product sooner.
>
>I'm very interested in what the group thinks about this and I believe 
>this topic is on the agenda, so we'll have a chance to talk about this 
>face-to-face on Tuesday.  If people think it should be in the draft, it 
>will be done.

I do think it is important to think about a larger set of scheduling 
functionality
up front as I suspect most scheduling applications will not find the meeting
request (invite) and simple responses (accept, decline, tentantive)
sufficient, and will wind up implementing more using X- mechanisms.  This
stuff will then not interoperate across products.  Also, this will help make
certain that the Core Object Specification we agree on can handle all
that is needed.

For example, how would your proposal (draft-ietf-calsch-sch-00.txt)
support relaying information about individual attendee status when
a prouct wishes to update invitees about the current status of all
invitees?  I believe this is covered by the STATUS property within
draft-ietf-calsch-csct-00.txt.  It seems the EXPECT property in (csct) was
mapped to several properties within sch.  Would somethine similar be
done for additional attendee properties?  If so, would this be a reasonable
mapping (for a hypothetical poker meeting)?

(csct):
ATTENDEE;EXPECT=REQUIRE;ROLE=OWNER;STATUS=CONFIRMED:John Smith 
<jsmith@host1.com>
ATTENDEE;EXPECT=REQUIRE;STATUS=TENTATIVE:Henry Cabot <hcabot@host2.com>
ATTENDEE;EXPECT=REQUEST;STATUS=DECLINED:Jane Doe <jdoe@host1.com>
ATTENDEE;EXPECT=FYI;STATUS=SENT;X-BRINGSBEER=YES:Jim Jones <jjones@host2.com>

(sch):
AttendReq:JohnSmith <jsmith@host1.com>,Henry Cabot <hcabot@host1.com>
AttendOpt:Jane Doe <jdoe@host1.com>
AttendFyi:Jim Jones <jjones@host2.com>
AttendOwner:JohnSmith <jsmith@host1.com>
AttendStatusConfirmed:John Smith <jsmith@host1.com>
AttendStatusTentative:Henry Cabot <hcabot@host1.com>
AttendStatusDeclined:Jane Doe <jdoe@host1.com>
AttendStatusSent:Jim Jones <jjones@host2.com>
X-AttendBringsBeer:Jim Jones <jjones@host2.com>

Seems to me that with the (sch) format could result in the name listed
in several different lines to implement similar functionality as specified
by the TYPE, ROLE, STATUS, RSVP, EXPECT and MEMBER property
parameters in (csct).  I prefer the (csct) approach here and am not convinced
that it greatly increases the difficulty in parsing it.  The (sch) proposal gets
worse the more additional attendee property modifiers are added.

Vinod Seraphin
vseraphin@lotus.com