draft-ietf-calext-eventpub-extensions-06.txt   draft-ietf-calext-eventpub-extensions-07.txt 
Network Working Group M. Douglass Network Working Group M. Douglass
Internet-Draft Spherical Cow Group Internet-Draft Spherical Cow Group
Updates: 5545,5546 (if approved) May 5, 2018 Updates: 5545,5546 (if approved) May 15, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: November 6, 2018 Expires: November 16, 2018
Event Publishing Extensions to iCalendar Event Publishing Extensions to iCalendar
draft-ietf-calext-eventpub-extensions-06 draft-ietf-calext-eventpub-extensions-07
Abstract Abstract
This specification introduces a number of new iCalendar properties This specification updates [RFC5545] and [RFC5546] by introducing a
and components which are of particular use for event publishers and number of new iCalendar properties and components which are of
in social networking. particular use for event publishers and in social networking.
This specification also defines a new STRUCTURED-DATA property for This specification also defines a new STRUCTURED-DATA property for
iCalendar [RFC5545] to allow for data that is directly pertinent to iCalendar [RFC5545] to allow for data that is directly pertinent to
an event or task to be included with the calendar data. an event or task to be included with the calendar data.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2018. This Internet-Draft will expire on November 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2. Components and properties . . . . . . . . . . . . . . . . . . 4 2. Components and properties . . . . . . . . . . . . . . . . . . 4
3. Typed References . . . . . . . . . . . . . . . . . . . . . . 4 3. Typed References . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Piano Concert Performance . . . . . . . . . . . . . . 5 3.1.1. Piano Concert Performance . . . . . . . . . . . . . . 5
3.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 6
3.1.2.1. Reserving facilities . . . . . . . . . . . . . . 6 3.1.2.1. Reserving facilities . . . . . . . . . . . . . . 6
4. Modifications to Calendar Components . . . . . . . . . . . . 6 4. Modifications to Calendar Components . . . . . . . . . . . . 6
5. New Property Parameters . . . . . . . . . . . . . . . . . . . 7 5. New Property Parameters . . . . . . . . . . . . . . . . . . . 7
5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Redefined Property SOURCE . . . . . . . . . . . . . . . . . . 10 6. Redefined Property SOURCE . . . . . . . . . . . . . . . . . . 10
7. New Properties . . . . . . . . . . . . . . . . . . . . . . . 11 7. New Properties . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Participant Type . . . . . . . . . . . . . . . . . . . . 11 7.1. Participant Type . . . . . . . . . . . . . . . . . . . . 12
7.2. Calendar Address . . . . . . . . . . . . . . . . . . . . 12 7.2. Calendar Address . . . . . . . . . . . . . . . . . . . . 13
7.3. Styled-Description . . . . . . . . . . . . . . . . . . . 12 7.3. Styled-Description . . . . . . . . . . . . . . . . . . . 14
7.4. Structured-Location . . . . . . . . . . . . . . . . . . . 14 7.4. Structured-Location . . . . . . . . . . . . . . . . . . . 16
7.5. Structured-Resource . . . . . . . . . . . . . . . . . . . 16 7.5. Structured-Resource . . . . . . . . . . . . . . . . . . . 17
7.6. Structured-Data . . . . . . . . . . . . . . . . . . . . . 17 7.6. Structured-Data . . . . . . . . . . . . . . . . . . . . . 19
8. New Components . . . . . . . . . . . . . . . . . . . . . . . 19 8. New Components . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Schedulable Participant . . . . . . . . . . . . . . . . . 22 8.2. Schedulable Participant . . . . . . . . . . . . . . . . . 24
9. Participant Types . . . . . . . . . . . . . . . . . . . . . . 22 9. Extended examples . . . . . . . . . . . . . . . . . . . . . . 24
10. Resource Types . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Extended examples . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 24 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 12.1. Additional iCalendar Registrations . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12.1.1. Property Registrations . . . . . . . . . . . . . . . 27
14.1. Additional iCalendar Registrations . . . . . . . . . . . 26 12.1.2. Parameter Registrations . . . . . . . . . . . . . . 27
14.1.1. Property Registrations . . . . . . . . . . . . . . . 26 12.1.3. Component Registrations . . . . . . . . . . . . . . 27
14.1.2. Parameter Registrations . . . . . . . . . . . . . . 26 12.2. New Registration Tables . . . . . . . . . . . . . . . . 28
14.1.3. Component Registrations . . . . . . . . . . . . . . 26 12.2.1. Participant Types Registry . . . . . . . . . . . . . 28
14.2. New Registration Tables . . . . . . . . . . . . . . . . 27 12.2.2. Resource Types Registry . . . . . . . . . . . . . . 28
14.2.1. Participant Types Registry . . . . . . . . . . . . . 27 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14.2.2. Resource Types Registry . . . . . . . . . . . . . . 27 14. Normative References . . . . . . . . . . . . . . . . . . . . 29
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 30
16. Normative References . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The currently existing iCalendar standard [RFC5545] lacks useful The currently existing iCalendar standard [RFC5545] lacks useful
methods for referencing additional, external information relating to methods for referencing additional, external information relating to
calendar components. Additionally there is no standard way to calendar components. Additionally there is no standard way to
provide rich text descriptions or meta-data associated with the provide rich text descriptions or meta-data associated with the
event. event.
Current practice is to embed this information as links in the Current practice is to embed this information as links in the
description or to add x-properties. description or to add non-standard properties as defined in [RFC5545]
section 3.8.8.2.
This document defines a number of properties and a component This document updates [RFC5545] to define a number of properties and
referencing such external information that can provide additional a component referencing such external information that can provide
information about an iCalendar component. The intent is to allow additional information about an iCalendar component. The intent is
interchange of such information between applications or systems to allow interchange of such information between applications or
(e.g., between clients, between client and server, and between systems (e.g., between clients, between client and server, and
servers). Formats such as VCARD are likely to be most useful to the between servers). Formats such as VCARD are likely to be most useful
receivers of such events as they may be used in other applications - to the receivers of such events as they may be used in other
such as address books. applications - such as address books.
This specification defines a new PARTICIPANT component. Many people This specification defines a new PARTICIPANT component. Many people
or groups may participate in an event. This component provides or groups may participate in an event. This component provides
detailed information. Such participants may act as attendees to the detailed information. Such participants may act as attendees to the
event (or derived events) or may just provide a reference - perhaps event (or derived events) or may just provide a reference - perhaps
for mailing lists. for mailing lists.
The following properties are defined in this specification The following properties are defined in this specification
STYLED-DESCRIPTION: Supports HTML descriptions. Event publishers STYLED-DESCRIPTION: Supports HTML descriptions. Event publishers
skipping to change at page 4, line 23 skipping to change at page 4, line 22
CALENDAR-ADDRESS: Used in the PARTICIPANT component to provide the CALENDAR-ADDRESS: Used in the PARTICIPANT component to provide the
calendar address of the participant. calendar address of the participant.
In addition the SOURCE property defined in [RFC7986] is redefined to In addition the SOURCE property defined in [RFC7986] is redefined to
allow VALUE=TEXT and broaden its usage. allow VALUE=TEXT and broaden its usage.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Components and properties 2. Components and properties
Previous extensions to the calendaring standards have been largely Previous extensions to the calendaring standards have been largely
restricted to the addition of properties or parameters. This is restricted to the addition of properties or parameters. This is
partly because iCalendar libraries had trouble handling components partly because iCalendar libraries had trouble handling components
nested deeper than those defined in [RFC5545] nested deeper than those defined in [RFC5545]
In a break with this 'tradition' this specification introduces one of In a break with this 'tradition' this specification introduces one of
these extensions as a component rather than a property. This is a these extensions as a component rather than a property. This is a
skipping to change at page 4, line 48 skipping to change at page 4, line 48
It also allows for the addition of extra properties inside the It also allows for the addition of extra properties inside the
component and resolves some of the problems of trying to add detailed component and resolves some of the problems of trying to add detailed
information as a parameter. information as a parameter.
3. Typed References 3. Typed References
The properties defined here can all reference external meta-data The properties defined here can all reference external meta-data
which may be used by applications to provide enhanced value to users. which may be used by applications to provide enhanced value to users.
By providing type information as parameters, clients and servers are By providing type information as parameters, clients and servers are
able to discover interesting references and make use of them, perhaps able to discover interesting references and make use of them, perhaps
for indexing or the presentation of additional related information for indexing or the presenting of additional related information for
for the user. the user.
The [RFC5545] LOCATION property provides only an unstructured single The [RFC5545] LOCATION property provides only an unstructured single
text value for specifying the location where an event (or task) will text value for specifying the location where an event (or task) will
occur. This is inadequate for use cases where structured location occur. This is inadequate for use cases where structured location
information (e.g. address, region, country, postal code) is required information (e.g. address, region, country, postal code) is required
or preferred, and limits widespread adoption of iCalendar in those or preferred, and limits widespread adoption of iCalendar in those
settings. settings.
Using STRUCTURED-LOCATION, information about a number of interesting Using STRUCTURED-LOCATION, information about a number of interesting
locations can be communicated, for example, parking, restaurants and locations can be communicated, for example, address, region, country,
the venue. Servers and clients can retrieve the objects when storing postal code as well as other informations such as the parking,
the event and use them to index by geographic location. restaurants and the venue. 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 When a calendar client receives a calendar component it can search
the set of supplied properties looking for those of particular the set of supplied properties looking for those of particular
interest. The TYPE and FMTTYPE parameters, if supplied, can be used interest. The TYPE and FMTTYPE parameters, if supplied, can be used
to help the selection. to help the selection.
The PARTICIPANT component is designed to handle common use cases in The PARTICIPANT component is designed to handle common use cases in
event publication. It is generally important to provide information event publication. It is generally important to provide information
about the organizers of such events. Sponsors wish to be referenced about the organizers of such events. Sponsors wish to be referenced
in a prominent manner. In social calendaring it is often important in a prominent manner. In social calendaring it is often important
skipping to change at page 6, line 22 skipping to change at page 6, line 22
3.1.2. Itineraries 3.1.2. Itineraries
These additions also provide opportunities for the travel industry. These additions also provide opportunities for the travel industry.
When booking a flight the PARTICIPANT component can be used to When booking a flight the PARTICIPANT component can be used to
provide references to businesses at the airports and to car hire provide references to businesses at the airports and to car hire
businesses at the destination. businesses at the destination.
The embedded location information can guide the traveller at the The embedded location information can guide the traveller at the
airport or to their final destination. The contact information can airport or to their final destination. The contact information can
provide detailed information about the booking agent, the airlines provide detailed information about the booking agent, the airlines,
and car hire companies and the hotel. car hire companies and the hotel.
3.1.2.1. Reserving facilities 3.1.2.1. Reserving facilities
For a meeting, the size of a room and the equipment needed depends to 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. some extent on the number of attendees actually in the room.
A meeting may have 10 attendees non of which are co-located. The A meeting may have 10 attendees non of which are co-located. The
current ATTENDEE property dos not allow for the additon of such meta- current ATTENDEE property dos not allow for the additon of such meta-
data. The PARTICIPANT property allows attendees to specify their data. The PARTICIPANT property allows attendees to specify their
location. location.
skipping to change at page 7, line 46 skipping to change at page 7, line 46
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; and MAY occur more than once. ; and MAY occur more than once.
; ;
styleddescription / sdataprop styleddescription / sdataprop
; ;
) )
5. New Property Parameters 5. New Property Parameters
This specification makes use of the LABEL property parameter which is This specification makes use of the LABEL parameter which is defined
defined in [RFC7986] in [RFC7986]
5.1. Loctype 5.1. Loctype
Parameter name: LOCTYPE Parameter name: LOCTYPE
Purpose: To specify the type of location. Purpose: To specify the type of location.
Format Definition: Format Definition:
This parameter is defined by the following notation: This parameter is defined by the following notation:
skipping to change at page 8, line 36 skipping to change at page 8, line 36
5.2. Restype 5.2. Restype
Parameter name: RESTYPE Parameter name: RESTYPE
Purpose: To specify the type of resource. Purpose: To specify the type of resource.
Format Definition: Format Definition:
This parameter is defined by the following notation: This parameter is defined by the following notation:
restypeparam = "RESTYPE" "=" param-value restypeparam = "RESTYPE" "=" restypevalue CRLF
restypevalue = ("ROOM"
/ "PROJECTOR"
/ "REMOTE-CONFERENCE-AUDIO"
/ "REMOTE-CONFERENCE-VIDEO"
/ x-name ; Experimental status
/ iana-token) ; Other IANA-registered
; values
Description: This parameter MAY be specified on STRUCTURED-RESOURCE Description: This parameter MAY be specified on STRUCTURED-RESOURCE
and provides a way to differentiate multiple properties. and provides a way to differentiate multiple properties.
The allowable values are defined in Section 10 New resource types The registered values are described below. New resource types
SHOULD be registered in the manner laid down in this specification 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.
5.3. Order 5.3. Order
Parameter name: ORDER Parameter name: ORDER
Purpose: To define ordering for the associated property. Purpose: To define ordering for the associated property.
Format Definition: Format Definition:
This parameter is defined by the following notation: This parameter is defined by the following notation:
skipping to change at page 11, line 50 skipping to change at page 12, line 14
7. New Properties 7. New Properties
7.1. Participant Type 7.1. Participant Type
Property name: PARTICIPANT-TYPE Property name: PARTICIPANT-TYPE
Purpose: To specify the type of participant. Purpose: To specify the type of participant.
Value type: The value type for this property is TEXT. The allowable Value type: The value type for this property is TEXT. The allowable
values are defined in Section 9. values are defined below.
Property Parameters: Non-standard parameters can be specified on Property Parameters: Non-standard parameters can be specified on
this property. this property.
Conformance: This property MUST be specified within a PARTICIPANT Conformance: This property MUST be specified within a PARTICIPANT
component. component.
Description: This property defines the type of participation in Description: This property defines the type of participation in
events or tasks. Participants can be individuals or events or tasks. Participants can be individuals or
organizations, for example a soccer team, the spectators, or the organizations, for example a soccer team, the spectators, or the
musicians. musicians.
Format Definition: Format Definition:
This parameter is defined by the following notation: This parameter is defined by the following notation:
participanttype = "PARTICIPANT-TYPE" "=" iana-token participanttype = "PARTICIPANT-TYPE" "=" partvalue CRLF
partvalue = ("ACTIVE"
/ "INACTIVE"
/ "SPONSOR"
/ "CONTACT"
/ "BOOKING-CONTACT"
/ "EMERGENCY-CONTACT"
/ "PUBLICITY-CONTACT"
/ "PLANNER-CONTACT"
/ "PERFORMER"
/ "SPEAKER"
/ x-name ; Experimental status
/ iana-token) ; Other IANA-registered
; values
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 part - 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
7.2. Calendar Address 7.2. Calendar Address
Property name: CALENDAR-ADDRESS Property name: CALENDAR-ADDRESS
Purpose: To specify the calendar address for a participant. Purpose: To specify the calendar address for a participant.
Value type: CAL-ADDRESS Value type: CAL-ADDRESS
Property Parameters: IANA or non-standard property parameters can be Property Parameters: IANA or non-standard property parameters can be
skipping to change at page 16, line 18 skipping to change at page 17, line 49
STRUCTURED-LOCATION;LABEL="The venue": STRUCTURED-LOCATION;LABEL="The venue":
http://dir.example.com/venues/big-hall.vcf http://dir.example.com/venues/big-hall.vcf
7.5. Structured-Resource 7.5. Structured-Resource
Property name: STRUCTURED-RESOURCE Property name: STRUCTURED-RESOURCE
Purpose: This property provides a typed reference to external Purpose: This property provides a typed reference to external
information about a resource or optionally a plain text typed information about a resource or optionally a plain text typed
value. value. Typically a resource is anything that might be required or
used by a calendar entity and possibly has a directory entry.
Value type: There is no default value type for this property. The Value type: There is no default value type for this property. The
value type can be set to URI or TEXT. value type can be set to URI or TEXT.
Property Parameters: IANA, non-standard, label, restype or format Property Parameters: IANA, non-standard, label, restype or format
type parameters can be specified on this property. type parameters can be specified on this property.
Conformance: This property MAY be specified zero or more times in Conformance: This property MAY be specified zero or more times in
any iCalendar component. any iCalendar component.
Description: When used in a component the value of this property Description: When used in a component the value of this property
provides information about resources used for the event. provides information about resources used for the event.
Such resources may be a room or a projector. This RESTYPE value
registry provides a place in which resource types may be
registered for use by scheduling sevices.
When a LABEL parameter is supplied the language of the label must When a LABEL parameter is supplied the language of the label must
match that of the content and of the LANGUAGE parameter if match that of the content and of the LANGUAGE parameter if
present. present.
Format Definition: Format Definition:
This property is defined by the following notation: This property is defined by the following notation:
strucres = "STRUCTURED-RESOURCE" strucresparam / strucres = "STRUCTURED-RESOURCE" strucresparam /
( (
skipping to change at page 17, line 41 skipping to change at page 19, line 41
; and MAY occur more than once ; and MAY occur more than once
; ;
(";" other-param) (";" other-param)
) )
Example: Example:
The following is an example of this property. It refers to a The following is an example of this property. It refers to a
projector. projector.
STRUCTURED-RESOURCE;restype="projector": STRUCTURED-RESOURCE;value=uri;restype="projector":
http://dir.example.com/projectors/3d.vcf http://dir.example.com/projectors/3d.vcf
7.6. Structured-Data 7.6. Structured-Data
Property Name: STRUCTURED-DATA Property Name: STRUCTURED-DATA
Purpose: This property specifies ancillary data associated with the Purpose: This property specifies ancillary data associated with the
calendar component. calendar component.
Value Type: TEXT, BINARY or URI Value Type: TEXT, BINARY or URI
skipping to change at page 22, line 38 skipping to change at page 24, line 38
If both of these conditions apply then the participant defined by the If both of these conditions apply then the participant defined by the
value of the URL property will take part in scheduling operations as value of the URL property will take part in scheduling operations as
defined in [RFC5546]. defined in [RFC5546].
An appropriate use for the PARTICIPANT component in scheduling would An appropriate use for the PARTICIPANT component in scheduling would
be to store SEQUENCE and DTSTAMP properties associated with replies be to store SEQUENCE and DTSTAMP properties associated with replies
from each ATTENDEE. A LOCATION property within the PARTICIPANT from each ATTENDEE. A LOCATION property within the PARTICIPANT
component might allow better selection of meeting times when component might allow better selection of meeting times when
participants are in different timezones. participants are in different timezones.
9. Participant Types 9. Extended examples
This section describes types of participation and provides registered
values for the PARTICIPANT-TYPE property.
ACTIVE: A participant taking an active role - for example a team
member.
INACTIVE: A participant taking an inactive part - 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
10. Resource Types
This section describes some initial resource types registered values
for the RESTYPE parameter. Typically a resource is anything that
might be required or used by a calendar entity and possibly has a
directory entry.
Such resources may be a room or a projector. This registry provides
a place in which such resources may be registered for use by
scheduling sevices.
ROOM: A room for he event/meeting.
PROJECTOR: Projection equipment.
REMOTE-CONFERENCE-AUDIO: Audio remote conferencing facilities.
REMOTE-CONFERENCE-VIDEO: Video remote conferencing facilities.
11. Extended examples
The following are some examples of the use of the properties defined The following are some examples of the use of the properties defined
in this specification. They include additional properties defined in in this specification. They include additional properties defined in
[RFC7986] which includes IMAGE. [RFC7986] which includes IMAGE.
11.1. Example 1 9.1. Example 1
The following is an example of a VEVENT describing a concert. It The following is an example of a VEVENT describing a concert. It
includes location information for the venue itself as well as includes location information for the venue itself as well as
references to parking and restaurants. references to parking and restaurants.
BEGIN:VEVENT BEGIN:VEVENT
CREATED:20170216T145739Z CREATED:20170216T145739Z
DESCRIPTION: Piano Sonata No 3\n DESCRIPTION: Piano Sonata No 3\n
Piano Sonata No 30 Piano Sonata No 30
DTSTAMP:20171116T145739Z DTSTAMP:20171116T145739Z
DTSTART;TZID=America/New_York:20170315T150000Z DTSTART;TZID=America/New_York:20170315T150000Z
skipping to change at page 24, line 37 skipping to change at page 25, line 34
BEGIN:PARTICIPANT BEGIN:PARTICIPANT
PARTICIPANT-TYPE:SPONSOR PARTICIPANT-TYPE:SPONSOR
SOURCE:http://example.com/sponsor.vcf SOURCE:http://example.com/sponsor.vcf
END:PARTICIPANT END:PARTICIPANT
BEGIN:PARTICIPANT BEGIN:PARTICIPANT
PARTICIPANT-TYPE:PERFORMER: PARTICIPANT-TYPE:PERFORMER:
SOURCE:http://www.example.com/people/johndoe.vcf SOURCE:http://www.example.com/people/johndoe.vcf
END:PARTICIPANT END:PARTICIPANT
END:VEVENT END:VEVENT
11.2. Example 2 9.2. Example 2
The following is an example of a VEVENT describing a meeting. One of The following is an example of a VEVENT describing a meeting. One of
the attendees is a remote participant. the attendees is a remote participant.
BEGIN:VEVENT BEGIN:VEVENT
CREATED:20170216T145739Z CREATED:20170216T145739Z
DTSTAMP:20101116T145739Z DTSTAMP:20101116T145739Z
DTSTART;TZID=America/New_York:20170315T150000Z DTSTART;TZID=America/New_York:20170315T150000Z
DTEND;TZID=America/New_York:20170315T163000Z DTEND;TZID=America/New_York:20170315T163000Z
LAST-MODIFIED:20170216T145739Z LAST-MODIFIED:20170216T145739Z
SUMMARY:Conference plaaning SUMMARY:Conference plaaning
skipping to change at page 25, line 25 skipping to change at page 26, line 25
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com
BEGIN:PARTICIPANT BEGIN:PARTICIPANT
PARTICIPANT-TYPE:ACTIVE: PARTICIPANT-TYPE:ACTIVE:
SOURCE:http://www.example.com/people/b.vcf SOURCE:http://www.example.com/people/b.vcf
LOCATION:At home LOCATION:At home
END:PARTICIPANT END:PARTICIPANT
END:VEVENT END:VEVENT
12. Security Considerations 10. Security Considerations
Applications using these properties need to be aware of the risks Applications using these properties need to be aware of the risks
entailed in using the URIs provided as values. See [RFC3986] for a entailed in using the URIs provided as values. See [RFC3986] for a
discussion of the security considerations relating to URIs. discussion of the security considerations relating to URIs.
Security considerations relating to the "ATTACH" property, as Security considerations relating to the "ATTACH" property, as
described in [RFC5545], are applicable to the "STRUCTURED-DATA" described in [RFC5545], are applicable to the "STRUCTURED-DATA"
property. property.
13. Privacy Considerations 11. Privacy Considerations
Properties with a "URI" value type can expose their users to privacy Properties with a "URI" value type can expose their users to privacy
leaks as any network access of the URI data can be tracked. Clients leaks as any network access of the URI data can be tracked. Clients
SHOULD NOT automatically download data referenced by the URI without SHOULD NOT automatically download data referenced by the URI without
explicit instruction from users. This specification does not explicit instruction from users. This specification does not
introduce any additional privacy concerns beyond those described in introduce any additional privacy concerns beyond those described in
[RFC5545]. [RFC5545].
14. IANA Considerations 12. IANA Considerations
This section defines updates to the tables defined in [RFC5545] and This section defines updates to the tables defined in [RFC5545] and
new tables. new tables.
14.1. Additional iCalendar Registrations 12.1. Additional iCalendar Registrations
14.1.1. Property Registrations 12.1.1. Property Registrations
This document defines the following new iCalendar properties to be This document defines the following new iCalendar properties to be
added to the registry defined in Section 8.2.3 of [RFC5545]: added to the registry defined in Section 8.2.3 of [RFC5545]:
+---------------------+---------+----------------------+ +---------------------+---------+----------------------+
| Property | Status | Reference | | Property | Status | Reference |
+---------------------+---------+----------------------+ +---------------------+---------+----------------------+
| CALENDAR-ADDRESS | Current | RFCXXXX, Section 7.2 | | CALENDAR-ADDRESS | Current | RFCXXXX, Section 7.2 |
| PARTICIPANT-TYPE | Current | RFCXXXX, Section 7.1 | | PARTICIPANT-TYPE | Current | RFCXXXX, Section 7.1 |
| SOURCE | Current | RFCXXXX, Section 6 | | SOURCE | Current | RFCXXXX, Section 6 |
| STRUCTURED-DATA | Current | RFCXXXX, Section 7.6 | | STRUCTURED-DATA | Current | RFCXXXX, Section 7.6 |
| STYLED-DESCRIPTION | Current | RFCXXXX, Section 7.3 | | STYLED-DESCRIPTION | Current | RFCXXXX, Section 7.3 |
| STRUCTURED-LOCATION | Current | RFCXXXX, Section 7.4 | | STRUCTURED-LOCATION | Current | RFCXXXX, Section 7.4 |
| STRUCTURED-RESOURCE | Current | RFCXXXX, Section 7.5 | | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 7.5 |
+---------------------+---------+----------------------+ +---------------------+---------+----------------------+
14.1.2. Parameter Registrations 12.1.2. Parameter Registrations
This document defines the following new iCalendar property parameters This document defines the following new iCalendar property parameters
to be added to the registry defined in Section 8.2.4 of [RFC5545]: to be added to the registry defined in Section 8.2.4 of [RFC5545]:
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
| Property Parameter | Status | Reference | | Property Parameter | Status | Reference |
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
| LOCTYPE | Current | RFCXXXX, Section 5.1 | | LOCTYPE | Current | RFCXXXX, Section 5.1 |
| ORDER | Current | RFCXXXX, Section 5.3 | | ORDER | Current | RFCXXXX, Section 5.3 |
| RESTYPE | Current | RFCXXXX, Section 5.2 | | RESTYPE | Current | RFCXXXX, Section 5.2 |
| SCHEMA | Current | RFCXXXX, Section 5.4 | | SCHEMA | Current | RFCXXXX, Section 5.4 |
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
14.1.3. Component Registrations 12.1.3. Component Registrations
This document defines the following new iCalendar components to be This document defines the following new iCalendar components to be
added to the registry defined in Section 8.3.1 of [RFC5545]: added to the registry defined in Section 8.3.1 of [RFC5545]:
+-------------+---------+----------------------+ +-------------+---------+----------------------+
| Component | Status | Reference | | Component | Status | Reference |
+-------------+---------+----------------------+ +-------------+---------+----------------------+
| PARTICIPANT | Current | RFCXXXX, Section 8.1 | | PARTICIPANT | Current | RFCXXXX, Section 8.1 |
+-------------+---------+----------------------+ +-------------+---------+----------------------+
14.2. New Registration Tables 12.2. New Registration Tables
This section defines new registration tables for PARTICIPANT-TYPE and This section defines new registration tables for PARTICIPANT-TYPE and
RESTYPE values. These tables maybe updated using the same approaches RESTYPE values. These tables maybe updated using the same approaches
laid down in Section 8.2.1 of [RFC5545] laid down in Section 8.2.1 of [RFC5545]
14.2.1. Participant Types Registry 12.2.1. Participant Types Registry
The following table has been used to initialize the participant types The following table has been used to initialize the participant types
registry. registry.
+-------------------+---------+--------------------+ +-------------------+---------+----------------------+
| Participant Type | Status | Reference | | Participant Type | Status | Reference |
+-------------------+---------+--------------------+ +-------------------+---------+----------------------+
| ACTIVE | Current | RFCXXXX, Section 9 | | ACTIVE | Current | RFCXXXX, Section 7.1 |
| INACTIVE | Current | RFCXXXX, Section 9 | | INACTIVE | Current | RFCXXXX, Section 7.1 |
| SPONSOR | Current | RFCXXXX, Section 9 | | SPONSOR | Current | RFCXXXX, Section 7.1 |
| CONTACT | Current | RFCXXXX, Section 9 | | CONTACT | Current | RFCXXXX, Section 7.1 |
| BOOKING-CONTACT | Current | RFCXXXX, Section 9 | | BOOKING-CONTACT | Current | RFCXXXX, Section 7.1 |
| EMERGENCY-CONTACT | Current | RFCXXXX, Section 9 | | EMERGENCY-CONTACT | Current | RFCXXXX, Section 7.1 |
| PUBLICITY-CONTACT | Current | RFCXXXX, Section 9 | | PUBLICITY-CONTACT | Current | RFCXXXX, Section 7.1 |
| PLANNER-CONTACT | Current | RFCXXXX, Section 9 | | PLANNER-CONTACT | Current | RFCXXXX, Section 7.1 |
| PERFORMER | Current | RFCXXXX, Section 9 | | PERFORMER | Current | RFCXXXX, Section 7.1 |
| SPEAKER | Current | RFCXXXX, Section 9 | | SPEAKER | Current | RFCXXXX, Section 7.1 |
+-------------------+---------+--------------------+ +-------------------+---------+----------------------+
14.2.2. Resource Types Registry 12.2.2. Resource Types Registry
The following table has been used to initialize the resource types The following table has been used to initialize the resource types
registry. registry.
+-------------------------+---------+---------------------+ +-------------------------+---------+----------------------+
| Resource Type | Status | Reference | | Resource Type | Status | Reference |
+-------------------------+---------+---------------------+ +-------------------------+---------+----------------------+
| PROJECTOR | Current | RFCXXXX, Section 10 | | PROJECTOR | Current | RFCXXXX, Section 5.2 |
| ROOM | Current | RFCXXXX, Section 10 | | ROOM | Current | RFCXXXX, Section 5.2 |
| REMOTE-CONFERENCE-AUDIO | Current | RFCXXXX, Section 10 | | REMOTE-CONFERENCE-AUDIO | Current | RFCXXXX, Section 5.2 |
| REMOTE-CONFERENCE-VIDEO | Current | RFCXXXX, Section 10 | | REMOTE-CONFERENCE-VIDEO | Current | RFCXXXX, Section 5.2 |
+-------------------------+---------+---------------------+ +-------------------------+---------+----------------------+
15. Acknowledgements 13. Acknowledgements
The author would like to thank Chuck Norris of eventful.com for his The author would like to thank Chuck Norris of eventful.com for his
work which led to the development of this RFC. work which led to the development of this RFC.
The author would also like to thank the members of CalConnect, The The author would also like to thank the members of CalConnect, The
Calendaring and Scheduling Consortium, the Event Publication Calendaring and Scheduling Consortium, the Event Publication
technical committee and the following individuals for contributing technical committee and the following individuals for contributing
their ideas and support: their ideas and support:
Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis, Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis,
16. Normative References 14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 28, line 39 skipping to change at page 29, line 39
[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", RFC 5546, Interoperability Protocol (iTIP)", RFC 5546,
DOI 10.17487/RFC5546, December 2009, DOI 10.17487/RFC5546, December 2009,
<https://www.rfc-editor.org/info/rfc5546>. <https://www.rfc-editor.org/info/rfc5546>.
[RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986,
DOI 10.17487/RFC7986, October 2016, DOI 10.17487/RFC7986, October 2016,
<https://www.rfc-editor.org/info/rfc7986>. <https://www.rfc-editor.org/info/rfc7986>.
[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>.
[W3C.REC-xml-20060816] [W3C.REC-xml-20060816]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20060816, August 2006, xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>. <http://www.w3.org/TR/2006/REC-xml-20060816>.
Appendix A. Open issues Appendix A. Open issues
None at the moment None at the moment
 End of changes. 40 change blocks. 
155 lines changed or deleted 180 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/