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.

Table of Contents

1.  Introduction
    1.1.  Conventions Used in This Document
2.  Typed References
3.  New Property Parameters
    3.1.  Rel
        3.1.1.  Relation Type CAL_CONTACT
        3.1.2.  Relation Type CAL_LOCATION
        3.1.3.  Relation Type CAL_ORGANIZEDBY
        3.1.4.  Relation Type CAL_PERFORMER
        3.1.5.  Relation Type CAL_PRINCIPAL_PERFORMER
        3.1.6.  Relation Type CAL_ACTIVE_PARTICIPANT
        3.1.7.  Relation Type CAL_INACTIVE_PARTICIPANT
        3.1.8.  Relation Type CAL_SPONSOR
        3.1.9.  Relation Type CAL_PRINCIPAL_SPONSOR
        3.1.10.  Relation Type CAL_AUDIO_MEDIA
        3.1.11.  Relation Type CAL_VIDEO_MEDIA
    3.2.  Title
4.  New Properties
    4.1.  Link
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  Normative References
§  Author's Address

1.  Introduction

The currently existing iCalendar standard [RFC5545] (Desruisseaux, B., “Internet Calendaring and Scheduling Core Object Specification (iCalendar),” September 2009.) 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Desruisseaux, B., “Internet Calendaring and Scheduling Core Object Specification (iCalendar),” September 2009.) 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, 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

3.1.  Rel

Parameter name:

REL

Purpose:

To specify the relationship of data referenced by a LINK property.

Format Definition:

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.

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, 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

Description:

This parameter MAY be specified on all LINK properties, and provides a human readable label, perhaps for icons or links..

4.  New Properties

4.1.  Link

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)

                  )

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

Author's Address