[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Access Rights According to CSA
Maybe I am wrong, but isn't this discussion a little premature. We have
not defined any of the basic architecture for Calendaring, but we are
discussing how to describe the access permissions via an undetermined
protocol.
Darren
>----------
>From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com]
>Sent: Monday, July 29, 1996 2:24 pm
>To: ietf-calendar
>Subject: Access Rights According to CSA
>
>Folks, health warning...long note:
>
>Since I haven't formatted the XAPIA CSA document into a I-D like *.txt
>format,
>here is the text from that document on access rights etc.
>
>I don't know how this will format in an email message, so let me describe.
>This
>is the AccessList abstract data type from the CSA specification. I keep
>quoting
>scripture from it because it was defined as a consensus document from input
>from Lotus, WordPerfect, Novell, Microsoft, DAC Associates, IBM, CE Software,
>Campbell Services, Microsystems Software, Attachmate, Arabesque Software, and
>SunSoft. It has been implemented in over four vendor products. Sorry for the
>tendency to reuse. It's just good stuff, built on previous consensus
>
>The access list in the CSA is a linked list of a two-tuple of the calendar
>user
>and a mask of access rights. This access list is defined on a calendar basis
>for determining access privileges to the calendar container by a number of
>external users. The highest access right is the rights equivalent to the
>calendar owner. Remember these are the access rights given an external user.
>The individual objects or entries in a calendar have classifications that
>match
>the basic three levels made use of here (ie, PUBLIC, PRIVATE, and
>CONFIDENTIAL). I think that this meets the requirements indicated in the
>notes
>so far.
>
>Here is the descriptive prose that describes a very good model for access
>control (page 11-12, CSA):
>The accessibility of a calendar to an individual user can be controlled by
>the
>access rights given that user. Access rights are paired with a calendar
>user.
>A calendar user can be an individual, group or resource. The access rights
>are
>maintained in an access list. The access list is a particular calendar
>attribute. The access rights are individually controlled and can be
>accumulated to define a range of accessibility of a user to a calendar and
>its
>entries. The access rights can also be specified in terms of one of three
>access roles. These include the role of the owner of a calendar, the
>organizer
>of a particular entry within the calendar, and the sponsor of a particular
>entry within the calendar. The owner role permits the user to do anything to
>the calendar or calendar entries that the owner of the calendar can do. This
>includes deleting the calendar, viewing, inserting, and changing calendar
>attributes, adding and deleting calendar entries, and viewing, inserting, and
>changing entry attributes. The organizer role permits the user to delete the
>entry or view and change entry attributes for those calendar entries which
>the
>user is specified as the organizer. The organizer defaults to the calendar
>user that created the entry. The sponsor role permits the user to delete the
>entry or view and change entry attributes for those calendar entries which
>the
>user is specified as the sponsor. The sponsor is the calendar user that
>effectively owns the calendar event or todo. In addition to these roles, an
>access right can be set to limit access to free time searches, view, insert
>or
>change calendar attributes, or view, insert or change entries; dependent on
>thei
>r classification as public, confidential, or private. The entry
>classification
>acts as a secondary filter on accessibility.
>Here is the definition of the access list abstract data type:
>Access List
>NAME
> Access List - type definition for a list of access rights data value.
>C DECLARATION
> typedef struct CSA_TAG_ACCESS_RIGHTS {
> CSA_calendar_user *user;
> CSA_flags rights;
> struct CSA_TAG_ACCESS_RIGHTS *next;
> } CSA_access_rights, *CSA_access_list;
>DESCRIPTION
>A data value of this data type is used to define the access rights for a list
>of calendar users. An access list is a list of access rights data
>structures.
>The access rights structure consists of the following components:
>1. user - Identifies the calendar user associated with this access entry.
>2. rights - Specifies the access rights for this user to this calendar. The
>defined access rights include:
>CSA_FREE_TIME_SEARCH
>CSA_VIEW_PUBLIC_ENTRIES
>CSA_VIEW_CONFIDENTIAL_ENTRIES
>CSA_VIEW_PRIVATE_ENTRIES
>CSA_INSERT_PUBLIC_ENTRIES
>CSA_INSERT_CONFIDENTIAL_ENTRIES
>CSA_INSERT_PRIVATE_ENTRIES
>CSA_CHANGE_PUBLIC_ENTRIES
>CSA_CHANGE_CONFIDENTIAL_ENTRIES
>CSA_CHANGE_PRIVATE_ENTRIES
>CSA_VIEW_CALENDAR_ATTRIBUTES
>CSA_INSERT_CALENDAR_ATTRIBUTES
>CSA_CHANGE_CALENDAR_ATTRIBUTES
>CSA_ORGANIZER_RIGHTS
>CSA_SPONSOR_RIGHTS
>CSA_OWNER_RIGHTS
>CSA_FREE_TIME_SEACH - When set, implies that the user will be able to access
>the calendar entries for free time search. No access is provided to the
>calendar attributes.
>CSA_VIEW_PUBLIC_ENTRIES, CSA_VIEW_PRIVATE_ENTRIES, and
>CSA_VIEW_CONFIDENTIAL_ENTRIES - When set, gives the user access to list and
>read the calendar entries with an access class of public, private, or
>confidential, respectively. No access is provided to the calendar
>attributes.
>CSA_INSERT_PUBLIC_ENTRIES, CSA_INSERT_PRIVATE_ENTRIES,
>CSA_INSERT_CONFIDENTIAL_ENTRIES - When set, gives the user access to add the
>calendar entries with an access classs of public, private, or confidential,
>respectively. No access is provided to the calendar attributes.
>CSA_CHANGE_PUBLIC_ENTRIES, CSA_CHANGE_PRIVATE_ENTRIES,
>CSA_CHANGE_CONFIDENTIAL_ENTRIES - When set, gives the user access to update,
>and delete the calendar entries with an access classs of public, private, or
>confidential, respectively. No access is provided to the calendar
>attributes.
>CSA_VIEW_CALENDAR_ATTRIBUTES - When set, gives the user access to list and
>read
>the calendar attributes.
>CSA_INSERT_CALENDAR_ATTRIBUTES - When set, gives the user access to add
>calendar attributes.
>CSA_CHANGE_CALENDAR_ATTRIBUTES - When set, gives the user access to update,
>and
>delete the calendar attributes.
>CSA_ORGANIZER_RIGHTS - When set gives the user access rights to read, update,
>or delete the entry attributes for any calendar entry for which the user is
>specified as the organizer.
>CSA_SPONSOR_RIGHTS - When set gives the user the same access to read, update,
>or delete the entry attributes for any calendar entry for which the user is
>specified as the sponsor.
>CSA_OWNER_RIGHTS - When set gives the user the same access rights as the
>owner
>of the calendar. These rights permit the user to read, update, or add either
>the calendar attributes or the calendar entries, regardless of their access
>class.
>The default access rights are implementation specific.
>3. next - Points to the access entry for the next calendar user in this
>access
>list.
>Now, here are the descriptions for the classification options for calendar
>entries:
>Classification
>NAME
> Classification - definition of the classification attribute.
>C DECLARATION
> #define CSA_ENTRY_ATTR_CLASSIFICATION \
> &-//XAPIA/CSA/ENTRYATTR//NONSGML Classification//EN8
>DESCRIPTION
>The access classification for the calendar entry. The default for this
>attribute is CSA_CLASS_PUBLIC. The valid values include:
>CSA_CLASS_PUBLIC
>CSA_CLASS_PRIVATE
>CSA_CLASS_CONFIDENTIAL
>The attribute can be modified by a call to csa_update_entry_attributes().
>Support for this attribute is mandatory for implementations conforming to
>this
>specification.
>This attribute is a CSA_VALUE_UINT32 type of attribute.
>Phewww! I think that's it.
>- - Frank
>