Subject: RE: SKICal CONTROL

From: [email-masked]
Date: Tue, 13 Mar 2001 10:48:34 -0600

> Subject: SKICal CONTROL
> 
> 
> 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.

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? I am
also not certain what "legally responsible" actually means compared with the
semantics for ORGANIZER, which is the person responsible for scheduling the
event. This semantic interaction needs some clarification. Maybe scenarios
would help?

> 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. 

Simple sounds good!

>    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]. 
> 

Can the value be anything other than a MAILTO URI? If not, then shouldn't
this be a MUST rather than a MAY?

How many times can this property appear in a VEVENT? If more than once, what
does this mean?
        
>     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] 
> 

There are some errors in the examples. SEMICOLON appears where a COLON ought
to be.

-- Frank

---

From: [email-masked]
Date: Tue, 13 Mar 2001 11:19:58 -0600

> 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.

The ORGANIZER is the entity that scheduled the event, not necessarily the
entity that is responsible  for or controls the event. In an enterprise or
web calendar environment, some entity is responsible for defining the
holiday VEVENT definitions that a subscriber can add to their calendar. This
would be the logical entity to addressed by the ORGANIZER property. I think
for most of your examples, logical entities can be identified.

---

From: [email-masked]
Date: Tue, 13 Mar 2001 17:12:22 -0500

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

Nothing wrong w/that scenario.  Ever notice that a real even has > 1 
Sponsor?  Look as NASCAR, F1 Racing, Sporting Events, etc.  Check out the 
IETF Sponsors list next time you sign up...  Your point about clearly 
stating it though is a very good one.  Implicit assumptions are not nice 
in an interop. spec.

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]
Date: Mon, 19 Mar 2001 11:19:49 -0500

George wrote:
> > 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.
> 
>   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?

The functional use of ORGANIZER and CONTACT are quite clearly defined. 
From RFC 2445:

4.8.4.2 Contact

   Property Name: CONTACT

   Purpose: The property is used to represent contact information or
   alternately a reference to contact information associated with the
   calendar component.

and

4.8.4.3 Organizer

   Property Name: ORGANIZER

   Purpose: The property defines the organizer for a calendar component.

In a nutshell: Organizer is the coordination point for any workflow. 
Contact is a non-workflow point of contact (ie: "If you need directions to 
this event, contact Frank at..."). 

The use for an Organizer for Shannons examples is simple: the Organizer is 
responsible for handling any updates that may be necessary (ie:"Due to the 
local flooding, the Concerts on the Common scheduled for this Saturday has 
been cancelled." could be sent by the Town's "Organizer". 

In my company, the official Holiday Schedule is PUBLISHed by 1 entity. All 
other attempts by other Iris (or non-Iris) employees to reschedule or 
modify the "official" holiday set are rejected (either by me or by my 
client that sees an Organzier mismatch from what it was told was valid to 
accept).  Would you want a disgruntled employee to give everyone tons of 
extra days off when its not company policy?  Of course not.  So by having 
updates only come from the sanctioned Organizer I can be reasonably 
certain I only take off the given holidays.

Another example: In New England where I am a prisoner, err an employee of Iris, Patriots Day is a semi-regional holiday so if 
"Tax day" occurs on the same day, "Tax day" gets pushed out 1 more day. As 
such, the IRS may want to "update" their regular tax schedule for some of 
us tax payers.  In order for me to accept the update, I need an Organizer 
that matches the original notices.

>   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?

Workflow goes thru the ORGANZIER so a REPLY to the ORGANIZER w/your "There 
is a mistake" COMMENT is appropriate.  One could conceivably also contact 
the CONTACT but that would be "out of band" from any C&S workflow.

>   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?

I would not expect ANY workflow msgs to be sent to the CONTROL entities. 
See above for ORGANIZER vs CONTACT usage.

Bruce

---

From: [email-masked]
Date: Mon, 19 Mar 2001 11:19:49 -0500

events
tax-filing

4.8.4.2 Contact

   Property Name: CONTACT

and

4.8.4.3 Organizer

   Property Name: ORGANIZER

CONTROL?
Should

Bruce

---

From: [email-masked]
Date: Mon, 19 Mar 2001 11:31:37 -0500

Shannon asked:
>How should "ORGANIZER" be handled for the possibly large number of 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.

For all the examples above there are definite uses for an Organizer.  The 
Organizer is the one who is responsible for organizing the Holidays, 
public events, etc.  Whom is this you may be thinking.  Simple, whom ever 
defines it and then publishes it.  Who says that in the US, "April 15th 
(or the closest following weekday if on a weekend) is when final tax 
payments are due?".  The US goverment (or if you prefer, the IRS).  Who 
would be responsible for organizing local public events like St. Patricks 
Day Parades, Concerts on the Town Common, etc?  The local government of 
course.

If one of the entities is going to publish some kind of event schedule or 
timetable then there has to be some Organizer to disseminate and possibly 
update that information.

Nearly all of the examples Shannon asked about are the PUBLISH type.  That 
is, the IRS does not care to get a COUNTER from me when it tells me I have 
taxes due on 15-Apr-01.  Nor does it want a COUNTER proposal for how much 
(or when) I should pay.  In iTIP, PUBLISHes are done w/o ATTENDEEs so 
there should be no confusion.

One could see some cases where REQUEST is used instead of PUBLISH.  For 
example, the local government wants to get an idea of how may folks plan 
to attend the local free concerts on the common so they can judge how much 
police or emergency services to have on hand.  I doubt they would want 
DELEGATION or COUNTER messages from individuals but they may want to get a 
feel for attendance.  As such, ATTENDEE is not really counterproductive or 
confusing; it may be a single address like 
"mailto:[email-masked]" and NOT likely the entire 
taxpayer list for Westford...

However this kind of case is not likely to be as predominant as the 
PUBLISH case.

Bruce

---

From: [email-masked]
Date: Wed, 21 Mar 2001 12:25:17 -0500

Graham suggested:
>     Two VCALENDAR components might be related with a SIBLING
> relationship, without having any PARENT or CHILD relationship to any
> other component (for example, 2 New Years' parties organized by the same
> organizer in different cities linked with live video feeds).

The relationship described is not one that affects C&S workflow though.  In
the text on CHILD/PARENT there is an assumption that changes to the PARENT
may affect the CHILD to some degree but not visa versa.

What are the logical semantics of using the SIBLING link (apart from
"completeness" of link types in the model)?  I grok the remote feed concept
since we use it here.  But just because a blizzard causes the Boston event
from happening, it has no impact/affect on the, say, Orlando meeting.

I just see SIBLING as a case of "what other kinds of Tree links exist?"
rather than a solution to a C&S need.  The Event A and B are separate but
related in my mind is one of the 10% in the 90/10 rule at best.  When is
the last time someone here used this feature?  And how often do you use it
when you do??

Guess Im just on another simplification kick again.  (Although if we dont
get 2 or more implementations of it in our interop efforts its subject to
removal from the RFC as Frank so often notes.)

Bruce

---

From: Pär Lannerö <[email-masked]>
Date: Thu, 22 Mar 2001 00:28:19 +0100

Bruce wrote:
> >[The PARTREL property] differs from RELATED-TO since
> >that property defines a relationship between calendar objects describing
> >SKiSources and not between SKiSources themselves.
> 
> Im not groking your definition of a SKiSource compared to the entry 
> represented by, say, a VEVENT in iCalendar.  So the distiction between 
> RELATED-TO and  PARTREL is nonexistant to me.  Can you differentiate it 
> better (at least for me)??

Greg wrote:

                RELATED-TO
descriptor      <------->       descriptor
        |                               |
        |                               |
        v       PARTREL                 v
     event      <------->            event

He could just as well have written:

                RELATED-TO
    VEVENT      <------->           VEVENT
        |                               |
        |                               |
        v       PARTREL                 v
   SKiSource    <------->          SKiSource

Example: a concert (SKiSource) may be part of (PARTREL) a music festival 
(another SKiSource) even though the festival may not even be described 
by any calendar object (VEVENT) existing in the same calendaring system. 
The PARTREL property will be very meaningful anyway, especially if it
has 
a CN-parameter.

    VEVENT      
        |                               
        |                               
        v       PARTREL                 
   Concert      <------->          Festival

/Pär

----- Par Lannero ------------ Ny mobiltelefon: 0739-442043 -----
----- [email-masked] -------- icq:306436 -------------