Re: RFC 2445 Proposal: ATTCOUNTER

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug answered on 02/28/2002 12:48:26 PM:

> As I am working mostly in creating a CS and not a CUA, my *thoughts*
> were that a CUA would have to remember that it sent a COUNTER so
> that it could inform the CU when the DECLINECOUNTER or new object
> arrived. Some kind of 'this is pending' stack in the CUA and
> out of scope for the CAP protocol.

Also you have the dilemma if _you_ send 2+ COUNTERs.  Just how do you determine which COUNTER matches the DECLINECOUNTER I send back?  I may not have gotten one of them or I may have accepted/rejected it but the response got lost in transit...  In any case, there is insufficient info in the DECLINECOUNTER to match it to > 1 COUNTER as we've defined it so far.

> >  How does it distinguish between the 2 COUNTERs you sent (you changed
> > your mind after the 1st one)?
> 
> As you pointed out in another email: COMMENT.

Dont rely on it though!  Its a "0 or 1".  Even then I could send back "Sorry, cant do it then." for all declines and its not that useful...  You still dont know exactly WHICH COUNTER I am declining.

> > It doesnt really matter since the COUNTER(s) was not accepted.
> 
> The 1st CU will know that, the 2nd+ AA-CU will never know that.
> To the 2nd+ AA-CU, it will appear that the ORGANIZER never
> responded.

This is all future navel gazing and there are current limitations that make doing lots of these desirable but yet unspec'd features quite hard.  Im simply proposing a fix for a problem we all agreed on back in Aug-2000. 

> > That still wont match it up to any particular COUNTER unless you only
> > allow 1 COUNTER per cal-address.  We've never had any such restriction
> > and I dont see a need to add one.
> 
> Not true:
> 
>    ATTCOUNTER:cu-1
> 
> vs.
> 
>    ATTCOUNTER:SENT-BY-cu-1-aa:cu-1

For the case of you (and each AA) can only send 1 COUNTER then this would be valid.  However, is that a reasonable/valid restriction?  I think not.  For example, I COUNTER with a new date/time and later on I find I need to suggest another new time so I send a 2nd COUNTER w/a working time.  Now, how do you determine which COUTNER my DECLINECOUNTER with "ATTCOUNTER:cu-1" matches?

> I think I am pointing out that it just moves the problem from the
> COUNTER to the DECLINECOUNTER. It is not exactly the same problem.

No its not.  The only problem we had was that an Organizer has no way to tell what ATTENDEE is COUNTERing.  You're now saying that we need some way for the COUTNERing ATTENDEE to thread up DECLINECOUNTER(s).  Since we have REQUEST (if they accept it) or DECLINECOUNTER (if they reject it) then is there a pressing need to identify which COUNTER??  Since even if we adopt the ATTCOUNTER on DECLINECOUNTER, it still wont resolve the need I say leave it off.

> Without replicating the ATTCOUNTER into the DECLINECOUNTER, it
> guarantees the ATTENDEE's AA, or the ATTENDEE will never
> know that it was rejected.

Not correct.  The ATTENDEE would know because they always get the DECLINECOUNTER.  The AA can tell by how the ATTENDEEs CUA deals with the DECLINECOUNTER (remove the marker you created for a pending COUNTER, etc).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...