Subject: Re: COUNTER - and who sent it.

From: [email-masked]
Date: Tue, 22 Oct 2002 10:31:15 -0400

Doug wrote:
>The issue is that there would be no way to know who sent
>the COUNTER method once stored in the CS so that a
>possible DECLINE-COUNTER could be sent at a later time.

Perhaps Im just too relaxed after a well earned vacation so Ill ask for 
some clarification.  Why isn't the SENT-BY property parameter of the 
ATTENDEE sufficient enough to detect this?  After all its used by someone 
else (ie: the AA) to ACCEPT on my behalf so why isnt it good enough for a 
COUNTER??  Unless the CS is removing propeties and property parameters 
this info should still be there once the COUNTER is deposited into the 
calendar, yes?  I must be missing something here...

Besides, the workflow should be thru the relevant ATTENDEE and NOT thru 
any SENT-BY address.  Otherwise I could get into a case where both I and 
my AA COUNTER with different info and the Chair starts to do workflow to 
both addresses when it should only be dealing with mine.

Back to my 1500+ msg backlog while I await enlightenment...  (Was this so 
that I could see which AA COUNTERed for me??  More caffine, less spam....)

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: Tue, 22 Oct 2002 15:00:52 -0600

[email-masked] wrote:
> ATTENDEE sufficient enough to detect this?  After all its used by 
> someone else (ie: the AA) to ACCEPT on my behalf so why isnt it good 
> enough for a COUNTER??  Unless the CS is removing propeties and property 
> parameters this info should still be there once the COUNTER is deposited 
> into the calendar, yes?  I must be missing something here...

(1) We had this debate in 2000 and this group agreed that SENT-BY
     should not be used - I posted Franks summary a week or two ago.
     It and what led up to ATT-COUNTER is in the archives.

(2) The 'SENT-BY' could be from the original REQUEST and that
     would override the who sent this 'COUNTER' to me.

(3) 'SENT-BY' is limited to a 'mailto' url, ATT-COUNTER is not.

(4) The COUNTER object could be a COUNTER to an updated REQUEST
     and might contain:

		METHOD:COUNTER
		...

		ATTENDEE:...SENT-BY="MAILTO:[email-masked]"
                  ;PARTSTAT=accepted:MAILTO:[email-masked]
		ATTENDEE:...SENT-BY="MAILTO:[email-masked]"
                  ;PARTSTAT=accepted:MAILTO:[email-masked]

		...

    So who sent the COUNTER?
    Who do you send any DECLINECOUNTER to?

> both addresses when it should only be dealing with mine.

Where as ATT-COUNTER is defined as who you send the accept or decline
counter back to, which would be the e-mail address from an iMIP message
and could also be a CAP URL.

> Back to my 1500+ msg backlog while I await enlightenment...  (Was this 
> so that I could see which AA COUNTERed for me??  More caffine, less 
> spam....)

It was so you knew who to send a DECLINECOUNTER to.

---

From: [email-masked]
Date: Wed, 23 Oct 2002 16:57:12 -0400

>      It and what led up to ATT-COUNTER is in the archives.

I didnt see any traffic since ~9/27 and Im still digging out from my 2 
week haitus and resulting email flood.  I didnt see ATT-COUNTER in my 
search since it was referred to then as ATTCOUNTER w/o a hyphen.

My main question was where did the proposal come from since I didnt see 
traffic on it (at least not for the past 2 years ;^) ).  Im finally 
getting back into work mode and the lights are coming back on...

>      would override the who sent this 'COUNTER' to me.

<DIGRESSION>
Please dont tell me you think that I should round trip the SENT-BY on my 
next REQUEST or DECLINE-COUNTER message.  That wasnt the expectation for 
the use of SENT-BY when we created it.  Its main use/intent is for 
detecting when someone responds on another users behalf (ie: the AA).  I 
dont think anyone expects it to be 'round tripped' (although its not 
strictly illegal).  See Franks note from the 08/29/2000 02:54:13 PM AST 
under the heading "iTIP: Who sent that message?" as refresher...
</DIGRESSION>

> (3) 'SENT-BY' is limited to a 'mailto' url, ATT-COUNTER is not.

Didnt see that much details in the posting I replied to or in Franks note 
from 08/29/2000 11:33:12 AM AST that I just found.  Thats fine by me.

>     Who do you send any DECLINECOUNTER to?

You are assuming that SENT-BYs are preserved and round tripped ad-nauseum. 
 I dont belive this to be true.  They are only really useful between the 
sending CUA (their proxy actually) and the Organizer.  They are not really 
that useful to any other entity in the process.  (Do you _really_ need to 
know or care if I or my AA accepted as long as my PARTSTAT=ACCEPTED??)

> and could also be a CAP URL.

Something unclear from your posting: what are the restrictions on the new 
property?  Franks proposal was for a new property but it had no clear 
definition (nor have I found one so far).  Steve had suggested:

Proposal 2: Add a new parameter to the ATTENDEE
property:  ATTCOUNTER.  It can only be specified (a)
when the component method is COUNTER and (b) for the
one Attendee who issued the COUNTER.

which all of us at the time liked.  It made it very clear when ATTCOUNTER 
(ack ATT-COUNTER) could be used. 

One thing that noone has codified yet is "Does the ATT-COUNTER property 
value have to match a currently existing ATTENDEE value?"  That is, does 
the ATT-COUNTER have to come from an ATTENDEE that the Organizer thinks is 
involved or can it come from just anyone?  Since I could be COUNTERing 
that I should NOT be at an event its possible that the ATT-COUNTER does 
not match any ATTENDEE property I send back in my COUNTER but it SHOULD 
(MUST?) match my ATTENDEE property that the Organzier has on their copy of 
the event.

Also, I assume that we are allowing a SENT-BY property parameter to be on 
ATT-COUTNER since its possible my AA is doing the COUNTERing.  Do you 
agree?

> It was so you knew who to send a DECLINECOUNTER to.

Ya know, a simple "Go check your infamous FT archives for 'ATTCOUNTER' 
would have probably sufficed...". :^)

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 23 Oct 2002 15:33:20 -0600

> search since it was referred to then as ATTCOUNTER w/o a hyphen.

The debate was in 2000.

> You are assuming that SENT-BYs are preserved and round tripped 
> ad-nauseum.  I dont belive this to be true.  They are only really useful 
> between the sending CUA (their proxy actually) and the Organizer.  They 
> are not really that useful to any other entity in the process.  (Do you 
> _really_ need to know or care if I or my AA accepted as long as my 
> PARTSTAT=ACCEPTED??)

Do you think that it is invalid for the ORGANIZER to get a COUNTER
and have to keep both the SENT-BY values for all the ATTENDEEs
and to know who sent the COUNTER? If no - then you are agreeing
that SENT-BY is not sufficient.

If it is valid to keep them (and I think it is), then SENT-BY
can not work to remember who sent the COUNTER when the ORGANIZER
might have several SENT-BY values already in the object.

> the ATT-COUNTER have to come from an ATTENDEE that the Organizer thinks 
> is involved or can it come from just anyone?  Since I could be 
> COUNTERing that I should NOT be at an event its possible that the 
> ATT-COUNTER does not match any ATTENDEE property I send back in my 
> COUNTER but it SHOULD (MUST?) match my ATTENDEE property that the 
> Organzier has on their copy of the event.

There is a entire "ATT-COUNTER" section in -09 (7.2), it seems clear
to me that it comes from the cal-address that sent the COUNTER.
Did you miss that section? Or are you saying that is not what
you get when you read that section?

> Also, I assume that we are allowing a SENT-BY property parameter to be 
> on ATT-COUTNER since its possible my AA is doing the COUNTERing.  Do you 
> agree?

Yes.

---

From: [email-masked]
Date: Mon, 28 Oct 2002 15:36:39 -0500

> > search since it was referred to then as ATTCOUNTER w/o a hyphen.

Yep and at that time we all used ATTCOUNTER (sans hyphen) so when I 
searched for your ATT-COUNTER (with hyphen) I didnt see it so I failed to 
find the discussion the first time around.  Thats why I failed to find it 
when I looked so hence my original query when it was covered...  (We agree 
that we need it, I just failed to see any recent discussion of it or the 
summary you posted a couple weeks ago so I chimed in.)

> that SENT-BY is not sufficient.

Ya missed my point.  We never intended/expected that SENT-BY would be 
round tripped or forwarded on to others in the workflow process.  (Go 
search the related archive thread to see the same discussion then...). 

My point is simply this: Is there any real value in Andrea seeing that my 
AA sent some message to You on my behalf (assuming you are the Organizer)? 
 I say no.  What info can he safely derive from it that is of any real use 
to _him_.  I fully grok why the Organizer would want that info but Im 
saying its of minimal use to other ATTENDEEs at best and was not intended 
to be preserved ad naseum in all workflow messages.

<DIGRESSION>
You used SENT-BY on an ATTENDEE that had the same value as that ATTENDEE 
property.  Thats not the use for SENT-BY.  SENT-BY is the CU whose acting 
on behalf of that ATTENDEE.  You are NOT acting as your proxy, you are 
you.

Also, I strongly disagree w/the COUNTERing CU parroting a PARTSTAT 
property parameter on behalf  of a different CU.  Just because you can 
COUNTER does not mean you have the power to take actions on part of any 
other CU.  Otherwise I could use a COUNTER to a meeting and say that you 
PARTSTAT=ACCEPTED when in fact you've never even seen the request (or 
you've already DECLINED).  Good/safe thing to do??...  The same concern 
goes for other property parameters too...
</DIGRESSION>

> might have several SENT-BY values already in the object.

To restate/rephrase/clarify again: The Organizer can/should keep that info 
around for its own use but they should NOT be sending it along in workflow 
messages that get sent to other folks.

> you get when you read that section?

Argh! Ive been using the apparently abandoned FTP url you posted a while 
back.  (Even the recent thread on diffs uses ftp.royer.com instead of  
inet-consulting.com in the Subject!  Ugh!!).  Actually though when I look 
at http://inet-consulting.com/cap-09-b.txt, ATT-COUNTER is NOT section 
7.2.  Section 7.2 is listed as:

7.2      CALID Property . . . . . . . . . . . . . . . . . . . . .  54

I can find no mention of ATT-COUNTER in the text at all.  Is there more 
skewage??...

Rescan the original thread, I was one of the ones that proposed ATTCOUNTER 
and pushed for it over SENT-BY so Im NOT against this proposal in concept. 
 I just wanted clarification on where this new property came from 
(hyphenation threw me off)...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Oct 2002 15:22:54 -0700

>  > that SENT-BY is not sufficient.

Maybe I did miss your point
  - but you did not answer my question. Is it valid
for the ORGANIZER to keep the SENT-BY values?

I say yes.

---

From: [email-masked]
Date: Tue, 29 Oct 2002 14:11:15 -0500

> for the ORGANIZER to keep the SENT-BY values?

Im _FOR_ ATTCOUNTER so we dont have to keep going back & forth over that. 
I was for it in 2000 (go check) and Im for it now. 

My point about your example was that you used:

as motivation.  My response is simply this: you dont use a SENT-BY for 
yourself since you are not acting on your behalf.  You are you and not 
someone acting as your proxy (ie: your AA).  As such the example above is 
not correct (although its legal by just ABNF parsing).

Bruce

---

From: [email-masked]
Date: Tue, 29 Oct 2002 14:16:05 -0500

> for the ORGANIZER to keep the SENT-BY values?

I say yes too.

The other point I was trying to make before was that its NOT expected that 
the Organzier would pass the SENT-BY values on in messages to OTHER 
ATTENDEEs.  Its only of real use between the ATTENDEE and the ORGANIZER; 
not to the rest of the ATTENDEEs at large.  Expecting them to be preserved 
and sent out to other ATTENDEEs is not what was originally envisioned and 
it only makes the receivers job at interpreting and rendering harder.

To be 100% clear: YES the Organizer is anticipated/expected to perserve 
the SENT-BY info in some form but they are NOT expected to resend it 
subsequent messages to others.  Thats my story and Im sticking to it...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Oct 2002 13:42:42 -0700

[email-masked] wrote:
> Im _FOR_ ATTCOUNTER so we dont have to keep going back & forth over 
> that.  I was for it in 2000 (go check) and Im for it now.

Thank you - yes - we agree - now can you answer my question? :-)

> yourself since you are not acting on your behalf.

Now I understand your point. Look closer the two email addresses
are NOT the same (I did not use SENT-BY for myself).

>  You are you and not 
> someone acting as your proxy (ie: your AA).  As such the example above 
> is not correct (although its legal by just ABNF parsing).

I agree - that it is not valid.

-- 
-
Doug Royer                       Work: (208)612-INET
[email-masked]                   Fax:  (866)594-8574
http://INET-Consulting.com       Cell: (208)520-4044
http://Royer.com/People/Doug

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Oct 2002 13:50:00 -0700

[email-masked] wrote:
> The other point I was trying to make before was that its NOT expected 
> that the Organzier would pass the SENT-BY values on in messages to OTHER 
> ATTENDEEs.

Debatable - however the only(?) recipient of a COUNTER *IS*
the ORGANIZER - which I think MUST keep the SENT-BY values
in ALL messages - otherwise the data would be lost. So
the only CUA that would get any COUNTER is the ORGANIZER, which
MUST keep a copy of who sent them (if stored in UNPROCESED
state). Do you agree?

At what point would a COUNTER be sent to another ATTENDEE?
And even IF a COUNTER was sent to another ATTENDEE, that
CS MAY have a SENT-BY's in the entries.

> Its only of real use between the ATTENDEE and the ORGANIZER; 
> not to the rest of the ATTENDEEs at large.  Expecting them to be 
> preserved and sent out to other ATTENDEEs is not what was originally 
> envisioned and it only makes the receivers job at interpreting and 
> rendering harder.
> 

They CAN send the SENT-BY's in updates to any or all ATTENDEEs. There
is no such restriction that I can find. However those ATTENDEE's would
still not get a COUNTER, so the point is mute? Correct?

How would that make things more difficult for non-ORGANIZERs? They
would generally ignore the SENT-BY values - if they got them.

---

From: [email-masked]
Date: Wed, 30 Oct 2002 12:08:39 -0500

Doug wrote on 10/29/2002 03:50:00 PM:
> the ORGANIZER - 

From 2446:

3.2.7 COUNTER

   The "COUNTER" method for a "VEVENT" calendar component is used by an
   "Attendee" of an existing event to submit to the "Organizer" a
   counter proposal to the event description. The "Attendee" sends this
   message to the "Organizer" of the event.

so the answer is that COUNTER is only between an Attendee and the 
Organizer.  No other parties are involved (except maybe an AA or two).

>                  which I think MUST keep the SENT-BY values
> in ALL messages - otherwise the data would be lost. 

The SENT-BY information is ONLY of any real use in the context of the 
message it is associated with.  In all other cases its misleading or 
confusing or even inappropriate and inaccurate.

>                                                      So

The SENT-BY is only valid/useful in the context of the message it was on. 
It was never intended to be preserved and passed on as a kind of hearsay 
("Bruces AA says that he is delegating the meeting to Tom Ransdell").

In this conext I agree that SENT-BY is preserved (along w/all other 
supported properties and property parameters) on that particular message.

I do NOT agree that if you accept my COUNTER and send out a REQUEST to the 
other Attendees that my AAs SENT-BY value should be put on your new 
REQUEST.  Do you??  (It was implied in your "If it is valid to keep them 
(and I think it is)"

> At what point would a COUNTER be sent to another ATTENDEE?

From 2446:

   The "Organizer" rejects the counter proposal by sending the
   "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts
   the counter proposal by rescheduling the event as described in
   section 3.2.2.1 Rescheduling an Event.

so if you accept my (or my AAs) COUNTER to your REQUEST you send out a new 
REQUEST to those involved.  Copying over any SENT-BY property parameter is 
not that useful in the workflow process really.  There is only a minor 
distinction between "Bruce has ACCEPTED Dougs invitation" and "Bruces AA 
has ACCEPTED Dougs invitation on Bruces behalf" (or COUNTERed or...). 

ATTENDEEs do not send COUNTERs to one another.  The Organzier is the 
controller of the workflow process, NOT the separate Attendees.

> still not get a COUNTER, so the point is mute? Correct?

We did not _intend_ for SENT-BY to be preserved ad-naseum thru the entire 
workflow process.  I havent checked for any text that expressly precludes 
this; Im too busy looking for the next CAP URL.

The SENT-BY is intended for indicating a proxys participatoin on someones 
behalf.  As such its only 'valid' between the proxy and the Organzier (or 
the proxy and the Attendee if proxying for the Organzier).  Beyond that 
point it becomes hearsay and of no use to anyone; the Organizer claims 
that someone acting on my behalf has ACCEPTed, etc.

Also, where do you draw the line logically? 

If my AA COUNTERs and you reject it, does the SENT-BY still get put on 
subsequent REQUESTs? 

If the Organizer copied it to a new REQUEST and sent it out and I ACCEPTed 
then would you still put it on any subsequent REQUESTs? 

How about if I sent a REFRESH somewhere in the process? 

If I COUNTER a REQUEST that already has a SENT-BY on an _another_ ATTENDEE 
do I have to round trip it back to you (as if that would serve ANY purpose 
at all!!) 

If you ACCEPT my COUNTER w/another ATTENDEEs SENT-BY on it would it then 
be sent out on the new REQUEST too??  Certainly NOT IMHO but maybe thats 
just me.

You are opening up a can of worms that has no benefit or use.

> would generally ignore the SENT-BY values - if they got them.

Maybe in your engine but "generally" is not precise enough for an standard 
development.  "Generally" recurrence rule handling/parsing/processing 
works consistantly...  "Generally" CUAs should be able to deal with 
multipart MIME and still interoperate fully... 

To paraphrase someone: "These aren't the property parameters you're 
looking for.  We can move along..."

Bruce

---

From: [email-masked]
Date: Wed, 30 Oct 2002 12:44:51 -0500

> Thank you - yes - we agree - now can you answer my question? :-)

I did in an earlier posting, perhaps in a related thread though.  Your 

> > for the ORGANIZER to keep the SENT-BY values?

The SENT-BY property parameter is ONLY valid/useful in the context of the 
message it was on.  It is NOT useful/valid on any other messages either to 
the sender or to other parties involved.

I would expect the Organizer to keep my AAs SENT-BY info only in so far as 
it relates to the message she sent on my behalf.  Preserving it beyond 
that is not useful (nor was it ever intended to be preserved as such). She 
only acted on my behalf for that message, not for any other messages that 
the SENT-BY was _not_ on...

If I ACCEPT and them my AA COUNTERs (and you reject it), would you send 
out her SENT-BY= on any further updates you send?  Id hope not since it 
has no value and is not accurate.

> are NOT the same (I did not use SENT-BY for myself).

Argh!  Such tiny difference on my monitor is nearly unreadable.  It took 
me 3 reads to see the "a" vs "a1".  To avoid such violent agreements in 
the future may I suggest you use some value that is more noticably 
different like "a" and "z"...

Bruce