<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC5545 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5545.xml">
<!ENTITY RFC5988 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.xml">
<!ENTITY W3C.REC-xml-20060816 SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-20060816.xml">
<!ENTITY W3C.WD-xptr-xpointer-20021219 SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.WD-xptr-xpointer-20021219.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="5"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-douglass-link-extension-01" ipr="trust200902">

  <front>
    <title abbrev="Link Extension to Icalendar">Link Extension to Icalendar</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <author initials="M." surname="Douglass" fullname="Michael Douglass">
      <organization abbrev="RPI">Rensselaer Polytechnic Institute</organization>
      <address>
        <postal>
          <street>110 8th Street</street>
          <city>Troy</city>
          <region>NY</region>
          <code>12180</code>
          <country>USA</country>
        </postal>
        <email>douglm@rpi.edu</email>
        <uri>http://www.rpi.edu/</uri>
      </address>
    </author>

    <date year="2011" />

    <area>Applications</area>

    <keyword>icalendar</keyword>

    <keyword>link</keyword>

    <abstract>
      <t>
        This specification introduces new iCalendar
        property LINK to provide ancillary information for iCalendar
        components and changes RELATED-TO to define temporal relationships.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        The currently existing iCalendar standard <xref target='RFC5545'/> lacks
        a general purpose method for referencing additional, external information
        relating to calendar components.
      </t>

      <t>
        This document proposes a method for referencing typed external
        information that can provide additional information about an iCalendar
        component. This new LINK property is closely aligned to the LINK header 
        defined in 
        <xref target='RFC5988'/>
      </t>

      <t>
        In addition the RELTYPE parameter is extended to take new values 
        defining temporal relationships, a GAP parameter is defined to provide
        lead and lag values and RELATED-TO is extended to allow URI values.
        These changes allows the RELATED-TO property to define a richer set of
        relationships useful for project management.
      </t>

      <section anchor="conventions" title='Conventions Used in This Document'>
        <t>
          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 <xref target='RFC2119'/>.
        </t>
      </section>
    </section>

    <section anchor="typed_references"
             title="Typed References">
      <t>
        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. 
      </t>

      <t>
        It is often necessary to relate calendar components. The current
        RELATED-TO property only allows for a UID which is inadequate for many
        purposes. Allowing other types may help but might raise a number of 
        backward compatibility issues. The link property can link components 
        in different collections or even on different servers.
      </t>

      <t>
        When publishing events it is useful to be able to refer back to the 
        source of that information. The actual event may have been consumed from 
        a feed or an ics file on a web site. A LINK property can provide
        a reference to the originator of the event.
      </t>

      <t>
        Project management tools often need to be able to specify the relationships
        between the various events and tasks which make up a project. This 
        specification defines relation types for those purposes.
      </t>
    </section>

    <section anchor="reference_types"
             title="Reference Types">
      <t>
        The actual reference value can take three forms specified by the type
        parameter
        <list style='hanging'>
          <t hangText="URI:">
            The default type. This is a URI referring to the target.
          </t>
          <t hangText="UID:">
            This allows for linking within a single collection and the value is
            assumed to be another component within that collection.
          </t>
          <t hangText="REFERENCE:">
            An xpointer. In an XML environment it may be necessary to refer to
            an external XML artifact. The XPointer is defined in 
            <xref target='W3C.WD-xptr-xpointer-20021219'/> and allows
            addressing portions of XML documents.
          </t>
        </list>
      </t>
    </section>

    <section anchor="link_relation_types"
             title="Link Relation Types">
      <t>
        <xref target='RFC5988'/> defines two form of relation types, registered
        and extension. Registered relation types are added to a registry defined 
        by <xref target='RFC5988'/> while extension relation types are specified 
        as unique unregistered URIs, (at least unregistered in the 
        <xref target='RFC5988'/> registry). 
      </t>
      
      <t>
        The relation types defined here will be registered with IANA in 
        accordance with the specifications in  <xref target='RFC5988'/>.
      </t>
    </section>

    <section anchor="redefined_relation_type_value"
             title="Redefined Relation Type Value">
      <t>
        Relationship parameter type values are defined in section 3.2.15. of 
        <xref target='RFC5545'/>. This specification redefines that type to 
        include the new values FINISHTOSTART, FINISHTOFINISH, 
        STARTTOFINISH and STARTTOSTART.
      </t>

      <t>
        <list style='hanging'>
          <t hangText="Format Definition:">
            <figure>
              <preamble>
                 This property parameter is defined by the following notation:
              </preamble>
    
              <artwork type="abnf">
       reltypeparam       = "RELTYPE" "="
                           ("PARENT"    ; Parent relationship - Default
                          / "CHILD"     ; Child relationship
                          / "SIBLING"   ; Sibling relationship
                          / "FINISHTOSTART"
                          / "FINISHTOFINISH"
                          / "STARTTOFINISH"
                          / "STARTTOSTART"
                          / iana-token  ; Some other IANA-registered
                                        ; iCalendar relationship type
                          / x-name)     ; A non-standard, experimental
                                        ; relationship type
              </artwork>
            </figure>
          </t>
                  
          <t hangText="Description:">
            This parameter can be specified on a property that
            references another related calendar. The parameter may specify the
            hierarchical relationship type of the calendar component
            referenced by the property when the value is PARENT, CHILD or SIBLING.
            It defines the temporal relationship when the value is one of 
            FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART. 
            If this parameter is not specified on an
            allowable property, the default relationship type is PARENT.
            Applications MUST treat x-name and iana-token values they don't
            recognize the same way as they would the PARENT value.
          </t>
  
          <t hangText="RELTYPE=PARENT:">
            Identifies the referenced calendar component is a superior of
            calendar component
          </t>
  
          <t hangText="RELTYPE=CHILD:">
            Indicates that the referenced calendar component is a subordinate of the 
            calendar component.
          </t>
  
          <t hangText="RELTYPE=SIBLING:">
            Indicates that the referenced 
            calendar component is a peer of the calendar component. 
          </t>
          
          <t hangText="RELTYPE=FINISHTOSTART:">
            As soon as the Predecessor Interval finishes, the Successor 
            Interval starts. For example, when sanding is complete, painting begins.
          </t>
  
          <t hangText="RELTYPE=FINISHTOFINISH:">
            The Successor Interval continues as long as the Predecessor Interval.
            For example, the concession stand stops serving 20 minutes after the 
            end of the game.
          </t>
  
          <t hangText="RELTYPE=STARTTOFINISH:">
            The start of the Predecessor controls the finish of the Successor.
            For example, the start of Attendee Check-in controls the end of the 
            interval "Set up registration booth."
          </t>
  
          <t hangText="RELTYPE=STARTTOSTART:">
            The Predecessor Interval triggers the start of the second task. 
            The Gap indicates the lag time. For example, 20 minutes after the 
            caterer begins work, the dining lines are open.          
          </t>
        </list>
      </t>
    </section>

    <section anchor="new_property_parameters"
             title="New Property Parameters">
      <section anchor="rel"
               title="Rel">
        <t>
          <list style='hanging'>
            <t hangText="Parameter name:">
              REL
            </t>
  
            <t hangText="Purpose:">
              To specify the relationship of data referenced by a LINK property.
            </t>
  
            <t hangText="Format Definition:">
              <figure>
                <preamble>
                  This parameter is defined by the following notation:
                </preamble>
  
                <artwork type="abnf">
  relparam      = "REL" "="
                  ("SOURCE"      ; Link to source of this component 
                 / DQUOTE uri DQUOTE                   
                 / x-name        ; Experimental reference type
                 / iana-token)   ; Other IANA registered type
                </artwork>
              </figure>
            </t>
                    
            <t hangText="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.  In addition
              to the values defined here any value defined in <xref target='RFC5988'/>
              may be used. There is no default relation type.
            </t>
  
            <t hangText="REL=SOURCE:">
              identifies the source of the event information.
            </t>
  
            <t hangText="Registration:">
              These relation types are registered in <xref target='RFC5988'/>
            </t>
          </list>
        </t>
      </section>
      
      <section anchor="Gap"
               title="Gap">
        <t>
          <list style='hanging'>
            <t hangText="Parameter name:">
              GAP
            </t>
  
            <t hangText="Purpose:">
              To specify the length of the gap, positive or negative between two
              temporally related components.
            </t>
  
            <t hangText="Format Definition:">
              <figure>
                <preamble>
                  This parameter is defined by the following notation:
                </preamble>
  
                <artwork type="abnf">
  gapparam      = "GAP" "=" dur-value
                </artwork>
              </figure>
            </t>
                    
            <t hangText="Description:">
              This parameter MAY be specified on the RELATED-TO property, and
              defines the duration of time between the predecessor and successor
              in an interval.
            </t>
          </list>
        </t>
      </section>
      
      <section anchor="Title"
               title="Title">
        <t>
          <list style='hanging'>
            <t hangText="Parameter name:">
              TITLE
            </t>
  
            <t hangText="Purpose:">
              To provide a human readable title.
            </t>
  
            <t hangText="Format Definition:">
              <figure>
                <preamble>
                  This parameter is defined by the following notation:
                </preamble>
  
                <artwork type="abnf">
  titleparam     = "TITLE" "=" text
                </artwork>
              </figure>
            </t>
  
            <t hangText="Description:">
              This parameter MAY be specified on all LINK properties, and
              provides a human readable label, perhaps for icons or links..
            </t>
          </list>
        </t>
      </section>
    </section>

    <section anchor="new_parameter_values"
             title="New Parameter Values">
      <t>
        This specification defines a new value to be used with the VALUE
        property parameter:
        
        <list style='hanging'>
          <t hangText="UID">
            VALUE=UID indicates that the associated value is the UID for a 
            component.
          </t>
          
          <t hangText="REFERENCE">
            VALUE=REFERENCE indicates that the associated value is an xpointer
            referencing an associated XML artifact.
          </t>
        </list>
      </t>
    </section>

    <section anchor="new_properties"
             title="New Properties">
      <section anchor="link"
               title="Link">
        <t>
          <list style='hanging'>
            <t hangText="Property name:">
              LINK
            </t>
  
            <t hangText="Purpose:">
              This property provides a reference to external information about a
              component.
            </t>
  
            <t hangText="Value type:">
              URI, TEXT or REFERENCE
            </t>
  
            <t hangText="Property Parameters:">
              Non-standard, reference type or format type parameters can be
              specified on this property.
            </t>
  
            <t hangText="Conformance:">
              This property MAY be specified in any iCalendar component.
            </t>
  
            <t hangText="Description:">
              When used in a component the value of this property points to
              additional information related to the component. For example,
              it may reference the originating web server.
            </t>
  
            <t hangText="Format Definition:">
              <figure>
                <preamble>
                  This property is defined by the following notation:
                </preamble>
  
                <artwork>
  link            = "LINK" linkparam ":" ( ":" uri ) /
                    (
                      ";" "VALUE" "=" "REFERENCE"
                      ":" text
                    )
                    CRLF


  linkparam       = *(

                  ; the following is MANDATORY
                  ; and MAY occur more than once

                  (";" relparam) /

                  ; the following are MANDATORY
                  ; but MUST NOT occur more than once

                  (";" gapparam) /
                  (";" fmttypeparam) /
                  (";" titleparam) /

                  ; the following is OPTIONAL
                  ; and MAY occur more than once

                  (";" xparam)

                  )

                </artwork>
              </figure>
            </t>
  
            <t hangText="Example:">
              <figure>
                <preamble>
                  The following is an example of this property. It points to a
                  server acting as the source for the event.
                </preamble>
  
                <artwork>
                 LINK;REL=SOURCE;TITLE=The Egg:
                   http://example.com/events
                </artwork>
              </figure>
            </t>
          </list>
        </t>
      </section>
    </section>

    <section anchor="redefined_property_related_to"
             title="Redefined RELATED-TO Property">
      <section anchor="related-to"
               title="RELATED-TO">
        <t>
          <list style='hanging'>
            <t hangText="Property name:">
              RELATED-TO
            </t>
  
            <t hangText="Purpose:">
              This property is used to represent a relationship or
              reference between one calendar component and another. The definition
              here extends the definition in Section 3.8.4.5. of 
              <xref target='RFC5545'/> by allowing URI values adn a GAP parameter.
            </t>
  
            <t hangText="Value type:">
              URI or TEXT
            </t>
  
            <t hangText="Property Parameters:">
              Non-standard, reference type, gap, value or format type parameters can be
              specified on this property.
            </t>
  
            <t hangText="Conformance:">
              This property MAY be specified in any iCalendar component.
            </t>
  
            <t hangText="Description:">
              By default or when VALUE=UID is specified, the property value 
              consists of the persistent, globally
              unique identifier of another calendar component.  This value would
              be represented in a calendar component by the "UID" property.
            </t>

            <t>
              By default, the property value points to another calendar
              component that has a PARENT relationship to the referencing
              object.  The "RELTYPE" property parameter is used to either
              explicitly state the default PARENT relationship type to the
              referenced calendar component or to override the default PARENT
              relationship type and specify either a CHILD or SIBLING
              relationship or a temporal relationship.  
            </t>

            <t>
              The PARENT relationship indicates that the calendar
              component is a subordinate of the referenced calendar component.
              The CHILD relationship indicates that the calendar component is a
              superior of the referenced calendar component.  The SIBLING
              relationship indicates that the calendar component is a peer of
              the referenced calendar component.
            </t>

            <t>
              The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART
              relationships define temporal relationships as specified in the 
              reltype parameter definition.
            </t>

            <t>
              Changes to a calendar component referenced by this property can
              have an implicit impact on the related calendar component.  For
              example, if a group event changes its start or end date or time,
              then the related, dependent events will need to have their start
              and end dates changed in a corresponding way.  Similarly, if a
              PARENT calendar component is cancelled or deleted, then there is
              an implied impact to the related CHILD calendar components.  This
              property is intended only to provide information on the
              relationship of calendar components.  It is up to the target
              calendar system to maintain any property implications of this
              relationship.
            </t>
  
            <t hangText="Format Definition:">
              <figure>
                <preamble>
                  This property is defined by the following notation:
                </preamble>
  
                <artwork>
   related    = "RELATED-TO" relparam ( ":" text ) /
                (
                  ";" "VALUE" "=" "UID"
                  ":" uid
                )
                (
                  ";" "VALUE" "=" "URI"
                  ":" uri
                )
                CRLF

   relparam   = *(
              ;
              ; The following are OPTIONAL,
              ; but MUST NOT occur more than once.
              ;
              (";" reltypeparam) /
              (";" gapparam) /
              ;
              ; The following is OPTIONAL,
              ; and MAY occur more than once.
              ;
              (";" other-param)
              ;
              )
                </artwork>
              </figure>
            </t>
  
            <t hangText="Example:">
              <figure>
                <preamble>
                  The following are examples of this property.
                </preamble>
  
                <artwork>
       RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com

       RELATED-TO:19960401-080045-4000F192713-0052@example.com

       RELATED-TO;VALUE=URI;RELTYPE=STARTTOFINISH:
        http://example.com/caldav/user/jb/cal/
        19960401-080045-4000F192713.ics
                </artwork>
              </figure>
            </t>
          </list>
        </t>
      </section>
    </section>

    <section title='Security Considerations'>
      <t>
       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. 
      </t>
    </section>

    <section anchor="iana_considerations" title='IANA Considerations'>

      <!--
      <section anchor="new_rel_registration"
               title="New Reference Type Registration">
        <t>
          This section defines the process to register new or modified
          reference types with IANA.
        </t>

        <section anchor="reftype_registration_procedure"
                 title="Reference Type Registration Procedure">
          <t>
            The IETF will create a mailing list,
            <eref target="mailto:icalreference@ietf.org">icalreference@ietf.org</eref>,
            which can be used for public discussion of reference type
            proposals prior to registration. Use of the mailing list
            is strongly encouraged. The IESG will appoint a designated
            expert who will monitor the
            <eref target="mailto:icalreference@ietf.org">icalreference@ietf.org</eref>
            mailing list and review registrations.
          </t>

          <t>
            Registration of new reference types MUST be reviewed by
            the designated expert and published in an RFC. A Standard
            Tracks RFC is REQUIRED for the registration of reference types.
            A Standard Tracks RFC is also REQUIRED for changes to reference types 
            previously documented in a Standard Tracks RFC.
          </t>

          <t>
            The registration procedure begins when a completed registration
            template, defined in the sections below, is sent to
            <eref target="mailto:icalreference@ietf.org">icalreference@ietf.org</eref>
            and
            <eref target="mailto:iana@iana.org">iana@iana.org</eref>.
            The designated expert is expected to tell IANA and the submitter
            of the registration within two weeks whether the registration
            is approved, approved with minor changes, or rejected with
            cause.  When a registration is rejected with cause, it can be
            re-submitted if the concerns listed in the cause are addressed.
            Decisions made by the designated expert can be appealed to the
            IESG Applications Area Director, then to the IESG. They follow
            the normal appeals procedure for IESG decisions.
          </t>
        </section>

        <section anchor="registration_template_for_reference_types"
                 title="Registration Template for Reference Types" >
          <t>
            A reference type is defined by completing the following template.
            <list style="hanging">
              <t hangText="Reference Type Name:">
                The name of the reference type.
              </t>
              <t hangText="Purpose:">
                The purpose of the reference type.
                Give a short but clear description.
              </t>

              <t hangText="Description:">
                Any special notes about the reference type, how it is to be used,
                etc.
              </t>
              <t hangText="Example(s):">
                One or more examples of use of the use of the reference type.
              </t>
            </list>
          </t>
        </section>
      </section>

      <section anchor="initial_relation_type_registries"
               title="Initial Relation Type Registries" >
        <t>
          The IANA is requested to create and maintain the following
          registries for reference types with pointers to
          appropriate reference documents.
        </t>

        <section anchor="reference_types_registry"
                 title="Reference Types Registry">
          <t>
            The following table is to be used to initialize the
            reference types registry.
          </t>
          <texttable>
            <ttcol align="left">Name</ttcol>
            <ttcol align="left">Status</ttcol>
            <ttcol align="left">Reference</ttcol>

            <c>AUDIO</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="reference_type_audio"/></c>

            <c>CONTACT</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="reference_type_contact"/></c>

            <c>LOCATION</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="reference_type_location"/></c>

            <c>ORGANIZEDBY</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="reference_type_organizedby"/></c>

            <c>PERFORMER</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="reference_type_performer"/></c>

            <c>PRINCIPAL_PERFORMER</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="reference_type_principal_performer"/></c>

            <c>SPONSOR</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="reference_type_sponsor"/></c>

            <c>VIDEO</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="reference_type_video"/></c>
          </texttable>
        </section>
      </section> -->
    </section>

    <section title="Acknowledgements">
      <t>
        The author would like to thank Chuck Norris of eventful.com for his work 
        which led to the development of this RFC.  
      </t>
      <t>
        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:
      </t>
      <t>
        Cyrus Daboo, Dan Mendell
      </t>
      <t>
        The authors would also like to thank the Calendaring and
        Scheduling Consortium for advice with this specification.
      </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      &RFC2119;
      &RFC5545;
      &RFC5988;
      &RFC3688;
      &RFC3986;
      &W3C.REC-xml-20060816;
      &W3C.WD-xptr-xpointer-20021219;
    </references>

    <!-- Change Log

v00 2007-10-19  MD    Initial version
                      -->
  </back>
</rfc>

