Foreword

This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) Documents as located at

http://www.calconnect.org/documents/disclaimerpublic.pdf.

1.  Terms and definitions

For the purposes of this document, the following terms and definitions apply.

1.1. Access Control

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. Delegate (Clause 1.26) and Designate (Clause 1.29).)

1.2. Access Control List

ACL

A list of access control elements that define access control to a particular calendar system entity. See IETF RFC 3744 for its use in a WebDAV context.

1.3. Accessibility

Information pertaining to access to a resource by the physically disabled. This applies to Location Resources.

1.4. Admittance Info

All information required to gain access to a resource. It applies to Location Resources.

1.5. Agenda

See Calendar (Clause 1.13).

1.6. Alarm

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. VALARM (Clause 1.73) in IETF RFC 5545). They can also be used to designate the type of ‘alert’ that serves as the notification (e.g., email message, audible sound, pop-up window).

[SOURCE: IETF RFC 4791; IETF RFC 5545; IETF RFC 5546]

1.7. Application/calendar + XML

The MIME content type that indicates an iCalendar object expressed in XML.

1.8. Appointment

See Calendar (Clause 1.13).

1.9. Attendee

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.

[SOURCE: IETF RFC 5545]

1.10. Auto schedule

Accept scheduling invitations automatically with no human intervention.

1.11. Booking Window

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.

1.12. CalDAV

A standard protocol to allow calendaring and scheduling via extensions to the WebDAV protocol. Defined by two specifications, the first, IETF RFC 4791, specifies a calendar access protocol that allows Calendar User Agents to access and manage calendar data. The second specification, Internet-Draft draft-desruisseaux-caldav-sched-10, specifies a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the “calendar-auto-schedule” feature of CalDAV.

[SOURCE: IETF RFC 4791; Internet-Draft draft-desruisseaux-caldav-sched-10]

1.13. Calendar

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.

1.14. Calendar Access Rights

See Access Control (Clause 1.1), Access Control List (Clause 1.2), Delegate (Clause 1.26), and Designate (Clause 1.29).

1.15. Calendar Collection

A calendar collection contains calendar object resources (e.g., VEVENT, VTODO, VJOURNAL, VFREEBUSY, etc.) that represent calendar components within a calendar.

[SOURCE: IETF RFC 4791; IETF RFC 5545]

1.16. Calendar Object

A single object that can be any of the constituent components of a calendar (cp. Component (Clause 1.24)).

[SOURCE: IETF RFC 4791]

1.17. Calendar Service

A server application that provides calendar user agents access to calendar stores.

1.18. Calendar Store

CS

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.

[SOURCE: IETF RFC 3283]

1.19. Calendar User

CU

A person who accesses or modifies calendar information.

1.20. Calendar User Agent

CUA

1.21. CalConnect

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.

1.22. CalWS

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.

1.23. Capacity

Capacity of a resource, expressed as a numerical quantity. This applies to a Location Resource.

1.24. Component

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. Property (Clause 1.53)).

[SOURCE: IETF RFC 4791; IETF RFC 5545]

1.25. Counter

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

[SOURCE: IETF RFC 5546]

1.26. Delegate

In common usage ‘delegate’ may mean either a person who acts for someone else (cp. Designate (Clause 1.29)) or refer to the act of appointing someone as a representative. The term has very specific meaning in the iCalendar (Clause 1.35) and iTIP (Clause 1.38) RFCs. In iCalendar, delegate means to specify that another individual, rather than oneself, should attend an event (cp. Delegator (Clause 1.28) and Delegatee (Clause 1.27)). In iTIP, delegate means to assign ownership of a task to another individual.

[SOURCE: IETF RFC 5545; IETF RFC 5546]

1.27. Delegatee

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.

[SOURCE: IETF RFC 5545]

1.28. Delegator

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.

[SOURCE: IETF RFC 5545]

1.29. Designate

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. Access Control (Clause 1.1) and Access Control List (Clause 1.2).)

[SOURCE: IETF RFC 5546]

1.30. DTEND

The DTEND property for a VEVENT (Clause 1.75) calendar component specifies the noninclusive end of the event.

1.31. DTSTART

The DTSTART property for a VEVENT (Clause 1.75) specifies the inclusive start of the event. For recurring (Clause 1.56) events, it also specifies the very first instance in the recurrence set.

1.32. Event

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.

1.33. Freebusy

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.

1.34. iCal

The name of Apple, Inc’s desktop calendar user agent. Often used as an abbreviation for the iCalendar (Clause 1.35) standard.

1.35. iCalendar

The Internet Calendaring and Scheduling Core Object Specification. An IETF standard ( IETF RFC 5545) for a text representation of calendar data. Scheduling operations are specified in IETF RFC 5546.

1.36. IETF

The Internet Engineering Task Force

According to IETF RFC 3935, “The IETF has traditionally been a community for experimentation with things that are not fully understood, standardization of protocols for which some understanding has been reached, and publication of (and refinement of) protocols originally specified outside the IETF process. . . . The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds.”

1.37. iMIP

iCalendar Message-Based Interoperability Protocol

An IETF standard (IETF RFC 6047) that describes how iTIP messages are exchanged via email.

1.38. iTIP

iCalendar Transport-Independent Interoperability Protocol

An IETF Standard ( IETF RFC 5546) that specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems without reference to a specific transport protocol so as to allow multiple methods of communication between systems (see iMIP (Clause 1.37), iSchedule (Clause 1.39)).

1.39. iSchedule

A draft specification that describes how iTIP (Clause 1.38) messages are exchanged via HTTP

[SOURCE: Internet-Draft draft-desruisseaux-ischedule-01]

1.40. Instance

A single event of a larger group of events specified as a recurring event (cp. Recurring (Clause 1.56)).

[SOURCE: IETF RFC 4791; IETF RFC 5545]

1.41. Inventory Info

All information on other resources available as part of a resource.

1.42. Invitation/Invite

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. Request (Clause 1.57)).

1.43. Journal entry

From IETF RFC 5545, one or more descriptive text notes associated with a particular calendar date. Examples of a journal entry include a daily record of a legislative body or a journal entry of individual telephone contacts for the day or an ordered list of accomplishments for the day.

1.44. Maximum Instances

Maximum number of instances of an event a resource can be scheduled for from a given point in time.

1.45. Meeting

See Event (Clause 1.32).

1.46. MIME

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 IETF RFC 2045, IETF RFC 2046, IETF RFC 2047).

1.47. Mime Type

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 IETF RFC 2046 for use in email sent through SMTP, but their use has expanded to other protocols such as HTTP, RTP and SIP and for other uses (e.g., OS-level file type identification for application/file association).

1.48. Multiple Bookings

Number of simultaneous bookings allowed by a resource, during scheduling.

1.49. Notification

See Alarm (Clause 1.6).

1.50. OASIS

Organization for the Advancement of Structured Information Standards

A Standards Development Organization primarily focused on web services standards. OASIS and CalConnect have reciprocal memberships for joint work on WS-Calendar.

[SOURCE: OASIS]

1.51. Organizer

A calendar user who creates a calendar item, requests free/busy information, or published free/busy information. It is an Organizer who invites Attendees.

[SOURCE: IETF RFC 5545]

1.52. Priority

A level of importance and/or urgency calendar users can apply to Tasks and Events.

[SOURCE: IETF RFC 5545]

1.53. Property

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.

[SOURCE: IETF RFC 5545]

1.54. Publish

Generally, to make calendar information, such as freebusy time, available to a select group or to the public. From the RFC for iTIP (Clause 1.38), “The ‘PUBLISH’ method in a ‘VEVENT’ calendar component is an unsolicited posting of an iCalendar object.”

1.55. RECURRENCE-ID

This property is used to identify a specific instance of a recurring (Clause 1.56) VEVENT (Clause 1.75), VTODO (Clause 1.78), or VJOURNAL (Clause 1.77) calendar component.

1.56. Recurring

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.

1.57. Request

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. IETF RFC 4791), a query between a client and a server that results in object creation, modification, or deletion (cp. IETF RFC 4791 and IETF RFC 5545), and it is the name of a method in iTIP that makes “an explicit invitation to one or more attendees” (among other things, cp. IETF RFC 5546).

[SOURCE: IETF RFC 4791; IETF RFC 5545; IETF RFC 5546; Internet-Draft draft-desruisseaux-ischedule-01]

1.58. Reminder

See Alarm (Clause 1.6).

1.59. Repeating

See Recurring (Clause 1.56).

1.60. Resource

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.

1.61. Resource Kind

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.

1.62. Resource Manager Info

Information on the person(s) responsible for the daily upkeep of a resource.

1.63. Response

Acceptance or refusal of a meeting request sent to a meeting proposer.

1.64. RFC

Request for Comments

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

[SOURCE: IETF]

1.65. RSVP

Specifies whether there is an expectation of a reply from a specific calendar user

[SOURCE: IETF RFC 5545]

1.66. Scheduling

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.

1.67. Scheduling Admin Contact Info

An attribute that contains contact information for the scheduling approvers, if approval is required.

1.68. Task

A representation of an item of work assigned to an individual. In IETF RFC 5545, these are “VTODO” calendar components, which are groupings of component properties and possibly “VALARM” calendar components that represent an action-item or assignment.

1.69. Text/calendar

The MIME content type for encoding iCalendar objects. Example usage includes: email, web pages.

1.70. Time Zone

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 IETF RFC 5545, time zones are represented using “VTIMEZONE” calendar components, each with a Time Zone Identifier (TZID) that can be used to tie a particular date and time to a specific timezone.

1.71. Transparency

A property of an event that defines whether it will appear free or busy in free/busy time searches.

1.72. UTC

Coordinated Universal Time

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:

1.73. VALARM

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 VEVENT (Clause 1.75) and VTODO (Clause 1.78) components.

1.74. vCalendar

A text representation of calendar and scheduling data created by the Versit consortium (also, the vCalendar specification). The IETF RFC 5545 iCalendar specification supersedes the work of vCalendar, though VCALENDAR remains as a component type in the IETF RFC 5545 iCalendar specification.

1.75. VEVENT

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.

1.76. VFREEBUSY

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.

1.77. VJOURNAL

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 DTSTART (Clause 1.31) property is used to specify the calendar date with which the journal entry is associated. Examples of a journal entry include a daily record of a legislative body or a journal entry of individual telephone contacts for the day or an ordered list of accomplishments for the day. The VJOURNAL calendar component can also be used to associate a document with a calendar date.

1.78. VTODO

A VTODO calendar component is a grouping of component properties and possibly VALARM (Clause 1.73) calendar components that represent an action-item or assignment. For example, it can be used to represent an item of work assigned to an individual; such as “turn in travel expense today”.

1.79. WS-Calendar

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 http://www.oasis-open.org/committees/workgroup.php?wg_abbrev=ws-calendar). (See CalWS (Clause 1.22).)

1.80. xCal

A draft specification that defines an XML representation of iCalendar data.

[SOURCE: Internet-Draft draft-daboo-et-al-icalendar-in-xml-11]

Bibliography

[1]  IETF RFC 2045, N. FREED and N. BORENSTEIN. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. 1996. RFC Publisher. https://www.rfc-editor.org/info/rfc2045.

[2]  IETF RFC 2046, N. FREED and N. BORENSTEIN. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. 1996. RFC Publisher. https://www.rfc-editor.org/info/rfc2046.

[3]  IETF RFC 2047, K. MOORE. MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. 1996. RFC Publisher. https://www.rfc-editor.org/info/rfc2047.

[4]  IETF RFC 3283, B. MAHONEY, G. BABICS and A. TALER. Guide to Internet Calendaring. 2002. RFC Publisher. https://www.rfc-editor.org/info/rfc3283.

[5]  IETF RFC 3744, G. CLEMM, J. RESCHKE, E. SEDLAR and J. WHITEHEAD. Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol. 2004. RFC Publisher. https://www.rfc-editor.org/info/rfc3744.

[6]  IETF RFC 3935, H. ALVESTRAND. A Mission Statement for the IETF. 2004. RFC Publisher. https://www.rfc-editor.org/info/rfc3935.

[7]  IETF RFC 4791, C. DABOO, B. DESRUISSEAUX and L. DUSSEAULT. Calendaring Extensions to WebDAV (CalDAV). 2007. RFC Publisher. https://www.rfc-editor.org/info/rfc4791.

[8]  IETF RFC 5545, B. DESRUISSEAUX (ed.). Internet Calendaring and Scheduling Core Object Specification (iCalendar). 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5545.

[9]  IETF RFC 5546, C. DABOO (ed.). iCalendar Transport-Independent Interoperability Protocol (iTIP). 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5546.

[10]  IETF RFC 6047, A. MELNIKOV (ed.). iCalendar Message-Based Interoperability Protocol (iMIP). 2010. RFC Publisher. https://www.rfc-editor.org/info/rfc6047.

[11]  Internet-Draft draft-desruisseaux-caldav-sched-10, CYRUS DABOO and BERNARD DESRUISSEAUX. CalDAV Scheduling Extensions to WebDAV. 2011. https://datatracker.ietf.org/doc/html/draft-desruisseaux-caldav-sched-10.

[12]  Internet-Draft draft-daboo-et-al-icalendar-in-xml-11, MIKE DOUGLASS, CYRUS DABOO and STEVEN LEES. xCal: The XML Format for iCalendar. 2011. https://datatracker.ietf.org/doc/html/draft-daboo-et-al-icalendar-in-xml-11.

[13]  Internet-Draft draft-desruisseaux-ischedule-01, CYRUS DABOO and BERNARD DESRUISSEAUX. Internet Calendar Scheduling Protocol (iSchedule). 2010. https://datatracker.ietf.org/doc/html/draft-desruisseaux-ischedule-01.

[14]  IETF, ietf.org

[15]  OASIS, oasis-open.org