draft-ietf-calext-eventpub-extensions-00.txt   draft-ietf-calext-eventpub-extensions-01.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) August 24, 2016 Updates: 5545,5546 (if approved) March 5, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: February 25, 2017 Expires: September 6, 2017
Event Publishing Extensions to iCalendar Event Publishing Extensions to iCalendar
draft-ietf-calext-eventpub-extensions-00 draft-ietf-calext-eventpub-extensions-01
Abstract Abstract
This specification introduces a number of new iCalendar properties This specification introduces a number of new iCalendar properties
which are of particular use for event publishers and in social and components which are of particular use for event publishers and
networking. in social networking.
This specification also defines a new STRUCTURED-DATA property for This specification also defines a new STRUCTURED-DATA property for
iCalendar (RFC 5545) 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 25, 2017. This Internet-Draft will expire on September 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Typed References . . . . . . . . . . . . . . . . . . . . . . 4 2. Components and properties . . . . . . . . . . . . . . . . . . 4
2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Typed References . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Piano Concert Performance . . . . . . . . . . . . . . 5 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Piano Concert Performance . . . . . . . . . . . . . . 5
3. Modifications to Calendar Components . . . . . . . . . . . . 5 3.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 5
4. New Property Parameters . . . . . . . . . . . . . . . . . . . 6 4. Modifications to Calendar Components . . . . . . . . . . . . 6
4.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. New Property Parameters . . . . . . . . . . . . . . . . . . . 7
4.2. Assoctype . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. New Properties . . . . . . . . . . . . . . . . . . . . . . . 9 6. New Properties . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Associate . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Participant Type . . . . . . . . . . . . . . . . . . . . 9
5.2. Styled-Description . . . . . . . . . . . . . . . . . . . 11 6.2. Styled-Description . . . . . . . . . . . . . . . . . . . 9
5.3. Structured-Location . . . . . . . . . . . . . . . . . . . 13 6.3. Structured-Location . . . . . . . . . . . . . . . . . . . 11
5.4. Structured-Resource . . . . . . . . . . . . . . . . . . . 14 6.4. Structured-Resource . . . . . . . . . . . . . . . . . . . 13
5.5. Structured-Data . . . . . . . . . . . . . . . . . . . . . 16 6.5. Source . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Associate Types . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Structured-Data . . . . . . . . . . . . . . . . . . . . . 16
7. Extended examples . . . . . . . . . . . . . . . . . . . . . . 18 7. New Components . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Participant Types . . . . . . . . . . . . . . . . . . . . . . 20
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. Extended examples . . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Property Registrations . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10.2. Parameter Registrations . . . . . . . . . . . . . . . . 20 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
10.3. Associate Type Registrations . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Property Registrations . . . . . . . . . . . . . . . . . 22
12. Normative References . . . . . . . . . . . . . . . . . . . . 21 12.2. Parameter Registrations . . . . . . . . . . . . . . . . 22
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 22 12.3. Component Registrations . . . . . . . . . . . . . . . . 22
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 22 12.4. Participant Types Registry . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
14. Normative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
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. calendar components. Additionally there is no standard way to
provide rich text descriptions or meta-data associated with the
event.
This document defines a number of properties referencing such Current practice is to embed this information as links in the
external information that can provide additional information about an description or to add x-properties.
iCalendar component. The intent is to allow interchange of such
information between applications or systems (e.g., between clients,
between client and server, and between servers). Formats such as
VCARD are likely to be most useful.
A new property is also defined to support HTML descriptions. Event This document defines a number of properties and components
publishers typically wish to provide more and better formatted referencing such external information that can provide additional
information about the event. information about an iCalendar component. The intent is to allow
interchange of such information between applications or systems
(e.g., between clients, between client and server, and between
servers). Formats such as VCARD are likely to be most useful.
Additionally this specification defines a property to allow the The following properties and components are defined in this
inclusion of structured data within the iCalendar object itself. The specification
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 it
is 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.
Rather than define new iCalendar properties for the variety of event Styled-Description: Supports HTML descriptions. Event publishers
types that might occur, it would be better to leverage existing typically wish to provide more and better formatted information
"schemas" for such data. For example, schemas available at about the event.
https://schema.org include different event types. By using standard
schemas, interoperability can be improved between calendar clients
and non-calendaring systems that wish to generate or process the
data.
This specification defines a new "STRUCTURED-DATA" iCalendar property Structured-Location: There may be a number of locations associated
to allow for direct inclusion of ancillary data whose schema is with an event. This provides detailed information about the
defined elsewhere. This property includes parameters to clearly location.
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 Structured-Resource: Events need resources such as rooms,
include documents or links to documents within the calendar data. projectors, conferencing capabilities.
However, that property does not allow data to be included as a "TEXT"
value (a feature that "STRUCTURED-DATA" does allow), plus attachments Structured-Data: The existing properties in iCalendar cover key
are often treated as "opaque" data to be processed by some other elements of events and tasks such as start time, end time,
system rather than the calendar client. Thus the existing "ATTACH" location, summary, etc. However, different types of events often
property is not sufficient to cover the specific needs of inclusion have other specific "fields" that it is useful to include in the
of schema data. Extending the "ATTACH" property to support a new calendar data. For example, an event representing an airline
value type would likely cause interoperability problems. Thus a new flight could include the airline, flight number, departure and
property to support inclusion of schema data is warranted. 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.
Participant: Many people or groups may participate in an event.
This component provides detailed information. Such participants
may act as attendees to the event (or derived events) or may just
provide a reference - perhaps for mailing lists.
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
[RFC2119]. [RFC2119].
2. Typed References 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 'tradition' this specification introduces some
of these extensions as components rather than properties. This is a
better match for the way XML and JSON handles such structures and
allows richer definitions.
It also allows for the addition of extra properties inside the
component and resolves some of the problems of trying to add detailed
information as a parameter.
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 presentation of additional related information
for the user. for the user.
These properties are designed to handle common use cases in event These properties are designed to handle common use cases in event
publication. It is generally important to provide information about publication. It is generally important to provide information about
the organizers of such org.bedework.util.jms.events. Sponsors wish the organizers of such events. Sponsors wish to be referenced in a
to be referenced in a prominent manner. In social calendaring it is prominent manner. In social calendaring it is often important to
often important to identify the active associates in the event, for identify the active participants in the event, for example a school
example a school sports team, and the inactive associates, for sports team, and the inactive participants, for example the parents.
example the parents.
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 "TODO" text value for specifying the location where an event (or task) will
item) will occur. This is inadequate for use cases where structured occur. This is inadequate for use cases where structured location
location information (e.g. address, region, country, postal code) is information (e.g. address, region, country, postal code) is required
required or preferred, and limits widespread adoption of iCalendar in or preferred, and limits widespread adoption of iCalendar in those
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, parking, restaurants and
the venue. Servers and clients can retrieve the objects when storing the venue. Servers and clients can retrieve the objects when storing
the event and use them to index by geographic location. 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.
2.1. Use Cases 3.1. Use Cases
The main motivation for these properties has been event publication The main motivation for these properties has been event publication
but there are opportunities for use elsewhere. The following use but there are opportunities for use elsewhere. The following use
cases will describe some possible scenarios. cases will describe some possible scenarios.
2.1.1. Piano Concert Performance 3.1.1. Piano Concert Performance
In putting together a concert there are many associates: piano tuner, In putting together a concert there are many participants: piano
performer, stage hands etc. In addition there are sponsors and tuner, performer, stage hands etc. In addition there are sponsors
various contacts to be provided. There will also be a number of 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 related locations. A number of events can be created, all of which
relate to the performance in different ways. relate to the performance in different ways.
There may be an iTip meeting request for the piano tuner who will There may be an iTip [RFC5545] meeting request for the piano tuner
arrive before the performance. Other members of staff may also who will arrive before the performance. Other members of staff may
receive meeting requests. also receive meeting requests.
An event can also be created for publication which will have an An event can also be created for publication which will have a
ASSOCIATE reference to the pianist providing vcard information about PARTICIPANT component for the pianist providing a reference to vcard
the performer. This event would also hold information about parking, information about the performer. This event would also hold
local subway stations and the venue itself. In addition, there will information about parking, local subway stations and the venue
be sponsorship information for sponsors of the event and perhaps paid itself. In addition, there will be sponsorship information for
sponsorship properties essentially advertising local establishments. sponsors of the event and perhaps paid sponsorship properties
essentially advertising local establishments.
2.1.2. Itineraries 3.1.2. Itineraries
These properties also provide opportunities for the travel industry. These additions also provide opportunities for the travel industry.
When booking a flight the ASSOCIATE property can be used to provide When booking a flight the PARTICIPANT component can be used to
references to businesses at the airports and to car hire businesses provide references to businesses at the airports and to car hire
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. and car hire companies and the hotel.
3. Modifications to Calendar Components 4. Modifications to Calendar Components
The following changes to the syntax defined in iCalendar [RFC5545] The following changes to the syntax defined in iCalendar [RFC5545]
are made here. New elements are defined in subsequent sections. are made here. New elements are defined in subsequent sections.
eventc = "BEGIN" ":" "VEVENT" CRLF
eventprop *alarmc *participantc
"END" ":" "VEVENT" CRLF
eventprop =/ *( eventprop =/ *(
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; and MAY occur more than once. ; and MAY occur more than once.
; ;
styleddescription / strucloc / strucres / associate / styleddescription / strucloc / strucres / sdataprop
sdataprop
; ;
) )
todoc = "BEGIN" ":" "VTODO" CRLF
todoprop *alarmc *participantc
"END" ":" "VTODO" CRLF
todoprop =/ *( todoprop =/ *(
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; and MAY occur more than once. ; and MAY occur more than once.
; ;
styleddescription / strucloc / strucres / associate / styleddescription / strucloc / strucres / sdataprop
sdataprop
; ;
) )
journalc = "BEGIN" ":" "VJOURNAL" CRLF
jourprop *participantc
"END" ":" "VJOURNAL" CRLF
jourprop =/ *( jourprop =/ *(
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; and MAY occur more than once. ; and MAY occur more than once.
; ;
styleddescription / associate / styleddescription / sdataprop
sdataprop
; ;
) )
4. 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 property parameter which is
defined in [I-D.ietf-calext-extensions] defined in [I-D.ietf-calext-extensions]
4.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:
loctypeparam = "LOCTYPE" "=" param-value loctypeparam = "LOCTYPE" "=" param-value
Description: This parameter MAY be specified on STRUCTURED-LOCATION Description: This parameter MAY be specified on STRUCTURED-LOCATION
and provides a way to differentiate multiple properties. For and provides a way to differentiate multiple properties. For
example, it allows event producers to provide location information example, it allows event producers to provide location information
for the venue and the parking. for the venue and the parking.
Values for this parameter are taken from the values defined in Values for this parameter are taken from the values defined in
[RFC4589]. New location types SHOULD be registered in the manner [RFC4589]. New location types SHOULD be registered in the manner
laid down in that specification laid down in that specification
4.2. Assoctype 5.2. Restype
Parameter name: ASSOCTYPE
Purpose: To specify the type of associate.
Format Definition:
This parameter is defined by the following notation:
assoctypeparam = "ASSOCTYPE" "=" param-value
Description: This parameter MAY be specified on the ASSOCIATE
property, and defines the type of association. Allowable values
are defined in Section 6.
4.3. 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" "=" param-value
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.
Values for this parameter are taken from the values defined in Values for this parameter are taken from the values defined in
[todo]. New resource types SHOULD be registered in the manner [todo]. New resource types SHOULD be registered in the manner
laid down in that specification laid down in that specification
4.4. 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:
orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1
skipping to change at page 8, line 34 skipping to change at page 8, line 34
property instance as being at the lowest level of ordering. property instance as being at the lowest level of ordering.
Note that the value of this parameter is to be interpreted only in Note that the value of this parameter is to be interpreted only in
relation to values assigned to other corresponding instances of relation to values assigned to other corresponding instances of
the same property in the same entity. A given value, or the the same property in the same entity. A given value, or the
absence of a value, MUST NOT be interpreted on its own. absence of a value, MUST NOT be interpreted on its own.
This parameter MAY be applied to any property that allows multiple This parameter MAY be applied to any property that allows multiple
instances. instances.
4.5. Schema 5.4. Schema
Parameter Name: SCHEMA Parameter Name: SCHEMA
Purpose: To specify the schema used for the content of a Purpose: To specify the schema used for the content of a
"STRUCTURED-DATA" property value. "STRUCTURED-DATA" property value.
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 9, line 11 skipping to change at page 9, line 11
corresponding "STRUCTURED-DATA" property value. This can be used corresponding "STRUCTURED-DATA" property value. This can be used
to supplement the media type information provided by the "FMTTYPE" to supplement the media type information provided by the "FMTTYPE"
parameter on the corresponding property. parameter on the corresponding property.
Example: Example:
STRUCTURED-DATA;FMTTYPE=application/ld+json; STRUCTURED-DATA;FMTTYPE=application/ld+json;
SCHEMA="https://schema.org/FlightReservation"; SCHEMA="https://schema.org/FlightReservation";
ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy
5. New Properties 6. New Properties
5.1. Associate 6.1. Participant Type
Property name: ASSOCIATE Property name: PARTTYPE
Purpose: This property provides a typed reference to external Purpose: To specify the type of participant.
information about associates in an event or optionally a plain
text typed value.
Value type: The default value type for this property is URI. The Value type: The value type for this property is TEXT. The allowable
value type can also be set to TEXT to indicate plain text content. values are defined in Section 8.
Property Parameters: Non-standard, label, assoctype, order or format Property Parameters: Non-standard parameters can be specified on
type parameters can be specified on this property. this property.
Conformance: This property MAY be specified in any iCalendar Conformance: This property MUST be specified within a PARTICIPANT
component. component.
Description: When used in a component the value of this property Description: This property defines the type of participation in
points to information about an event associate. This is NOT an events or tasks. Participants can be individuals or
attendee in a scheduling sense and the ATTENDEE property may in organizations, for example a soccer team, the spectators, or the
fact be specified in addition. Associates in events can be musicians.
individuals or organizations, for example a soccer team, the
spectators, or the musicians.
Format Definition: Format Definition:
This property is defined by the following notation: This parameter is defined by the following notation:
associate = "ASSOCIATE" assocparam
(
(
";" "VALUE" "=" "URI"
":" uri
) /
(
";" "VALUE" "=" "TEXT"
":" text
)
)
CRLF
assocparam = *(
;
; the following are OPTIONAL
; but MUST NOT occur more than once
;
(";" fmttypeparam) /
(";" labelparam) /
(";" orderparam) /
(";" assoctypeparam) /
;
; the following is OPTIONAL
; and MAY occur more than once
;
(";" other-param)
;
)
Note: When the ORDER parameter is supplied it defines the ordering
of ASSOCIATE properties with the same value for the TYPE
parameter.
Example:
The following is an example of this property. It points to a VCARD
providing information on an event associate.
ASSOCIATE;ASSOCTYPE=PRINCIPAL_PERFORMER:
http://dir.example.com/vcard/aviolinist.vcf
Example:
The following is an example referring to a VCARD providing
information on the primary contact.
ASSOCIATE;FMTTYPE=text/vcard;
ASSOCTYPE=PRIMARY-CONTACT;LABEL=A contact:
http://dir.example.com/vcard/contacts/contact1.vcf
Example:
The following is an example of the property used to link to VCARD
information on the event planner.
ASSOCIATE;FMTTYPE=text/vcard; participanttype = "PARTICIPANT-TYPE" "=" iana-token
ASSOCTYPE=PLANNER-CONTACT;LABEL=ClownsIsUs:
http://dir.example.com/vcard/clowns-is-us.vcf
5.2. Styled-Description 6.2. Styled-Description
Property name: STYLED-DESCRIPTION Property name: STYLED-DESCRIPTION
Purpose: This property provides for one or more rich-text Purpose: This property provides for one or more rich-text
descriptions to replace or augment that provided by the descriptions to replace or augment that provided by the
DESCRIPTION property. DESCRIPTION property.
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. Other text-based value 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 types can be used when defined in the future. Clients MUST ignore
skipping to change at page 13, line 4 skipping to change at page 11, line 32
; The following are OPTIONAL, ; The following are OPTIONAL,
; but MUST NOT occur more than once. ; but MUST NOT occur more than once.
; ;
(";" altrepparam) / (";" languageparam) / (";" altrepparam) / (";" languageparam) /
(";" fmttypeparam) / (";" fmttypeparam) /
; ;
; the following is OPTIONAL ; the following is OPTIONAL
; 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 points to an html The following is an example of this property. It points to an html
description. description.
STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html STYLED-DESCRIPTION;VALUE=URI:http://example.org/desc001.html
5.3. Structured-Location 6.3. Structured-Location
Property name: STRUCTURED-LOCATION Property name: STRUCTURED-LOCATION
Purpose: This property provides a typed reference to external Purpose: This property provides a typed reference to external
information about the location of an event or optionally a plain information about the location of an event or optionally a plain
text typed value. text typed value.
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. Other text-based value value type can be set to URI or TEXT. Other text-based value
types types
skipping to change at page 14, line 43 skipping to change at page 13, line 12
(";" other-param) (";" other-param)
) )
Example: Example:
The following is an example of this property. It points to a venue. The following is an example of this property. It points to a venue.
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
5.4. Structured-Resource 6.4. 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.
Value type: The default value type for this property is URI. The Value type: The default value type for this property is URI. The
value type can also be set to TEXT to indicate plain text content. value type can also be set to TEXT to indicate plain text content.
skipping to change at page 16, line 11 skipping to change at page 14, line 38
) )
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;restype="projector":
http://dir.example.com/projectors/3d.vcf http://dir.example.com/projectors/3d.vcf
5.5. Structured-Data 6.5. Source
Property name: SOURCE
Purpose: This property provides a reference to vcard information
about a participant in an event or optionally a plain text typed
value.
Value type: The default value type for this property is URI. The
value type can also be set to TEXT to indicate plain text content.
Property Parameters: Non-standard or format type parameters can be
specified on this property.
Conformance: This property MAY be appear in any iCalendar component.
Description: This property provides information about the component
in which it appears. It may provide a refernce to a vcard giving
directory information about a resource or participant.
Format Definition:
This property is defined by the following notation:
source = "SOURCE" sourceparam
(
(
";" "VALUE" "=" "URI"
":" uri
) /
(
";" "VALUE" "=" "TEXT"
":" text
)
)
CRLF
sourceparam = *(
;
; the following are OPTIONAL
; but MUST NOT occur more than once
;
(";" fmttypeparam) /
;
; the following is OPTIONAL
; and MAY occur more than once
;
(";" other-param)
;
)
Example:
The following is an example referring to a VCARD.
SOURCE;FMTTYPE=text/vcard;
http://dir.example.com/vcard/contacts/contact1.vcf
6.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 Value Type: TEXT
Property Parameters: IANA, non-standard, inline encoding, and value Property Parameters: IANA, non-standard, inline encoding, and value
data type property parameters can be specified on this property. data type property parameters can be specified on this property.
skipping to change at page 16, line 34 skipping to change at page 16, line 28
content information. content information.
Conformance: This property can be specified multiple times in an Conformance: This property can be specified multiple times in an
iCalendar object. Typically it would be used in "VEVENT", iCalendar object. Typically it would be used in "VEVENT",
"VTODO", or "VJOURNAL" calendar components. "VTODO", or "VJOURNAL" calendar components.
Description: This property is used to specify ancillary data in some Description: This property is used to specify ancillary data in some
structured format either directly (inline) as a "TEXT" or "BINARY" structured format either directly (inline) as a "TEXT" or "BINARY"
value, or as a link via a "URI" value. 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 non-calendaring 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. Thus a new property to support
inclusion of schema data is warranted.
Format Definition: Format Definition:
This property is defined by the following notation: This property is defined by the following notation:
sdataprop = "STRUCTURED-DATA" sdataparam sdataprop = "STRUCTURED-DATA" sdataparam
(":" text) / (":" text) /
( (
";" "ENCODING" "=" "BASE64" ";" "ENCODING" "=" "BASE64"
";" "VALUE" "=" "BINARY" ";" "VALUE" "=" "BINARY"
":" binary ":" binary
skipping to change at page 17, line 47 skipping to change at page 18, line 5
STRUCTURED-DATA;FMTTYPE=application/ld+json; STRUCTURED-DATA;FMTTYPE=application/ld+json;
SCHEMA="https://schema.org/SportsEvent"; SCHEMA="https://schema.org/SportsEvent";
VALUE=TEXT:{\n VALUE=TEXT:{\n
"@context": "http://schema.org"\,\n "@context": "http://schema.org"\,\n
"@type": "SportsEvent"\,\n "@type": "SportsEvent"\,\n
"homeTeam": "Pittsburgh Pirates"\,\n "homeTeam": "Pittsburgh Pirates"\,\n
"awayTeam": "San Francisco Giants"\n "awayTeam": "San Francisco Giants"\n
}\n }\n
6. Associate Types 7. New Components
This section describes types of association and provide registered 7.1. Participant
values for the ASSOCIATE property ASSOCTYPE parameter.
ACTIVE: An associate taking an active role - for example a team Component name: PARTICIPANT
Purpose: This component provides information about a participant in
an event or optionally a plain text typed value.
Conformance: This component MAY be appear in any iCalendar
component.
Description: This component provides information about an
participant in an event, task or poll. A participant may be an
attendee in a scheduling sense and the ATTENDEE property may be
specified in addition (See backwards compatability issues).
Participants in events can be individuals or organizations, for
example a soccer team, the spectators, or the musicians.
The SOURCE property if present may refer to an external definition
of the participant - such as a vcard.
The URI property (def?) if present will provide a mailto: or other
address. If a related ATTENDEE proeprty is generated it will have
the same value as the URI.
Format Definition:
This property is defined by the following notation:
participantc = "BEGIN" ":" "PARTICIPANT" CRLF
partprop *alarmc
"END" ":" "PARTICIPANT" CRLF
partprop = *(
;
; The following are REQUIRED,
; but MUST NOT occur more than once.
;
dtstamp / participanttype /
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
created / description / last-mod / seq /
source / status / summary / url /
;
; The following are OPTIONAL,
; and MAY occur more than once.
;
attach / categories / comment /
contact / rstatus / related /
resources / x-prop / iana-prop
;
)
Note: When the PRIORITY is supplied it defines the ordering of
PARTICIPANT components with the same value for the TYPE parameter.
Example:
The following is an example of this component. It contains a SOURCE
property which points to a VCARD providing information about the
event participant.
BEGIN:PARTICIPANT
PARTTYPE:PRINCIPAL_PERFORMER
SOURCE:http://dir.example.com/vcard/aviolinist.vcf
END:PARTICIPANT
Example:
The following is an example for the primary contact.
BEGIN: PARTICIPANT
SOURCE;FMTTYPE=text/vcard;
http://dir.example.com/vcard/contacts/contact1.vcf
PARTTYPE:PRIMARY-CONTACT
DESCRIPTION:A contact:
END:PARTICIPANT
8. Participant Types
This section describes types of participation and provide registered
values for the PARTTYPE property.
ACTIVE: A participant taking an active role - for example a team
member. member.
INACTIVE: An associate taking an inactive part - for example an INACTIVE: A participant taking an inactive part - for example an
audience member. audience member.
SPONSOR: A sponsor of the event. The ORDER parameter may be used SPONSOR: A sponsor of the event. The ORDER parameter may be used
with this associate type to define the relative order of multiple with this participant type to define the relative order of
sponsors. multiple sponsors.
CONTACT: Contact information for the event. The ORDER parameter may CONTACT: Contact information for the event. The ORDER parameter may
be used with this associate type to define the relative order of be used with this participant type to define the relative order of
multiple contacts. multiple contacts.
BOOKING-CONTACT: Contact information for reservations or payment BOOKING-CONTACT: Contact information for reservations or payment
EMERGENCY-CONTACT: Contact in case of emergency EMERGENCY-CONTACT: Contact in case of emergency
PUBLICITY-CONTACT: Contact for publicity PUBLICITY-CONTACT: Contact for publicity
PLANNER-CONTACT: Contact for the event planner or organizer PLANNER-CONTACT: Contact for the event planner or organizer
PERFORMER: A performer - for example the soloist or the accompanist. PERFORMER: A performer - for example the soloist or the accompanist.
The ORDER parameter may be used with this associate type to define The ORDER parameter may be used with this participant type to
the relative order of multiple sponsors. For example, ORDER=1 define the relative order of multiple performers. For example,
could define the principal performer or soloist. ORDER=1 could define the principal performer or soloist.
SPEAKER: Speaker at an event SPEAKER: Speaker at an event
7. Extended examples 9. 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
[I-D.ietf-calext-extensions] which includes IMAGE and LIVEFEED. [I-D.ietf-calext-extensions] which includes IMAGE and LIVEFEED.
7.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:20101116T145739Z CREATED:20101116T145739Z
DESCRIPTION: Piano Sonata No 3\n DESCRIPTION: Piano Sonata No 3\n
Piano Sonata No 30 Piano Sonata No 30
DTSTAMP:20101116T145739Z DTSTAMP:20101116T145739Z
DTSTART;TZID=America/New_York:20110315T150000Z DTSTART;TZID=America/New_York:20110315T150000Z
DTEND;TZID=America/New_York:20110315T163000Z DTEND;TZID=America/New_York:20110315T163000Z
LAST-MODIFIED:20101116T145739Z LAST-MODIFIED:20101116T145739Z
SUMMARY:Beethoven Piano Sonatas SUMMARY:Beethoven Piano Sonatas
UID:123456 UID:123456
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
STRUCTURED-LOCATION;LABEL="The venue": STRUCTURED-LOCATION;LABEL="The venue":
http://dir.example.com/venues/parking.vcf http://dir.example.com/venues/parking.vcf
ASSOCIATE;ASSOCTYPE=SPONSOR:http://example.com/sponsor.vcf BEGIN:PARTICIPANT
ASSOCIATE;ASSOCTYPE=PERFORMER: PARTTYPE:SPONSOR
http://www.example.com/people/johndoe.vcf SOURCE:http://example.com/sponsor.vcf
END:PARTICIPANT
BEGIN:PARTICIPANT
PARTTYPE:PERFORMER:
SOURCE:http://www.example.com/people/johndoe.vcf
END:PARTICIPANT
END:VEVENT END:VEVENT
8. 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.
9. 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].
10. IANA Considerations 12. IANA Considerations
10.1. Property Registrations
12.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 |
+---------------------+---------+----------------------+ +---------------------+---------+----------------------+
| ASSOCIATE | Current | RFCXXXX, Section 5.1 | | PARTTYPE | Current | RFCXXXX, Section 6.1 |
| STRUCTURED-DATA | Current | RFCXXXX, Section 5.5 | | STRUCTURED-DATA | Current | RFCXXXX, Section 6.6 |
| STYLED-DESCRIPTION | Current | RFCXXXX, Section 5.2 | | STYLED-DESCRIPTION | Current | RFCXXXX, Section 6.2 |
| STRUCTURED-LOCATION | Current | RFCXXXX, Section 5.3 | | STRUCTURED-LOCATION | Current | RFCXXXX, Section 6.3 |
| STRUCTURED-RESOURCE | Current | RFCXXXX, Section 5.4 | | STRUCTURED-RESOURCE | Current | RFCXXXX, Section 6.4 |
| SOURCE | Current | RFCXXXX, Section 6.5 |
+---------------------+---------+----------------------+ +---------------------+---------+----------------------+
10.2. Parameter Registrations 12.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 |
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
| ASSOCTYPE | Current | RFCXXXX, Section 4.2 | | LOCTYPE | Current | RFCXXXX, Section 5.1 |
| LOCTYPE | Current | RFCXXXX, Section 4.1 | | ORDER | Current | RFCXXXX, Section 5.3 |
| ORDER | Current | RFCXXXX, Section 4.4 | | RESTYPE | Current | RFCXXXX, Section 5.2 |
| RESTYPE | Current | RFCXXXX, Section 4.3 | | SCHEMA | Current | RFCXXXX, Section 5.4 |
| SCHEMA | Current | RFCXXXX, Section 4.5 |
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
10.3. Associate Type Registrations 12.3. Component Registrations
The following table has been used to initialize the associate types This document defines the following new iCalendar components to be
added to the registry defined in Section 8.3.1 of [RFC5545]:
+-------------+---------+----------------------+
| Component | Status | Reference |
+-------------+---------+----------------------+
| PARTICIPANT | Current | RFCXXXX, Section 7.1 |
+-------------+---------+----------------------+
12.4. Participant Types Registry
The following table has been used to initialize the participant types
registry. registry.
+-------------------+---------+--------------------+ +-------------------+---------+--------------------+
| Associate Type | Status | Reference | | Participant Type | Status | Reference |
+-------------------+---------+--------------------+ +-------------------+---------+--------------------+
| ACTIVE | Current | RFCXXXX, Section 6 | | ACTIVE | Current | RFCXXXX, Section 8 |
| INACTIVE | Current | RFCXXXX, Section 6 | | INACTIVE | Current | RFCXXXX, Section 8 |
| SPONSOR | Current | RFCXXXX, Section 6 | | SPONSOR | Current | RFCXXXX, Section 8 |
| CONTACT | Current | RFCXXXX, Section 6 | | CONTACT | Current | RFCXXXX, Section 8 |
| BOOKING-CONTACT | Current | RFCXXXX, Section 6 | | BOOKING-CONTACT | Current | RFCXXXX, Section 8 |
| EMERGENCY-CONTACT | Current | RFCXXXX, Section 6 | | EMERGENCY-CONTACT | Current | RFCXXXX, Section 8 |
| PUBLICITY-CONTACT | Current | RFCXXXX, Section 6 | | PUBLICITY-CONTACT | Current | RFCXXXX, Section 8 |
| PLANNER-CONTACT | Current | RFCXXXX, Section 6 | | PLANNER-CONTACT | Current | RFCXXXX, Section 8 |
| PERFORMER | Current | RFCXXXX, Section 6 | | PERFORMER | Current | RFCXXXX, Section 8 |
| SPEAKER | Current | RFCXXXX, Section 6 | | SPEAKER | Current | RFCXXXX, Section 8 |
+-------------------+---------+--------------------+ +-------------------+---------+--------------------+
11. 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 the Calendaring The author would also like to thank the members of the Calendaring
and Scheduling Consortium Event Publication technical committee and and Scheduling Consortium Event Publication technical committee and
the following individuals for contributing their ideas and support: the following individuals for contributing their ideas and support:
Cyrus Daboo, John Haug, Dan Mendell, Scott Otis, Cyrus Daboo, John Haug, Dan Mendell, Scott Otis,
The authors would also like to thank the Calendaring and Scheduling The authors would also like to thank the Calendaring and Scheduling
Consortium for advice with this specification. Consortium for advice with this specification.
12. Normative References 14. Normative References
[I-D.ietf-calext-extensions] [I-D.ietf-calext-extensions]
Daboo, C., "New Properties for iCalendar", draft-ietf- Daboo, C., "New Properties for iCalendar", draft-ietf-
calext-extensions-05 (work in progress), August 2016. calext-extensions-05 (work in progress), August 2016.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 22, line 19 skipping to change at page 24, line 28
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types
Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006,
<http://www.rfc-editor.org/info/rfc4589>. <http://www.rfc-editor.org/info/rfc4589>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009, RFC 5545, DOI 10.17487/RFC5545, September 2009,
<http://www.rfc-editor.org/info/rfc5545>. <http://www.rfc-editor.org/info/rfc5545>.
[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", RFC 5546,
DOI 10.17487/RFC5546, December 2009,
<http://www.rfc-editor.org/info/rfc5546>.
[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
restype values: Need to determine what if any registry of resource restype values: Need to determine what if any registry of resource
types already exists and use that. types already exists and use that.
Appendix B. Change log Appendix B. Change log
v05 2017-02-18 MD
o Change ASSOCIATE back to PARTICIPANT
o PARTICIPANT becomes a component rather than a property. Turn many
of the former parameters into properties.
v05 2016-08-?? MD
o Name changed - taken up by calext working group
v05 2016-06-26 MD v05 2016-06-26 MD
o Fix up abnf o Fix up abnf
o change ref to ietf from daboo o change ref to ietf from daboo
o take out label spec - use Cyrus spec o take out label spec - use Cyrus spec
v05 2016-06-14 MD v05 2016-06-14 MD
 End of changes. 78 change blocks. 
269 lines changed or deleted 414 lines changed or added

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