Subject: iTIP: Who sent that message?

From: [email-masked]
Date: Sun, 27 Aug 2000 21:56:22 -0700 (PDT)

How do you determine who sent a COUNTER message? A COUNTER message can
have multiple ATTENDEE properties, and it will not have come from teh
ORGANIZER, so there is apparently no unambiguous, in-band way to determine
who sent the message. This makes it tough to send back a response to the
COUNTER message if your architecture involves storing incomming messages
in a file and processing them later.

Of course, I could add an X- property to the component to indicate who
sent the message, but I really think that the information should be part
of the message.

Am I missing something, or is this worthy of an additional parameter for
ATTENDEE?

eric.

---

From: [email-masked]
Date: Mon, 28 Aug 2000 11:55:53 -0400

Bruce:
I believe that the original idea was that the only ATTENDEE properties 
would be the originator and the chair who is receiving the COUNTER.
But as written in RFC 2446, I agree that this is an issue needing 
clarification (mere fixing text) or a change request (change functionality 
if we consider what is written to be what the other authors intended).
-- Frank

---

From: [email-masked]
Date: Mon, 28 Aug 2000 12:29:59 -0400

Frank suggested:
>I believe that the original idea was that the only ATTENDEE 
>properties would be the originator and the chair who is 
>receiving the COUNTER. 

That may be if I you take 3.2.7 COUNTER strictly by what it claimed:

   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.

but the restriction table clearly states:

    ATTENDEE        0+      Can also  be used to propose other
                            "Attendees"

and this is a good thing.  This ability is clearly one that C&S needs to 
have ("Hey Frank, dont forget to invite the new RFC co-editor to the 
conference call!") w/o relying on OOB means.

>I agree that this is an issue needing clarification (mere fixing 
>text) or a change request (change functionality if we consider 
>what is written to be what the other authors intended).

Given that the iTIP messages are 'full snapshots' of the entry (including 
COUNTER, see the actual examples under 4.2.4 Countering an Event 
Proposal), I think some new text is in order.  If the COUNTER were _not_ a 
full snapshot then how could B suggest adding new ATTENDEEs and removing 
others all in the same COUNTER?  However mere text changes wont solve the 
problem (without removing funtionality), since neither 2445 or 2446 have 
any means to convey the senders identity in this case. 

First blush would seem to indicate that a new property is necessary but 
not inside the vEvent, etc. but rather at the outer 'container' level.  A 
few more cycles yeilds the concept of a property parameter on the METHOD 
(ie: METHOD;SENT-BY="mailto:[email-masked]":COUNTER) but Im only tossing 
out ideas; not doing the actual redesign now...

Bruce
PS: Just why is the restriction table 0+ instead of 1+??
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Mon, 28 Aug 2000 22:07:49 -0400

>Proposal 2 sounds OK, but perhaps it could be generalized by just using
>the existing SENT-BY parameter?

This changes the semantics of the SENT-BY parameter. Don't like this idea.
-- Frank

---

From: [email-masked]
Date: Tue, 29 Aug 2000 13:17:45 -0400

Eric said:
>It still makes me uneasy, since it is a parameter that has such a small
>purpose.

Im in the same boat as Eric (see previous posting)...

Bruce

---

From: [email-masked]
Date: Tue, 29 Aug 2000 13:25:03 -0400

Frank and Steve pondered:
>>Separate out the routing information from the content information!
>Agreed.

This is not the case of mixed information per-se but rather a case of just 
not diving deep enough on the less frequently traveled C&S workflow paths 
(as we saw recently with the RRULEs issues).

Our "fully encapsulated" goal was and still is worthwhile for many cases 
but as we discovered in DC in December a separation model is also 
necessary at times...  Lets learn the right lessons from this as we fix 
it; not just "We should'a done something different".

Bruce

---

From: [email-masked]
Date: Tue, 29 Aug 2000 16:19:49 -0400

Bruce is correct. The intent was that a "counterer" could suggest a 
different list of attendees.
But without the ATT-COUNTER property this is kind of broke :-(
-- Frank

---

From: [email-masked]
Date: Tue, 29 Aug 2000 16:24:30 -0400

John and all others:
>I'm concerned because, if not, then it becomes difficult to
>extend a property definition over time.

Bruce Kahn and I talked about this in a call today. We reviewed for the 
100th time the iCalendar specification. We got a shock. It appears that 
the editors (moi for one) did not include "iana-param" or "iana-prop" in 
any of the definitions for the standard properties.
This was certainly an oversight on the editors' part. There is the 
"iana-comp" in the definition of a component, but not the counterpart for 
new standardized properties or parameters in the various standard property 
definitions.
My humble apologies! This is certain a numero uno Change Request 
candidate. Without this, the ABNF doesn't currently allow registered 
extensions. Only "x-prop" and "x-param" experimental extensions. Not what 
we had intended folks.
Eric:
After the dust settles on this one, can you please add this to our list of 
defects that need change requests? Thanks.
-- Frank

---

From: [email-masked]
Date: Wed, 30 Aug 2000 13:49:02 -0400

I see some noise on the list that support the ATT-Counter property.  I 
don't see much saying anyone does not like the idea.  Frank, since it's 
your idea, do you have some text to put on the list and we'll get it 
approved and added.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

---

From: [email-masked]
Date: Wed, 30 Aug 2000 14:17:04 -0400

Yes, ma'am.