draft-ietf-calext-extensions-04.txt   draft-ietf-calext-extensions-05.txt 
Network Working Group C. Daboo Network Working Group C. Daboo
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Updates: 5545 (if approved) June 28, 2016 Updates: 5545 (if approved) August 22, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: December 30, 2016 Expires: February 23, 2017
New Properties for iCalendar New Properties for iCalendar
draft-ietf-calext-extensions-04 draft-ietf-calext-extensions-05
Abstract Abstract
This document defines a set of new properties for iCalendar data as This document defines a set of new properties for iCalendar data as
well as extending the use of some existing properties to the entire well as extending the use of some existing properties to the entire
iCalendar object. iCalendar object.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 December 30, 2016. This Internet-Draft will expire on February 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Backwards Compatible Extension Properties . . . . . . . . . . 3 3. Backwards Compatible Extension Properties . . . . . . . . . . 3
4. Modifications to Calendar Components . . . . . . . . . . . . 3 4. Modifications to Calendar Components . . . . . . . . . . . . 3
5. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. NAME Property . . . . . . . . . . . . . . . . . . . . . . 5 5.1. NAME Property . . . . . . . . . . . . . . . . . . . . . . 5
5.2. DESCRIPTION Property . . . . . . . . . . . . . . . . . . 6 5.2. DESCRIPTION Property . . . . . . . . . . . . . . . . . . 6
5.3. UID Property . . . . . . . . . . . . . . . . . . . . . . 6 5.3. UID Property . . . . . . . . . . . . . . . . . . . . . . 6
5.4. LAST-MODIFIED Property . . . . . . . . . . . . . . . . . 7 5.4. LAST-MODIFIED Property . . . . . . . . . . . . . . . . . 7
5.5. URL Property . . . . . . . . . . . . . . . . . . . . . . 7 5.5. URL Property . . . . . . . . . . . . . . . . . . . . . . 8
5.6. CATEGORIES Property . . . . . . . . . . . . . . . . . . . 7 5.6. CATEGORIES Property . . . . . . . . . . . . . . . . . . . 8
5.7. REFRESH-INTERVAL Property . . . . . . . . . . . . . . . . 8 5.7. REFRESH-INTERVAL Property . . . . . . . . . . . . . . . . 8
5.8. SOURCE Property . . . . . . . . . . . . . . . . . . . . . 9 5.8. SOURCE Property . . . . . . . . . . . . . . . . . . . . . 9
5.9. COLOR Property . . . . . . . . . . . . . . . . . . . . . 9 5.9. COLOR Property . . . . . . . . . . . . . . . . . . . . . 10
5.10. IMAGE Property . . . . . . . . . . . . . . . . . . . . . 10 5.10. IMAGE Property . . . . . . . . . . . . . . . . . . . . . 11
5.11. CONFERENCE Property . . . . . . . . . . . . . . . . . . . 12 5.11. CONFERENCE Property . . . . . . . . . . . . . . . . . . . 12
6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 13 6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 14
6.1. DISPLAY Property Parameter . . . . . . . . . . . . . . . 13 6.1. DISPLAY Property Parameter . . . . . . . . . . . . . . . 14
6.2. EMAIL Property Parameter . . . . . . . . . . . . . . . . 14 6.2. EMAIL Property Parameter . . . . . . . . . . . . . . . . 15
6.3. FEATURE Property Parameter . . . . . . . . . . . . . . . 15 6.3. FEATURE Property Parameter . . . . . . . . . . . . . . . 16
6.4. LABEL Property Parameter . . . . . . . . . . . . . . . . 16 6.4. LABEL Property Parameter . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. Property Registrations . . . . . . . . . . . . . . . . . 17 9.1. Property Registrations . . . . . . . . . . . . . . . . . 19
9.2. Parameter Registrations . . . . . . . . . . . . . . . . . 18 9.2. Parameter Registrations . . . . . . . . . . . . . . . . . 20
9.3. Display Types Registry . . . . . . . . . . . . . . . . . 18 9.3. Property Parameter Value Registries . . . . . . . . . . . 20
9.4. Feature Types Registry . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 20 publication) . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The iCalendar [RFC5545] data format is used to represent calendar The iCalendar [RFC5545] data format is used to represent calendar
data and is used with iTIP [RFC5546] to handle scheduling operations data and is used with iTIP [RFC5546] to handle scheduling operations
between calendar users. iCalendar is in widespread use, and in between calendar users. iCalendar is in widespread use, and in
accordance with provisions in that specification, extension elements accordance with provisions in that specification, extension elements
have been added by various vendors to the data format in order to have been added by various vendors to the data format in order to
support and enhance capabilities. This specification collects a support and enhance capabilities. This specification collects a
number of these ad-hoc extensions and uses the new IANA registry number of these ad-hoc extensions and uses the new IANA registry
skipping to change at page 5, line 9 skipping to change at page 5, line 8
jourprop =/ *( jourprop =/ *(
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; but MUST NOT occur more than once. ; but MUST NOT occur more than once.
; ;
color / color /
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; and MAY occur more than once. ; and MAY occur more than once.
; ;
conference / image image
; ;
) )
5. Properties 5. Properties
5.1. NAME Property 5.1. NAME Property
Property Name: NAME Property Name: NAME
Purpose: This property specifies the name of the calendar. Purpose: This property specifies the name of the calendar.
skipping to change at page 7, line 15 skipping to change at page 7, line 15
Purpose: This property specifies the persistent, globally unique Purpose: This property specifies the persistent, globally unique
identifier for the iCalendar object. This can be used, for identifier for the iCalendar object. This can be used, for
example, to identify duplicate calendar streams that a client may example, to identify duplicate calendar streams that a client may
have been given access to. It can be used in conjunction with the have been given access to. It can be used in conjunction with the
"LAST-MODIFIED" property also specified on the "VCALENDAR" object, "LAST-MODIFIED" property also specified on the "VCALENDAR" object,
to identify the most recent version of a calendar. to identify the most recent version of a calendar.
Conformance: This property can be specified once in an iCalendar Conformance: This property can be specified once in an iCalendar
object. object.
The description of the "UID" property in [RFC5545] contains some
recommendations on how the value can be constructed. In particular,
it suggests use of host names, IP addresses, and domain names to
construct the value. However, this is no longer considered good
practice, particularly from a security and privacy standpoint, since
use of such values can leak key information about a calendar user, or
their client and network environment. This specification updates
[RFC5545] by stating that "UID" values MUST NOT include any data that
might identify a user, host, domain, or any other security or privacy
sensitive information. It is RECOMMENDED that calendar user agents
now generate "UID" values that are hex-encoded random UUID values as
defined in Sections 4.4 and 4.5 of [RFC4122].
The following is an example of such a property value:
UID:5FC53010-1267-4F8E-BC28-1D7AE55A7C99
Additionally, if calendar user agents choose to use other forms of
opaque identifiers for the "UID" value, they MUST have a length less
than 255 octets, and MUST conform to the "iana-token" ABNF syntax
defined in Section 3.1 of [RFC5545].
5.4. LAST-MODIFIED Property 5.4. LAST-MODIFIED Property
This specification modifies the definition of the "LAST-MODIFIED" This specification modifies the definition of the "LAST-MODIFIED"
property to allow it to be defined on an iCalendar object. The property to allow it to be defined on an iCalendar object. The
following additions are made to the definition of this property, following additions are made to the definition of this property,
originally specified in Section 3.8.7.3 of [RFC5545]. originally specified in Section 3.8.7.3 of [RFC5545].
Purpose: This property specifies the date and time that the Purpose: This property specifies the date and time that the
information associated with the calendar was last revised. information associated with the calendar was last revised.
skipping to change at page 12, line 22 skipping to change at page 13, line 13
Value Type: URI - no default. Value Type: URI - no default.
Property Parameters: IANA, non-standard, feature, and label property Property Parameters: IANA, non-standard, feature, and label property
parameters can be specified on this property. parameters can be specified on this property.
Conformance: This property can be specified multiple times in a Conformance: This property can be specified multiple times in a
"VEVENT" or "VTODO" calendar component. "VEVENT" or "VTODO" calendar component.
Description: This property specifies information for accessing a Description: This property specifies information for accessing a
conferencing system for attendees of a meeting or task. This conferencing system for attendees of a meeting or task. This
might be a tel: URI [RFC3966] for a telephone-based conference might be for a telephone-based conference number dial-in with
number dial-in (with access codes included), or it might be an access codes included (such as a tel: URI [RFC3966] or a sip: or
http: or https: URI [RFC7230] for a web-based video chat, or a URI sips: URI [RFC3261]), or it might be for a web-based video chat
for an instant messaging group chat room. If a specific URI for a (such as an http: or https: URI [RFC7230]), or a URI for an
conferencing system is not available, a data: URI [RFC2397] instant messaging group chat room (such as an xmpp: URI
containing a text description can be used. [RFC5122]). If a specific URI for a conferencing system is not
available, a data: URI [RFC2397] containing a text description can
be used.
A conference system can be a bi-directional communication channel, A conference system can be a bi-directional communication channel,
or a uni-directional "broadcast feed". or a uni-directional "broadcast feed".
The "FEATURE" property parameter is used to describe the key The "FEATURE" property parameter is used to describe the key
capabilities of the conference system to allow a client to choose capabilities of the conference system to allow a client to choose
the ones that give the required level of interaction from a set of the ones that give the required level of interaction from a set of
multiple properties. multiple properties.
The "LABEL" property paramater is used to convey additional The "LABEL" property paramater is used to convey additional
details on the use of the URI. For example, the URIs or access details on the use of the URI. For example, the URIs or access
codes for the moderator and attendee of a teleconference system codes for the moderator and attendee of a teleconference system
could be different, and the "LABEL" property parameter could be could be different, and the "LABEL" property parameter could be
used to "tag" each "CONFERENCE" property to indicate which is used to "tag" each "CONFERENCE" property to indicate which is
which. which.
The "LANGUAGE" property parameter can be used to specify the
language used for text values used with this property (as per
Section 3.2.10 of [RFC5545].
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
conference = "CONFERENCE" confparam ":" uri CRLF conference = "CONFERENCE" confparam ":" uri CRLF
confparam = *( confparam = *(
; ;
; The following is REQUIRED, ; The following is REQUIRED,
; but MUST NOT occur more than once. ; but MUST NOT occur more than once.
; ;
(";" "VALUE" "=" "URI") / (";" "VALUE" "=" "URI") /
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; and MUST NOT occur more than once. ; and MUST NOT occur more than once.
; ;
(";" featureparam) / (";" labelparam) / (";" featureparam) / (";" labelparam) /
(";" languageparam ) /
; ;
; 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: The following are examples of this property: Example: The following are examples of this property:
skipping to change at page 14, line 22 skipping to change at page 15, line 22
; event ; event
"THUMBNAIL" / ; a smaller variant of "FULLSIZE" to be "THUMBNAIL" / ; a smaller variant of "FULLSIZE" to be
; used when space for the image is ; used when space for the image is
; constrained ; constrained
x-name / ; Experimental type x-name / ; Experimental type
iana-token) ; Other IANA registered type iana-token) ; Other IANA registered type
; ;
; Default is BADGE ; Default is BADGE
Description: This property parameter MAY be specified on "IMAGE" Description: This property parameter MAY be specified on "IMAGE"
properties. In the absence of this parameter, the value "BADGE" properties. In the absence of this parameter, the default value
MUST be used for the default behavior. The value determines how a "BADGE" MUST be used. The value determines how a client ought to
client ought to present an image supplied in iCalendar data to the present an image supplied in iCalendar data to the user.
user.
Values for this parameter are registered with IANA as per Values for this parameter are registered with IANA as per
Section 9.3. New values can be added to this registry following Section 9.3.1. New values can be added to this registry following
the procedure outlined in Section 8.2.1 of [RFC5545]. the procedure outlined in Section 8.2.1 of [RFC5545].
Servers and clients MUST handle x-name and iana-token values they Servers and clients MUST handle x-name and iana-token values they
don't recognize by not displaying any image at all. don't recognize by not displaying any image at all.
Example: Example:
IMAGE;VALUE=URI;DISPLAY=BADGE,THUMBNAIL;FMTTYPE=image/png:https://exa IMAGE;VALUE=URI;DISPLAY=BADGE,THUMBNAIL;FMTTYPE=image/png:https://exa
mple.com/images/weather-cloudy.png mple.com/images/weather-cloudy.png
skipping to change at page 16, line 28 skipping to change at page 17, line 26
Purpose: To provide a human readable label. Purpose: To provide a human readable label.
Format Definition: This property parameter is defined by the Format Definition: This property parameter is defined by the
following notation: following notation:
labelparam = "LABEL" "=" param-value labelparam = "LABEL" "=" param-value
Description: This property parameter MAY be specified on the Description: This property parameter MAY be specified on the
"CONFERENCE" property. It is anticipated that other extensions to "CONFERENCE" property. It is anticipated that other extensions to
iCalendar will re-use this property parameter on new properties iCalendar will re-use this property parameter on new properties
that they define. As a result, clients SHOULD expect to find this that they define. As a result, clients MUST expect to find this
property parameter present on many different properties. It property parameter present on many different properties. It
provides a human readable label that can be presented to calendar provides a human readable label that can be presented to calendar
users to allow them to discriminate between properties which might users to allow them to discriminate between properties which might
be similar, or provide additional information for properties that be similar, or provide additional information for properties that
are not self-describing. are not self-describing. The "LANGUAGE" property parameter can be
used to specify the language of the text in the parameter value
(as per Section 3.2.10 of [RFC5545].
Example: Example:
CONFERENCE;VALUE=URI;FEATURE=VIDEO; CONFERENCE;VALUE=URI;FEATURE=VIDEO;
LABEL="Web video chat, access code=76543"; LABEL="Web video chat, access code=76543";
:https://video-chat.example.com/;group-id=1234 :https://video-chat.example.com/;group-id=1234
7. Security Considerations 7. Security Considerations
Several of the new properties or parameters defined by this Several of the new properties or parameters defined by this
skipping to change at page 17, line 27 skipping to change at page 18, line 26
Both the "COLOR" and "IMAGE" properties are likely to be used by Both the "COLOR" and "IMAGE" properties are likely to be used by
calendar users to express their own personal view of the calendar calendar users to express their own personal view of the calendar
data. In addition, these properties could be used by attackers to data. In addition, these properties could be used by attackers to
produce a confusing display in a calendar user agent. When such produce a confusing display in a calendar user agent. When such
properties are encountered in calendar data that has come from other properties are encountered in calendar data that has come from other
calendar users (e.g., via a scheduling message, "public" calendar calendar users (e.g., via a scheduling message, "public" calendar
subscription, shared calendar etc), it is advisable for the client to subscription, shared calendar etc), it is advisable for the client to
give the receiving calendar user the option to remove (or adjust) give the receiving calendar user the option to remove (or adjust)
these properties as the data is imported into their calendar system. these properties as the data is imported into their calendar system.
This specification changes the recommendations on how "UID" property
values are constructed to minimize leaking any information that might
be security sensitive.
Security considerations in [RFC5545], and [RFC5546] MUST also be Security considerations in [RFC5545], and [RFC5546] MUST also be
adhered to. adhered to.
8. Privacy Considerations 8. Privacy Considerations
Several of the new properties or parameters defined by this Several of the new properties or parameters defined by this
specification allow reference to "external" URIs. Access to those specification allow reference to "external" URIs. Access to those
URIs could be tracked, leading to loss of privacy. Clients SHOULD URIs could be tracked, leading to loss of privacy. Clients SHOULD
ensure that suitable permission is granted by calendar users before ensure that suitable permission is granted by calendar users before
such URIs are dereferenced. such URIs are dereferenced. In particular, calendar publishers
wishing to help protect the privacy of their subscribers MUST use
HTTP with Transport Layer Security [RFC7230] ("https:" URIs instead
of "http:" URIs) for access to calendar data or ancillary data such
as images.
In general, users have to rely on the privacy policies of any
conferencing system being accessed via the "CONFERENCE" property, for
their own privacy protection. It is entirely possible for such
systems to uniquely identify and log the activity and participation
(or not) of calendar users in the conference. Calendar user agents
SHOULD track which conferencing systems are used and warn users the
first time a new one is about to be used. This is particularly
important if the client automatically "dials in" to the conference
when the event start time occurs.
By giving different calendar users different values for the "REFRESH-
INTERVAL" property, it is possible for a publisher of calendar data
to uniquely identify each refresh from each calendar users' clients,
and thereby track user activity and IP address over time. To address
this, clients SHOULD add or subtract some random amount of time from
the published "REFRESH-INTERVAL" value when doing actual refreshes.
This specification changes the recommendations on how "UID" property
values are constructed to minimize leaking any information that might
be privacy sensitive.
Privacy considerations in [RFC5545], and [RFC5546] MUST also be Privacy considerations in [RFC5545], and [RFC5546] MUST also be
adhered to. adhered to.
9. IANA Considerations 9. IANA Considerations
9.1. Property Registrations 9.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.3.2 of [RFC5545]: added to the registry defined in Section 8.3.2 of [RFC5545]:
skipping to change at page 18, line 40 skipping to change at page 20, line 19
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
| Property Parameter | Status | Reference | | Property Parameter | Status | Reference |
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
| DISPLAY | Current | RFCXXXX, Section 6.1 | | DISPLAY | Current | RFCXXXX, Section 6.1 |
| EMAIL | Current | RFCXXXX, Section 6.2 | | EMAIL | Current | RFCXXXX, Section 6.2 |
| FEATURE | Current | RFCXXXX, Section 6.3 | | FEATURE | Current | RFCXXXX, Section 6.3 |
| LABEL | Current | RFCXXXX, Section 6.4 | | LABEL | Current | RFCXXXX, Section 6.4 |
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
9.3. Display Types Registry 9.3. Property Parameter Value Registries
This document defines the following new iCalendar value registry as Two new IANA registries for iCalendar elements have been added.
per Section 8.2.6 of [RFC5545]: Additional codes MAY be used, provided the process described in
Section 8.2.1 of [RFC5545] is used to register them, using the
template in Section 8.2.6 of [RFC5545].
9.3.1. Display Types Registry
The following table has been used to initialize the Display Types
Registry.
+--------------+---------+----------------------+ +--------------+---------+----------------------+
| Display Type | Status | Reference | | Display Type | Status | Reference |
+--------------+---------+----------------------+ +--------------+---------+----------------------+
| BADGE | Current | RFCXXXX, Section 6.1 | | BADGE | Current | RFCXXXX, Section 6.1 |
| GRAPHIC | Current | RFCXXXX, Section 6.1 | | GRAPHIC | Current | RFCXXXX, Section 6.1 |
| FULLSIZE | Current | RFCXXXX, Section 6.1 | | FULLSIZE | Current | RFCXXXX, Section 6.1 |
| THUMBNAIL | Current | RFCXXXX, Section 6.1 | | THUMBNAIL | Current | RFCXXXX, Section 6.1 |
+--------------+---------+----------------------+ +--------------+---------+----------------------+
9.4. Feature Types Registry 9.3.2. Feature Types Registry
This document defines the following new iCalendar value registry as The following table has been used to initialize the Feature Types
per Section 8.2.6 of [RFC5545]: Registry.
+--------------+---------+----------------------+ +--------------+---------+----------------------+
| Feature Type | Status | Reference | | Feature Type | Status | Reference |
+--------------+---------+----------------------+ +--------------+---------+----------------------+
| AUDIO | Current | RFCXXXX, Section 6.3 | | AUDIO | Current | RFCXXXX, Section 6.3 |
| CHAT | Current | RFCXXXX, Section 6.3 | | CHAT | Current | RFCXXXX, Section 6.3 |
| FEED | Current | RFCXXXX, Section 6.3 | | FEED | Current | RFCXXXX, Section 6.3 |
| MODERATOR | Current | RFCXXXX, Section 6.3 | | MODERATOR | Current | RFCXXXX, Section 6.3 |
| PHONE | Current | RFCXXXX, Section 6.3 | | PHONE | Current | RFCXXXX, Section 6.3 |
| SCREEN | Current | RFCXXXX, Section 6.3 | | SCREEN | Current | RFCXXXX, Section 6.3 |
skipping to change at page 19, line 40 skipping to change at page 21, line 35
11. References 11. References
11.1. Normative References 11.1. 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>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[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>.
skipping to change at page 20, line 22 skipping to change at page 22, line 22
Module Level 3", World Wide Web Consortium Recommendation Module Level 3", World Wide Web Consortium Recommendation
REC-css3-color-20110607, June 2011, REC-css3-color-20110607, June 2011,
<http://www.w3.org/TR/2011/REC-css3-color-20110607>. <http://www.w3.org/TR/2011/REC-css3-color-20110607>.
11.2. Informative References 11.2. Informative References
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998, DOI 10.17487/RFC2397, August 1998,
<http://www.rfc-editor.org/info/rfc2397>. <http://www.rfc-editor.org/info/rfc2397>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004, RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>. <http://www.rfc-editor.org/info/rfc3966>.
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)",
RFC 5122, DOI 10.17487/RFC5122, February 2008,
<http://www.rfc-editor.org/info/rfc5122>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) publication)
Changes in draft-ietf-calext-extensions-05:
1. IESG: Fixed IANA section to properly define the two new
registries.
2. IESG: Added xmpp, sip, and sips as example URIs for CONFERENCE.
3. IESG: Added languageparam to CONFERENCE and also indicated it
can appear alongside LABEL.
4. IESG: Changed SHOULD -> MUST for clients to expect LABEL.
5. IESG: Privacy: use https: instead of http:.
6. IESG: Privacy: text on tracking via CONFERENCE.
7. IESG: Privacy: text on tracking via REFRESH-INTERVAL.
8. IESG: Modified UID value generation to be stricter about what is
allowed..
9. IESG: Other editorial tweaks.
10. Removed CONFERENCE from VJOURNAL ABNF.
Changes in draft-ietf-calext-extensions-04: Changes in draft-ietf-calext-extensions-04:
1. SECDIR: Added new items to Security Considerations and added 1. SECDIR: Added new items to Security Considerations and added
Privacy Considerations. Privacy Considerations.
2. SECDIR: fixed missing conference item in component ABNF 2. SECDIR: fixed missing conference item in component ABNF
definitions. definitions.
3. SECDIR: editorial fixes. 3. SECDIR: editorial fixes.
 End of changes. 27 change blocks. 
47 lines changed or deleted 154 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/