Subject: RFC 2445 Proposal: ATTCOUNTER

From: [email-masked]
Date: Wed, 27 Feb 2002 14:59:51 -0500

Here is my proposal to resolve how an Organizer is able to tell who is 
actually sending the COUNTER method.

This text is a proposal that updates RFC 2445 itself.  The updates RFC 
2446 are after the proposal.

------------------------------------------------------------

4.8.4.x Countering Attendee

   Property Name: ATTCOUNTER

   Purpose: The property defines an "Attendee" within a calendar
   component who is counter proposing the definition or content 
   of the component.

   Value Type: CAL-ADDRESS

   Property Parameters: Non-standard, language, common name, and sent by 
   property parameters can be specified on this property.

   Conformance: This property MUST be specified in an iCalendar object
   that specifies a counter proposal to a group scheduled calendar entity.
   This property MUST NOT be specified in an iCalendar object that 
   specifies only a time zone definition or that defines calendar 
   entities that are not group scheduled entities, but are entities 
   only on a single user's calendar.  This property MUST NOT be specified
   on an iCalendar object that does not involve counter proposing a
   new definition or content for a group scheduled calendar entity.

   Description: The property is specified within the "VEVENT", "VTODO",
   "VJOURNAL calendar components to specify the sender of a counter 
   proposal to a group scheduled calendar entity.  The value of the 
   property MUST match one of the ATTENDEE properties specified on the
   group scheduled entity that it is being counter proposed.  The value
   of the property MAY NOT match one of the ATTENDEE properties specified
   on the counter proposed group scheduled calendar entity; the ATTENDEE
   could be counter proposing an ATTENDEE list that does not include
   themselves.

   The property has the property parameters CN, for specifying the
   common or display name associated with the countering user, SENT-BY, 
   for specifying another calendar user that is acting on behalf of 
   the countering ATTENDEE. The non-standard parameters may also be 
specified 
   on this property. If the LANGUAGE property parameter is specified, 
   the identified language applies to the CN parameter value.

   Format Definition: The property is defined by the following notation:

     attcounter = "ATTCOUNTER" attcounterparam ":" cal-address CRLF

     attcounterparam = *(

                ; The following are optional,
                ; but MUST NOT occur more than once

                ( ";" cnparam ) / ( ";" sentbyparam ) / 
                ( ";" languageparam ) /

                ; The following are optional,
                ; and MAY occur more than once

                ( ";" xparam ) / ( ";" iana-param )

                )

   Example: The following is an example of this property:

     ATTCOUNTER;CN=John Smith:MAILTO:[email-masked]

   The following is an example of this property used by another calendar
   user who is counter proposing on behalf of an ATTENDEE:

     ATTCOUNTER;SENT-BY="MAILTO:[email-masked]":
      MAILTO:[email-masked]

------------------------------------------------------------------------

The changes to RFC 2446 involve inserting a:

     ATTCOUNTER     0

into ALL restriction tables _except_ the ones in Sections 3.2.7 COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO).  For those 2 cases it would be:

     ATTCOUNTER     0 or 1

for the obvious reasons.

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: Wed, 27 Feb 2002 13:34:46 -0700

[email-masked] wrote:

> into ALL restriction tables _except_ the ones in Sections 3.2.7
> COUNTER (for VEVENT) and Section 3.4.7 COUNTER (for VTODO).  For those
> 2 cases it would be:
> 
>      ATTCOUNTER     0 or 1
> 
> for the obvious reasons.

Also in DECLINE-COUNTER? So the CUA knows how/who to
send it back to. What if you AND your AA do a COUNTER.
If I then do a DECLINE-COUNTER, I would return two objects
that could look identical.

If we add the ATTCOUNTER to DECLINE-COUNTER one object would have
you as the ATTCOUNTER, the other would have you as the ATTCOUNTER plus
have SENT-BY set to your AA. If I then DECLINET-COUNTER, then you get
two unique DECLINE-COUNTER objects, one for each received and
processed.

---

From: "Graham Gilmore" <[email-masked]>
Date: Wed, 27 Feb 2002 16:34:54 -0500

Maybe I'm missing one of those "obvious reasons" here, but based on the

>    new definition or content for a group scheduled calendar entity.

    In what case(s) could ATTCOUNTER have 0 rather than 1 occurrence in the
two COUNTER sections mentioned for RFC 2446?  Should it simply be 1?  :

> into ALL restriction tables _except_ the ones in Sections 3.2.7 COUNTER
(for VEVENT) and Section 3.4.7 COUNTER (for VTODO).  For those 2 cases it
> for the obvious reasons.

    Graham

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Feb 2002 16:07:56 -0700

>    property MUST match one of the ATTENDEE properties specified on the

(1) Per iTIP, COUNTER is not allowed in a VJOURNAL.
    (So it could never have a ATTCOUNTER?)

(2) Rather than saying ("VEVENT", "VTODO", "VJOURNAL"), how
about saying:

   The property is specified within iTIP components that contain
   the COUNTER property to specify the sender ...

(3) Lets let iTIP and any of its future rev's dictate where
    ATTCOUNTER (COUNTER) goes in iTIP objects. In CAP lets just add
    it to 'whatever iTIP allows for COUNTER properties' ?

(4) Where you also proposing we allow COUNTER in VJOURNAL?