Network Working Group M. Douglass
Internet-Draft RPI
Intended status: Standards Track June 30, 2010
Expires: January 1, 2011
Link Extension to Icalendar
draft-douglass-link-extension-00
Abstract
This specification introduces a new iCalendar property LINK to
provide ancillary information for iCalendar components.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 1, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Douglass Expires January 1, 2011 [Page 1]
Internet-Draft Link Extension to Icalendar June 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Typed References . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Property Parameters . . . . . . . . . . . . . . . . . . . 4
3.1. Rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Relation Type CAL_CONTACT . . . . . . . . . . . . . . 5
3.1.2. Relation Type CAL_LOCATION . . . . . . . . . . . . . . 6
3.1.3. Relation Type CAL_ORGANIZEDBY . . . . . . . . . . . . 6
3.1.4. Relation Type CAL_PERFORMER . . . . . . . . . . . . . 6
3.1.5. Relation Type CAL_PRINCIPAL_PERFORMER . . . . . . . . 6
3.1.6. Relation Type CAL_ACTIVE_PARTICIPANT . . . . . . . . . 6
3.1.7. Relation Type CAL_INACTIVE_PARTICIPANT . . . . . . . . 6
3.1.8. Relation Type CAL_SPONSOR . . . . . . . . . . . . . . 7
3.1.9. Relation Type CAL_PRINCIPAL_SPONSOR . . . . . . . . . 7
3.1.10. Relation Type CAL_AUDIO_MEDIA . . . . . . . . . . . . 7
3.1.11. Relation Type CAL_VIDEO_MEDIA . . . . . . . . . . . . 7
3.2. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. New Properties . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Douglass Expires January 1, 2011 [Page 2]
Internet-Draft Link Extension to Icalendar June 2010
1. Introduction
The currently existing iCalendar standard [RFC5545] lacks a general
purpose method for referencing additional, external information
relating to calendar components.
This document proposes a method for referencing typed external
information that can provide additional information about an
iCalendar component (such as a VCARD). This method is general
purpose and may be used anywhere the need to reference additional
information is desired.
This new LINK property is closely aligned to the LINK header defined
in [TODO draft-nottingham-http-link-header]
1.1. 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
[RFC2119].
2. Typed References
The LINK property defines a typed reference or relation to external
meta-data or related resources. By providing type and format
information as parameters, clients and servers are able to discover
interesting references and make use of them, perhaps for indexing or
the presentation of interesting links for the user.
Many of these relations are designed to handle common use cases in
event publication. It is generally important to provide information
about the organizers of such events. Sponsors also 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.
This property will also allow references to other data that has a
time components. For example, in the power industry it allows the
creation of schedules of power usage linked to related information
about the amount and cost.
For example the [RFC5545] LOCATION property provides only an
unstructured 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,
Douglass Expires January 1, 2011 [Page 3]
Internet-Draft Link Extension to Icalendar June 2010
postal code) is required or preferred, and limits widespread adoption
of iCalendar in those settings.
Using LINK, structured information about the venue such as address,
city, region/state and postal code can be communicated, perhaps using
a VCARD object. Servers and clients can retrieve the vcard object
when storing the event and use it to index by geographic location.
As another example, a calendar item can reference a video feed for
the event. This provides event publishers with a means to attract
consumers to their sites while providing a service directly
accessible from the users' calendar client.
3. New Property Parameters
Parameter name: REL
Purpose: To specify the relationship of data referenced by a LINK
property.
Format Definition:
Douglass Expires January 1, 2011 [Page 4]
Internet-Draft Link Extension to Icalendar June 2010
This parameter is defined by the following notation:
relparam = "REL" "="
("CAL_CONTACT" ; A contact address
"CAL_LOCATION"
; A location reference (a.k.a. "Venue")
"CAL_ORGANIZEDBY"
; An event organizer - NOT a meeting scheduler
"CAL_PERFORMER" ; Performer at an event
"CAL_PRINCIPAL_PERFORMER"
; A principal performer at an event
"CAL_PRINCIPAL_SPONSOR" ; A principal sponsor
"CAL_SPONSOR" ; Sponsor for an event
"CAL_PR_CONTACT" ; Public relations contact
"CAL_ACTIVE_PARTICIPANT" ; e.g. a team,
"CAL_INACTIVE_PARTICIPANT" ; e.g. parents of a team,
"CAL_VIRTUAL_LOCATION" ; A Virtual location
; (a.k.a. "Chatroom")
"CAL_TELECONFERENCE_DIALIN"
"CAL_TICKETING_OFFICE" ; Make reservations
; and/or pay
; Media feeds
"CAL_AUDIO_MEDIA" ; An audio feed
"CAL_SOCIAL_MEDIA" ; Feed other than Audio/Video
"CAL_VIRTUAL_MEDIA" ; A Virtual World Space
/ x-name ; Experimental reference type
/ iana-token) ; Other IANA registered type
Description: This parameter MUST be specified on all LINK
properties, and defines the type of reference. This allows
programs consuming this data to automatically scan for references
they support. For example, a mobile device may be able to consume
LOCATION references, but not other types of reference.
Registration: These relation types are registered in [TODO ref to
draft-nottingham-http-link-header].
3.1.1. Relation Type CAL_CONTACT
This type identifies a contact for the event. An appropriate format
for this reference would be text/vcard allowing clients to display
rich contact information.
Douglass Expires January 1, 2011 [Page 5]
Internet-Draft Link Extension to Icalendar June 2010
3.1.2. Relation Type CAL_LOCATION
This type identifies the location of the event. An appropriate
format for this reference would be text/vcard allowing clients to
display rich location information and possibly link to mapping
applications.
Event consumers can use this reference to index the event by the
geographic location allowing proximity searching.
3.1.3. Relation Type CAL_ORGANIZEDBY
This type identifies an organizer for the event. An appropriate
format for this reference would be text/vcard allowing clients to
display rich information.
This type is distinct from the ORGANIZER property which is only
allowed on scheduling messages. This property allows event
organizers to identify themselves.
3.1.4. Relation Type CAL_PERFORMER
This type identifies a performer for the event. An appropriate
format for this reference would be text/vcard allowing clients to
display rich information about the performer.
This reference allows event consumers to index events by the
performer and may appear once for each performer.
3.1.5. Relation Type CAL_PRINCIPAL_PERFORMER
This type identifies a principal performer for the event. An
appropriate format for this reference would be text/vcard allowing
clients to display rich information about the performer.
This reference allows event consumers to index events by the
principal performer.
3.1.6. Relation Type CAL_ACTIVE_PARTICIPANT
This type identifies an active participant in an event. The form for
this reference could be text/vcard identifying a group such as a team
or an individual.
3.1.7. Relation Type CAL_INACTIVE_PARTICIPANT
This type identifies inactive participants for an event. These are
usually interested parties that may act as spectators, for example,
Douglass Expires January 1, 2011 [Page 6]
Internet-Draft Link Extension to Icalendar June 2010
the parents of team members. The form for this reference could be
text/vcard identifying a group such as a team or an individual.
This reference allows event organizers to notify the participants in
the event of changes.
3.1.8. Relation Type CAL_SPONSOR
This type identifies a sponsor for the event. An appropriate format
for this reference would be text/vcard allowing clients to display
rich information about sponsors or perhaps to insert sponsor logos
where appropriate.
It is assumed that there may be multiple references of this type,
each identifying a different sponsor.
3.1.9. Relation Type CAL_PRINCIPAL_SPONSOR
This type identifies a principal sponsor for the event. An
appropriate format for this reference would be text/vcard allowing
clients to display rich information about sponsors or perhaps to
insert sponsor logos where appropriate.
It is assumed that there may be multiple references of this type,
each identifying a different sponsor.
3.1.10. Relation Type CAL_AUDIO_MEDIA
This type identifies an audio feed associated with the event.
3.1.11. Relation Type CAL_VIDEO_MEDIA
This type identifies a video feed associated with the event.
3.2. Title
Parameter name: TITLE
Purpose: To provide a human readable title.
Format Definition:
This parameter is defined by the following notation:
titleparam = "TITLE" "=" text
Douglass Expires January 1, 2011 [Page 7]
Internet-Draft Link Extension to Icalendar June 2010
Description: This parameter MAY be specified on all LINK properties,
and provides a human readable label, perhaps for icons or links..
4. New Properties
Property name: LINK
Purpose: This property provides a reference to external information
about a component.
Value type: URI
Property Parameters: Non-standard, reference type or format type
parameters can be specified on this property.
Conformance: This property MAY be specified in any iCalendar
component.
Description: When used in a component the value of this property
points to additional information related to the component. For
example, it may reference a VCARD giving detailed information
about the venue of a VEVENT.
Format Definition:
This property is defined by the following notation:
link = "LINK" linkparam ":" uri CRLF
linkparam = *(
; the following are MANDATORY
; but MUST NOT occur more than once
(";" relparam) /
(";" fmttypeparam) /
(";" titleparam) /
; the following is OPTIONAL
; and MAY occur more than once
(";" xparam)
)
Douglass Expires January 1, 2011 [Page 8]
Internet-Draft Link Extension to Icalendar June 2010
Example:
The following is an example of this property. It points to a
VCARD version describing the location of a VEVENT.
LINK;REL=LOCATION;TYPE=text/vcard;
TITLE=The Egg:
http://eventful.com/vcard/venues/V0-001-000361522-8
5. Security Considerations
Applications using the LINK 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.
6. IANA Considerations
7. Acknowledgements
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 public events technical committee and the
following individuals for contributing their ideas and support:
Cyrus Daboo, Dan Mendell
The authors would also like to thank the Calendaring and Scheduling
Consortium for advice with this specification.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Douglass Expires January 1, 2011 [Page 9]
Internet-Draft Link Extension to Icalendar June 2010
Core Object Specification (iCalendar)", RFC 5545,
September 2009.
[W3C.REC-xml-20060816]
Yergeau, F., Paoli, J., Sperberg-McQueen, C., Maler, E.,
and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", World Wide Web Consortium FirstEdition REC-xml-
20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.
Author's Address
Michael Douglass
Rensselaer Polytechnic Institute
110 8th Street
Troy, NY 12180
USA
Email: douglm@rpi.edu
URI: http://www.rpi.edu/
Douglass Expires January 1, 2011 [Page 10]