From: http://www.ietf.org/internet-drafts/draft-douglass-link-extension-00.txt Title: Link Extension to Icalendar Reference: IETF Network Working Group, Internet Draft 'draft-douglass-link-extension-00' Date: June 30, 2010 HTML: http://tools.ietf.org/id/draft-douglass-link-extension-00.html Data Tracker: https://datatracker.ietf.org/doc/draft-douglass-link-extension/ Tracker Listing: http://ietfreport.isoc.org/idref/draft-douglass-link-extension/ Tools: http://tools.ietf.org/html/draft-douglass-link-extension-00 (HTML) Announced: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg31737.html See also: IETF Calendaring and Scheduling Standards Simplification (CALSIFY) Working Group http://www.ietf.org/html.charters/calsify-charter.html Calendaring and Scheduling Standards Simplification WG Status Pages http://tools.ietf.org/wg/calsify/ List archive for ietf-calsify -- RFC2445, 2446 and 2447 Discusions http://lists.osafoundation.org/pipermail/ietf-calsify/ CalConnect, The Calendaring and Scheduling Consortium http://www.calconnect.org/ ============================================================================== 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 3.1. Rel 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 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) ) 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, . 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]