[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Role Simplification Proposal
One of the key scenarios we found that broke our previous proposal was
authenticating an organizer who was different from the Owner. The only
way to ensure that the organizer had the right to act on the owners
behalf would be if an attendee received a signed request from the owner
that designated someone as organizer. All attendees who received that
message could store the fact that the "organizer" has an unambiguous
right to play the role of owner. However, if the organizer then went and
invited other attendees, those attendees not have a paper trail
authorizing the organizer to act on the owner's behalf. This would also
be the case for forwarded attendees.
We thought that keeping the same framework but limiting the actions was
a hack and hence the new proposal.
steve
-----Original Message-----
From: Frank Dawson [mailto:fdawson@earthlink.net]
Sent: Tuesday, December 23, 1997 10:25 AM
To: IETF Calendaring & Scheduling Mail List
Cc: Derik Stenerson; Steve Mansour; Steve Silverberg (Exchange)
Subject: Role Simplification Proposal
Role Simplification Proposal
PROBLEM: There has been numerous discussions on and off the mailing list
about concerns with the current definition of the "ATTENDEE" property
and
the "ROLE=OWNER" parameter value sequence. Some of these discussions
involved:
* It is unclear if an ORGANIZER role implies attendance at an event or
participation in a group scheduled to-do;
* Definition of OWNER role for "ATTENDEE" is not clearly differentiated
from
the calendar store OWNER;
* Unclear how the delegation of the ORGANIZER can rescinded by the
OWNER;
* Inherent window for a race-condition when OWNER tried to rescind
"organizership" from a delegated ORGANIZER. The "Attendees" to an event
might first receive a message from the delegated ORGANIZER; before the
message rescinding "organizership" is received from the actual event
OWNER.
* Unclear if there can be more than one OWNER and ORGANIZER.
* Current proposal may not reflect current practice for implementing
"proxy"
support.
REQUIREMENTS: The following are requirements for the attendee and role
capbility:
* Identify those calendar users invited to attend an event or asked to
participate in a to-do;
* Allow a REQUEST to be forwarded to another calendar user;
* Allow an "Attendee" to a group scheduled event or to-do to delegate
their
attendance to another calendar user;
* Identify the calendar user/calendar store that is scheduling the
calendar
component;
* Identify when another calendar user is acting on behalf of the
organizer
of a group scheduled event or to-do;
* Identify the role that an attendee is expected to play
SOLUTION: The "ATTENDEE" property and "ROLE" parameter needs to be
revised
to address these concerns and make sure that the requirements for this
property/parameter are met.
PROPOSAL: The specified would be changed to reflect that the "ATTENDEE"
property is to be used *only* to specify those calendar users invited to
attend a group scheduled event or participate in a to-do. A new,
separate
property would be used to specify who is scheduling the event or to-do.
The
scheduling workflow semantics of "OWNER" and "ORGANIZER" roles would be
converged into a single "ORGANIZER" property. That is, the previous
semantics of "OWNER" and "ORGANIZER" are captured in the "ORGANIZER"
property. The version 1 specifications would be simplified to *not*
support
delegation of the "Organizer". This might be addressed in a subsequent
version of the specifications. Multiple "Organizers" might be allowed in
iCalendar but would be restricted to a single "Organizer" in Version 1
of
iTIP. The participation role for "Attendees" would be specified by a
revised
"ROLE" parameter on the "ATTENDEE" property. The participation role has
no
scheduling workflow semantic. It only indicates that the intended role
the
"Attendee" is expected to have in the event or to-do (e.g., CHAIR the
meeting or act as a PARTICIPANT in the meeting)
The iCalendar draft is proposed to be modified as follows:
* Change the "ATTENDEE" property semantics to specify that the property
specifies those calendar users that are invited to attend a group
scheduled
event or participation in a group scheduled to-do.
* Change "ATTENDEE" property's "ROLE" parameter semantics to specify
that
the parameter specifies the intended role that the "Attendee" is being
assigned for the group scheduled event or to-do. The enumerated values
will
be changed to: CHAIR, to indicate that the "Attendee" will chair or
otherwise facilitate the event or to-do; PARTICIPANT, to indicate that
the
"Attendee" will be a participate in the event or to-do. The default
value is
PARTICIPANT. In addition, any other IANA-registered parameter value may
be
specified.
* Retain the other existing property parameters for "ATTENDEE" property,
as
currently defined.
* Add the "ORGANIZER" property to specify the calendar user that is
organizing the group scheduled event or to-do. The property value data
type
is the same as that specified for the "ATTENDEE" property.
* The only calendar user type allowed for the "ORGANIZER" property is an
INDIVIDUAL. Hence, no "TYPE" nor "GROUP" parameter will be needed in the
"ORGANIZER" property.
* No delegation of "Organizer" will be supported in Version 1.0 of
iCalendar, so the "DELEGATED-TO" and "DELEGATED-FROM" parameters will
not be
neeed in the "ORGANIZER" property..
* The "ORGANIZER" does not participate in the group scheduled event or
to-do, so no "REPLY" parameter is needed in the "ORGANIZER" property.
* Add the "SENT-BY" parameter to the "ORGANIZER" and "ATTENDEE" property
to
specify another calendar user that is acting on behalf of the calendar
user
specified in the property value. This parameter provides support for the
capability in current calendaring and scheduling systems for another
calendar user to get access to an individual's calendar store and act on
their behalf. For example, "Bill" might give "Susan" access to act on
his
behalf in his calendar store. A property sequence of
"ATTENDEE;REPLY=ACCEPT;SENT-BY=susan@host.com:bill@ host. com" would
indicate that "Susan" is replying on behalf of "Bill";
* Examples changed to reflect these modifications.
The iTIP draft is proposed to be modified as follows:
* Responses to a REQUEST method are always sent to the calendar user
identified by the value of the "ORGANIZER" property. If the calendar
component is group scheduled, then there must be a single "ORGANIZER"
property specified.
* Only one "ORGANIZER" is allowed in a group scheduled calendar
component.
Support for multiple "Organizers" of a group scheduled calendar
component is
deferred to a subsequent version of the interoperability protocol. This
will
simplify the interoperability specification and reflects current
practice.
* The "ORGANIZER" can not be delegated to another calendar user. In
order to
change the "Organizer", the original group scheduled calendar component
must
be CANCELled and another event or to-do must be scheduled. This will
simplify the interoperability specification and reflects current
practice;
* Examples changed to reflect these modifications.
The iMIP draft is proposed to be modified as follows:
* In cases where strong authentication is used, the signature is always
of
the sender of the iMIP message. Hence, when sent by a calendar user
acting
on behalf of the "Organizer" or "Attendee" (eg,
"ORGANIZER;SENT-BY="maitto:susan@host.com": mailto:bill@ host.com" or
"ATTENDEE; REPLY=DECLINE;SENT-BY= "mail-to:
susan@host.com":mailto:bill@host.com";), the iMIP message is signed not
by
the "Organizer" or "Attendee", but by the calendar user specified in the
"SENT-BY" parameter.
* Examples changed to reflect these modifications.
An example in the old specification:
ATTENDEE;RSVP=TRUE;ROLE=ATTENDEE:frank@host.com
ATTENDEE;ROLE=ORGANIZER:susan@host.com
ATTENDEE;ROLE=OWNER:steve@host.com
Will become:
ATTENDEE;RSVP=TRUE;ROLE=PARTICIPANT:frank@host.com
ATTENDEE;ROLE=CHAIR;steve@host.com
ORGANIZER:susan@host.com
- - Frank Dawson