doc: Add RFC documents

1 files changed, 1453 insertions, 0 deletions

diff --git a/doc/rfc/rfc9073.txt b/doc/rfc/rfc9073.txt
new file mode 100644
index 0000000..b712af7
--- /dev/null
+++ b/doc/rfc/rfc9073.txt
@@ -0,0 +1,1453 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       M. Douglass
+Request for Comments: 9073                                      Bedework
+Updates: 5545                                                August 2021
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+                Event Publishing Extensions to iCalendar
+
+Abstract
+
+   This specification updates RFC 5545 by introducing a number of new
+   iCalendar properties and components that are of particular use for
+   event publishers and in social networking.
+
+   This specification also defines a new "STRUCTURED-DATA" property for
+   iCalendar (RFC 5545) to allow for data that is directly pertinent to
+   an event or task to be included with the calendar data.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9073.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Conventions Used in This Document
+     1.2.  Terms Used in This Document
+   2.  Components and Properties
+   3.  Typed References
+     3.1.  Use Cases
+       3.1.1.  Piano Concert Performance
+       3.1.2.  Itineraries
+         3.1.2.1.  Reserving Facilities
+   4.  Modifications to Calendar Components
+   5.  New Property Parameters
+     5.1.  Order
+     5.2.  Schema
+     5.3.  Derived
+   6.  New Properties
+     6.1.  Location Type
+     6.2.  Participant Type
+     6.3.  Resource Type
+     6.4.  Calendar Address
+     6.5.  Styled-Description
+     6.6.  Structured-Data
+   7.  New Components
+     7.1.  Participant
+       7.1.1.  Schedulable Participant
+     7.2.  Location
+     7.3.  Resource
+   8.  Extended Examples
+     8.1.  Example 1
+     8.2.  Example 2
+   9.  Security Considerations
+     9.1.  URIs
+     9.2.  Malicious Content
+     9.3.  HTML Content
+   10. Privacy Considerations
+     10.1.  Tracking
+     10.2.  Revealing Locations
+   11. IANA Considerations
+     11.1.  Additional iCalendar Registrations
+       11.1.1.  Properties
+       11.1.2.  Parameters
+       11.1.3.  Components
+     11.2.  Participant Types and Resource Types Registries
+       11.2.1.  Participant Types
+       11.2.2.  Resource Types
+   12. Normative References
+   Acknowledgements
+   Author's Address
+
+1.  Introduction
+
+   The currently existing iCalendar standard [RFC5545] lacks useful
+   methods for referencing additional, external information relating to
+   calendar components.  Additionally, there is no standard way to
+   provide rich-text descriptions or metadata associated with the event.
+
+   Current practice is to embed this information as links in the
+   description or to add nonstandard properties, as defined in
+   Section 3.8.8.2 of [RFC5545].
+
+   This document updates [RFC5545] 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, such as vCard [RFC6350], are likely to be
+   most useful to the receivers of such events as they may be used in
+   other applications -- such as address books.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   The notation used in this memo is the ABNF notation of [RFC5234] as
+   used by iCalendar [RFC5545].  Any syntax elements shown below that
+   are not explicitly defined in this specification come from iCalendar
+   [RFC5545].
+
+1.2.  Terms Used in This Document
+
+   Event:  When the word 'event' (perhaps with a capitalized 'E') is
+      used, we are referring to gatherings, formal or informal (for
+      example, a sports event, a party, or a concert).
+
+   Social Calendaring:  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., social, model.  For example, we may want to
+      record who is participating in a public event.
+
+2.  Components and Properties
+
+   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 [RFC5545].
+
+   In a break with this 'convention', this specification defines a
+   number of components rather than properties.  This is a better match
+   for the way [W3C.REC-xml-20081126] and JSON [RFC8259] handle such
+   structures and allows richer definitions.
+
+   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.
+
+3.  Typed References
+
+   The properties and components defined here can all reference external
+   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 presenting additional, related
+   information for the user.
+
+   As always, clients should exercise caution in following references to
+   external data.
+
+   The "LOCATION" property [RFC5545] 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., address, region, country, or postal code)
+   is required or preferred and limits widespread adoption of iCalendar
+   in those settings.
+
+   Using the "VLOCATION" component, rich information about multiple
+   locations can be communicated in a "STRUCTURED-DATA" property;
+   examples include address, region, country, postal code, parking
+   availability, nearby restaurants, and the venue, among others.
+   Servers and clients can retrieve the objects when storing the event
+   and use them to index by geographic location.
+
+   When a calendar client receives a calendar component, it can search
+   the set of locations looking for those of particular interest.  The
+   "LOCATION-TYPE" property and "FMTTYPE" parameter applied to the
+   "STRUCTURED-DATA" property, if supplied, can be used to help the
+   selection.
+
+   The "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, it is often important
+   to identify the active participants (e.g,, a school sports team) and
+   the inactive participants (e.g., the parents) in the event.
+
+   The "PARTICIPANT" component can be used to provide useful extra data
+   about an attendee.  For example, a location inside the PARTICIPANT
+   gives the actual location of a remote attendee.  (But see the note
+   about privacy.)
+
+   Alternatively, the "PARTICIPANT" component can be used to provide a
+   reference -- perhaps the address for mailing lists.
+
+3.1.  Use Cases
+
+   The main motivation for these changes has been event publication, but
+   there are opportunities for use elsewhere.  The following use cases
+   will describe some possible scenarios.
+
+3.1.1.  Piano Concert Performance
+
+   In putting together a concert, there are many participants: piano
+   tuner, performer, stage hands, etc.  In 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.
+
+   There may be an iCalendar Transport-independent Interoperability
+   Protocol (iTIP) [RFC5546] meeting request for the piano tuner, who
+   will arrive before the performance.  Other members of staff may also
+   receive meeting requests.
+
+   An event can also be created for publication, which will have a
+   "PARTICIPANT" component for the pianist providing a reference to
+   vCard information ([RFC6350]) about the performer.  This event would
+   also hold information about parking, local subway stations, and the
+   venue itself.  In addition, there may be sponsorship information for
+   sponsors of the event and perhaps paid sponsorship properties,
+   essentially advertising local establishments.
+
+3.1.2.  Itineraries
+
+   These additions also provide opportunities for the travel industry.
+   When booking a flight, the "PARTICIPANT" component can be used to
+   provide references to businesses at the airports and to rental car
+   businesses at the destination.
+
+   The embedded location information can guide the traveler around the
+   airport itself or to their final destination.  The contact
+   information can provide detailed information about the booking agent,
+   airlines, car hire companies, and hotel.
+
+3.1.2.1.  Reserving Facilities
+
+   For a meeting, the size of a room and the equipment needed depends,
+   to some extent, on the number of attendees actually in the room.
+
+   A meeting may have many attendees, none of which are co-located.  The
+   current "ATTENDEE" property does not allow for the addition of such
+   metadata.  The "PARTICIPANT" component allows attendees to specify
+   their location.
+
+4.  Modifications to Calendar Components
+
+   The following changes to the syntax defined in iCalendar [RFC5545]
+   are made here.  New elements are defined in subsequent sections.
+
+   ; Addition of PARTICIPANT, 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, and VRESOURCE
+   ; as valid components
+   todoc      = "BEGIN" ":" "VTODO" CRLF
+                todoprop *alarmc *participantc *locationc *resourcec
+                "END" ":" "VTODO" CRLF
+
+   ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
+   todoprop =/ *styleddescription
+               *sdataprop
+
+   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
+   ; as valid components
+   journalc   = "BEGIN" ":" "VJOURNAL" CRLF
+                jourprop *participantc *locationc *resourcec
+                "END" ":" "VJOURNAL" CRLF
+
+   ; Addition of properties STYLED-DESCRIPTION and STRUCTURED-DATA
+   jourprop =/ *styleddescription
+               *sdataprop
+
+   ; Addition of PARTICIPANT, VLOCATION, and VRESOURCE
+   ; as valid components
+   freebusyc  = "BEGIN" ":" "VFREEBUSY" CRLF
+                fbprop *participantc *locationc *resourcec
+                "END" ":" "VFREEBUSY" CRLF
+
+   ; Addition of property STYLED-DESCRIPTION
+   fbprop     =/ *styleddescription
+
+5.  New Property Parameters
+
+5.1.  Order
+
+   Parameter name:  ORDER
+
+   Purpose:  This parameter defines ordering for the associated
+      property.
+
+   Format Definition:  This parameter is defined by the following
+      notation:
+
+      orderparam    = "ORDER" "=" integer
+                      ;           Must be greater than or equal to 1
+
+   Description:  The "ORDER" parameter is OPTIONAL and is used to
+      indicate the relative ordering of the corresponding instance of a
+      property.  Its value MUST be an integer greater than or equal to 1
+      that specifies the order, with 1 being the first in the ordering.
+
+      When the parameter is absent, the default MUST 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.
+
+      When any "ORDER" parameters have the same value, all the
+      associated properties appear as a group within which there is no
+      defined order.
+
+      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.
+
+      This parameter MUST NOT be applied to a property that does not
+      allow multiple instances.
+
+   Example uses:  The ORDER may be applied to the "PARTICIPANT-TYPE"
+      property to indicate the relative importance of the participant,
+      for example, as a sponsor or a performer.  For example, ORDER=1
+      could define the principal performer or soloist.
+
+5.2.  Schema
+
+   Parameter Name:  SCHEMA
+
+   Purpose:  This parameter specifies the schema used for the content of
+      a "STRUCTURED-DATA" property value.
+
+   Format Definition:  This parameter is defined by the following
+      notation:
+
+      schemaparam    = "SCHEMA" "=" DQUOTE uri DQUOTE
+
+   Description:  This property parameter SHOULD be specified on
+      "STRUCTURED-DATA" properties.  When 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.
+
+   Example:
+        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==
+
+5.3.  Derived
+
+   Parameter Name:  DERIVED
+
+   Purpose:  This parameter specifies that the value of the associated
+      property is derived from some other property value or values.
+
+   Format Definition:  This parameter is defined by the following
+      notation:
+
+      derivedparam    = "DERIVED" "=" ("TRUE" / "FALSE")
+      ; Default is FALSE
+
+   Description:  This property parameter MAY be specified on any
+      property when the value is derived from some other property or
+      properties.  When present with a value of TRUE, clients MUST NOT
+      update the property.
+
+      As an example, if a "STYLED-DESCRIPTION" property is present with
+      FMTTYPE="application/rtf", then there may be an additional
+      "STYLED-DESCRIPTION" property with FMTTYPE="text/html" and
+      DERIVED=TRUE, as well as a value created from the rtf value.
+
+   Example:
+      STYLED-DESCRIPTION;FMTTYPE=text/html;
+       DERIVED=TRUE:<html>...</html>
+
+6.  New Properties
+
+   This specification makes use of the "NAME" property, which is defined
+   in [RFC7986].
+
+6.1.  Location Type
+
+   Property Name:  LOCATION-TYPE
+
+   Purpose:  This property specifies the type(s) of a location.
+
+   Value Type:  The value type for this property is TEXT.  The allowable
+      values are defined below.
+
+   Description:  This property MAY be specified in "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.
+
+   Format Definition:  This property is defined by the following
+      notation:
+
+      loctype      = "LOCATION-TYPE" loctypeparam ":"
+                     text *("," text)
+                     CRLF
+
+      loctypeparam   = *(";" other-param)
+
+      Multiple values may be used if the location has multiple purposes,
+      for example, a hotel and a restaurant.
+
+      Values for this parameter are taken from the values defined in
+      Section 3 of [RFC4589].  New location types SHOULD be registered
+      in the manner laid down in Section 5 of [RFC4589].
+
+6.2.  Participant Type
+
+   Property Name:  PARTICIPANT-TYPE
+
+   Purpose:  This property specifies the type of participant.
+
+   Value Type:  The value type for this property is TEXT.  The allowable
+      values are defined below.
+
+   Property Parameters:  Nonstandard parameters can be specified on this
+      property.
+
+   Conformance:  This property MUST be specified once within a
+      "PARTICIPANT" component.
+
+   Description:  This property defines the type of participation in
+      events or tasks.  Participants can be individuals or
+      organizations, for example, a soccer team, the spectators, or the
+      musicians.
+
+   Format Definition:  This property is defined by the following
+      notation:
+
+      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)
+
+   Example:  The following is an example of this property.
+
+      PARTICIPANT-TYPE:SPEAKER
+
+   The registered values for the "PARTICIPANT-TYPE" property have the
+   meanings described here:
+
+   ACTIVE:  A participant taking an active role -- for example, a team
+      member.
+
+   INACTIVE:  A participant taking an inactive role -- for example, an
+      audience member.
+
+   SPONSOR:  A sponsor of the event.  The "ORDER" parameter may be used
+      with this participant type to define the relative order of
+      multiple sponsors.
+
+   CONTACT:  Contact information for the event.  The "ORDER" parameter
+      may be used with this participant type to define the relative
+      order of multiple contacts.
+
+   BOOKING-CONTACT:  Contact information for reservations or payment.
+
+   EMERGENCY-CONTACT:  Contact in case of emergency.
+
+   PUBLICITY-CONTACT:  Contact for publicity.
+
+   PLANNER-CONTACT:  Contact for the event planner or organizer.
+
+   PERFORMER:  A performer -- for example, the soloist or the
+      accompanist.  The "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.
+
+   SPEAKER:  Speaker at an event.
+
+6.3.  Resource Type
+
+   Property Name:  RESOURCE-TYPE
+
+   Purpose:  This property specifies the type of resource.
+
+   Value Type:  The value type for this property is TEXT.  The allowable
+      values are defined below.
+
+   Format Definition:  This property is defined by the following
+      notation:
+
+      restypeprop   = "RESOURCE-TYPE" restypeparam ":"
+                      restypevalue CRLF
+
+      restypevalue  = ("ROOM"
+                     / "PROJECTOR"
+                     / "REMOTE-CONFERENCE-AUDIO"
+                     / "REMOTE-CONFERENCE-VIDEO"
+                     / iana-token)     ; Other IANA-registered
+                     ; values
+
+      restypeparam   = *(";" other-param)
+
+   Description:  This property MAY be specified in "VRESOURCE"
+      components and provides a way to differentiate multiple resources.
+
+      The registered values are described below.  New resource types
+      SHOULD be registered in the manner laid down in this
+      specification.
+
+   ROOM:  A room for the event/meeting.
+
+   PROJECTOR:  Projection equipment.
+
+   REMOTE-CONFERENCE-AUDIO:  Audio remote conferencing facilities.
+
+   REMOTE-CONFERENCE-VIDEO:  Video remote conferencing facilities.
+
+6.4.  Calendar Address
+
+   Property Name:  CALENDAR-ADDRESS
+
+   Purpose:  This property specifies the calendar address for a
+      participant.
+
+   Value Type:  CAL-ADDRESS
+
+   Property Parameters:  IANA-registered or nonstandard property
+      parameters can be specified on this property.
+
+   Conformance:  This property MAY be specified once within a
+      "PARTICIPANT" component.
+
+   Description:  This property provides a calendar user address for the
+      participant.  If there is an "ATTENDEE" property with the same
+      value, then the participant is schedulable.
+
+   Format Definition:  This property is defined by the following
+      notation:
+
+      calendaraddress   = "CALENDAR-ADDRESS" caladdressparam ":"
+                     cal-address CRLF
+
+      caladdressparam   = *(";" other-param)
+
+6.5.  Styled-Description
+
+   Property Name:  STYLED-DESCRIPTION
+
+   Purpose:  This property provides for one or more rich-text
+      descriptions to replace that provided by the "DESCRIPTION"
+      property.
+
+   Value Type:  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 ignore
+      any properties with value types they do not understand.
+
+   Property Parameters:  IANA-registered, nonstandard, id, alternate
+      text representation, format type, derived, and language property
+      parameters can be specified on this property.
+
+   Conformance:  The property can be specified multiple times in the
+      "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY", "PARTICIPANT", or
+      "VALARM" calendar components.
+
+      If it does appear more than once, there MUST be exactly one
+      instance of the property with no "DERIVED" parameter or
+      DERIVED=FALSE.  All others MUST have DERIVED=TRUE.
+
+      Additionally, if there is one or more "STYLED-DESCRIPTION"
+      property, then the "DESCRIPTION" property should either be absent
+      or have the parameter DERIVED=TRUE.
+
+   Description:  This property supports rich-text descriptions, for
+      example, HTML.  Event publishers typically wish to provide more
+      and better-formatted information about the event.
+
+      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 and to capture the body text
+      for an EMAIL category of alarm.  In the "PARTICIPANT" component,
+      it provides a detailed description of the participant.
+
+      VALUE=TEXT is used to provide rich text inline as the property
+      value.
+
+      VALUE=URI is used to provide a link to rich-text content, which is
+      expected to be displayed inline as part of the event.
+
+      In either case, the "DESCRIPTION" property should be absent or
+      contain a plain-text rendering of the styled text.
+
+      Applications MAY 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 treat it as
+      type "text/html" and process the content as defined in
+      [W3C.REC-html51-20171003].
+
+      Multiple "STYLED-DESCRIPTION" properties may be used to provide
+      different formats or different language variants.  However, all
+      but one MUST have DERIVED=TRUE.
+
+   Format Definition:  This property is defined by the following
+      notation:
+
+      styleddescription = "STYLED-DESCRIPTION" styleddescparam ":"
+                         styleddescval CRLF
+
+      styleddescparam   = *(
+                         ; The following is REQUIRED
+                         ; but MUST NOT occur more than once.
+                         ;
+                         (";" "VALUE" "=" ("URI" / "TEXT")) /
+                         ;
+                         ; 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
+
+   Example:  The following is an example of this property.  It points to
+      an HTML description.
+
+      STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html
+
+6.6.  Structured-Data
+
+   Property Name:  STRUCTURED-DATA
+
+   Purpose:  This property specifies ancillary data associated with the
+      calendar component.
+
+   Value Type:  There is no default value type for this property.  The
+      value type can be set to TEXT, BINARY, or URI.
+
+   Property Parameters:  IANA-registered, nonstandard, inline 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 be present for text or inline binary
+      encoded content information.
+
+   Conformance:  This property can be specified multiple times in an
+      iCalendar object.  Typically, it would be used in the "VEVENT",
+      "VTODO", or "VJOURNAL" calendar components.
+
+   Description:  The existing properties in iCalendar cover key elements
+      of events and tasks, such as start time, end time, location,
+      summary, etc.  However, different types of events often have other
+      specific "fields" that 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, 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.
+
+      This property is used to specify ancillary data in some structured
+      format, either directly (inline) as a "TEXT" or "BINARY" value or
+      as a link via a "URI" value.
+
+      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> include different event types.  By using
+      standard schemas, interoperability can be improved between
+      calendar clients and noncalendaring systems that wish to generate
+      or process the data.
+
+      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.
+
+      iCalendar does support an "ATTACH" 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, 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, some implementations
+      manage attachments by stripping them out and replacing with a link
+      to the resource.  Thus, a new property to support inclusion of
+      schema data is warranted.
+
+   Format Definition:  This property is defined by the following
+      notation:
+
+      sdataprop    = "STRUCTURED-DATA" sdataparam
+                       (
+                         ";" "VALUE" "=" "TEXT"
+                         ":" text
+                       ) /
+                       (
+                         ";" "ENCODING" "=" "BASE64"
+                         ";" "VALUE" "=" "BINARY"
+                         ";" binary
+                       ) /
+                       (
+                         ";" "VALUE" "=" "URI"
+                         ":" uri
+                       )
+                       CRLF
+
+      sdataparam  = *(
+                       ;
+                       ; The following is OPTIONAL for a URI value,
+                       ; REQUIRED for a TEXT or BINARY value,
+                       ; and MUST NOT occur more than once.
+                       ;
+                       (";" fmttypeparam) /
+                       (";" schemaparam) /
+                       ;
+                       ; The following is OPTIONAL
+                       ; and MAY occur more than once.
+                       ;
+                       (";" other-param)
+                       ;
+                    )
+
+   Example:  The following is an example of this property.
+
+      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
+
+7.  New Components
+
+7.1.  Participant
+
+   Component name:  PARTICIPANT
+
+   Purpose:  This component provides information about a participant in
+      an event or task.
+
+   Conformance:  This component can be specified multiple times in a
+      "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component.
+
+   Description:  This component provides information about a participant
+      in a calendar component.  A participant may be an attendee in a
+      scheduling sense, and the "ATTENDEE" property may be specified in
+      addition.  Participants can be individuals or organizations, for
+      example, a soccer team, the spectators, or the musicians.
+
+      "STRUCTURED-DATA" properties, if present, may refer to definitions
+      of the participant -- such as a vCard.
+
+      The "CALENDAR-ADDRESS" property, if present, will provide a cal-
+      address.  If an "ATTENDEE" property has the same value, the
+      participant is considered schedulable.  The "PARTICIPANT"
+      component can be used to contain additional metadata related to
+      the attendee.
+
+   Format Definition:  This component is defined by the following
+      notation:
+
+      participantc = "BEGIN" ":" "PARTICIPANT" CRLF
+                     partprop *locationc *resourcec
+                     "END" ":" "PARTICIPANT" CRLF
+
+      partprop     = *(
+                     ;
+                     ; 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
+                     ;
+                     )
+
+   Note:  When the "PRIORITY" property is supplied, it defines the
+      ordering of "PARTICIPANT" components with the same value for the
+      "PARTICIPANT-TYPE" property.
+
+   Privacy Issues:  When a "LOCATION" property is 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 broadcast this information
+      without the express permission of the participants whose location
+      would be exposed.  For further comments, see Section 10.
+
+   Example:  The following is an example of this component.  It contains
+      a "STRUCTURED-DATA" property that points to a vCard providing
+      information about the event participant.
+
+      BEGIN:PARTICIPANT
+      UID: em9lQGZvb2GFtcGxlLmNvbQ
+      PARTICIPANT-TYPE:PERFORMER
+      STRUCTURED-DATA;VALUE=URI:
+       http://dir.example.com/vcard/aviolinist.vcf
+      END:PARTICIPANT
+
+   Example:  The following is an example for the primary contact.
+
+      BEGIN:PARTICIPANT
+      UID: em9lQGZvb2GFtcGxlLmNvbQ
+      STRUCTURED-DATA;VALUE=URI;
+       http://dir.example.com/vcard/contacts/contact1.vcf
+      PARTICIPANT-TYPE:CONTACT
+      DESCRIPTION:A contact
+      END:PARTICIPANT
+
+   Example:  The following is an example for a participant with contact
+      and location.
+
+      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
+
+7.1.1.  Schedulable Participant
+
+   A "PARTICIPANT" component may represent someone or something that
+   needs to be scheduled, as defined for ATTENDEE in [RFC5545] and
+   [RFC5546].  The "PARTICIPANT" component may also represent someone or
+   something that is NOT to receive scheduling messages.
+
+   For backwards compatibility with existing clients and servers when
+   used to schedule events and tasks, the "ATTENDEE" property MUST be
+   used to specify the scheduling parameters as defined for that
+   property.
+
+   For other, future uses, the "CALENDAR-ADDRESS" property MUST be used
+   to specify those parameters.
+
+   A "PARTICIPANT" component is defined to be schedulable if:
+
+   *  it contains a "CALENDAR-ADDRESS" property and
+
+   *  that property value is the same as the value for an "ATTENDEE"
+      property.
+
+   If both of these conditions apply, then the participant defined by
+   the value of the URL property will take part in scheduling
+   operations, as defined in [RFC5546].
+
+   An appropriate use for the "PARTICIPANT" component in scheduling
+   would be to store "SEQUENCE" and "DTSTAMP" properties associated with
+   replies from each "ATTENDEE" property.  A "LOCATION" property within
+   the "PARTICIPANT" component might allow better selection of meeting
+   times when participants are in different time zones.
+
+7.2.  Location
+
+   Component name:  VLOCATION
+
+   Purpose:  This component provides rich information about the location
+      of an event using the structured data property or, optionally, a
+      plain-text typed value.
+
+   Conformance:  This component can be specified multiple times in a
+      "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY", or "PARTICIPANT"
+      calendar component.
+
+   Description:  There may be a number of locations associated with an
+      event.  This component provides detailed information about a
+      location.
+
+      When used in a component, the value of this property provides
+      information about the event venue or of related services, such as
+      parking, dining, stations, etc.
+
+      "STRUCTURED-DATA" properties, if present, may refer to
+      representations of the location -- such as a vCard.
+
+   Format Definition:  This component is defined by the following
+      notation:
+
+      locationc    = "BEGIN" ":" "VLOCATION" CRLF
+                     locprop
+                     "END" ":" "VLOCATION" CRLF
+
+      locprop      = *(
+                     ;
+                     ; The following are REQUIRED
+                     ; but MUST NOT occur more than once.
+                     ;
+                     uid /
+                     ;
+                     ; The following are OPTIONAL
+                     ; but MUST NOT occur more than once.
+                     ;
+                     description / geo / loctype / name
+                     ;
+                     ; The following are OPTIONAL
+                     ; and MAY occur more than once.
+                     ;
+                     sdataprop / iana-prop
+                  )
+
+      The "NAME" property is defined in [RFC7986].
+
+   Example:  The following is an example of this component.  It points
+      to a venue.
+
+      BEGIN:VLOCATION
+      UID:123456-abcdef-98765432
+      NAME:The venue
+      STRUCTURED-DATA;VALUE=URI:
+       http://dir.example.com/venues/big-hall.vcf
+      END:VLOCATION
+
+7.3.  Resource
+
+   Component name:  VRESOURCE
+
+   Purpose:  This component provides a typed reference to external
+      information about a resource or, optionally, a plain-text typed
+      value.  Typically, a resource is anything that might be required
+      or used by a calendar entity and possibly has a directory entry.
+
+   Conformance:  This component can be specified multiple times in a
+      "VEVENT", "VTODO", "VJOURNAL", "VFREEBUSY", or "PARTICIPANT"
+      calendar component.
+
+   Description:  When used in a component, this component provides
+      information about resources used for the event, such as rooms,
+      projectors, and conferencing capabilities.
+
+      The RESOURCE-TYPE value registry provides a place in which
+      resource types may be registered.
+
+      "STRUCTURED-DATA" properties, if present, may refer to
+      representations of the resource -- such as a vCard.
+
+   Format Definition:  This component is defined by the following
+      notation:
+
+      resourcec    = "BEGIN" ":" "VRESOURCE" CRLF
+                     resprop
+                     "END" ":" "VRESOURCE" CRLF
+
+      resprop      = *(
+                     ;
+                     ; The following are REQUIRED
+                     ; but MUST NOT occur more than once.
+                     ;
+                     uid /
+                     ;
+                     ; The following are OPTIONAL
+                     ; but MUST NOT occur more than once.
+                     ;
+                     description / geo / name / restype /
+                     ;
+                     ; The following are OPTIONAL
+                     ; and MAY occur more than once.
+                     ;
+                     sdataprop / iana-prop
+                   )
+
+      The "NAME" property is defined in [RFC7986].
+
+   Example:  The following is an example of this component.  It refers
+      to a projector.
+
+      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
+
+8.  Extended Examples
+
+   The following are some examples of the use of the properties defined
+   in this specification.  They include additional properties defined in
+   [RFC7986], which includes "IMAGE".
+
+8.1.  Example 1
+
+   The following is an example of a "VEVENT" describing a concert.  It
+   includes location information for the venue itself, as well as
+   references to parking and restaurants.
+
+   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
+
+8.2.  Example 2
+
+   The following is an example of a "VEVENT" describing a meeting.  One
+   of the attendees is a remote participant.
+
+   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
+
+9.  Security Considerations
+
+   This specification extends [RFC5545] and makes further use of
+   possibly linked data.  While calendar data is not unique in this
+   regard, it is worth reminding implementors of some of the dangers and
+   safeguards.
+
+9.1.  URIs
+
+   See [RFC3986] for a discussion of the security considerations
+   relating to URIs.  Because of the issues discussed there and below,
+   clients SHOULD NOT follow URIs and fetch content automatically and
+   should only do so at the explicit request of the user.
+
+   Fetching remote resources carries inherent risks.  Connections must
+   only be allowed on 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.
+
+   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.
+
+9.2.  Malicious Content
+
+   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, and deleting structured data.
+
+   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.
+
+   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 check this property for malicious or
+   inappropriate content.  Upon detecting such content, servers SHOULD
+   remove the property.
+
+9.3.  HTML Content
+
+   When processing HTML content, applications need to be aware of the
+   many security and privacy issues, as described in the IANA
+   Considerations section of [W3C.REC-html51-20171003].
+
+10.  Privacy Considerations
+
+10.1.  Tracking
+
+   Properties with a "URI" value type can expose their users to privacy
+   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 automatically download data referenced by the URI
+   without explicit instruction from users.
+
+   To help alleviate some of the concerns, protocols and services could
+   provide proxy services for downloading referenced data.
+
+10.2.  Revealing Locations
+
+   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 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.
+
+   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.
+
+   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.
+
+   For example, there may be some privacy considerations relating to the
+   "ORDER" parameter, as it provides an indication of the organizer's
+   perception of the relative importance of other participants.
+
+11.  IANA Considerations
+
+11.1.  Additional iCalendar Registrations
+
+11.1.1.  Properties
+
+   This document defines the following iCalendar properties that have
+   been added to the "Properties" registry defined in Section 8.2.3 of
+   [RFC5545]:
+
+         +====================+=========+=======================+
+         | Property           | Status  | Reference             |
+         +====================+=========+=======================+
+         | CALENDAR-ADDRESS   | Current | RFC 9073, Section 6.4 |
+         +--------------------+---------+-----------------------+
+         | LOCATION-TYPE      | Current | RFC 9073, Section 6.1 |
+         +--------------------+---------+-----------------------+
+         | PARTICIPANT-TYPE   | Current | RFC 9073, Section 6.2 |
+         +--------------------+---------+-----------------------+
+         | RESOURCE-TYPE      | Current | RFC 9073, Section 6.3 |
+         +--------------------+---------+-----------------------+
+         | STRUCTURED-DATA    | Current | RFC 9073, Section 6.6 |
+         +--------------------+---------+-----------------------+
+         | STYLED-DESCRIPTION | Current | RFC 9073, Section 6.5 |
+         +--------------------+---------+-----------------------+
+
+              Table 1: Additions to the Properties Registry
+
+11.1.2.  Parameters
+
+   This document defines the following iCalendar property parameters
+   that have been added to the "Parameters" registry defined in
+   Section 8.2.4 of [RFC5545]:
+
+              +===========+=========+=======================+
+              | Parameter | Status  | Reference             |
+              +===========+=========+=======================+
+              | ORDER     | Current | RFC 9073, Section 5.1 |
+              +-----------+---------+-----------------------+
+              | SCHEMA    | Current | RFC 9073, Section 5.2 |
+              +-----------+---------+-----------------------+
+              | DERIVED   | Current | RFC 9073, Section 5.3 |
+              +-----------+---------+-----------------------+
+
+               Table 2: Additions to the Parameters Registry
+
+11.1.3.  Components
+
+   This document defines the following iCalendar components that have
+   been added to the "Components" registry defined in Section 8.3.1 of
+   [RFC5545]:
+
+             +=============+=========+=======================+
+             | Component   | Status  | Reference             |
+             +=============+=========+=======================+
+             | PARTICIPANT | Current | RFC 9073, Section 7.1 |
+             +-------------+---------+-----------------------+
+             | VLOCATION   | Current | RFC 9073, Section 7.2 |
+             +-------------+---------+-----------------------+
+             | VRESOURCE   | Current | RFC 9073, Section 7.3 |
+             +-------------+---------+-----------------------+
+
+               Table 3: Additions to the Components Registry
+
+11.2.  Participant Types and Resource Types Registries
+
+   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 [RFC5545].
+
+   This document creates new IANA registries for participant and
+   resource types.  IANA will maintain these registries and, following
+   the policies outlined in [RFC8126], new tokens are assigned after
+   Expert Review.  The Expert Reviewer will generally consult the IETF
+   GEOPRIV Working Group mailing list or its designated successor.
+   Updates or deletions of tokens from the registration follow the same
+   procedures.  The Expert Review should be guided by a few common-sense
+   considerations.  For example, tokens should not be specific to a
+   country, region, organization, or company; they should be well
+   defined and widely recognized.  The 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 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
+   follow the character set restrictions for XML Names
+   [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.
+
+11.2.1.  Participant Types
+
+          +===================+=========+=======================+
+          | Participant Type  | Status  | Reference             |
+          +===================+=========+=======================+
+          | ACTIVE            | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | INACTIVE          | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | SPONSOR           | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | CONTACT           | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | BOOKING-CONTACT   | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | EMERGENCY-CONTACT | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | PUBLICITY-CONTACT | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | PLANNER-CONTACT   | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | PERFORMER         | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+          | SPEAKER           | Current | RFC 9073, Section 6.2 |
+          +-------------------+---------+-----------------------+
+
+             Table 4: Initial Contents of the Participant Types
+                                  Registry
+
+11.2.2.  Resource Types
+
+       +=========================+=========+=======================+
+       | Resource Type           | Status  | Reference             |
+       +=========================+=========+=======================+
+       | PROJECTOR               | Current | RFC 9073, Section 6.3 |
+       +-------------------------+---------+-----------------------+
+       | ROOM                    | Current | RFC 9073, Section 6.3 |
+       +-------------------------+---------+-----------------------+
+       | REMOTE-CONFERENCE-AUDIO | Current | RFC 9073, Section 6.3 |
+       +-------------------------+---------+-----------------------+
+       | REMOTE-CONFERENCE-VIDEO | Current | RFC 9073, Section 6.3 |
+       +-------------------------+---------+-----------------------+
+
+          Table 5: Initial Contents of the Resource Types Registry
+
+12.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC4589]  Schulzrinne, H. and H. Tschofenig, "Location Types
+              Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006,
+              <https://www.rfc-editor.org/info/rfc4589>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5545]  Desruisseaux, B., Ed., "Internet Calendaring and
+              Scheduling Core Object Specification (iCalendar)",
+              RFC 5545, DOI 10.17487/RFC5545, September 2009,
+              <https://www.rfc-editor.org/info/rfc5545>.
+
+   [RFC5546]  Daboo, C., Ed., "iCalendar Transport-Independent
+              Interoperability Protocol (iTIP)", RFC 5546,
+              DOI 10.17487/RFC5546, December 2009,
+              <https://www.rfc-editor.org/info/rfc5546>.
+
+   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
+              DOI 10.17487/RFC6350, August 2011,
+              <https://www.rfc-editor.org/info/rfc6350>.
+
+   [RFC7986]  Daboo, C., "New Properties for iCalendar", RFC 7986,
+              DOI 10.17487/RFC7986, October 2016,
+              <https://www.rfc-editor.org/info/rfc7986>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", STD 90, RFC 8259,
+              DOI 10.17487/RFC8259, December 2017,
+              <https://www.rfc-editor.org/info/rfc8259>.
+
+   [W3C.REC-html51-20171003]
+              Faulkner, S., Ed., Eicholz, A., Ed., Leithead, T., Ed.,
+              and A. Danilo, Ed., "HTML 5.1 2nd Edition", World Wide Web
+              Consortium Recommendation REC-html51-20171003, October
+              2017, <https://www.w3.org/TR/2017/REC-html51-20171003>.
+
+   [W3C.REC-xml-20040204]
+              Sperberg-McQueen, M., Maler, E., Bray, T., Paoli, J., and
+              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
+              Edition)", World Wide Web Consortium Recommendation REC-
+              xml-20040204, February 2004,
+              <https://www.w3.org/TR/2004/REC-xml-20040204>.
+
+   [W3C.REC-xml-20081126]
+              Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, M., Ed.,
+              Maler, E., Ed., and F. Yergeau, Ed., "Extensible Markup
+              Language (XML) 1.0 (Fifth Edition)", World Wide Web
+              Consortium Recommendation REC-xml-20081126, November 2008,
+              <https://www.w3.org/TR/2008/REC-xml-20081126>.
+
+Acknowledgements
+
+   The author would like to thank Chuck Norris of eventful.com for his
+   work, which led to the development of this RFC.
+
+   The author would also like to thank the members of CalConnect: The
+   Calendaring and Scheduling Consortium, the Event Publication
+   technical committee, and the following individuals for contributing
+   their ideas and support:
+
+   Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, and Scott Otis.
+
+Author's Address
+
+   Michael Douglass
+   Bedework
+   226 3rd Street
+   Troy, NY 12180
+   United States of America
+
+   Email: mdouglass@bedework.com
+   URI:   http://bedework.com