summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9073.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9073.txt')
-rw-r--r--doc/rfc/rfc9073.txt1453
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