Subject: SKICal CONTROL

From: Pär Lannerö <[email-masked]>
Date: Tue, 13 Mar 2001 16:09:08 +0100

The ORGANIZER of a VEVENT is not always the organizer of the
corresponding real life event.

If I publish an event (or more generally, a "SKiSource") and want to
indicate what organization/person is legally responsible for the event,
or what organizations are sponsors of the event, or other such roles 
which are important in event directories, I cannot use ORGANIZER.

Yet there is a need for this information to be included in a controlled
manner (that is, not as easy-to-forget free text notes in DESCRIPTION)
for many SKICal user groups.

The following property ("CONTROL") is intended to meet this need. 
I believe it is a good idea if this property replaces RESPONSIBLE,
ASSOCIATION and OTHERAGENTS in earlier SKICal specifications. It greatly 
reduces the complexity of the specification.

Comments welcome!

-From the current SKICal draft----------------------------------------

   Property Name: CONTROL 

   Purpose: This property indicates responsibilities, jurisdictions, 
   ownership, and other formal or informal relationships for parties 
   involved in the SKiSource. 

   Value Type: TEXT. (MAILTO) 

   Property Parameters: Non-standard property parameters can be 
   specified on this property. 

   Conformance: This property CAN be specified within a "VEVENT"
   calendar component. 

   Description: To declare relationships, responsibilities and
   liabilities of formal, informal, or contractual nature amongst 
   parties involved in a SKiSource or particular aspects of a 
   SKiSource. The CONTROL property is used to define these 
   responsibilities and jurisdictions. 

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

    control = "CONTROL" controlparam ":" uri CRLF 
        
    ; the value MAY be a MAILTO URI, as defined  
    ; by RFC-1738[4]. 
        
    controlparam  = *( 
        ; the following is optional, 
        ; but MUST NOT occur more than once 
        (";" languageparam ) / (";" cnparam ) / (";" skiroleparam)

        ; It is highly RECOMMENDED that SKICal objects actually
        ; use the cnparam since some applications will not 
        ; bother to read the altrep'ed vCard.

        ; the following is optional, 
        ; and MAY occur more than once 
         
        (";" xparam) 
        ) 

   Example: The following are examples of this property: 

    CONTROL;SKiROLE=producer;CN=Nobelkommitten:MAILTO:[email-masked]  
    CONTROL;SKiROLE=producer;CN=Opera house:MAILTO:[email-masked] 
    CONTROL;SKiROLE=responsible;MAILTO:[email-masked]
    CONTROL;SKiROLE=contracting agency:MAILTO:[email-masked]  
    CONTROL;SKiROLE=sponsor;CN=Stockholms stad:MAILTO:kultur@stadshuset.
     a.se
    CONTROL;SKiROLE=in association with;CN=Svenska Turistforbundet:MAILT
     O:[email-masked] 
    CONTROL;SKiROLE=responsible-is-member-of;CN=Rotary international:MAI
     LTO:[email-masked] 

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

/Pär

---

From: John Stracke <[email-masked]>
Date: Tue, 13 Mar 2001 10:53:44 -0500

> reduces the complexity of the specification.

Looks good to me.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |I used to belong to a solipsism club, but I got|
[email-masked]|bored & voted everybody else out.              |
\================================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 13 Mar 2001 10:44:43 -0600

This raises a question that has been bothering me for a while.

How should "ORGANIZER" be handled for the possibly large number of events
for which it hold no meaning? Examples: Holidays; public events; tax-filing
deadlines; etc.

In the context of events, such as holidays, shared by all the users of a
given calendar system (probably by way of user groups and a group
calendar) - the concept of ORGANIZER and for that matter ATTENDEE are
counterproductive and likely confusing if displayed or revealed to an end
user.

CONTROL seems like a possible step in the right direction.

A few specific questions about CONTROL.

Where are the possible set for the SKiROLE parameter's set? Is it possible
to use anything here? Or is there a limited set being proposed? If the
SKiROLE's are intended to be mapped to a programmed response (perhaps a way
of being displayed etc) then a limited set is desirable.

A second point - are CONTROL's intended to be mapped to a USER (however
loosely defined) within the calendar store, or are they intended to be
referencing an external agency with no other connection to the calendar
store (and therefore no requirement of any validation/security on the USER
id etc.)

A third point - from the examples it is implied - but never clearly stated -
that there may be multiple CONTROL properties for a given vEvent.

A fourth point - is control only intended for vEvents? Or is it suggested
for other vObjects such as vTodo's? (so a vToDO for "File your US Taxes"
might have a CONTROL of the IRS?

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pär Lannerö
Sent: Tuesday, March 13, 2001 9:09 AM
To: [email-masked]
Subject: SKICal CONTROL

Comments welcome!

   Property Name: CONTROL

    controlparam  =

        (";" xparam)
        )

/Pär

---

From: George Babics <[email-masked]>
Date: Tue, 13 Mar 2001 14:45:02 -0500

> for which it hold no meaning? Examples: Holidays; public events; tax-filing

  An organizer can still have a meaning. It is the person who created
or published the meeting. One may ask questions about a public event
to the organizer. Or if there was a mistake in the holiday event,
who does one contact?

  One can use the CONTACT property, but then would one specify
CONTACT for a holiday?

  Thus, who does one contact, the ORGANIZER, the CONTACT, or the CONTROL?
Furthermore, who should be contacted depending on which situation? Should
ORGANIZER be the default contact if CONTACT or CONTROL are not
specified?

  In context of iTIP, one needs to organizer to be able to know who to
send REFRESH and possibly other requests to.

> counterproductive and likely confusing if displayed or revealed to an end

  The organizer may be useful as I described above.

  Furthermore, one need not add attendees to an event.

  If one looks at the publish method in iTIP (one would normally publish
a public event or holiday rather than invite people to it), the attendee
attribute is not permitted.

George

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 14 Mar 2001 09:38:05 +0100

A brief semantic review from Greg.

The word "Organizer" implies some sort of "control" over an event ("Who's in
charge here, anyway?").  But this rather generic term  is  specifically
designated in 2445 to name the controller of an "object of description", the
iCal calendar components.

This "object of description" may in some cases (but not always) point to an
"event" which has it's own "objects of description"  for example a Trade
Fare.  In some formalized way; contracts, rental agreements etc, the
organization of the trade fare is constituted.  In this formalization,
responsible parties are named.  As Bruce contributed, there can be quite a
few such responsible parties for any given event.

We suggest the property CONTROL as a place holder for designating such
responsible parties, and we suggest using the parameter SKIROLE to
distinguish between their functions.

In the event that an EVENT had no other formalized description other than an
iCal object, for example a lunch date between George and myself, CONTROL
would not be needed, ORGANIZER would signify who was calling for
(organizing) the meeting.

But in the event our meeting involved interaction with a third party, such
as the IETF,  (I could be the ORGANIZER of a meeting with George at the
IETF) and our meeting was influenced by the organization of the IETF
meeting, then it could be important to identify who the responsible parties
(controllers) of the IETF meeting are.

Frank asks a pertinent question: "Is this just informational or is there
some scheduling workflow requirement for this "CONTROL" information? Is
there some requirement/description beyond specifying the individual that is
"legally responsible" for the event?"

Greg: It is informational - until used otherwise.  To gain more than
information status there should be some constraint on possible values.  And
as Shannon pointed out, there should be constraint on the SKIROLE values
that qualify the CONTROL value.  At this stage in SKiCal development it is
up to users to apply these constraints.

> for which it hold no meaning? Examples: Holidays; public events;
tax-filing

George Babics answered:

George