Subject: Re: RFC 2445 Proposal: ATTCOUNTER

From: [email-masked]
Date: Thu, 28 Feb 2002 13:29:55 -0500

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: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 28 Feb 2002 12:47:10 -0700

[email-masked] wrote:
> DECLINECOUNTER.

>  The AA can tell by how the ATTENDEEs CUA deals with
> the DECLINECOUNTER (remove the marker you created for a pending
> COUNTER, etc).

The marker would be in the ATTENDESS-CUA, how could the AA-CUA
remove it? It can't be in the CS or two+ vendor implementations
will not interoperate with respect to DECLINECOUNTER.