Event Publishing Extensions to iCalendar
Bedework
226 3rd Street
Troy
NY
12180
United States of America
mdouglass@bedework.com
http://bedework.com
ART
iCalendar
properties
This specification updates RFC 5545 by
introducing a number of new iCalendar
properties and components that are of particular use for event
publishers and in social networking.
This specification also defines a new "STRUCTURED-DATA" property for
iCalendar (RFC 5545) to allow for data that is directly pertinent
to an event or task to be included with the calendar data.
Introduction
The currently existing iCalendar standard lacks
useful methods for referencing additional, external information
relating to calendar components. Additionally, there is no standard
way to provide rich-text descriptions or metadata associated with
the event.
Current practice is to embed this information as links
in the description or to add nonstandard properties, as defined in
.
This document updates to define a
number of properties and components referencing such external
information that can provide additional information about an iCalendar
component. The intent is to allow the interchange of such information between
applications or systems (e.g., between clients, between client and server,
and between servers). Formats, such as vCard ,
are likely to be
most useful to the receivers of such events as they may be used
in other applications -- such as address books.
Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
The notation used in this memo is the ABNF notation of as
used by iCalendar . Any syntax elements shown below that
are not explicitly defined in this specification come from iCalendar .
Terms Used in This Document
- Event:
-
When the word 'event' (perhaps with a capitalized 'E') is used,
we are referring to gatherings, formal or informal (for example,
a sports event, a party, or a concert).
- Social Calendaring:
-
Historically, calendar data and scheduling has been heavily
biased towards meetings in a corporate environment. Some of
the features defined in this document are to support a more
informal, i.e., social, model. For example, we may want to
record who is participating in a public event.
Components and Properties
Previous extensions to the calendaring standards have been largely
restricted to the addition of properties or parameters. This is
partly because iCalendar libraries had trouble handling components
nested deeper than those defined in .
In a break with this 'convention', this specification defines
a number of components rather than properties. This
is a better match for the way
and JSON handle such structures
and allows richer definitions.
It also allows for the addition of extra properties inside the
components and resolves some of the problems of trying to add
detailed information as a parameter.
Typed References
The properties and components defined here can all reference
external metadata, which may be used by applications to
provide further information to users. By providing type information,
clients and servers are able to discover interesting
references and make use of them, perhaps for indexing or
presenting additional, related information for the user.
As always, clients should exercise caution in following
references to external data.
The "LOCATION" property provides only
an unstructured single text value for specifying the location where an event
(or task) will occur. This is inadequate for use cases where
structured location information (e.g., address, region, country, or
postal code) is required or preferred and limits widespread adoption of
iCalendar in those settings.
Using the "VLOCATION" component, rich information about multiple
locations can be communicated in a "STRUCTURED-DATA" property;
examples include address, region,
country, postal code, parking availability, nearby restaurants, and
the venue, among others. Servers and clients can retrieve the objects when
storing the event and use them to index by geographic location.
When a calendar client receives a calendar component, it can search the
set of locations looking for those of particular interest.
The "LOCATION-TYPE" property and "FMTTYPE" parameter applied to the "STRUCTURED-DATA" property, if supplied, can be used to help the selection.
The "PARTICIPANT" component is designed to handle common use cases in
event
publication. It is generally important to provide information
about the organizers of such events. Sponsors wish to be
referenced in a prominent manner. In social calendaring, it is
often important to identify the active participants
(e.g,, a school sports team) and the inactive participants (e.g., the parents) in the event.
The "PARTICIPANT" component can be used to provide useful
extra data about an attendee. For example, a location
inside the PARTICIPANT gives the actual location of a remote
attendee. (But see the note about privacy.)
Alternatively, the "PARTICIPANT" component can be used to provide
a reference -- perhaps the address for mailing lists.
Use Cases
The main motivation for these changes has been event publication, but
there are opportunities for use elsewhere. The following use cases will
describe some possible scenarios.
Piano Concert Performance
In putting together a concert, there are many participants: piano tuner,
performer, stage hands, etc. In addition, there are sponsors and various
contacts to be provided. There will also be a number of related locations.
A number of events can be created, all of
which relate to the performance in different ways.
There may be an iCalendar Transport-independent Interoperability Protocol (iTIP) meeting
request for the piano tuner, who will arrive
before the performance. Other members of staff may also receive meeting
requests.
An event can also be created for publication, which will have a "PARTICIPANT"
component for the pianist providing a reference to vCard information
() about the performer.
This event would also hold information about parking, local subway stations,
and the venue itself. In addition, there may be sponsorship information
for sponsors of the event and perhaps paid sponsorship properties,
essentially advertising local establishments.
Itineraries
These additions also provide opportunities for the travel industry.
When booking a flight, the "PARTICIPANT" component can be used to provide
references to businesses at the airports and to rental car businesses
at the destination.
The embedded location information can guide the traveler around the airport itself
or to their final destination. The contact information can provide
detailed information about the booking agent, airlines, car hire
companies, and hotel.
Reserving Facilities
For a meeting, the size of a room and the equipment needed
depends, to some extent, on the number of attendees actually
in the room.
A meeting may have many attendees, none of which are co-located.
The current "ATTENDEE" property does not allow for the addition
of such metadata. The "PARTICIPANT" component allows attendees to
specify their location.
Modifications to Calendar Components
The following changes to the syntax defined in iCalendar
are made here. New elements are
defined in subsequent sections.
New Property Parameters
Order
- Parameter name:
- ORDER
- Purpose:
- This parameter defines ordering for the associated property.
- Format Definition:
-
This parameter is defined by the following notation:
- Description:
-
The "ORDER" parameter is OPTIONAL and is used to indicate the
relative ordering of the corresponding instance of a property.
Its value MUST be an integer greater than or equal to 1 that
specifies the order, with 1 being the first in the ordering.
When the parameter is absent, the default MUST be to interpret the
property instance as being ordered last, that is,
the property will appear after any other instances of the
same property with any value of ORDER.
When any "ORDER" parameters have the same value, all the associated
properties appear as a group within which there is no
defined order.
Note that the value of this parameter is to be interpreted only in
relation to values assigned to other corresponding instances of
the same property in the same entity.
This parameter MUST NOT be applied to a property that does not
allow multiple instances.
- Example uses:
-
The ORDER may be applied to the "PARTICIPANT-TYPE" property
to indicate the relative importance of the participant, for
example, as a sponsor or a performer. For example, ORDER=1 could
define the principal performer or soloist.
Schema
- Parameter Name:
- SCHEMA
- Purpose:
-
This parameter specifies the schema used for the content of a
"STRUCTURED-DATA" property value.
- Format Definition:
-
This parameter is defined by the following notation:
- Description:
-
This property parameter SHOULD be specified on
"STRUCTURED-DATA" properties. When present, it provides
identifying information about the nature of the content
of the corresponding "STRUCTURED-DATA" property value.
This can be used to supplement the media type information
provided by the "FMTTYPE" parameter on the corresponding
property.
- Example:
-
Derived
- Parameter Name:
- DERIVED
- Purpose:
-
This parameter specifies that the value of the associated property is
derived from some other property value or values.
- Format Definition:
-
This parameter is defined by the following notation:
- Description:
-
This property parameter MAY be specified on any property
when the value is derived from some other property or
properties. When present with a value of TRUE, clients MUST NOT update
the property.
As an example, if a "STYLED-DESCRIPTION" property is present with
FMTTYPE="application/rtf", then there may be an additional
"STYLED-DESCRIPTION" property with FMTTYPE="text/html" and
DERIVED=TRUE, as well as a value created from the rtf value.
- Example:
-
...