draft-ietf-calext-eventpub-extensions-03.txt   draft-ietf-calext-eventpub-extensions-04.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 4, 2017 Updates: 5545,5546 (if approved) October 10, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: November 5, 2017 Expires: April 13, 2018
Event Publishing Extensions to iCalendar Event Publishing Extensions to iCalendar
draft-ietf-calext-eventpub-extensions-03 draft-ietf-calext-eventpub-extensions-04
Abstract Abstract
This specification introduces a number of new iCalendar properties This specification introduces a number of new iCalendar properties
and components which are of particular use for event publishers and and components which are of particular use for event publishers and
in social 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 [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 http://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 5, 2017. This Internet-Draft will expire on April 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Itineraries . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Loctype . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Restype . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. New Properties . . . . . . . . . . . . . . . . . . . . . . . 9 6. New Properties . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Participant Type . . . . . . . . . . . . . . . . . . . . 9 6.1. Participant Type . . . . . . . . . . . . . . . . . . . . 10
6.2. Schedule Address . . . . . . . . . . . . . . . . . . . . 9 6.2. Schedule Address . . . . . . . . . . . . . . . . . . . . 10
6.3. Styled-Description . . . . . . . . . . . . . . . . . . . 10 6.3. Styled-Description . . . . . . . . . . . . . . . . . . . 11
6.4. Structured-Location . . . . . . . . . . . . . . . . . . . 12 6.4. Structured-Location . . . . . . . . . . . . . . . . . . . 12
6.5. Structured-Resource . . . . . . . . . . . . . . . . . . . 13 6.5. Structured-Resource . . . . . . . . . . . . . . . . . . . 14
6.6. Source . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.6. Source . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.7. Structured-Data . . . . . . . . . . . . . . . . . . . . . 16 6.7. Structured-Data . . . . . . . . . . . . . . . . . . . . . 18
7. New Components . . . . . . . . . . . . . . . . . . . . . . . 18 7. New Components . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Participant . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Schedulable Participant . . . . . . . . . . . . . . . . . 21 7.2. Schedulable Participant . . . . . . . . . . . . . . . . . 22
8. Participant Types . . . . . . . . . . . . . . . . . . . . . . 21 8. Participant Types . . . . . . . . . . . . . . . . . . . . . . 22
9. Extended examples . . . . . . . . . . . . . . . . . . . . . . 22 9. Extended examples . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
12.1. Property Registrations . . . . . . . . . . . . . . . . . 24 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.2. Parameter Registrations . . . . . . . . . . . . . . . . 24 12.1. Property Registrations . . . . . . . . . . . . . . . . . 25
12.3. Component Registrations . . . . . . . . . . . . . . . . 24 12.2. Parameter Registrations . . . . . . . . . . . . . . . . 26
12.4. Participant Types Registry . . . . . . . . . . . . . . . 25 12.3. Component Registrations . . . . . . . . . . . . . . . . 26
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 12.4. Participant Types Registry . . . . . . . . . . . . . . . 26
14. Normative References . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 26 14. Normative References . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
referencing such external information that can provide additional referencing such external information that can provide additional
information about an iCalendar component. The intent is to allow information about an iCalendar component. The intent is to allow
interchange of such information between applications or systems interchange of such information between applications or systems
(e.g., between clients, between client and server, and between (e.g., between clients, between client and server, and between
servers). Formats such as VCARD are likely to be most useful to the servers). Formats such as VCARD are likely to be most useful to the
receivers of such events as they may be used in other applications - receivers of such events as they may be used in other applications -
such as address books. such as address books.
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
typically wish to provide more and better formatted information typically wish to provide more and better formatted information
about the event. about the event.
Structured-Location: There may be a number of locations associated STRUCTURED-LOCATION: There may be a number of locations associated
with an event. This provides detailed information about the with an event. This provides detailed information about the
location. location.
Structured-Resource: Events need resources such as rooms, STRUCTURED-RESOURCE: Events need resources such as rooms,
projectors, conferencing capabilities. projectors, conferencing capabilities.
Structured-Data: The existing properties in iCalendar cover key STRUCTURED-DATA: The existing properties in iCalendar cover key
elements of events and tasks such as start time, end time, elements of events and tasks such as start time, end time,
location, summary, etc. However, different types of events often location, summary, etc. However, different types of events often
have other specific "fields" that it is useful to include in the have other specific "fields" that it is useful to include in the
calendar data. For example, an event representing an airline calendar data. For example, an event representing an airline
flight could include the airline, flight number, departure and flight could include the airline, flight number, departure and
arrival airport codes, check-in and gate-closing times etc. As arrival airport codes, check-in and gate-closing times etc. As
another example, a sporting event might contain information about another example, a sporting event might contain information about
the type of sport, the home and away teams, the league the teams the type of sport, the home and away teams, the league the teams
are in, information about nearby parking, etc. are in, information about nearby parking, etc.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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, 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.
These PARTICIPANT component is designed to handle common use cases in When a calendar client receives a calendar component it can search
the set of supplied properties looking for those of particular
interest. The TYPE and FMTTYPE parameters, if supplied, can be used
to help the selection.
The PARTICIPANT component is designed to handle common use cases in
event publication. It is generally important to provide information 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
to identify the active participants in the event, for example a to identify the active participants in the event, for example a
school sports team, and the inactive participants, for example the school sports team, and the inactive participants, for example the
parents. parents.
When a calendar client receives a calendar component it can search The PARTICIPANT component canalso be used to provide useful extra
the set of supplied properties looking for those of particular daat about an attendee. For example a LOCATION property inside the
interest. The TYPE and FMTTYPE parameters, if supplied, can be used PARTICIPANT gives the actual location of a remote attendee.
to help the selection.
3.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.
3.1.1. Piano Concert Performance 3.1.1. Piano Concert Performance
In putting together a concert there are many participants: piano In putting together a concert there are many participants: piano
skipping to change at page 7, line 46 skipping to change at page 8, line 41
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 the
[todo]. New resource types SHOULD be registered in the manner registry. New resource types SHOULD be registered in the manner
laid down in that specification laid down in this specification
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 12, line 13 skipping to change at page 13, line 4
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
6.4. Structured-Location 6.4. 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.
types
Property Parameters: IANA, non-standard, label, loctype or format Property Parameters: IANA, non-standard, label, loctype 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 the event venue or of related services provides information about the event venue or of related services
such as parking, dining, stations etc.. such as parking, dining, stations etc..
skipping to change at page 14, line 5 skipping to change at page 15, line 5
http://dir.example.com/venues/big-hall.vcf http://dir.example.com/venues/big-hall.vcf
6.5. Structured-Resource 6.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.
Value type: The default value type for this property is URI. The Value type: There is no default value type for this property. The
value type can also be set to TEXT to indicate plain text content. 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.
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 (":" uri) / strucres = "STRUCTURED-RESOURCE" strucresparam /
(
(
";" "VALUE" "=" "URI"
":" uri
) /
( (
";" "VALUE" "=" "TEXT" ";" "VALUE" "=" "TEXT"
":" text ":" text
) )
)
CRLF CRLF
strucresparam = *( strucresparam = *(
; ;
; the following are OPTIONAL ; the following are OPTIONAL
; but MUST NOT occur more than once ; but MUST NOT occur more than once
; ;
(";" fmttypeparam) / (";" fmttypeparam) /
(";" labelparam) / (";" labelparam) /
(";" languageparam) / (";" languageparam) /
skipping to change at page 21, line 40 skipping to change at page 22, line 40
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.
8. Participant Types 8. Participant Types
This section describes types of participation and provide registered This section describes types of participation and provides registered
values for the PARTTYPE property. values for the PARTTYPE property.
ACTIVE: A participant taking an active role - for example a team ACTIVE: A participant taking an active role - for example a team
member. member.
INACTIVE: A participant 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 participant type to define the relative order of with this participant type to define the relative order of
skipping to change at page 22, line 28 skipping to change at page 23, line 28
The ORDER parameter may be used with this participant type to The ORDER parameter may be used with this participant type to
define the relative order of multiple performers. For example, define the relative order of multiple performers. For example,
ORDER=1 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
9. 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
[RFC7986] which includes IMAGE and LIVEFEED. [RFC7986] which includes IMAGE.
9.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:20170216T145739Z
DESCRIPTION: Piano Sonata No 3\n DESCRIPTION: Piano Sonata No 3\n
Piano Sonata No 30 Piano Sonata No 30
DTSTAMP:20101116T145739Z DTSTAMP:20171116T145739Z
DTSTART;TZID=America/New_York:20110315T150000Z DTSTART;TZID=America/New_York:20170315T150000Z
DTEND;TZID=America/New_York:20110315T163000Z DTEND;TZID=America/New_York:20170315T163000Z
LAST-MODIFIED:20101116T145739Z LAST-MODIFIED:20170216T145739Z
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
IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h
ttp://example.com/images/concert.png
BEGIN:PARTICIPANT BEGIN:PARTICIPANT
PARTTYPE:SPONSOR PARTTYPE:SPONSOR
SOURCE:http://example.com/sponsor.vcf SOURCE:http://example.com/sponsor.vcf
END:PARTICIPANT END:PARTICIPANT
BEGIN:PARTICIPANT BEGIN:PARTICIPANT
PARTTYPE:PERFORMER: PARTTYPE: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
9.2. Example 2
The following is an example of a VEVENT describing a meeting. One of
the attendees is a remote participant.
BEGIN:VEVENT
CREATED:20170216T145739Z
DTSTAMP:20101116T145739Z
DTSTART;TZID=America/New_York:20170315T150000Z
DTEND;TZID=America/New_York:20170315T163000Z
LAST-MODIFIED:20170216T145739Z
SUMMARY:Conference plaaning
UID:123456
ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CN=B:mailto:b@example.com
BEGIN:PARTICIPANT
PARTTYPE:ACTIVE:
SOURCE:http://www.example.com/people/b.vcf
LOCATION:At home
END:PARTICIPANT
END:VEVENT
10. 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.
skipping to change at page 25, line 30 skipping to change at page 27, line 25
| PLANNER-CONTACT | Current | RFCXXXX, Section 8 | | PLANNER-CONTACT | Current | RFCXXXX, Section 8 |
| PERFORMER | Current | RFCXXXX, Section 8 | | PERFORMER | Current | RFCXXXX, Section 8 |
| SPEAKER | Current | RFCXXXX, Section 8 | | SPEAKER | Current | RFCXXXX, Section 8 |
+-------------------+---------+--------------------+ +-------------------+---------+--------------------+
13. 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 CalConnect, The
and Scheduling Consortium Event Publication technical committee and Calendaring and Scheduling Consortium, the Event Publication
the following individuals for contributing their ideas and support: technical committee and the following individuals for contributing
their ideas and support:
Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis, Cyrus Daboo, John Haug, Dan Mendell, Ken Murchison, Scott Otis,
The authors would also like to thank the Calendaring and Scheduling
Consortium for advice with this specification.
14. 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,
<http://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,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[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>. <https://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>. <https://www.rfc-editor.org/info/rfc5545>.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc7986>. <https://www.rfc-editor.org/info/rfc7986>.
[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 or define one here.
SOURCE property: Already defined in 7986. Should I recast this as
an extension of that property. Allows VALUE=TEXT and use in other
than a calendar.
Appendix B. Change log Appendix B. Change log
calext-v02 2017-04-20 MD calext-v02 2017-04-20 MD
o Add SCHEDULE-ADDRESS property o Add SCHEDULE-ADDRESS property
o PARTICIPANT becomes a component rather than a property. Turn many o PARTICIPANT becomes a component rather than a property. Turn many
of the former parameters into properties. of the former parameters into properties.
 End of changes. 36 change blocks. 
72 lines changed or deleted 107 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/