Subject: Re: iTIP: Who sent that message?

From: [email-masked]
Date: Mon, 28 Aug 2000 11:06:36 -0400

Eric astutely asked:
>How do you determine who sent a COUNTER message?

Well it seems that some folks are actually reading the RFCs before they 
implement them.  As the text of 3.2.7 COUNTER and 4.2.4 Countering an Event Proposal show, there is NO mechanism for determining this in iTIP. 

The best answers I could find are: "It's FM", a wild guess, or the use of 
external meta information (ie: the "Sender: ..." MIME header from the iMIP 
message, etc). 

This appears to be another sight that came from simplifying the original 
proposed iTIP message set down to the "minimal" set in the RFCs.  Chalk it 
up on the list of errata that needs to be dealt with.

A simpler solution that some appear to have taken is to NOT allow 
COUNTERing but I dont consider that viable in a real C&S system...

Bruce
===========================================================================
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] (Steve Mansour)
Date: Mon, 28 Aug 2000 11:20:53 -0700

[email-masked] wrote:

> Well it seems that some folks are actually reading the RFCs before
> they implement them.  As the text of 3.2.7 COUNTER and 4.2.4
> Countering an Event Proposal show, there is NO mechanism for
> determining this in iTIP.
>
> The best answers I could find are: "It's FM", a wild guess, or the use
> of external meta information (ie: the "Sender: ..." MIME header from
> the iMIP message, etc).
>
> This appears to be another sight that came from simplifying the
> original proposed iTIP message set down to the "minimal" set in the
> RFCs.  Chalk it up on the list of errata that needs to be dealt with.
>

This is a proposed update as pointed out in my message to the list on
Aug 10, 2000.  Here is an excerpt from that message

     2. Identify sender of iTIP COUNTER:

          Problem: You can't identify which Attendee a COUNTER
          message came from because all of the Attendees will
          appear in the component.

          Proposal 1:  Restrict the COUNTER message so that it
          can only specify the ORGANIZER and countering
          ATTENDEE.

          Note: You can still forward (party crashing,
          remember? :-) or delegate a REQUEST to change
          participants. However, only the ORGANIZER can remove
          a participant.  The down side to this approach is
          that you can't change the Attendees. This removes
          functionality.  The up side is that it requires no
          changes to iCalendar.

          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.

          Note: The good news is that no functionality is lost
          -- you can suggest a different attendee list.  The
          down side is that we have to update iCalendar with a
          new parameter.

So far, there's been one reply to the list favoring proposal 2, plus
I've received one private reply favoring proposal 2.  This is the one I
was planning to write up for the updated iTIP spec.

-Steve

---

From: Eric Busboom <[email-masked]>
Date: Mon, 28 Aug 2000 13:22:22 -0700 (PDT)

>      2. Identify sender of iTIP COUNTER:

Oh, sorry. It felt like a dumb question when I asked it, but I couldn't
figure out why....

> was planning to write up for the updated iTIP spec.

Proposal 2 sounds OK, but perhaps it could be generalized by just using
the existing SENT-BY parameter? It would be awkward, since you'd have the
calid in the property line twice ( once as a value and once in the SENT-BY
parameter) but it does solve the problem with minimal changes, since
SENT-BY is already spec'd for use in ATTENDEE. We'd just be overloading
the semantics a bit. 

eric.

---

From: [email-masked] (Steve Mansour)
Date: Mon, 28 Aug 2000 13:44:55 -0700

Eric Busboom wrote:

> ...

Yea, overloading SENT-BY is sure to come back to haunt us.  Remember that an
Event may already have several ATTENDEEs with SENT-BY parameters. We still
need to figure out which SENT-BY is sending the COUNTER. Will the person doing
the COUNTER have to strip out all SENT-BY info? Probably not a good idea.

Is the ATTCOUNTER param OK with you, Eric?  Bruce?

-Steve

---

From: John Stracke <[email-masked]>
Date: Tue, 29 Aug 2000 10:11:44 -0400

[email-masked] wrote:

> The best answers I could find are: "It's FM", a wild guess, or
> the use of external meta information (ie: the "Sender: ..."
> MIME header from the iMIP message, etc).

Clarification: that should be From:.  The Sender: is likely to be
an address for the CS admin or something.  RFC-822 (section
4.4.4...I had occasion to look this up last night) says you never
send a reply to Sender:.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Never do card tricks for your poker buddies. |
[email-masked]|                                             |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 29 Aug 2000 10:15:55 -0400

Eric Busboom wrote:

> the existing SENT-BY parameter?

SENT-BY means something completely different: the person who sent the
message, as opposed to the one on whose behalf it was sent.  In email terms,
it's like Sender:, not like From:.

Since the current system allows a SENT-BY on the ATTENDEE in a COUNTER
message, there'd be no way to distinguish between the old usage ("Joe wants
to submit a counterproposal, but Fred sent this message for him") and the new
("Fred wants to submit a counterproposal in which Joe is the only
attendee").  And we can't scrap old usage; it's likely to be useful
sometimes.

---

From: [email-masked]
Date: Tue, 29 Aug 2000 09:33:45 -0700 (PDT)

> the COUNTER have to strip out all SENT-BY info? Probably not a good idea.

Ah. 

> Is the ATTCOUNTER param OK with you, Eric?  Bruce?

I can live with ATTCOUNTER. This would be a boolean type, or maybe a
parameter with no value -- you just check for it's existence?

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

eric.

---

From: [email-masked] (Steve Mansour)
Date: Tue, 29 Aug 2000 09:48:54 -0700

> It still makes me uneasy, since it is a parameter that has such a small

right.  Frank's proposal for making it a property deals with this problem. Still
serves a small purpose, but it's clear. So, iTIP example 4.2.4 would become somthing
like:

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:COUNTER
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:[email-masked]
   ATTCOUNTER:mailto:[email-masked]
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:[email-masked]
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:[email-masked]
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:[email-masked]
   DTSTART:19970701T160000Z
   DTEND:19970701T190000Z
   DTSTAMP:19970612T190000Z
   SUMMARY:Discuss the Merits of the election results
   LOCATION:Green Conference Room
   COMMENT:This time works much better and I think the big conference room is too
big
   UID:[email-masked]
   SEQUENCE:0
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

This indicates that the counter proposal was made by "B".

-Steve