Subject: Re: RFC 2445 Proposal: ATTCOUNTER

From: [email-masked]
Date: Thu, 28 Feb 2002 09:57:41 -0500

Doug clarified on 02/27/2002 05:12:05 PM:
>                            I said what if YOU AND your AA BOTH
> send a COUNTER; Now BOTH DECLINE-COUNERs go the the same ATTCOUNTER
> value AND they both look the same. 

Not quite; unless sent at the exact same time they would at least have 
different DTSTAMPs and likely have different COMMENTs too.  If you were 
countering for different instances too then the RECURRENCE-ID would also 
differentiate them.  Had I accepted _any_ COUNTER then you'd be seeing a 
new REQUEST come along wouldnt you??  The DECLINECOUNTER is mainly used so 
that an ATTENDEE who counter proposes knows that the Organizer has 
received and rejected the COUNTER; its not the means to doing 
renegotiation of the new date/time/info.

Besides its no different than if I receive 2 COUNTERs from you alone and I 
DECLINECOUNTER them both.  Or I could have recieved duplicate COUNTERs 
from you because some spooler in the middle hiccupd and sent 2 of them. Or 
on the return path a mailer hiccupd and you got 2 copys of the 1 
DECINECOUNTER I sent.  Or you and your AA COUNTERed with different 
dates/times and I reject them both.  Or ... 

The point is that it doesnt matter if you get mulitple DECINECOUNTERs I am 
still declining the counter proposal.  There is no great magic to a 
DECLINECOUNTER that requires tons of "what ifs...".  They are all simply 
treated as "The Organzier had rejected your (or your proxys) counter 
proposal". 

>                        So I concluded that the ATTCOUNTER
> would have to also be in DECLINE-COUNTER as well. And then
> without something to differentiate them, how does your CUA
> know why it got two identical DECLINE-COUNTER objects?

How does it know your AA sent a COUNTER and that you sent a COUNTER?  How 
does it distinguish between the 2 COUNTERs you sent (you changed your mind 
after the 1st one)?  It doesnt really matter since the COUNTER(s) was not 
accepted. 

> I was proposing that the COUNTER ATTCOUNER value be copied
> entirely to the DECLINE-COUNTER so the origin of the original
> COUNTER can be identified.

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. 

Im just trying to fix an oversight in our original spec, not add new 
functionality.  If you want to add new functionality, draft up some text 
and propose it as an alternative to mine.

> If the COUNTERs orginated from the same CAP address (one from
> the OWNER and another from the AA), ...

Same response as above...

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 10:48:26 -0700

> Besides its no different than if I receive 2 COUNTERs from you alone
> and I DECLINECOUNTER them both.  Or I could have recieved duplicate
> COUNTERs from you because some spooler in the middle hiccupd and sent
> 2 of them. Or on the return path a mailer hiccupd and you got 2 copys
> of the 1 DECINECOUNTER I sent.  Or you and your AA COUNTERed with
> different dates/times and I reject them both.  Or ...

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.

If CU-1 processes both, then will not CU-2 just keep wondering what
happened? The next time CUA-1 did a sync, it would process
both. Then when CUA-2 did a sync, it would appear that nothing
at all changed. I would think that CU-2 might think that the
ORGANIZER never responded.

> How does it know your AA sent a COUNTER and that you sent a COUNTER?

By looking at the SENT-BY (or its absence) in ATTCOUNTER.

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

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

> 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

> functionality.  If you want to add new functionality, draft up some
> text and propose it as an alternative to mine.

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.
Without replicating the ATTCOUNTER into the DECLINECOUNTER, it
guarantees the ATTENDEE's AA, or the ATTENDEE will never
know that it was rejected.

And I might send a proposal soon, unless someone has pointed
out that I missed something.