<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2426 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2426.xml">
  <!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
  <!ENTITY RFC4589 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4589.xml">
  <!ENTITY RFC5545 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5545.xml">
  <!ENTITY RFC5546 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5546.xml">
  <!ENTITY RFC7986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7986.xml">
  <!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
  <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
  <!ENTITY RFC8259 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8259.xml">
  <!ENTITY W3C.REC-html51-20171003 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-html51-20171003.xml">
  <!ENTITY W3C.REC-xml-20081126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-xml-20081126.xml">
]> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" updates="5545" obsoletes=""     docName="draft-ietf-calext-eventpub-extensions-18" ipr="trust200902">
  <?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" ?> number="9073" ipr="trust200902" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true"     tocDepth="5" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Event Publishing Extensions to iCalendar">Event Publishing Extensions to iCalendar</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <seriesInfo name="RFC" value="9073"/>
    <author initials="M." surname="Douglass" fullname="Michael Douglass">
      <organization abbrev="Bedework">Bedework</organization>
      <address>
        <postal>
          <street>226 3rd Street</street>
          <city>Troy</city>
          <region>NY</region>
          <code>12180</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>mdouglass@bedework.com</email>
        <uri>http://bedework.com</uri>
      </address>
    </author>
    <date day='13' month='January' year='2021' /> month="July" year="2021"/>
    <area>Applications</area>
    <keyword>icalendar</keyword>
    <keyword>properties</keyword>
    <abstract>
      <t>
        This specification updates RFC5545 RFC 5545 by
        introducing a number of new iCalendar
        properties and components which that are of particular use for event
        publishers and in social networking.
      </t>
      <t>
        This specification also defines a new STRUCTURED-DATA "STRUCTURED-DATA" property for
        iCalendar RFC5545 (RFC 5545) to allow for data that is directly pertinent
        to an event or task to be included with the calendar data.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The currently existing iCalendar standard <xref target='RFC5545'/> target="RFC5545" format="default"/> lacks
        useful methods for referencing additional, external information
        relating to calendar components. Additionally Additionally, there is no standard
        way to provide rich text rich-text descriptions or meta-data metadata associated with
        the event.
      </t>
      <t>
        Current practice is to embed this information as links
        in the description or to add non-standard properties nonstandard properties, as defined in
        <xref target='RFC5545'/> section 3.8.8.2. target="RFC5545" sectionFormat="of" section="3.8.8.2"/>.
      </t>
      <t>
        This document updates <xref target='RFC5545'/> target="RFC5545" format="default"/> to define a
        number of properties and components referencing such external
        information that can provide additional information about an iCalendar
        component. The intent is to allow the interchange of such information between
        applications or systems (e.g., between clients, between client and  server,
        and between servers). Formats Formats, such as vCard <xref target='RFC2426'/> target="RFC6350" format="default"/>,
        are likely to be
        most useful to the receivers of such events as they may be used
        in other applications - -- such as address books.
      </t>
      <section anchor="conventions" title='Conventions numbered="true" toc="default">
        <name>Conventions Used in This Document'> Document</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
          NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
          "MAY" "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target='RFC2119'/> target="RFC2119"/> <xref target='RFC8174'/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

	<t> The notation used in this memo is the ABNF notation of <xref target="RFC5234"/> as
   used by iCalendar <xref target="RFC5545"/>.  Any syntax elements shown below that
   are not explicitly defined in this specification come from iCalendar <xref target="RFC5545"/>.</t>

      </section>
      <section anchor="terms" title='Terms numbered="true" toc="default">
        <name>Terms Used in This Document'>
        <t>
          <list style='hanging'>
            <t hangText="Event:"> Document</name>
        <dl newline="false" spacing="normal">
          <dt>Event:</dt>
          <dd>
              When the word 'event' (perhaps with a capitalised capitalized 'E') word 'event' is used used,
              we are referring to gatherings, formal or informal. For example informal (for example,
              a sports event, a party party, or a concert.
            </t>
            <t hangText="Social Calendaring:"> concert).
            </dd>
          <dt>Social Calendaring:</dt>
          <dd>
              Historically, calendar data and scheduling has been heavily
              biased towards meetings in a corporate environment. Some of
              the features defined in this document are to support a more
              informal, i.e. i.e., social, model. For example, we may want to
              record who is participating in a public event.
            </t>
          </list>
        </t>
            </dd>
        </dl>
      </section>
    </section>
    <section title="Components numbered="true" toc="default">
      <name>Components and properties"> Properties</name>
      <t>
        Previous extensions to the calendaring standards have been largely
        restricted to the addition of properties or parameters. This is
        partly because iCalendar libraries had trouble handling components
        nested deeper than those defined in <xref target='RFC5545'/>. target="RFC5545" format="default"/>.
      </t>
      <t>
        In a break with this 'tradition' 'convention', this specification defines
        a number of components rather than properties. This
        is a better match for the way <xref target='W3C.REC-xml-20081126'/> target="W3C.REC-xml-20081126" format="default"/>
        and JSON <xref target='RFC8259'/> target="RFC8259" format="default"/> handle such structures
        and allows richer definitions.
      </t>
      <t>
        It also allows for the addition of extra properties inside the
        components and resolves some of the problems of trying to add
        detailed information as a parameter.
      </t>
    </section>
    <section title="Typed References"> numbered="true" toc="default">
      <name>Typed References</name>
      <t>
        The properties and components defined here can all reference
        external meta-data metadata, which may be used by applications to
        provide further information to users. By providing type information,
        clients and servers are able to discover interesting
        references and make use of them, perhaps for indexing or the
        presenting of additional additional, related information for the user.
      </t>
      <t>As always, clients should exercise caution in following
      references to external data.</t>
      <t>
        The <xref target='RFC5545'/> LOCATION "LOCATION" property <xref target="RFC5545" format="default"/> provides only
        an unstructured single text value for specifying the location where an event
        (or task) will occur. This is inadequate for use cases where
        structured location information (e.g. (e.g., address, region, country, or
        postal code) is required or preferred, preferred and limits widespread adoption of
        iCalendar in those settings.
      </t>
      <t>
        Using the VLOCATION "VLOCATION" component, rich information about multiple
        locations can be communicated in a STRUCTURED-DATA property,
        for example, "STRUCTURED-DATA" property;
        examples include address, region,
        country, postal code as well as other information such as code, parking availability, nearby restaurants restaurants, and
        the venue. venue, among others. Servers and clients can retrieve the objects when
        storing the event and use them to index by geographic location.
      </t>
      <t>
        When a calendar client receives a calendar component component, it can search the
        set of locations looking for those of particular interest.

        The LOCATION-TYPE "LOCATION-TYPE" property and STRUCTURED-DATA FMTTYPE parameter, "FMTTYPE" parameter applied to the "STRUCTURED-DATA" property, if supplied, can be used to help the selection.
      </t>
      <t>
        The PARTICIPANT "PARTICIPANT" component is 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 calendaring, it is
        often important to identify the active participants in the event,
        for example
        (e.g,, a school sports team, team) and the inactive participants,
        for example participants (e.g., the parents. parents) in the event.
      </t>
      <t>
        The PARTICIPANT "PARTICIPANT" component can be used to provide useful
        extra data about an attendee. For example example, a location
        inside the PARTICIPANT gives the actual location of a remote
        attendee. (But see the note about privacy.)
      </t>
      <t>
        Alternatively
        Alternatively, the PARTICIPANT "PARTICIPANT" component can be used to provide
        a reference - -- perhaps the address for mailing lists.
      </t>
      <section title="Use Cases"> numbered="true" toc="default">
        <name>Use Cases</name>
        <t>
          The main motivation for these changes has been event publication publication, but
          there are opportunities for use elsewhere. The following use cases will
          describe some possible scenarios.
        </t>
        <section title="Piano numbered="true" toc="default">
          <name>Piano Concert Performance"> Performance</name>
          <t>
            In putting together a concert concert, there are many participants: piano tuner,
            performer, stage hands hands, etc. In addition 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.
          </t>
          <t>
            There may be an iTip iCalendar Transport-independent Interoperability Protocol (iTIP) <xref target='RFC5546'/>
	    target="RFC5546" format="default"/> meeting
            request for the piano tuner tuner, who will arrive
            before the performance. Other members of staff may also receive meeting
            requests.
          </t>
          <t>
            An event can also be created for publication publication, which will have a PARTICIPANT "PARTICIPANT"
            component for the pianist providing a reference to vCard
            <xref target='RFC2426'/> information
            (<xref target="RFC6350" format="default"/>) about the performer.
            This event would also hold information about parking, local subway stations stations,
            and the venue itself. In addition, there may be sponsorship information
            for sponsors of the event and perhaps paid sponsorship properties properties,
            essentially advertising local establishments.
          </t>
        </section>
        <section title="Itineraries"> numbered="true" toc="default">
          <name>Itineraries</name>

          <t>
            These additions also provide opportunities for the travel industry.
            When booking a flight flight, the PARTICIPANT "PARTICIPANT" component can be used to provide
            references to businesses at the airports and to rental car hire businesses
            at the destination.
          </t>
          <t>

            The embedded location information can guide the traveler at around the airport itself
            or to their final destination. The contact information can provide
            detailed information about the booking agent, the airlines, car hire
            companies
            companies, and the hotel.
          </t>
          <section title="Reserving facilities"> numbered="true" toc="default">
            <name>Reserving Facilities</name>
            <t>
              For a meeting, the size of a room and the equipment needed
              depends
              depends, to some extent extent, on the number of attendees actually
              in the room.
            </t>
            <t>
              A meeting may have many attendees attendees, none of which are co-located.
              The current ATTENDEE "ATTENDEE" property does not allow for the addition
              of such meta-data. metadata. The PARTICIPANT "PARTICIPANT" component allows attendees to
              specify their location.
            </t>
          </section>
        </section>
      </section>
    </section>
    <section title="Modifications numbered="true" toc="default">
      <name>Modifications to Calendar Components"> Components</name>
      <t>
        The following changes to the syntax defined in iCalendar
        <xref target='RFC5545'>iCalendar</xref> target="RFC5545" format="default"></xref> are made here. New elements are
        defined in subsequent sections.
      <figure>
        <artwork name="abnf"><![CDATA[
      </t>

<sourcecode type="abnf"><![CDATA[
; Addition of PARTICIPANT, VLOCATION VLOCATION, and VRESOURCE
; as valid components
eventc     = "BEGIN" ":" "VEVENT" CRLF
             eventprop *alarmc *participantc *locationc *resourcec
             "END" ":" "VEVENT" CRLF

; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
eventprop  =/ *styleddescription
              *sdataprop

; Addition of PARTICIPANT, VLOCATION VLOCATION, and VRESOURCE
; as valid components
todoc      = "BEGIN" ":" "VTODO" CRLF
             todoprop *alarmc *participantc *locationc *resourcec
             "END" ":" "VTODO" CRLF

; Addition of properties STYLED-DESCRIPTION, STYLED-DESCRIPTION and STRUCTURED-DATA
todoprop =/ *styleddescription
            *sdataprop

; Addition of PARTICIPANT, VLOCATION VLOCATION, and VRESOURCE
; as valid components
journalc   = "BEGIN" ":" "VJOURNAL" CRLF
             jourprop *participantc *locationc *resourcec
             "END" ":" "VJOURNAL" CRLF

; Addition of properties STYLED-DESCRIPTION, STYLED-DESCRIPTION and STRUCTURED-DATA
jourprop =/ *styleddescription
            *sdataprop

; Addition of PARTICIPANT, VLOCATION VLOCATION, and VRESOURCE
; as valid components
freebusyc  = "BEGIN" ":" "VFREEBUSY" CRLF
             fbprop *participantc *locationc *resourcec
             "END" ":" "VFREEBUSY" CRLF

; Addition of property STYLED-DESCRIPTION
fbprop     =/ *styleddescription

]]></artwork>
        </figure>
      </t>
]]></sourcecode>
    </section>
    <section anchor="new_property_parameters"
             title="New numbered="true" toc="default">
      <name>New Property Parameters"> Parameters</name>
      <section anchor="parameter_order"
               title="Order">
        <t>
          <list style='hanging'>
            <t hangText="Parameter name:">
              ORDER
            </t>

            <t hangText="Purpose:">
              To define numbered="true" toc="default">
        <name>Order</name>
        <dl newline="false" spacing="normal">
          <dt>Parameter name:</dt>
          <dd>ORDER</dd>
          <dt>Purpose:</dt>
          <dd>This parameter defines ordering for the associated property.
            </t> property.</dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This parameter is defined by the following notation:
                </preamble>

                <artwork type="abnf">
            </t>
<sourcecode type="abnf"><![CDATA[
orderparam    = "ORDER" "=" integer
                ;           Must be greater than or equal to 1
                </artwork>
              </figure>
            </t>

            <t hangText="Description:">
              The ORDER
]]></sourcecode>
          </dd>
          <dt>Description:</dt>
          <dd>
              <t>The "ORDER" parameter is OPTIONAL <bcp14>OPTIONAL</bcp14> and is used to indicate the
              relative ordering of the corresponding instance of a property.
              Its value MUST <bcp14>MUST</bcp14> be an integer greater than or equal to 1 that
              specifies the order order, with 1 being the first in the ordering.
            </t>

            <t>
              When ordering.</t>
              <t>When the parameter is absent, the default MUST <bcp14>MUST</bcp14> be to interpret the
              property instance as being ordered last, that is,
              the property will appear after any other instances of the
              same property with any value of ORDER.
            </t>

            <t>
              When ORDER.</t>
              <t>When any ORDER "ORDER" parameters have the same value value, all the associated
              properties appear as a group within which there is no
              defined order.
            </t>

            <t>
              Note order.</t>
              <t>Note that the value of this parameter is to be interpreted only in
              relation to values assigned to other corresponding instances of
              the same property in the same entity.
            </t>

            <t>
              This entity.</t>
              <t>This parameter MUST NOT <bcp14>MUST NOT</bcp14> be applied to a property that does not
              allow multiple instances.
            </t>

            <t hangText="Example uses:"> instances.</t>
            </dd>
          <dt>Example uses:</dt>
          <dd>
              The ORDER may be applied to the PARTICIPANT-TYPE "PARTICIPANT-TYPE" property
              to indicate the relative importance of the participant, for
              example
              example, as a sponsor or a performer.  For example, ORDER=1 could
              define the principal performer or soloist.
            </t>
          </list>
        </t>
            </dd>
        </dl>
      </section>
      <section title="Schema"
               anchor="parameter_schema">
        <t>
          <list style="hanging">
            <t hangText="Parameter Name:">
              SCHEMA
            </t>

            <t hangText="Purpose:">
              To specify anchor="parameter_schema" numbered="true" toc="default">
        <name>Schema</name>
        <dl newline="false" spacing="normal">
          <dt>Parameter Name:</dt>
          <dd>SCHEMA</dd>
          <dt>Purpose:</dt>
          <dd>
              This parameter specifies the schema used for the content of a
              "STRUCTURED-DATA" property value.
            </t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This parameter is defined by the following notation:
                </preamble>

                <artwork name="abnf"><![CDATA[
            </t>
<sourcecode type="abnf"><![CDATA[
schemaparam    = "SCHEMA" "=" DQUOTE uri DQUOTE
]]></artwork>
              </figure>
            </t>

            <t hangText="Description:">
]]></sourcecode>
          </dd>
          <dt>Description:</dt>
          <dd>
              This property parameter SHOULD <bcp14>SHOULD</bcp14> be specified on
              "STRUCTURED-DATA" properties. When present present, it provides
              identifying information about the nature of the content
              of the corresponding "STRUCTURED-DATA" property value.
              This can be used to supplement the media type information
              provided by the "FMTTYPE" parameter on the corresponding
              property.
            </t>

            <t hangText="Example:">
              <figure>
                <artwork><![CDATA[
            </dd>
          <dt>Example:</dt>
          <dd>
<sourcecode type=""><![CDATA[
  STRUCTURED-DATA;FMTTYPE=application/ld+json;
   SCHEMA="https://schema.org/FlightReservation";
   ENCODING=BASE64;VALUE=BINARY:ICAgIDxzY3JpcHQgdHlwZT0iYXBwb
   GljYXRpb24vbGQranNvbiI+CiAgICB7CiAgICAgICJAY29
   udGV4dCI6ICJodHRwOi8vc2NoZW1hLm9yZyIsCiAgICAgICJAdHlwZSI
   6ICJGbGlnaHRSZXNlcnZhdGlvbiIsCiAgICAgICJyZXNlcnZhdGlvbkl
   kIjogIlJYSjM0UCIsCiAgICAgICJyZXNlcnZhdGlvblN0YXR1cyI6ICJ
   odHRwOi8vc2NoZW1hLm9yZy9SZXNlcnZhdGlvbkNvbmZpcm1lZCIsCiA
   gICAgICJwYXNzZW5nZXJQcmlvcml0eVN0YXR1cyI6ICJGYXN0IFRyYWN
   rIiwKICAgICAgInBhc3NlbmdlclNlcXVlbmNlTnVtYmVyIjogIkFCQzE
   yMyIsCiAgICAgICJzZWN1cml0eVNjcmVlbmluZyI6ICJUU0EgUHJlQ2h
   lY2siLAogICAgICAidW5kZXJOYW1lIjogewogICAgICAgICJAdHlwZSI
   6ICJQZXJzb24iLAogICAgICAgICJuYW1lIjogIkV2YSBHcmVlbiIKICA
   gICAgfSwKICAgICAgInJlc2VydmF0aW9uRm9yIjogewogICAgICAgICJ
   AdHlwZSI6ICJGbGlnaHQiLAogICAgICAgICJmbGlnaHROdW1iZXIiOiA
   iVUExMTAiLAogICAgICAgICJwcm92aWRlciI6IHsKICAgICAgICAgICJ
   AdHlwZSI6ICJBaXJsaW5lIiwKICAgICAgICAgICJuYW1lIjogIkNvbnR
   pbmVudGFsIiwKICAgICAgICAgICJpYXRhQ29kZSI6ICJDTyIsCiAgICA
   gICAgICAiYm9hcmRpbmdQb2xpY3kiOiAiaHR0cDovL3NjaGVtYS5vcmc
   vWm9uZUJvYXJkaW5nUG9saWN5IgogICAgICAgIH0sCiAgICAgICAgInN
   lbGxlciI6IHsKICAgICAgICAgICJAdHlwZSI6ICJBaXJsaW5lIiwKICA
   gICAgICAgICJuYW1lIjogIlVuaXRlZCIsCiAgICAgICAgICAiaWF0YUN
   vZGUiOiAiVUEiCiAgICAgICAgfSwKICAgICAgICAiZGVwYXJ0dXJlQWl
   ycG9ydCI6IHsKICAgICAgICAgICJAdHlwZSI6ICJBaXJwb3J0IiwKICA
   gICAgICAgICJuYW1lIjogIlNhbiBGcmFuY2lzY28gQWlycG9ydCIsCiA
   gICAgICAgICAiaWF0YUNvZGUiOiAiU0ZPIgogICAgICAgIH0sCiAgICA
   gICAgImRlcGFydHVyZVRpbWUiOiAiMjAxNy0wMy0wNFQyMDoxNTowMC0
   wODowMCIsCiAgICAgICAgImFycml2YWxBaXJwb3J0IjogewogICAgICA
   gICAgIkB0eXBlIjogIkFpcnBvcnQiLAogICAgICAgICAgIm5hbWUiOiA
   iSm9obiBGLiBLZW5uZWR5IEludGVybmF0aW9uYWwgQWlycG9ydCIsCiA
   gICAgICAgICAiaWF0YUNvZGUiOiAiSkZLIgogICAgICAgIH0sCiAgICA
   gICAgImFycml2YWxUaW1lIjogIjIwMTctMDMtMDVUMDY6MzA6MDAtMDU
   6MDAiCiAgICAgIH0KICAgIH0KICAgIDwvc2NyaXB0Pg==
]]></artwork>
              </figure>
            </t>
          </list>
        </t>
      </section>

      <section title="Derived"
               anchor="parameter_derived">
        <t>
          <list style="hanging">
            <t hangText="Parameter Name:">
              DERIVED
            </t>

            <t hangText="Purpose:">
              To specify
]]></sourcecode>
          </dd>
        </dl>
      </section>
      <section anchor="parameter_derived" numbered="true" toc="default">
        <name>Derived</name>
        <dl newline="false" spacing="normal">
          <dt>Parameter Name:</dt>
          <dd>DERIVED</dd>
          <dt>Purpose:</dt>
          <dd>
              This parameter specifies that the value of the associated property is
              derived from some other property value or values.
            </t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This parameter is defined by the following notation:
                </preamble>

                <artwork name="abnf"><![CDATA[
            </t>
<sourcecode type="abnf"><![CDATA[
derivedparam    = "DERIVED" "=" ("TRUE" / "FALSE")
; Default is FALSE
]]></artwork>
              </figure>
            </t>

            <t hangText="Description:">
              This
]]></sourcecode>
          </dd>
          <dt>Description:</dt>
          <dd>
              <t>This property parameter MAY <bcp14>MAY</bcp14> be specified on any property
              when the value is derived from some other property or
              properties. When present with a value of TRUE TRUE, clients MUST NOT <bcp14>MUST NOT</bcp14> update
              the property.
            </t>

            <t>
              As property.</t>
              <t>As an example, if a STYLED-DESCRIPTION "STYLED-DESCRIPTION" property is present with
              FMTTYPE="application/rtf"
              FMTTYPE="application/rtf", then there may be an additional
              STYLED-DESCRIPTION
              "STYLED-DESCRIPTION" property with FMTTYPE="text/html" and
              DERIVED=TRUE and
              DERIVED=TRUE, as well as a value created from the rtf value.
            </t>

            <t hangText="Example:">
              <figure>
                <artwork><![CDATA[ value.</t>
            </dd>
          <dt>Example:</dt>
          <dd>
<sourcecode type="" ><![CDATA[
STYLED-DESCRIPTION;FMTTYPE=text/html;
 DERIVED=TRUE:<html>...</html>
]]></artwork>
              </figure>
            </t>
          </list>
        </t>
]]></sourcecode>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="new_properties"
             title="New Properties"> numbered="true" toc="default">
      <name>New Properties</name>
      <t>
        This specification makes use of the NAME property "NAME" property,
        which is defined in <xref target='RFC7986'/> target="RFC7986" format="default"/>.
      </t>
      <section anchor="loctype"
               title="Location Type">
        <t>
          <list style='hanging'>
            <t hangText="Property name:">
              LOCATION-TYPE
            </t>

            <t hangText="Purpose:">
              To specify numbered="true" toc="default">
        <name>Location Type</name>
        <dl newline="false" spacing="normal">
          <dt>Property Name:</dt>
          <dd>LOCATION-TYPE</dd>
          <dt>Purpose:</dt>
          <dd>This property specifies the type(s) of a location.
            </t>

            <t hangText="Value type:"> location.</dd>
          <dt>Value Type:</dt>
          <dd>
              The value type for this property is TEXT.  The
              allowable values are defined below.
            </t>

            <t hangText="Description:">
            </dd>
          <dt>Description:</dt>
          <dd>
              This property MAY <bcp14>MAY</bcp14> be specified in VLOCATION "VLOCATION" components and
              provides a way to differentiate multiple locations. For example,
              it allows event producers to provide location information for
              the venue and the parking.
            </t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This property is defined by the following notation:
                </preamble>

                <artwork type="abnf">
            </t>
<sourcecode type="abnf"><![CDATA[
loctype      = "LOCATION-TYPE" loctypeparam ":"
               text *("," text)
               CRLF

loctypeparam   = *(";" other-param)
                </artwork>
              </figure>
            </t>

            <t>
              Multiple
]]></sourcecode>
              <t>Multiple values may be used if the location has multiple
              purposes, for example example, a hotel and a restaurant.
            </t>

            <t>
              Values restaurant.</t>
              <t>Values for this parameter are taken from the values defined in
              <xref target='RFC4589'/> section 3. target="RFC4589" sectionFormat="of" section="3"/>. New location
	      types SHOULD <bcp14>SHOULD</bcp14> be
              registered in the manner laid down in section 5 of that specification.
            </t>
          </list>
        </t> <xref target="RFC4589"
	      sectionFormat="of" section="5"/>.</t>
            </dd>
        </dl>
      </section>
      <section anchor="participant-type"
               title="Participant Type">
        <t>
          <list style='hanging'>
            <t hangText="Property name:">
              PARTICIPANT-TYPE
            </t>

            <t hangText="Purpose:">
              To specify numbered="true" toc="default">
        <name>Participant Type</name>
        <dl newline="false" spacing="normal">
          <dt>Property Name:</dt>
          <dd>PARTICIPANT-TYPE</dd>
          <dt>Purpose:</dt>
          <dd>This property specifies the type of participant.
            </t>

            <t hangText="Value type:"> participant.</dd>
          <dt>Value Type:</dt>
          <dd>
              The value type for this property is TEXT.  The
              allowable values are defined below.
            </t>

            <t hangText="Property Parameters:">
              Non-standard
            </dd>
          <dt>Property Parameters:</dt>
          <dd>
              Nonstandard parameters can be specified on this property.
            </t>

            <t hangText="Conformance:">
            </dd>
          <dt>Conformance:</dt>
          <dd>
              This property MUST <bcp14>MUST</bcp14> be specified once within a PARTICIPANT "PARTICIPANT" component.
            </t>

            <t hangText="Description:">
            </dd>
          <dt>Description:</dt>
          <dd>
              This property defines the type of participation in events
              or tasks. Participants can be individuals
              or organizations, for example example, a soccer team, the spectators, or
              the musicians.
            </t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This property is defined by the following notation:
                </preamble>

                <artwork type="abnf">
            </t>

<sourcecode type="abnf"><![CDATA[
participanttype   = "PARTICIPANT-TYPE" partvalueparam ":"
                     partvalue CRLF

partvalue    = ("ACTIVE"
               / "INACTIVE"
               / "SPONSOR"
               / "CONTACT"
               / "BOOKING-CONTACT"
               / "EMERGENCY-CONTACT"
               / "PUBLICITY-CONTACT"
               / "PLANNER-CONTACT"
               / "PERFORMER"
               / "SPEAKER"
               / iana-token)     ; Other IANA-registered
                                 ; values

partvalueparam   = *(";" other-param)
                </artwork>
              </figure>
            </t>
]]></sourcecode>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t hangText="Example:">
              <figure>
                <preamble> keepWithNext="true">
                  The following is an example of this property:
                </preamble>

                <artwork type="abnf">
   PARTICIPANT-TYPE:SPEAKER
                </artwork>
              </figure>
            </t>
          </list> property.
            </t>
<sourcecode type="abnf"><![CDATA[
PARTICIPANT-TYPE:SPEAKER
]]></sourcecode>
          </dd>
        </dl>
        <t>
          The registered values for the PARTICIPANT-TYPE "PARTICIPANT-TYPE" property have
          the meanings described here:

          <list style='hanging'>
            <t hangText="ACTIVE:" >
              A
        </t>
        <dl newline="false" spacing="normal">
          <dt>ACTIVE:</dt>
          <dd>A participant taking an active role - -- for example example, a team member.
            </t>

            <t hangText="INACTIVE:"> member.</dd>
          <dt>INACTIVE:</dt>
          <dd>
              A participant taking an inactive role - -- for example example, an audience member.
            </t>

            <t hangText="SPONSOR:">
            </dd>
          <dt>SPONSOR:</dt>
          <dd>
              A sponsor of the event. The ORDER "ORDER" parameter may be used with this
              participant type to define the relative order of multiple sponsors.
            </t>
            <t hangText="CONTACT:">
            </dd>
          <dt>CONTACT:</dt>
          <dd>
              Contact information for the event. The ORDER "ORDER" parameter may be used with this
              participant type to define the relative order of multiple contacts.
            </t>

            <t hangText="BOOKING-CONTACT:">
            </dd>
          <dt>BOOKING-CONTACT:</dt>
          <dd>
              Contact information for reservations or payment
            </t>

            <t hangText="EMERGENCY-CONTACT:"> payment.
            </dd>
          <dt>EMERGENCY-CONTACT:</dt>
          <dd>
              Contact in case of emergency
            </t>

            <t hangText="PUBLICITY-CONTACT:"> emergency.
            </dd>
          <dt>PUBLICITY-CONTACT:</dt>
          <dd>
              Contact for publicity
            </t>

            <t hangText="PLANNER-CONTACT:"> publicity.
            </dd>
          <dt>PLANNER-CONTACT:</dt>
          <dd>
              Contact for the event planner or organizer
            </t>

            <t hangText="PERFORMER:"> organizer.
            </dd>
          <dt>PERFORMER:</dt>
          <dd>
              A performer - -- for example example, the soloist or the accompanist.  The
              ORDER
              "ORDER" parameter may be used with this participant type to define
              the relative order of multiple performers. For example, ORDER=1 could
              define the principal performer or soloist.
            </t>

            <t hangText="SPEAKER:">
            </dd>
          <dt>SPEAKER:</dt>
          <dd>
              Speaker at an event
            </t>
          </list>
        </t> event.
            </dd>
        </dl>
      </section>
      <section anchor="restype"
               title="Resource Type">
        <t>
          <list style='hanging'>
            <t hangText="Property name:"> numbered="true" toc="default">
        <name>Resource Type</name>
        <dl newline="false" spacing="normal">
          <dt>Property Name:</dt>
          <dd>
              RESOURCE-TYPE
            </t>

            <t hangText="Purpose:">
              To specify
            </dd>
          <dt>Purpose:</dt>
          <dd>
              This property specifies the type of resource.
            </t>

            <t hangText="Value type:">
            </dd>
          <dt>Value Type:</dt>
          <dd>
              The value type for this property is TEXT.  The
              allowable values are defined below.
            </t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This property is defined by the following notation:
                </preamble>

                <artwork type="abnf">
            </t>
<sourcecode type="abnf"><![CDATA[
restypeprop   = "RESOURCE-TYPE" restypeparam ":"
                restypevalue CRLF

restypevalue  = ("ROOM"
               / "PROJECTOR"
               / "REMOTE-CONFERENCE-AUDIO"
               / "REMOTE-CONFERENCE-VIDEO"
               / iana-token)     ; Other IANA-registered
               ; values

restypeparam   = *(";" other-param)
                </artwork>
              </figure>
            </t>

            <t hangText="Description:">
              This
]]></sourcecode>
          </dd>
          <dt>Description:</dt>
          <dd>
              <t>This property MAY <bcp14>MAY</bcp14> be specified in VRESOURCE "VRESOURCE" components and
              provides a way to differentiate multiple resources.
            </t>

            <t>
              The resources.</t>
              <t>The registered values are described below.
              New resource types SHOULD <bcp14>SHOULD</bcp14> be
              registered in the manner laid down in this specification.
            </t>

            <t hangText="ROOM:" >
              A specification.</t>
            </dd>
          <dt>ROOM:</dt>
          <dd>A room for the event/meeting.
            </t>

            <t hangText="PROJECTOR:">
              Projection equipment.
            </t>

            <t hangText="REMOTE-CONFERENCE-AUDIO:">
              Audio event/meeting.</dd>
          <dt>PROJECTOR:</dt>
          <dd>Projection equipment.</dd>
          <dt>REMOTE-CONFERENCE-AUDIO:</dt>
          <dd>Audio remote conferencing facilities.
            </t>

            <t hangText="REMOTE-CONFERENCE-VIDEO:">
              Video facilities.</dd>
          <dt>REMOTE-CONFERENCE-VIDEO:</dt>
          <dd>Video remote conferencing facilities.
            </t>
          </list>
        </t> facilities.</dd>
        </dl>
      </section>
      <section anchor="calendar-address"
               title="Calendar Address">
        <t>
          <list style='hanging'>
            <t hangText="Property name:"> numbered="true" toc="default">
        <name>Calendar Address</name>
        <dl newline="false" spacing="normal">
          <dt>Property Name:</dt>
          <dd>
              CALENDAR-ADDRESS
            </t>

            <t hangText="Purpose:">
              To specify
            </dd>
          <dt>Purpose:</dt>
          <dd>
              This property specifies the calendar address for a participant.
            </t>

            <t hangText="Value type:">
            </dd>
          <dt>Value Type:</dt>
          <dd>
              CAL-ADDRESS
            </t>

            <t hangText="Property Parameters:">
              IANA-registered,
            </dd>
          <dt>Property Parameters:</dt>
          <dd>
              IANA-registered or non-standard nonstandard property parameters can be
              specified on this property.
            </t>

            <t hangText="Conformance:">
            </dd>
          <dt>Conformance:</dt>
          <dd>
              This property MAY <bcp14>MAY</bcp14> be specified once within a PARTICIPANT "PARTICIPANT" component.
            </t>

            <t hangText="Description:">
            </dd>
          <dt>Description:</dt>
          <dd>
              This property provides a calendar user address for the
              participant. If there is an ATTENDEE "ATTENDEE" property with the same
              value
              value, then the participant is schedulable.
            </t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This property is defined by the following notation:
                </preamble>

                <artwork type="abnf">
            </t>
<sourcecode type="abnf"><![CDATA[
calendaraddress   = "CALENDAR-ADDRESS" caladdressparam ":"
               cal-address CRLF

caladdressparam   = *(";" other-param)
                </artwork>
              </figure>
            </t>
          </list>
        </t>
]]></sourcecode>
          </dd>
        </dl>
      </section>
      <section anchor="styled-description"
               title="Styled-Description">
        <t>
          <list style='hanging'>
            <t hangText="Property name:"> numbered="true" toc="default">
        <name>Styled-Description</name>
        <dl newline="false" spacing="normal">
          <dt>Property Name:</dt>
          <dd>
              STYLED-DESCRIPTION
            </t>

            <t hangText="Purpose:">
            </dd>
          <dt>Purpose:</dt>
          <dd>
              This property provides for one or more rich-text descriptions to
              replace that provided by the DESCRIPTION "DESCRIPTION" property.
            </t>

            <t hangText="Value type:">
            </dd>
          <dt>Value Type:</dt>
          <dd>
              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 <bcp14>MUST</bcp14> ignore any properties
              with value types they do not understand.
            </t>

            <t hangText="Property Parameters:">
            </dd>
          <dt>Property Parameters:</dt>
          <dd>
              IANA-registered, non-standard, nonstandard, id, alternate text
              representation, format type, derived derived, and language property
              parameters can be specified on this property.
            </t>

            <t hangText="Conformance:">
              The
            </dd>
          <dt>Conformance:</dt>
          <dd>
              <t>The property can be specified multiple times in the "VEVENT", "VTODO",
              "VJOURNAL", "VFREEBUSY", "PARTICIPANT", or "VALARM" calendar components.
            </t>

            <t>
              If components.</t>
              <t>If it does appear more than once once, there MUST <bcp14>MUST</bcp14> be exactly one
              instance of the property with no DERIVED "DERIVED" parameter or DERIVED=FALSE.
              All others MUST <bcp14>MUST</bcp14> have DERIVED=TRUE.
            </t>

            <t>
              Additionally, DERIVED=TRUE.</t>
              <t>Additionally, if there is one or more STYLED-DESCRIPTION
              property "STYLED-DESCRIPTION"
              property, then the DESCRIPTION "DESCRIPTION" property should be either be absent
              or have the parameter DERIVED=TRUE.
            </t>

            <t hangText="Description:">
              This DERIVED=TRUE.</t>
            </dd>
          <dt>Description:</dt>
          <dd>
              <t>This property supports rich-text descriptions, for example example, HTML.
              Event publishers typically wish to provide more and better
              formatted better-formatted
	      information about the event.
            </t>

            <t>
              This event.</t>
              <t>This property is used in the "VEVENT" and "VTODO" components 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, alarm and to
              capture the body text for an EMAIL category of alarm.
              In the PARTICIPANT component "PARTICIPANT" component, it provides a detailed description
              of the participant.
            </t>

            <t>
              VALUE=TEXT participant.</t>
              <t>VALUE=TEXT is used to provide rich-text rich text inline as the property
              value.
            </t>

            <t>
              VALUE=URI
              value.</t>
              <t>VALUE=URI is used to provide a link to rich-text content content, which is
              expected to be displayed inline as part of the event.
            </t>

            <t>
              In event.</t>
              <t>In either case case, the DESCRIPTION "DESCRIPTION" property should be absent or
              contain a plain text plain-text rendering of the styled text.
            </t>

            <t>
              Applications MAY text.</t>
              <t>Applications <bcp14>MAY</bcp14> attempt to guess the media type of the
              resource via inspection of its content if and only if the media
              type of the resource is not given by the "FMTTYPE" parameter.  If
              the media type remains unknown, calendar applications SHOULD <bcp14>SHOULD</bcp14> treat
              it as type "text/html" and process the content as defined in
              <xref target='W3C.REC-html51-20171003'/>
            </t>

            <t>
              Multiple STYLED-DESCRIPTION target="W3C.REC-html51-20171003" format="default"/>.</t>
              <t>Multiple "STYLED-DESCRIPTION" properties may be used to provide
              different formats or different language variants. However However,
              all but one MUST <bcp14>MUST</bcp14> have DERIVED=TRUE.
            </t> DERIVED=TRUE.</t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This property is defined by the following notation:
                </preamble>

                <artwork>
            </t>
<sourcecode type="abnf"><![CDATA[
styleddescription = "STYLED-DESCRIPTION" styleddescparam ":"
                   styleddescval CRLF

styleddescparam   = *(
                   ; the elements herein may appear in any order,
                      ; and the order The following is not significant. REQUIRED
                   ; but MUST NOT occur more than once.
                   ;
                   (";" "VALUE" "=" ("URI" / "TEXT"))

                      [";" altrepparam]
                      [";" languageparam]
                      [";" fmttypeparam]
                      [";" derivedparam]

                      *(";" /
                   ;
                   ; The following are OPTIONAL
                   ; but MUST NOT occur more than once.
                   ;
                   (";" altrepparam) / (";" languageparam) /
                   (";" fmttypeparam) / (";" derivedparam) /
                   ;
                   ; The following is OPTIONAL
                   ; and MAY occur more than once.
                   ;
                   (";" other-param)
                   )

styleddescval   = ( uri / text )
;Value MUST match value type
                </artwork>
              </figure>
            </t>
]]></sourcecode>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t hangText="Example:">
              <figure>
                <preamble> keepWithNext="true">
                  The following is an example of this property.  It points to an
                  html
                  HTML description.
                </preamble>

                <artwork>
       STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html
                </artwork>
              </figure>
            </t>
          </list>
            </t>
<sourcecode type=""><![CDATA[
STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html
]]></sourcecode>
          </dd>
        </dl>
      </section>
      <section title="Structured-Data" anchor="structured-data">
        <t>
          <list style="hanging">
            <t hangText="Property Name:"> anchor="structured-data" numbered="true" toc="default">
        <name>Structured-Data</name>
        <dl newline="false" spacing="normal">
          <dt>Property Name:</dt>
          <dd>
              STRUCTURED-DATA
            </t>

            <t hangText="Purpose:">
            </dd>
          <dt>Purpose:</dt>
          <dd>
              This property specifies ancillary data associated with
              the calendar component.
            </t>
            <t hangText="Value Type:">
            </dd>
          <dt>Value Type:</dt>
          <dd>
              There is no default value type for this property. The value type
              can be set to TEXT, BINARY BINARY, or URI
            </t>

            <t hangText="Property Parameters:"> URI.
            </dd>
          <dt>Property Parameters:</dt>
          <dd>
              IANA-registered, non-standard, nonstandard, inline encoding encoding, and value data type
              property parameters can be specified on this property.
              The format type and schema parameters can be specified
              on this property and MUST <bcp14>MUST</bcp14> be present for text or inline
              binary encoded content information.
            </t>

            <t hangText="Conformance:">
            </dd>
          <dt>Conformance:</dt>
          <dd>
              This property can be specified multiple times in an
              iCalendar object. Typically Typically, it would be used in the "VEVENT",
              "VTODO"
              "VTODO", or "VJOURNAL" calendar components.
            </t>

            <t hangText="Description:">
              The
            </dd>
          <dt>Description:</dt>
          <dd>
              <t>The existing
              properties in iCalendar cover key elements of events and tasks tasks,
              such as start time, end time, location, summary, etc. However,
              different types of events often have other specific "fields"
              that it is are useful to include in the calendar data. For example,
              an event representing an airline flight could include the airline,
              flight number, departure and arrival airport codes, check-in
              and gate-closing times times, etc. As another example, a sporting event
              might contain information about the type of sport, the home and
              away teams, the league the teams are in, information about
              nearby parking, etc.
            </t>

            <t>
              This etc.</t>
              <t>This property is used to specify ancillary data in some
              structured format format, either directly (inline) as a "TEXT" or
              "BINARY" value or as a link via a "URI" value.
            </t>

            <t>
              Rather value.</t>
              <t>Rather than define new iCalendar properties
              for the variety of event types that might occur, it would be
              better to leverage existing schemas for such data.
              For example, schemas available at https://schema.org <eref brackets="angle" target="https://schema.org"/> include
              different event types. By using standard schemas, interoperability
              can be improved between calendar clients and non-calendaring noncalendaring
              systems that wish to generate or process the data.
            </t>

            <t>
              This data.</t>
              <t>This property allows the direct inclusion of ancillary data whose
              schema is defined elsewhere. This property also includes parameters
              to clearly identify the type of the schema being used so that
              clients can quickly and easily spot what is relevant within the
              calendar data and present that to users or process it within
              the calendaring system.
            </t>

            <t>
              iCalendar system.</t>
              <t>iCalendar does support an "ATTACH" property property, which can be used
              to include documents or links to documents within the calendar
              data. However, that property does not allow data to be included
              as a "TEXT" value (a feature that "STRUCTURED-DATA" does allow),
              plus attachments are often treated as "opaque" data to be
              processed by some other system rather than the calendar client.
              Thus
              Thus, the existing "ATTACH" property is not sufficient to cover
              the specific needs of inclusion of schema data. Extending the
              "ATTACH" property to support a new value type would likely cause
              interoperability problems. Additionally Additionally, some implementations
              manage attachments by stripping them out and replacing with a
              link to the resource. Thus Thus, a new property to support
              inclusion of schema data is warranted.
            </t> warranted.</t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This property is defined by the following notation:
                </preamble>

                <artwork
            </t>
<sourcecode name="abnf"><![CDATA[
sdataprop    = "STRUCTURED-DATA" sdataparam
                 (
                   ";" "VALUE" "=" "TEXT"
                   ":" text
                 ) /
                 (
                   ";" "ENCODING" "=" "BASE64"
                   ";" "VALUE" "=" "BINARY"
                   ";" binary
                 ) /
                 (
                   ";" "VALUE" "=" "URI"
                   ":"
                     sdataval uri
                 )
                 CRLF

sdataparam  = *(
                 ; all parameter elements may appear in any order,
                 ; and the order The following is not significant.
                    (sdataparamtext OPTIONAL for a URI value,
                 ; REQUIRED for a TEXT or BINARY value,
                 ; and MUST NOT occur more than once.
                 ;
                 (";" fmttypeparam) / sdataparambin
                 (";" schemaparam) / sdataparamuri)
                    *(";"
                 ;
                 ; The following is OPTIONAL
                 ; and MAY occur more than once.
                 ;
                 (";" other-param)

   sdataparamtext = ";VALUE=TEXT"
                    ";" fmttypeparam
                    ";" schemaparam

   sdataparambin  = ";VALUE=BINARY"
                    ";ENCODING=BASE64"
                    ";" fmttypeparam
                    ";" schemaparam

   sdataparamuri  = ";VALUE=URI"
                    [";" fmttypeparam]
                    [";" schemaparam]

   sdataval       = ( binary / text /uri )
                 ; value MUST match value type
]]></artwork>
              </figure>
            </t>

            <t hangText="Example:">
              )
]]></sourcecode>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t>
              The following is an example of this property:
              <figure>
                <artwork><![CDATA[ property.
            </t>
<sourcecode type=""><![CDATA[
STRUCTURED-DATA;FMTTYPE=application/ld+json;
 SCHEMA="https://schema.org/SportsEvent";
 VALUE=TEXT:{\n
   "@context": "http://schema.org"\,\n
   "@type": "SportsEvent"\,\n
   "homeTeam": "Pittsburgh Pirates"\,\n
   "awayTeam": "San Francisco Giants"\n
 }\n
]]></artwork>
              </figure>
            </t>
          </list>
        </t>
]]></sourcecode>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="new_components"
             title="New Components"> numbered="true" toc="default">
      <name>New Components</name>
      <section anchor="participant"
               title="Participant">
        <t>
          <list style='hanging'>
            <t hangText="Component name:">
              PARTICIPANT
            </t>

            <t hangText="Purpose:"> numbered="true" toc="default">
        <name>Participant</name>
        <dl newline="false" spacing="normal">
          <dt>Component name:</dt>
          <dd>PARTICIPANT</dd>
          <dt>Purpose:</dt>
          <dd>
              This component provides information about a participant
              in an event or task.
            </t>

            <t hangText="Conformance:">
            </dd>
          <dt>Conformance:</dt>
          <dd>
              This component can be specified multiple times in a
              "VEVENT", "VTODO", "VJOURNAL" "VJOURNAL", or "VFREEBUSY" calendar component.
            </t>

            <t hangText="Description:">
              This
            </dd>
          <dt>Description:</dt>
          <dd>
              <t>This component provides information about a participant
              in a calendar component. A participant may be an attendee
              in a scheduling sense sense, and the ATTENDEE "ATTENDEE" property may be
              specified in addition.
              Participants can be individuals
              or organizations, for example example, a soccer team, the spectators spectators, or
              the musicians.
            </t>

            <t>
              STRUCTURED-DATA properties musicians.</t>
              <t>"STRUCTURED-DATA" properties, if present present, may refer to
              definitions of the participant - -- such as a vCard.
            </t>

            <t>
              The CALENDAR-ADDRESS property vCard.</t>
              <t>The "CALENDAR-ADDRESS" property, if present present, will provide a
              cal-address. If an ATTENDEE "ATTENDEE" property has the same value value, the
              participant is considered schedulable. The PARTICIPANT "PARTICIPANT"
              component can be used to contain additional meta-data metadata
              related to the attendee.
            </t> attendee.</t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This component is defined by the following notation:
                </preamble>

                <artwork>
            </t>
<sourcecode type="abnf"><![CDATA[
participantc = "BEGIN" ":" "PARTICIPANT" CRLF
               partprop *locationc *resourcec
               "END" ":" "PARTICIPANT" CRLF

partprop     = *(
               ; the elements herein may appear in any order,
               ; and the order is not significant.

                  uid
                  participanttype

                  [calendaraddress]
                  [created]
                  [description]
                  [dtstamp]
                  [geo]
                  [last-mod]
                  [priority]
                  [seq]
                  [status]
                  [summary]
                  [url]

                  *attach
                  *categories
                  *comment
                  *contact
                  *location
                  *rstatus
                  *related
                  *resources
                  *strucloc
                  *strucres
                  *styleddescription
                  *sdataprop
                  *iana-prop

                </artwork>
              </figure>
            </t>

            <t hangText="Note:"> The following are REQUIRED
               ; but MUST NOT occur more than once.
               ;
               participanttype / uid /
               ;
               ; The following are OPTIONAL
               ; but MUST NOT occur more than once.
               ;
               calendaraddress / created / description / dtstamp /
               geo / last-mod / priority / seq /
               status / summary / url /
               ;
               ; The following are OPTIONAL
               ; and MAY occur more than once.
               ;
               attach / categories / comment
               contact / location / rstatus / related /
               resources / strucloc / strucres /
               styleddescription / sdataprop / iana-prop
               ;
               )
]]></sourcecode>
          </dd>
          <dt>Note:</dt>
          <dd>
              When the PRIORITY "PRIORITY" property is supplied supplied, it defines the ordering of
              PARTICIPANT
              "PARTICIPANT" components with the same value for the
              PARTICIPANT-TYPE
              "PARTICIPANT-TYPE" property.
            </t>

            <t hangText="Privacy Issues:">
            </dd>
          <dt>Privacy Issues:</dt>
          <dd>
              When a LOCATION "LOCATION" property is supplied supplied, it provides information about
              the location of a participant at a given time or times.
              This may represent an unacceptable privacy risk for some
              participants. User agents MUST NOT <bcp14>MUST NOT</bcp14> broadcast this information
              without the participant's express permission. permission of the participants whose location would be
              exposed. For further
              comments
              comments, see <xref target="privacy" />
            </t> format="default"/>.
          </dd>
          <dt>Example:</dt>
          <dd>
            <t hangText="Example:">
              <figure>
                <preamble> keepWithNext="true">
                  The following is an example of this component. It
                  contains a STRUCTURED-DATA "STRUCTURED-DATA" property which that points to a
                  vCard providing information about the event participant.
                </preamble>

                <artwork>
            </t>
<sourcecode type=""><![CDATA[
BEGIN:PARTICIPANT
UID: em9lQGZvb2GFtcGxlLmNvbQ
PARTICIPANT-TYPE:PERFORMER
STRUCTURED-DATA;VALUE=URI:
 http://dir.example.com/vcard/aviolinist.vcf
END:PARTICIPANT
                </artwork>
              </figure>
            </t>
]]></sourcecode>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t hangText="Example:">
              <figure>
                <preamble> keepWithNext="true">
                  The following is an example for the primary contact.
                </preamble>

                <artwork>
            </t>
<sourcecode type=""><![CDATA[
BEGIN:PARTICIPANT
UID: em9lQGZvb2GFtcGxlLmNvbQ
STRUCTURED-DATA;VALUE=URI;
 http://dir.example.com/vcard/contacts/contact1.vcf
PARTICIPANT-TYPE:CONTACT
DESCRIPTION:A contact
END:PARTICIPANT
                </artwork>
              </figure>
            </t>
]]></sourcecode>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t hangText="Example:">
              <figure>
                <preamble> keepWithNext="true">
                  The following is an example for a participant with
                  contact and location.
                </preamble>

                <artwork>
            </t>
<sourcecode type=""><![CDATA[
BEGIN:PARTICIPANT
UID: em9lQGZvb2GFtcGxlLmNdrt
STRUCTURED-DATA;VALUE=URI;
 http://dir.example.com/vcard/contacts/my-card.vcf
PARTICIPANT-TYPE:SPEAKER
DESCRIPTION:A participant
BEGIN:VLOCATION
UID:123456-abcdef-98765432
NAME:My home location
STRUCTURED-DATA;VALUE=URI:
 http://dir.example.com/addresses/my-home.vcf
END:VLOCATION
END:PARTICIPANT
                </artwork>
              </figure>
            </t>
          </list>
        </t>
]]></sourcecode>
          </dd>
        </dl>
        <section anchor="schedulable-participant"
                 title="Schedulable Participant"> numbered="true" toc="default">
          <name>Schedulable Participant</name>
          <t>
            A PARTICIPANT "PARTICIPANT" component may represent someone or something that
            needs to be scheduled scheduled, as defined for ATTENDEE in <xref target="RFC5545" /> format="default"/>
            and <xref target="RFC5546" />. format="default"/>. The PARTICIPANT "PARTICIPANT" component may
            also represent someone or something that is NOT to receive
            scheduling messages.
          </t>
          <t>
            For backwards compatibility wuth with existing clients and servers
            when used to schedule events and tasks tasks,
            the ATTENDEE "ATTENDEE" property MUST <bcp14>MUST</bcp14> be used to specify the sheduling scheduling
            parameters as defined for that property.
          </t>
          <t>
            For other, future uses uses, the CALENDAR-ADDRESS "CALENDAR-ADDRESS" property MUST <bcp14>MUST</bcp14> be used
            to specify those parameters.
          </t>
          <t>
            A PARTICIPANT "PARTICIPANT" component is defined to be schedulable if
            <list style='symbols'>
              <t>
                It if:
          </t>
          <ul spacing="normal">
            <li>it contains a CALENDAR-ADDRESS "CALENDAR-ADDRESS" property
              </t>
              <t>
                That and</li>
            <li>that property value is the same as the value for an ATTENDEE property.
              </t>
            </list>
          </t> "ATTENDEE" property.</li>
          </ul>
          <t>
            If both of these conditions apply apply, then the participant defined
            by the value of the URL property will take part in scheduling
            operations
            operations, as defined in <xref target="RFC5546" />. format="default"/>.
          </t>
          <t>
            An appropriate use for the PARTICIPANT "PARTICIPANT" component in scheduling
            would be to store SEQUENCE "SEQUENCE" and DTSTAMP "DTSTAMP" properties associated with
            replies from each ATTENDEE. "ATTENDEE" property. A LOCATION "LOCATION" property within the
            PARTICIPANT
            "PARTICIPANT" component might allow better selection of meeting times
            when participants are in different timezones. time zones.
          </t>
        </section>
      </section>
      <section anchor="vlocation"
               title="Location">
        <t>
          <list style='hanging'>
            <t hangText="Component name:"> numbered="true" toc="default">
        <name>Location</name>
        <dl newline="false" spacing="normal">
          <dt>Component name:</dt>
          <dd>
              VLOCATION
            </t>

            <t hangText="Purpose:">
            </dd>
          <dt>Purpose:</dt>
          <dd>
              This component provides rich information
              about the location of an event using the structured data
              property or optionally or, optionally, a plain text plain-text typed value.
            </t>

            <t hangText="Conformance:">
            </dd>
          <dt>Conformance:</dt>
          <dd>
              This component can be specified multiple times in a
              "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY" "VFREEBUSY", or
              "PARTICIPANT" calendar component.
            </t>

            <t hangText="Description:">
              There
            </dd>
          <dt>Description:</dt>
          <dd>
              <t>There may be a number of locations associated with an event.
              This component provides detailed information about a location.
            </t>

            <t>
              When location.</t>
              <t>When used in a component component, the value of this property provides
              information about the event venue or of related services services, such as
              parking, dining, stations etc..
            </t>

            <t>
              STRUCTURED-DATA properties stations, etc.</t>
              <t>"STRUCTURED-DATA" properties, if present present, may refer to
              representations of the location - -- such as a vCard.
            </t> vCard.</t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This component is defined by the following notation:
                </preamble>

                <artwork>
            </t>

<sourcecode type="abnf"><![CDATA[
locationc    = "BEGIN" ":" "VLOCATION" CRLF
               locprop
               "END" ":" "VLOCATION" CRLF

locprop      = *(
               ; the elements herein may appear in any order,
               ; and the order is not significant. The following are REQUIRED
               ; but MUST NOT occur more than once.
               ;
               uid

                  [name]
                  [description]
                  [geo]
                  [loctype]

                  *sdataprop
                  *iana-prop
                </artwork>
              </figure>
            </t>

            <t> /
               ;
               ; The following are OPTIONAL
               ; but MUST NOT occur more than once.
               ;
               description / geo / loctype / name
               ;
               ; The NAME following are OPTIONAL
               ; and MAY occur more than once.
               ;
               sdataprop / iana-prop
            )
]]></sourcecode>
              <t>The "NAME" property is defined in <xref target='RFC7986'/>
            </t> target="RFC7986" format="default"/>.</t>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t hangText="Example:">
              <figure>
                <preamble> keepWithNext="true">
                  The following is an example of this component. It points to a
                  venue.
                </preamble>

                <artwork>
            </t>
<sourcecode type=""><![CDATA[
BEGIN:VLOCATION
UID:123456-abcdef-98765432
NAME:The venue
STRUCTURED-DATA;VALUE=URI:
 http://dir.example.com/venues/big-hall.vcf
END:VLOCATION
                </artwork>
              </figure>
            </t>
          </list>
        </t>
]]></sourcecode>
          </dd>
        </dl>
      </section>
      <section anchor="vresource"
               title="Resource">
        <t>
          <list style='hanging'>
            <t hangText="Component name:"> numbered="true" toc="default">
        <name>Resource</name>
        <dl newline="false" spacing="normal">
          <dt>Component name:</dt>
          <dd>
              VRESOURCE
            </t>

            <t hangText="Purpose:">
            </dd>
          <dt>Purpose:</dt>
          <dd>
              This component provides a typed reference to external information
              about a resource or optionally or, optionally, a plain text plain-text typed value.
              Typically
              Typically, a resource is anything that
              might be required or used by a calendar entity and possibly has a
              directory entry.
            </t>

            <t hangText="Conformance:">
            </dd>
          <dt>Conformance:</dt>
          <dd>
              This component can be specified multiple times in a
              "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY" "VFREEBUSY", or
              "PARTICIPANT" calendar component.
            </t>

            <t hangText="Description:">
              When
            </dd>
          <dt>Description:</dt>
          <dd>
              <t>When used in a component component, this component provides
              information about resources used for the event event, such as
              rooms, projectors, and conferencing capabilities.
            </t>

            <t>
              The capabilities.</t>
              <t>The RESOURCE-TYPE
              value registry provides a place in which resource types
              may be registered.
            </t>

            <t>
              STRUCTURED-DATA properties registered.</t>
              <t>"STRUCTURED-DATA" properties, if present present, may refer to
              representations of the resource - -- such as a vCard.
            </t> vCard.</t>
            </dd>
          <dt>Format Definition:</dt>
          <dd>
            <t hangText="Format Definition:">
              <figure>
                <preamble> keepWithNext="true">
                  This component is defined by the following notation:
                </preamble>

                <artwork>
            </t>
<sourcecode type="abnf"><![CDATA[
resourcec    = "BEGIN" ":" "VRESOURCE" CRLF
               resprop
               "END" ":" "VRESOURCE" CRLF

resprop      = *(
               ; the elements herein may appear in any order,
               ; and the order is not significant. The following are REQUIRED
               ; but MUST NOT occur more than once.
               ;
               uid

                  [name]
                  [description]
                  [geo]
                  [restype]

                  *sdataprop
                  *iana-prop
                </artwork>
              </figure>
            </t>

            <t> /
               ;
               ; The following are OPTIONAL
               ; but MUST NOT occur more than once.
               ;
               description / geo / name / restype /
               ;
               ; The NAME following are OPTIONAL
               ; and MAY occur more than once.
               ;
               sdataprop / iana-prop
             )
]]></sourcecode>
              <t>The "NAME" property is defined in <xref target='RFC7986'/>
            </t> target="RFC7986" format="default"/>.</t>
          </dd>
          <dt>Example:</dt>
          <dd>
            <t hangText="Example:">
              <figure>
                <preamble> keepWithNext="true">
                  The following is an example of this component. It refers to a
                  projector.
                </preamble>

                <artwork>
            </t>
<sourcecode type=""><![CDATA[
BEGIN:VRESOURCE
UID:456789-abcdef-98765432
NAME:The projector
RESOURCE-TYPE:projector
STRUCTURED-DATA;VALUE=URI:http://dir.example.com/projectors/3d.vcf
END:VRESOURCE
                </artwork>
              </figure>
            </t>
          </list>
        </t>
]]></sourcecode>
          </dd>
        </dl>
      </section>
    </section>
    <section title='Extended examples'> numbered="true" toc="default">
      <name>Extended Examples</name>
      <t>
       The following are some examples of the use of the properties defined in
       this specification. They include additional properties defined in
       <xref target='RFC7986'/> target="RFC7986" format="default"/>, which includes IMAGE. "IMAGE".
      </t>
      <section title='Example 1'>
        <figure>
          <preamble> numbered="true" toc="default">
        <name>Example 1</name>
        <t keepWithNext="true">
            The following is an example of a VEVENT "VEVENT" describing a concert.
            It includes location
            information for the venue itself itself, as well as references to parking and
            restaurants.
          </preamble>

          <artwork>
        </t>
<sourcecode type=""><![CDATA[
BEGIN:VEVENT
CREATED:20200215T145739Z
DESCRIPTION: Piano Sonata No 3\n
 Piano Sonata No 30
DTSTAMP:20200215T145739Z
DTSTART;TZID=America/New_York:20200315T150000Z
DTEND;TZID=America/New_York:20200315T163000Z
LAST-MODIFIED:20200216T145739Z
SUMMARY:Beethoven Piano Sonatas
UID:123456
IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h
 ttp://example.com/images/concert.png
BEGIN:PARTICIPANT
PARTICIPANT-TYPE:SPONSOR
UID:dG9tQGZvb2Jhci5xlLmNvbQ
STRUCTURED-DATA;VALUE=URI:http://example.com/sponsor.vcf
END:PARTICIPANT
BEGIN:PARTICIPANT
PARTICIPANT-TYPE:PERFORMER:
UID:em9lQGZvb2GFtcGxlLmNvbQ
STRUCTURED-DATA;VALUE=URI:http://www.example.com/people/johndoe.vcf
END:PARTICIPANT
BEGIN:VLOCATION
UID:123456-abcdef-98765432
NAME:The venue
STRUCTURED-DATA;VALUE=URI:http://dir.example.com/venues/big-hall.vcf
END:VLOCATION
BEGIN:VLOCATION
UID:123456-abcdef-87654321
NAME:Parking for the venue
STRUCTURED-DATA;VALUE=URI:http://dir.example.com/venues/parking.vcf
END:VLOCATION
END:VEVENT

          </artwork>
        </figure>
]]></sourcecode>
      </section>
      <section title='Example 2'>
        <figure>
          <preamble> numbered="true" toc="default">
        <name>Example 2</name>
        <t keepWithNext="true">
            The following is an example of a VEVENT "VEVENT" describing a meeting.
            One of the attendees is a remote participant.
          </preamble>

          <artwork>
        </t>
<sourcecode type=""><![CDATA[
BEGIN:VEVENT
CREATED:20200215T145739Z
DTSTAMP:20200215T145739Z
DTSTART;TZID=America/New_York:20200315T150000Z
DTEND;TZID=America/New_York:20200315T163000Z
LAST-MODIFIED:20200216T145739Z
SUMMARY:Conference planning
UID:123456
ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com
BEGIN:PARTICIPANT
PARTICIPANT-TYPE:ACTIVE:
UID:v39lQGZvb2GFtcGxlLmNvbQ
STRUCTURED-DATA;VALUE=URI:http://www.example.com/people/b.vcf
LOCATION:At home
END:PARTICIPANT
END:VEVENT

          </artwork>
        </figure>
]]></sourcecode>
      </section>
    </section>
    <section title='Security Considerations'> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        This specification extends <xref target="RFC5545" /> format="default"/> and makes further use of
        possibly linked data. While calendar data is not unique in this
        regard
        regard, it is worth reminding implementors of some of the dangers
        and safeguards.
      </t>
      <section anchor='security-uris' title="URIs"> anchor="security-uris" numbered="true" toc="default">
        <name>URIs</name>
        <t>
          See <xref target="RFC3986" /> format="default"/> for a discussion of the security
          considerations relating to URIs. Because of the issues discussed there and below,
          clients SHOULD NOT <bcp14>SHOULD NOT</bcp14> follow URIs and fetch content automatically, automatically
          and should only do so at the explicit request of the user.
        </t>
        <t>Fetching remote resources carries inherent risks.
          Connections must only be allowed on well known well-known ports,
          using allowed protocols (generally just HTTP/HTTPS on
          their default ports). The URL must be
          resolved externally and not allowed to access internal resources.
          Connecting to an external source reveals IP (and therefore
          generally location) information.
        </t>
        <t>
          A maliciously constructed iCalendar object may contain a very large
          number of URIs.  In the case of published calendars with a large
          number of subscribers, such objects could be widely distributed.
          Implementations should be careful to limit the automatic fetching of
          linked resources to reduce the risk of this being an amplification
          vector for a denial-of-service attack.
        </t>
      </section>
      <section anchor='security-malicious-content'
               title="Malicious Content"> anchor="security-malicious-content" numbered="true" toc="default">
        <name>Malicious Content</name>
        <t>
          For the "STRUCTURED-DATA" property, agents need to be aware
          that a client could attack underlying storage by sending extremely large
          values and could attack processing time by uploading a recurring
          event with a large number of overrides and then repeatedly adding,
          updating
          updating, and deleting structured data.
        </t>
        <t>
          Agents should set reasonable limits on storage size and number
          of instances and apply those constraints. Calendar protocols should
          ensure there is a way to report on such limits being exceeded.
        </t>
        <t>
          Malicious content could be introduced into the calendar server by way
          of the "STRUCTURED-DATA" property and propagated to many end users via
          scheduling.  Servers SHOULD <bcp14>SHOULD</bcp14> check this property for malicious
          or inappropriate content.  Upon detecting such content, servers
          SHOULD
          <bcp14>SHOULD</bcp14> remove the property, property.
        </t>
      </section>
      <section anchor='security-html'
               title="HTML Content"> anchor="security-html" numbered="true" toc="default">
        <name>HTML Content</name>
        <t>
          When processing HTML content, applications need to be aware of the
          many security and privacy issues, as described in the IANA considerations Considerations
          section of
          <xref target='W3C.REC-html51-20171003'/> target="W3C.REC-html51-20171003" format="default"/>.
        </t>
      </section>
    </section>
    <section title='Privacy Considerations' anchor='privacy'> anchor="privacy" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <section title='Tracking' anchor='privacy-tracking'> anchor="privacy-tracking" numbered="true" toc="default">
        <name>Tracking</name>
        <t>
          Properties with a "URI" value type can expose their users to
          privacy leaks leaks, as any network access of the URI data can be
          tracked both by a network observer and by the
          entity hosting the remote resource.
          Clients SHOULD NOT <bcp14>SHOULD NOT</bcp14> automatically download data
          referenced by the URI without explicit instruction from users.
        </t>
        <t>
          To help alleviate some of the concerns concerns, protocols and services
          could provide proxy services for downloading referenced data.
        </t>
      </section>
      <section title='Revealing Locations' anchor='privacy-locations'> anchor="privacy-locations" numbered="true" toc="default">
        <name>Revealing Locations</name>
        <t>
          The addition of location information to the new participant
          component provides information about the location of
          participants at a given time. This information MUST NOT <bcp14>MUST NOT</bcp14> be
          distributed to other participants without those participant's
          express permission. Note that there may be a number of
          participants who may be unaware of their inclusion in the
          data.
        </t>
        <t>
          Agents processing and distributing
          calendar data must be aware that it has the property of
          providing information about a future time when a given
          individual may be at a particular location, which could
          enable targeted attacks against that individual.
        </t>
        <t>
          The same may be true of other information contained in the
          participant component. In general, revealing only as much
          as is absolutely necessary should be the approach taken.
        </t>
        <t>
          For example, there may be some privacy considerations relating to the ORDER "ORDER"
          parameter, as it provides an indication of the
          organizer's perception of the relative importance of other
          participants.
        </t>
      </section>
    </section>
    <section anchor="iana_considerations" title='IANA Considerations'> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="additional-icalendar-registrations"
               title="Additional numbered="true" toc="default">
        <name>Additional iCalendar Registrations"> Registrations</name>
        <section anchor="property_registrations"
                 title="Properties" > numbered="true" toc="default">
          <name>Properties</name>
          <t>
            This document defines the following new iCalendar properties to be
            that have been added to the "Properties" registry defined in Section 8.2.3 of <xref target='RFC5545'/>:
          </t>
          <texttable>
            <ttcol align="left">Property</ttcol>
            <ttcol align="left">Status</ttcol>
            <ttcol align="left">Reference</ttcol>

            <c>CALENDAR-ADDRESS</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="calendar-address"/></c>

            <c>LOCATION-TYPE</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="loctype"/></c>

            <c>PARTICIPANT-TYPE</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>RESOURCE-TYPE</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="restype"/></c>

            <c>STRUCTURED-DATA</c>
            <c>Current</c>
            <c>RFCXXXX, target="RFC5545" format="default" sectionFormat="of" section="8.2.3"/>:
          </t>
          <table align="center">
	    <name>Additions to the Properties Registry</name>
            <thead>
              <tr>
                <th align="left">Property</th>
                <th align="left">Status</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">CALENDAR-ADDRESS</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="calendar-address" format="default"/></td>
              </tr>
              <tr>
                <td align="left">LOCATION-TYPE</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="loctype" format="default"/></td>
              </tr>
              <tr>
                <td align="left">PARTICIPANT-TYPE</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">RESOURCE-TYPE</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="restype" format="default"/></td>
              </tr>
              <tr>
                <td align="left">STRUCTURED-DATA</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="structured-data" /></c>

            <c>STYLED-DESCRIPTION</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="styled-description"/></c>
          </texttable> format="default"/></td>
              </tr>
              <tr>
                <td align="left">STYLED-DESCRIPTION</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="styled-description" format="default"/></td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="parameter_registrations"
                 title="Parameters" > numbered="true" toc="default">
          <name>Parameters</name>
          <t>
            This document defines the following new iCalendar property parameters
            to be
            that have been added to the "Parameters" registry defined in Section 8.2.4 of <xref target='RFC5545'/>:
          </t>
          <texttable>
            <ttcol align="left">Property Parameter</ttcol>
            <ttcol align="left">Status</ttcol>
            <ttcol align="left">Reference</ttcol>

            <c>ORDER</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="parameter_order"/></c>

            <c>SCHEMA</c>
            <c>Current</c>
            <c>RFCXXXX, target="RFC5545" format="default" sectionFormat="of" section="8.2.4"/>:
          </t>
          <table align="center">
	    <name>Additions to the Parameters Registry</name>
            <thead>
              <tr>
                <th align="left">Parameter</th>
                <th align="left">Status</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">ORDER</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="parameter_order" format="default"/></td>
              </tr>
              <tr>
                <td align="left">SCHEMA</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="parameter_schema" /></c>
          </texttable> format="default"/></td>
              </tr>
              <tr>
                <td align="left">DERIVED</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="parameter_derived" format="default"/></td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="component_registrations"
                 title="Components" > numbered="true" toc="default">
          <name>Components</name>
          <t>
            This document defines the following new iCalendar components to be that have been
            added to the "Components" registry defined in Section 8.3.1 of <xref target='RFC5545'/>:
          </t>
          <texttable>
            <ttcol align="left">Component</ttcol>
            <ttcol align="left">Status</ttcol>
            <ttcol align="left">Reference</ttcol>

            <c>PARTICIPANT</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant"/></c>

            <c>VLOCATION</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="vlocation"/></c>

            <c>VRESOURCE</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="vresource"/></c>
          </texttable> target="RFC5545" format="default" sectionFormat="of" section="8.3.1"/>:
          </t>
          <table align="center">
	    <name>Additions to the Components Registry</name>
            <thead>
              <tr>
                <th align="left">Component</th>
                <th align="left">Status</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">PARTICIPANT</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant" format="default"/></td>
              </tr>
              <tr>
                <td align="left">VLOCATION</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="vlocation" format="default"/></td>
              </tr>
              <tr>
                <td align="left">VRESOURCE</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="vresource" format="default"/></td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="new_registration-tables"
               title="New Registration Tables"> numbered="true" toc="default">
        <name>Participant Types and Resource Types Registries</name>
        <t>
          This section defines new registration tables for PARTICIPANT-TYPE
          and RESOURCE-TYPE values. These tables are updated using the same
          approaches laid down in Section 8.2.1 of <xref target="RFC5545" /> format="default" sectionFormat="of" section="8.2.1"/>.
        </t>
        <t>
          This document creates new IANA registries for participant and resource
          types.

          IANA will maintain these registries and, following the policies
          outlined in <xref target="RFC8126" />, format="default"/>, new tokens are
          assigned after Expert Review.  The Expert Reviewer will generally
          consult the IETF GeoPRIV working group GEOPRIV Working Group mailing list or its designated
          successor.  Updates or deletions of tokens from the registration
          follow the same procedures.

          The expert review Expert Review should be guided by a few common sense common-sense
          considerations.  For example, tokens should not be specific to a
          country, region, organization, or company; they should be well- well
          defined and widely recognized.  The expert's Expert's support of IANA will
          include providing IANA with the new token(s) when the update is
          provided only in the form of a schema, schema and providing IANA with the
          new schema element(s) when the update is provided only in the form of
          a token.

          To ensure widespread usability across protocols, tokens MUST <bcp14>MUST</bcp14> follow
          the character set restrictions for XML Names [3]. <xref target="W3C.REC-xml-20040204"/>.

          Each registration must include the name of the token and a brief
          description similar to the ones offered herein for the initial
          registrations contained this document: document.
        </t>
        <section anchor="participant_types_registry"
                 title="Participant Types" >
          <t>
            The following table has been used to initialize the
            participant types registry.
          </t>
          <texttable>
            <ttcol numbered="true" toc="default">
          <name>Participant Types</name>

          <table align="center">
	    <name>Initial Contents of the Participant Types Registry</name>
            <thead>
              <tr>
                <th align="left">Participant Type</ttcol>
            <ttcol align="left">Status</ttcol>
            <ttcol align="left">Reference</ttcol>

            <c>ACTIVE</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>INACTIVE</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>SPONSOR</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>CONTACT</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>BOOKING-CONTACT</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>EMERGENCY-CONTACT</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>PUBLICITY-CONTACT</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>PLANNER-CONTACT</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>PERFORMER</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>

            <c>SPEAKER</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="participant-type"/></c>
          </texttable> Type</th>
                <th align="left">Status</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">ACTIVE</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">INACTIVE</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">SPONSOR</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">CONTACT</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">BOOKING-CONTACT</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">EMERGENCY-CONTACT</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">PUBLICITY-CONTACT</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">PLANNER-CONTACT</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">PERFORMER</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
              <tr>
                <td align="left">SPEAKER</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="participant-type" format="default"/></td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="resource_types_registry"
                 title="Resource Types" >
          <t>
            The following table has been used to initialize the resource
            types registry.
          </t>
          <texttable>
            <ttcol numbered="true" toc="default">
          <name>Resource Types</name>

          <table align="center">
	    <name>Initial Contents of the Resource Types Registry</name>
            <thead>
              <tr>
                <th align="left">Resource Type</ttcol>
            <ttcol align="left">Status</ttcol>
            <ttcol align="left">Reference</ttcol>

            <c>PROJECTOR</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="restype"/></c>

            <c>ROOM</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="restype"/></c>

            <c>REMOTE-CONFERENCE-AUDIO</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="restype"/></c>

            <c>REMOTE-CONFERENCE-VIDEO</c>
            <c>Current</c>
            <c>RFCXXXX, <xref target="restype"/></c>
          </texttable> Type</th>
                <th align="left">Status</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">PROJECTOR</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="restype" format="default"/></td>
              </tr>
              <tr>
                <td align="left">ROOM</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="restype" format="default"/></td>
              </tr>
              <tr>
                <td align="left">REMOTE-CONFERENCE-AUDIO</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="restype" format="default"/></td>
              </tr>
              <tr>
                <td align="left">REMOTE-CONFERENCE-VIDEO</td>
                <td align="left">Current</td>
                <td align="left">RFC 9073, <xref target="restype" format="default"/></td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4589.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5545.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5546.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7986.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>

      <reference anchor="W3C.REC-html51-20171003" target="https://www.w3.org/TR/2017/REC-html51-20171003">
        <front>
          <title>HTML 5.1 2nd Edition</title>
          <author initials="S." surname="Faulkner" fullname="Steve Faulkner" role="editor">
            <organization/>
          </author>
          <author initials="A." surname="Eicholz" fullname="Arron Eicholz" role="editor">
            <organization/>
          </author>
          <author initials="T." surname="Leithead" fullname="Travis Leithead" role="editor">
            <organization/>
          </author>
          <author initials="A." surname="Danilo" fullname="Alex Danilo" role="editor">
            <organization/>
          </author>
          <date month="October" year="2017"/>
        </front>
        <seriesInfo name="World Wide Web Consortium Recommendation" value="REC-html51-20171003"/>
      </reference>

      <reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2008/REC-xml-20081126">
        <front>
          <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
          <author initials="T." surname="Bray" fullname="Tim Bray" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Paoli" fullname="Jean Paoli" role="editor">
            <organization/>
          </author>
          <author initials="M." surname="Sperberg-McQueen" fullname="Michael Sperberg-McQueen" role="editor">
            <organization/>
          </author>
          <author initials="E." surname="Maler" fullname="Eve Maler" role="editor">
            <organization/>
          </author>
          <author initials="F." surname="Yergeau" fullname="François Yergeau" role="editor">
            <organization/>
          </author>
          <date month="November" year="2008"/>
        </front>
        <seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20081126"/>
      </reference>

      <reference anchor="W3C.REC-xml-20040204" target="https://www.w3.org/TR/2004/REC-xml-20040204">
        <front>
          <title>Extensible Markup Language (XML) 1.0 (Third Edition)</title>
          <author initials="M." surname="Sperberg-McQueen" fullname="Michael Sperberg-McQueen">
	                <organization/>
          </author>

	            <author initials="E." surname="Maler" fullname="Eve Maler">
            <organization/>
          </author>

          <author initials="T." surname="Bray" fullname="Tim Bray">
            <organization/>
          </author>
          <author initials="J." surname="Paoli" fullname="Jean Paoli">
            <organization/>
          </author>

          <author initials="F." surname="Yergeau" fullname="François Yergeau">
            <organization/>
          </author>
          <date month="February" year="2004"/>
        </front>
        <seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20040204"/>
      </reference>

    </references>

    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        The author would like to thank Chuck Norris <contact fullname="Chuck Norris"/> of eventful.com for his work work,
        which led to the development of this RFC.
      </t>
      <t>
        The author would also like to thank the members of CalConnect, CalConnect:
        The Calendaring and Scheduling Consortium,
        the Event Publication technical committee committee, and the following
        individuals for contributing their ideas and support:
      </t>
      <t>
        Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis.
      </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;
      &RFC2426;
      &RFC3986;
      &RFC4589;
      &RFC5545;
      &RFC5546;
      &RFC7986;
      &RFC8126;
      &RFC8174;
      &RFC8259;
      &W3C.REC-html51-20171003;
      &W3C.REC-xml-20081126;
    </references>

    <section title="Open issues">
      <t>
        None at the moment
      </t>
    </section>

    <section title="Change log">
      <t>To be deleted on publication</t>

      <t>
        calext-v18 2021-??-??  MD
        <list style='symbols'>
          <t>
            Fix incorrect participant type property name in PARTICIPANT.
          </t>
          <t>
            Allow parameters on LOCATION-TYPE.
          </t>
        </list>
      </t>

      <t>
        calext-v17 2021-01-03  MD
        <list style='symbols'>
          <t>
            Remove STRUCTURED-LOCATION property, add VLOCATION component.
          </t>
          <t>
            Remove STRUCTURED-RESOURCE property, add VRESOURCE component.
          </t>
          <t>
            Make LOCATION-TYPE multi-valued property for location.
          </t>
          <t>
            Make RESOURCE-TYPE multi-valued property for resource.
          </t>
          <t>
            Tidy up abnf.
          </t>
        </list>
      </t>

      <t>
        calext-v16 2019-10-09  MD
        <list style='symbols'>
          <t>
            Make LOCTYPE multi-valued.
          </t>
          <t>
            Add all ATTENDEE scheduling parameters to CALENDAR-ADDRESS.
          </t>
        </list>
      </t>
      <t>
        calext-v15 2019-10-08  MD
        <list style='symbols'>
          <t>
            Address various DICUSS points.
          </t>
        </list>
      </t>
      <t>
        calext-v14 2019-06-11  MD
        <list style='symbols'>
          <t>
            Definition of event and social calendaring.
          </t>
          <t>
            Remove redefinition of SOURCE - use STRUCTURED-DATA.
          </t>
        </list>
      </t>
      <t>
        calext-v13 2019-05-26  MD
        <list style='symbols'>
          <t>
            Respond to various issues.
          </t>
        </list>
      </t>
      <t>
        calext-v12 2019-02-28  MD
        <list style='symbols'>
          <t>
            Fix styled-description example. Respond to various AD issues.
            Some typos.
          </t>
        </list>
      </t>
      <t>
        calext-v11 2019-02-27  MD
        <list style='symbols'>
          <t>
            Add DERIVED parameter for styled-description, RELATED parameter
            for structured-location
          </t>
        </list>
      </t>
      <t>
        calext-v09 2018-08-30  MD
        <list style='symbols'>
          <t>
            Sorted out inconsistencies in refs to 5546
          </t>
        </list>
      </t>
      <t>
        calext-v08 2018-07-06  MD
        <list style='symbols'>
          <t>
            Add some text for equal ORDER values
          </t>
          <t>
            Switched scheduleaddress to calendaraddress in participant
            abnf. Also added more properties
          </t>
          <t>
            Fixed PARTICIPANT abnf
          </t>
        </list>
      </t>
      <t>
        calext-v04 2017-10-11  MD
        <list style='symbols'>
          <t>
            Change SCHEDULE-ADDRESS to CALENDAR-ADDRESS
          </t>
          <t>
            Explicitly broaden scope of SOURCE
          </t>
          <t>
            Add initial registry for RESTYPE and move new tables into
            separate section.
          </t>
          <t>
            Fix PARTTYPE/PARTICIPANT-TYPE inconsistency
          </t>
        </list>
      </t>
      <t>
        calext-v03 2017-10-09  MD
        <list style='symbols'>
          <t>
            Mostly typographical and other minor changes
          </t>
        </list>
      </t>
      <t>
        calext-v02 2017-04-20  MD
        <list style='symbols'>
          <t>
            Add SCHEDULE-ADDRESS property
          </t>
          <t>
            PARTICIPANT becomes a component rather than a property. Turn
            many of the former parameters into properties.
          </t>
          <t>
            Use existing ATTENDEE property for scheduling.
          </t>
        </list>
      </t>
      <t>
        calext-v01 2017-02-18  MD
        <list style='symbols'>
          <t>
            Change ASSOCIATE back to PARTICIPANT
          </t>
          <t>
            PARTICIPANT becomes a component rather than a property. Turn
            many of the former parameters into properties.
          </t>
        </list>
      </t>
      <t>
        calext-v00 2016-08-??  MD
        <list style='symbols'>
          <t>
            Name changed - taken up by calext working group
          </t>
        </list>
      </t>
      <t>
        v06 2016-06-26  MD
        <list style='symbols'>
          <t>
            Fix up abnf
          </t>
          <t>
            change ref to ietf from daboo
          </t>
          <t>
            take out label spec - use Cyrus spec
          </t>
        </list>
      </t>
      <t>
        v05 2016-06-14  MD
        <list style='symbols'>
          <t>
            Remove GROUP and HASH. they can be dealt with elsewhere if desired
          </t>
          <t>
            Change ORDER to integer >= 1.
          </t>
          <t>
            Incorporate Structured-Data into this specification.
          </t>
        </list>
      </t>
      <t>
        v04 2014-02-01  MD
        <list style='symbols'>
          <t>
            Added updates attribute.
          </t>
          <t>
            Minor typos.
          </t>
          <t>
            Resubmitted mostly to refresh the draft.
          </t>
        </list>
      </t>
      <t>
        v03 2013-03-06  MD
        <list style='symbols'>
          <t>
            Replace PARTICIPANT with ASSOCIATE plus related changes.
          </t>
          <t>
            Added section showing modifications to components.
          </t>
          <t>
            Replace ID with GROUP and modify HASH.
          </t>
          <t>
            Replace TITLE param with LABEL.
          </t>
          <t>
            Fixed STYLED-DESCRIPTION in various ways, correct example.
          </t>
        </list>
      </t>
      <t>
        v02 2012-11-02  MD
        <list style='symbols'>
          <t>
            Collapse sections with description of properties and the use cases
            into a section with sub-sections.
          </t>
          <t>
            New section to describe relating properties.
          </t>
          <t>
            Remove idref and upgrade hash to have the reference
          </t>
          <t>
            No default value types on properties..
          </t>
        </list>
      </t>
      <t>
        v01 2012-10-18  MD    Many changes.
        <list style='symbols'>
          <t>
            SPONSOR and STRUCTURED-CONTACT are now in PARTICIPANT
          </t>
          <t>
            Add a STRUCTURED-RESOURCE property
          </t>
          <t>
            STYLED-DESCRIPTION to handle rich text
          </t>
          <t>
            Much more...
          </t>
        </list>
      </t>
      <t>
        2011-01-07
        <list style='symbols'>
          <t>
            Remove MEDIA - it's going in the Cyrus RFC
          </t>
          <t>
            Rename EXTENDED-... to STRUCTURED-...
          </t>
          <t>
            Add TYPE parameter to SPONSOR
          </t>
        </list>
      </t>
      <t>
        v00 2007-10-19  MD    Initial version
        <contact fullname="Cyrus Daboo"/>, <contact fullname="John Haug"/>, <contact fullname="Dan Mendell"/>, <contact fullname="Ken Murchison"/>, and <contact fullname="Scott Otis"/>.
      </t>
    </section>
  </back>
</rfc>