© 2011 The Calendaring and Scheduling Consortium, Inc.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) Documents as located at
.
The document came about in an effort to compile, in one location, a common set of terminology with respect to calendaring and scheduling applications and standards. The document incorporates terminology already existing in calendaring standards such as
Some glossary terms may not appear in published standards today. These are common calendaring terms that are included so that everyone refers to components in the same manner.
As new standards evolve, the glossary will serve as a resource for those creating documents so that all the standards share a common set of terms.
Calendaring and scheduling implementers will be able to utilize the glossary to assist them as they read and decipher calendaring standards. Calendaring and scheduling users will be able to use the glossary to help them better understand the terminology deployed by applications written using calendaring standards.
For the purposes of this document, the following terms and definitions apply.
Access control is a system which enables an authority (e.g., user or resource administrator) to control access to different entities in a calendar system. Typically vendors create Preference/Settings options to instantiate access control. Terminology varies considerably across products but broadly speaking access control is usually broken into two areas, read access and write access. Vendor terminology used for read access includes: ‘read’, ‘reviewer’, ‘proxy read’, ‘viewer’, ‘see all’, and ‘see only freebusy’. Vendor terminology for write access includes: ‘write’, ‘editor’, ‘proxy write’, ‘proxy’, ‘manager’, ‘administrator’, ‘designate’, ‘read/create/edit’, ‘make changes’, ‘manage’, and ‘edit’. (Cp.
A list of access control elements that define access control to a particular calendar system entity. See
Information pertaining to access to a resource by the physically disabled. This applies to Location Resources.
All information required to gain access to a resource. It applies to Location Resources.
See
Use of the terms alarm, reminder, alert, and notifications vary by implementation and can represent several things. They can represent a setting applied to an event by which a user indicates they want a ‘notification’ to be triggered to ‘remind’ them about some event or action (cp.
The MIME content type that indicates an iCalendar object expressed in XML.
See
Specifies the participants or non-participants (e.g., room or resources) for an event. This property in iCalendar can contain multiple attributes specifying additional information, i.e., role, participation status, group membership, delegation, etc.
Accept scheduling invitations automatically with no human intervention.
Defines a window of time a resource can be booked for a particular date. That is, what is the earliest and latest opportunity to book a resource for a given date and time.
A standard protocol to allow calendaring and scheduling via extensions to the WebDAV protocol. Defined by two specifications, the first,
A collection of events. Examples include a person’s or group’s schedule, resource availability, and event listings. May also include items such as tasks, journal entries, etc.
See
A calendar collection contains calendar object resources (e.g., VEVENT, VTODO, VJOURNAL, VFREEBUSY, etc.) that represent calendar components within a calendar.
A single object that can be any of the constituent components of a calendar (cp.
A server application that provides calendar user agents access to calendar stores.
A data repository that may contain several calendars as well as properties and components of those calendars. A local calendar store is on the same device as the calendar user agent (CUA). A remote calendar store is not on the same machine/device as the calendar user agent.
A person who accesses or modifies calendar information.
Software with which the calendar user communicates with a calendar service or local calendar store to access calendar information.
Software that gathers calendar data on the Calendar User’s behalf.
The Calendaring and Scheduling Consortium is focused on the interoperable exchange of calendaring and scheduling information between dissimilar programs, platforms, and technologies. The Consortium’s mission is to promote general understanding of and provide mechanisms to allow interoperable calendaring and scheduling methodologies, tools and applications to enter the mainstream of computing.
CalWS-REST is a CalConnect Proposal and CalWS-SOAP will be a parallel CalConnect Proposal which define an API of basic operations which allow creation, retrieval, update and deletion of calendar objects. In addition, query and freebusy operations are defined to allow efficient, partial retrieval of calendar data.
Capacity of a resource, expressed as a numerical quantity. This applies to a Location Resource.
A piece of calendar data such as an event, a task or an alarm. Information about components is stored as properties of those components (cp.
A response sent by a Attendee of an event to the event Organizer to propose a change to the event or task such as the scheduled date/time, list of participants, etc. (cp. “counter offer”).
In common usage ‘delegate’ may mean either a person who acts for someone else (cp.
The attribute in iCalendar that specifies the calendar user(s) to whom a calendar user has delegated participation in an event. The actual attribute name is DELEGATED-TO.
The attribute in iCalendar that specifies the calendar user(s) that have delegated their participation in an event to another calendar user. The actual attribute name is DELEGATED-FROM.
A calendar user authorized to act on behalf of another calendar user. An example of a designate are assistants who schedules meetings for their superior. (Cp.
The DTEND property for a
The DTSTART property for a
A calendar object that is commonly used to represent things that mark time or use time. Examples include meetings, appointments, anniversaries, start times, arrival times, closing times.
A list of free and busy periods for a particular calendar user or resource. Primarily used for scheduling resources or meetings with other people. Time periods may be marked as busy, free, busy-unavailable (sometimes referred to as out of office) and busy-tentative.
The name of Apple, Inc’s desktop calendar user agent. Often used as an abbreviation for the
The Internet Calendaring and Scheduling Core Object Specification. An IETF standard (
According to
An IETF standard (
An IETF Standard (
A draft specification that describes how
A single event of a larger group of events specified as a recurring event (cp.
All information on other resources available as part of a resource.
A general term from common usage to convey a request for an attendee’s participation in an event. In RFC documents the more specific term is request (cp.
From
Maximum number of instances of an event a resource can be scheduled for from a given point in time.
See
An acronym for Multipurpose Internet Mail Extensions, a specification for formatting non-ASCII text message content, including iCalendar data, graphics, audio and video, so that they can be sent over the Internet. MIME is supported by email clients and web browsers (see
An Internet media type, sometimes a Content-type after the name of a header in several protocols whose value is such a type, is a two-part identifier for file formats on the Internet. The identifiers were originally defined in
Number of simultaneous bookings allowed by a resource, during scheduling.
See
A Standards Development Organization primarily focused on web services standards. OASIS and CalConnect have reciprocal memberships for joint work on WS-Calendar.
A calendar user who creates a calendar item, requests free/busy information, or published free/busy information. It is an Organizer who invites Attendees.
A level of importance and/or urgency calendar users can apply to Tasks and Events.
RFCs define the objects and components of their subject which in turn have properties which have values (sometimes referred to as ‘property parameters’ or ‘property attributes’). These “property parameters” contain meta-information about the property or the property value. Property parameters are provided to specify such information as the location of an alternate text representation for a property value, the language of a text property value, the value type of the property value, and other attributes. Throughout this glossary are references to component, property, and attribute following this usage.
Generally, to make calendar information, such as freebusy time, available to a select group or to the public. From the RFC for
This property is used to identify a specific instance of a
An event or task that happens more than once either with a regular interval (ex. daily, weekly, monthly) that can be expressed by a rule or with an explicit series of dates/times.
A broadly used term in multiple RFCs to represent an action. That action may be a query for property values from a client to a server (cp.
See
See
A resource in the scheduling context is any shared entity,that can be scheduled by a calendar user, but does not control its own attendance status. Resources can be of “Location”, “Equipment”, or “Role” type.
Specifies the kind of resource object represented. Some of the possible values are “Location”, “Thing”, or “Group”. Location is used for any physical location resource such as room, building, etc. Thing is used for any physical object that can scheduled like projector, printer, etc. Group is used to specify a group of resources with a specific skill set. For example: drivers, electricians, etc.
Information on the person(s) responsible for the daily upkeep of a resource.
Acceptance or refusal of a meeting request sent to a meeting proposer.
The IETF and other standards bodies use RFCs to define Internet standards. They document most of the protocols, mechanisms, procedures and best practices in use on the Internet
Specifies whether there is an expectation of a reply from a specific calendar user
Briefly the term refers to the process by which organizers and attendees plan events or assign tasks. More specifically the term encompasses the exchange of request/invitations and responses between organizers and attendees of scheduled events, tasks or journal entries.
An attribute that contains contact information for the scheduling approvers, if approval is required.
A representation of an item of work assigned to an individual. In
The MIME content type for encoding iCalendar objects. Example usage includes: email, web pages.
Areas of the Earth that have adopted the same local time. Time zones are generally centered on meridians of a longitude, that is a multiple of 15, thus making neighboring time zones one hour apart. However, the one hour separation is not universal and the shapes of time zones can be quite irregular because they usually follow the boundaries of states, countries or other administrative areas. In
A property of an event that defines whether it will appear free or busy in free/busy time searches.
UTC is designated to be at zero longitude. Also known as Zulu Time (Nato/military designation). Formerly GMT (Greenwich Mean Time) although there is a slight difference. UTC is the basis for all local time offsets. Offsets are either positive or negative. An example is UTC-8 (Pacific Standard Time). Some iCalendar examples:
DTSTART:19970714T133000 ;Local time
DTSTART:19970714T173000Z ;UTC time
DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time zone reference
A VALARM calendar component is a grouping of component properties that is a reminder or alarm for an event or a to-do. For example, it may be used to define a reminder for a pending event or an overdue to-do. VALARMs will thus be included within
A text representation of calendar and scheduling data created by the Versit consortium (also, the vCalendar specification). The
A VEVENT calendar component represents a scheduled amount of time on a calendar. For example, it can be an activity; such as a one-hour long, department meeting from 8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time on an individual calendar. The VEVENT is also the calendar component used to specify an anniversary or daily reminder within a calendar.
A grouping of component properties that represents either a request for free or busy time information, a reply to a request for free or busy time information, or a published set of busy time information.
A VJOURNAL calendar component is a grouping of component properties that represent one or more descriptive text notes associated with a particular calendar date. The
A VTODO calendar component is a grouping of component properties and possibly
An OASIS (Organization for the Advancement of Structured Information Standards) working group tasked with defining a cross-domain standard for passing schedule and interval information between and within services built around CalWS. The product of the working group will be a standard also named “WS-Calendar” (from ). (See
A draft specification that defines an XML representation of iCalendar data.
This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]
This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]
This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK]
This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is “Calendar Access Protocol” (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community.
This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. [STANDARDS-TRACK]
This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the “calendar-access” feature of CalDAV. [STANDARDS-TRACK]
This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]
This document, “iCalendar Message-Based Interoperability Protocol (iMIP)”, specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]