]>
Event Publishing Extensions to IcalendarRensselaer Polytechnic Institute110 8th StreetTroyNY12180USAdouglm@rpi.eduhttp://www.rpi.edu/
Applications
icalendarproperties
This specification introduces a number of new iCalendar properties
which are of particular use for event publishers and in social
networking.
The currently existing iCalendar standard lacks
useful methods for referencing additional, external information
relating to calendar components.
This document defines a number of properties referencing external
information that can provide additional information about an iCalendar
component. The intent is that such information can be automatically
discovered and used by clients. Formats such as VCARD are likely to be
most useful.
In addition a new property is defined to support HTML descriptions.
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 .
The properties defined here can all reference external meta-data which
may be used by applications to
provide enhanced value to users. By providing type information
as parameters, clients and servers are able to discover interesting
references and make use of them, perhaps for indexing or the
presentation of additional related information for the user.
These properties are 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 in the event, for example a school
sports team, and the inactive participants, for example the parents.
The LOCATION property provides only
an unstructured single text value for specifying the location where an event
(or "TODO" item) will occur. This is inadequate for use cases where
structured location information (e.g. address, region, country,
postal code) is required or preferred, and limits widespread adoption of
iCalendar in those settings.
Using STRUCTURED-LOCATION, information about a number of interesting
locations can be communicated, for example, parking, restaurants and
the venue. 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 supplied properties looking for those of particular interest.
The TYPE and FMTTYPE parameters, if supplied, can be used to help the
selection.
Having located such a property, e.g. STRUCTURED-LOCATION with TYPE=PARKING,
the client can use http GET on the supplied URL perhaps with an ACCEPT header set
to specify the desired format. The targeted server SHOULD respond with
a 406 if the resource is not available in the desired format(s).
The main motivation for these properties has been event publication but
there are opportunities for use elsewhere. The following use cases will
describe some possible scenarios.
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 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
reference to the pianist providing vcard information about the performer.
This event would also hold information about parking, local subway stations
and the venue itself. In addition, there will be sponsorship information
for sponsors of the event and perhaps paid sponsorship properties
essentially advertising local establishments.
These properties also provide opportunities for the travel industry.
When booking a flight the SPONSOR property can be used to provide
references to businesses at the airports and to car hire businesses
at the destination.
The embedded location information can guide the traveller at the airport
or to their final destination. The contact information can provide
detailed information about the booking agent, the airlines and car hire
companies and the hotel.
Within a single component we sometimes need to specify which properties
are related to each other and their state. For example, by relating a
STYLED-DESCRIPTION property to the DESCRIPTION property and saving an
indication of state, clients can know if one of them has changed and
notify the user.
This specification defines two new property parameters to enable this
relating of properties, the ID and the HASH.
The ID parameter provides a small integer identifier, unique for each
property on which it is specified.
The HASH parameter has a structured value with parts:
The id of the property to which the current
property is related
The base-64 encoded hashed value of the property to which the current
property is related
Method used to create that hash.
In the example below a STYLED-DESCRIPTION property is related to the
DESCRIPTION property which has an ID value of 2. If the DESCRIPTION
property value is changed then the hash-value stored with the
STYLED-DESCRIPTION will no longer match.
]]>
HASH
To specify the identifier value and hash value and method of
another property.
This parameter can be specified on properties that are
variants of another property and is used to detect
changes in that property to enable the values of all variants to be
kept synchronized.
The text value should be an identifier value which SHOULD be a
value specified on another propety within the component, a hash
value (encoded as a base-64 string), followed by a token describing
the algorithm used to calculate the hash value. Algorithm
names from the IANA Hash Function Textual Names registry [] MUST
be used.
Each element of the value is separated by a single ",",
ID
To uniquely identify a property.
This parameter can be specified on any property. It is used
to uniquely identify the property so it can be related to other
properties within the same component that specify a "HASH"
parameter id-value element matches the "ID" value.
Properties within the same component MUST NOT have an "ID"
parameter with the same value.
LOCTYPE
To specify the type of location.
This parameter MAY be specified on STRUCTURED-LOCATION and
provides a way to differentiate multiple properties. For example,
it allows event producers to provide location information for
the venue and the parking.
Values for this parameter are taken from the values defined in
. New location types SHOULD be
registered in the manner laid down in that specification
PARTTYPE
To specify the type of participant.
This parameter MAY be specified on the PARTICIPANT property, and
defines the type of participation. Allowable values are defined
in .
RESTYPE
To specify the type of resource.
This parameter MAY be specified on STRUCTURED-RESOURCE and
provides a way to differentiate multiple properties.
Values for this parameter are taken from the values defined in
[todo]. New resource types SHOULD be
registered in the manner laid down in that specification
ORDER
To define ordering for the associated property.
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 between 1 and 100 that
quantifies the order. Lower values correspond to a
higher level of ordering, with 1 being the highest.
When the parameter is absent, the default MUST be to interpret the
property instance as being at the lowest level of ordering.
Note that the value of this parameter is to be interpreted only in
relation to values assigned to other correcsponding instances of
the same property in the same entity. A given value, or the
absence of a value, MUST NOT be interpreted on its own.
This parameter MAY be applied to any property that allows multiple
instances.
TITLE
To provide a human readable title.
This parameter MAY be specified on all properties defined in this
specification, and
provides a human readable label, perhaps for icons or links..
PARTICIPANT
This property provides a typed reference to external information
about participants in an event or optionally a plain text typed value.
The default value type for this property is URI. The
value type can also be set to TEXT to indicate plain text
content.
Non-standard, title, parttype, order or format type parameters
can be specified on this property.
This property MAY be specified in any iCalendar component.
When used in a component the value of this property points to
information about an event participant. This is NOT an attendee
in a scheduling sense and the ATTENDEE property may in fact be
specified in addition. Participants in events can be individuals
or organizations, for example a soccer team, the spectators, or
the musicians.
When the ORDER parameter is supplied it defines the ordering of
PARTICIPANT properties with the same value for the TYPE parameter.
STYLED-DESCRIPTION
This property provides a more complete description of the
calendar component than that provided by the "SUMMARY" property.
There is no default value type for this property. The value type
can be set to URI or TEXT. Other text-based value types
can be used when defined in the future. Clients MUST ignore any properties
with value types they do not understand.
IANA, non-standard, hash, id, alternate text
representation, and language property parameters can be specified
on this property.
The property can be specified multiple times in the "VEVENT", "VTODO",
"VJOURNAL", or "VALARM" calendar components.
This property is used in the "VEVENT" and "VTODO" to
capture lengthy textual descriptions associated with the activity.
This property is used in the "VJOURNAL" calendar component to
capture one or more textual journal entries.
This property is used in the "VALARM" calendar component to
capture the display text for a DISPLAY category of alarm, and to
capture the body text for an EMAIL category of alarm.
VALUE=TEXT is used to provide html variants of the plain-text
DESCRIPTION property.
VALUE=URI is used to provide a link to html content which is
expected to be displayed inline as part of the event.
The "HASH" parameter value is calculated from the value of any
"DESCRIPTION" property present in the same component. If no
"DESCRIPTION" is present, then the "HASH" parameter MUST NOT be present.
The intent of this property is limited to providing a styled
version of the DESCRIPTION property. The URL property should be
used to link to websites or other related information.
STRUCTURED-LOCATION
This property provides a typed reference to external information
about the location of an event or optionally a plain text typed value.
There is no default value type for this property. The value type
can be set to URI or TEXT. Other text-based value types
IANA, non-standard, title, loctype or format type parameters can be
specified on this property.
This property MAY be specified zero or more times in any iCalendar
component.
When used in a component the value of this property provides
information about the event venue or of related services such as
parking, dining, stations etc..
STRUCTURED-RESOURCE
This property provides a typed reference to external information
about a resource or optionally a plain text typed value.
The default value type for this property is URI. The
value type can also be set to TEXT to indicate plain text
content.
IANA, non-standard, title, restype or format type parameters can be
specified on this property.
This property MAY be specified zero or more times in any iCalendar
component.
When used in a component the value of this property provides
information about resources used for the event.
This section describes types of participation and provide registered
values for the PARTICPANT property TYPE parameter.
A participant taking an active role - for example a team member.
A particpant taking an inactive part - for example an audience member.
A sponsor of the event. The ORDER parameter may be used with this
participant type to define the relative order of multiple sponsors.
Contact information for the event. The ORDER parameter may be used with this
participant type to define the relative order of multiple contacts.
Contact information for reservations or payment
Contact in case of emergency
Contact for publicity
Contact for the event planner or organizer
A performer - for example the soloist or the accompianist. The
ORDER parameter may be used with this participant type to define
the relative order of multiple sponsors. For example,ORDER=1 could
define the principal performer or soloist.
Speaker at an event
The following are some examples of the use of the properties defined in
this specification. They include additional properties defined in
which includes IMAGE and LIVEFEED.
Applications using these property need to be aware of the risks
entailed in using the URIs provided as values. See [RFC3986] for
a discussion of the security considerations relating to URIs.
This document defines the following new iCalendar properties to be
added to the registry defined in Section 8.2.3 of :
PropertyStatusReferencePARTICIPANTCurrentRFCXXXX, STYLED-DESCRIPTIONCurrentRFCXXXX, STRUCTURED-LOCATIONCurrentRFCXXXX, STRUCTURED-RESOURCECurrentRFCXXXX,
This document defines the following new iCalendar property parameters
to be added to the registry defined in Section 8.2.4 of :
Property ParameterStatusReferenceHASHCurrentRFCXXXX, IDCurrentRFCXXXX, LOCTYPECurrentRFCXXXX, PARTTYPECurrentRFCXXXX, RESTYPECurrentRFCXXXX, ORDERCurrentRFCXXXX, TITLECurrentRFCXXXX,
The following table has been used to initialize the participant
types registry.
Participant TypeStatusReferenceACTIVECurrentRFCXXXX, INACTIVECurrentRFCXXXX, SPONSORCurrentRFCXXXX, CONTACTCurrentRFCXXXX, BOOKING-CONTACTCurrentRFCXXXX, EMERGENCY-CONTACTCurrentRFCXXXX, PUBLICITY-CONTACTCurrentRFCXXXX, PLANNER-CONTACTCurrentRFCXXXX, PERFORMERCurrentRFCXXXX, SPEAKERCurrentRFCXXXX,
The author would like to thank Chuck Norris of eventful.com for his work
which led to the development of this RFC.
The author would also like to thank the members of the Calendaring and
Scheduling Consortium Event Publication technical committee and the following
individuals for contributing their ideas and support:
Cyrus Daboo, John Haug, Dan Mendell, Scott Otis,
The authors would also like to thank the Calendaring and
Scheduling Consortium for advice with this specification.
&RFC2119;
&RFC2434;
&RFC3688;
&RFC3986;
&RFC4589;
&RFC5545;
&W3C.REC-xml-20060816;
&I-D.daboo-icalendar-extensions;
Need to determine what if nay registry of resource tyes already
exists and use that.
v01 2012-11-02 MD
Collapse sections with description of properties and the use cases
into a section with sub-sections.
New section to describe relating properties.
Remove idref and upgrade hash to have the reference
No default value types on properties..
v01 2012-10-18 MD Many changes.
SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT
Add a STRUCTURED-RESOURCE property
STYLED-DESCRIPTION to handle rich text
Much more...
2011-01-07
Remove MEDIA - it's going in the Cyrus RFC
Rename EXTENDED-... to STRUCTURED-...
Add TYPE parameter to SPONSOR
v00 2007-10-19 MD Initial version