RFC 7986
New Properties for iCalendar
New Properties for iCalendar 🎀
Okay bestie, this one is RFC 7986 and it's giving standards track 💅 Written by C. Daboo at Apple Inc. and published by the Internet Engineering Task Force (IETF), it's dated October 2016, with ISSN 2070-1721. It updates RFC 5545, and it doesn't obsolete anything. The category is Standards Track, so this is the real deal 🔥
Abstract
okay so the abstract is short and sweet ✨ This doc defines a bunch of new properties for iCalendar data, and it also stretches the use of some existing properties so they work across the whole iCalendar object 🦋
Status of This Memo
this is an Internet Standards Track document 💜 It's a product of the IETF and it represents the consensus of the IETF community. It's been through public review and got the thumbs up from the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841. For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7986 🌸
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🙈
Table of Contents
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Backwards-Compatible Extension Properties .......................3
4. Modifications to Calendar Components ............................4
5. Properties ......................................................5
5.1. NAME Property ..............................................5
5.2. DESCRIPTION Property .......................................6
5.3. UID Property ...............................................7
5.4. LAST-MODIFIED Property .....................................8
5.5. URL Property ...............................................8
5.6. CATEGORIES Property ........................................8
5.7. REFRESH-INTERVAL Property ..................................9
5.8. SOURCE Property ...........................................10
5.9. COLOR Property ............................................10
5.10. IMAGE Property ...........................................11
5.11. CONFERENCE Property ......................................13
6. Property Parameters ............................................14
6.1. DISPLAY Property Parameter ................................14
6.2. EMAIL Property Parameter ..................................15
6.3. FEATURE Property Parameter ................................16
6.4. LABEL Property Parameter ..................................17
7. Security Considerations ........................................18
8. Privacy Considerations .........................................18
9. IANA Considerations ............................................19
9.1. Property Registrations ....................................19
9.2. Parameter Registrations ...................................20
9.3. Property Parameter Value Registries .......................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................22
Acknowledgments ...................................................23
Author's Address ..................................................231. Introduction 🧚
so the iCalendar data format ([RFC5545]) is how calendar data gets represented, and it pairs up with the iCalendar Transport-Independent Interoperability Protocol (iTIP) ([RFC5546]) to handle scheduling between calendar users 📅 iCalendar is everywhere, and the spec lets vendors add extension elements to the format to level up what it can do. So a bunch of vendors did exactly that 💅 This spec gathers a bunch of those ad hoc extensions and uses the new IANA registry capability from [RFC5545] to register standard versions with clearly defined meanings and semantics. Plus, some brand new elements are added for features vendors have been begging for lately 😭✨
2. Conventions Used in This Document 📝
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 🫶
the notation in this memo is the ABNF notation from [RFC5234], the way iCalendar [RFC5545] uses it. Any syntax elements shown below that aren't explicitly defined in this spec come straight from iCalendar [RFC5545] 💖
3. Backwards-Compatible Extension Properties 🌈
so iCalendar properties can have different value types, and you indicate which one with a "VALUE" parameter. Each property's definition names a "default" value type that gets assumed when there's no "VALUE" parameter. Here's the tea ☕ That default is a problem for iCalendar parser and generator software that doesn't know the defaults for new properties. Say a new property FOO had a default value type of URI, and you used a URI value with a comma in it. A generator that doesn't know this would probably treat the value as "TEXT" and backslash-escape the comma, which makes it an invalid URI value 💀
To dodge this, this spec recommends that every property not defined in [RFC5545] always includes a "VALUE" parameter whenever the type isn't "TEXT". So in that example, FOO would carry VALUE=URI. That lets parser and generator software keep track of the right types for unknown properties 🎀
New properties defined here use the term "no default" in their "Value Type" definition, which tells you the "VALUE" parameter has to be included 🙌
4. Modifications to Calendar Components 🍓
this section lays out the changes to the syntax from iCalendar [RFC5545]. The new elements get defined in the sections that follow 🦋
calprops =/ *(
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
uid / last-mod / url /
refresh / source / color
;
; The following are OPTIONAL,
; and MAY occur more than once.
;
name / description / categories /
image
;
) eventprop =/ *(
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
color /
;
; The following are OPTIONAL,
; and MAY occur more than once.
;
conference / image
;
) todoprop =/ *(
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
color /
;
; The following are OPTIONAL,
; and MAY occur more than once.
;
conference / image
;
) jourprop =/ *(
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
color /
;
; The following are OPTIONAL,
; and MAY occur more than once.
;
image
;
)5. Properties 💅
5.1. NAME Property 🎀
Property Name: NAME
Purpose: this one specifies the name of the calendar 🌸
Value Type: TEXT
Property Parameters: IANA, non-standard, alternate text representation, and language property parameters can be attached to this property 💖
Conformance: you can specify this property multiple times in an iCalendar object, but each property MUST represent the name of the calendar in a different language. Main character rule, no duplicates in the same language 👑
Description: this property names the iCalendar object so calendar user agents can show it to a user. A calendar only has one name, but you can drop in multiple language variants by including the property several times, each with a different LANGUAGE parameter value ✨
Format Definition: this property is defined by the following notation:
name = "NAME" nameparam ":" text CRLF
nameparam = *(
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
(";" altrepparam) / (";" languageparam) /
;
; The following is OPTIONAL,
; and MAY occur more than once.
;
(";" other-param)
;
)Example: here's what it looks like in action 🧚
NAME:Company Vacation Days5.2. DESCRIPTION Property 🌷
this spec tweaks the "DESCRIPTION" property so it can be defined in an iCalendar object 💜 These additions get layered onto the definition from Section 3.8.1.5 of [RFC5545], so keep that one open too 📖
Purpose: this property specifies the description of the calendar 🦋
Conformance: you can specify this property multiple times in an iCalendar object, but each property MUST represent the description of the calendar in a different language. Same energy as the NAME property: one language per instance 🫶
Description: this property holds a lengthy text description of the iCalendar object, so calendar user agents can explain the nature of the calendar data to a user. A calendar only has one description, but multiple language variants work the same way as before: include the property several times, each with a different "LANGUAGE" parameter value 🌈
5.3. UID Property 🦋
okay so this bit lets the "UID" property show up inside an iCalendar object now 💖 it's the same property from Section 3.8.4.7 of [RFC5545], just with a few new bits added on top.
Purpose: this is the persistent, globally unique identifier for the iCalendar object ✨ it's super handy for spotting duplicate calendar streams a client might have been given access to. Pair it with the "LAST-MODIFIED" property (also on the "VCALENDAR" object) and you can figure out which version of a calendar is the newest 👑
Conformance: this property can be specified once in an iCalendar object.
Okay, now the tea 🫖 the description of "UID" in [RFC5545] suggested building the value out of host names, IP addresses, and domain names. That's no longer considered good practice, especially for security and privacy, because it can leak key info about a calendar user or their client and network setup 🙈 So this spec updates [RFC5545] and says 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 hex-encoded random Universally Unique Identifier (UUID) values, as defined in Sections 4.4 and 4.5 of [RFC4122] 🫶
Here's what that looks like:
UID:5FC53010-1267-4F8E-BC28-1D7AE55A7C99And if calendar user agents choose to use some other form of opaque identifier for "UID", it 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 🌸
This spec modifies the "LAST-MODIFIED" property so it can be defined in an iCalendar object too. The additions are on top of the original definition from Section 3.8.7.3 of [RFC5545] 🧚
Purpose: this property specifies the date and time that the information associated with the calendar was last revised.
Conformance: this property can be specified once in an iCalendar object.
5.5. URL Property 🍓
Same glow-up here. "URL" can now live in an iCalendar object as well, building on Section 3.8.4.6 of [RFC5545] 💅
Purpose: this property may be used to convey a location where a more dynamic rendition of the calendar information can be found.
Conformance: this property can be specified once in an iCalendar object.
5.6. CATEGORIES Property 🌈
"CATEGORIES" gets the same upgrade, building on Section 3.8.1.2 of [RFC5545] ⭐
Purpose: this property defines the categories for an entire calendar.
Conformance: this property can be specified multiple times in an iCalendar object.
Description: when multiple properties are present, the set of categories that apply to the iCalendar object are the union of all the categories listed in each property value. So you just add them all together 🎀
5.7. REFRESH-INTERVAL Property ⏰
Property Name: REFRESH-INTERVAL
Purpose: this property specifies a suggested minimum interval for polling for changes of the calendar data from the original source of that data 🦋
Value Type: DURATION -- no default
Property Parameters: IANA and non-standard property parameters can be specified on this property.
Conformance: this property can be specified once in an iCalendar object.
Description: this property specifies a positive duration that gives a suggested minimum polling interval for checking for updates to the calendar data. The value of this property SHOULD be used by calendar user agents to limit the polling interval for calendar data updates to the minimum interval specified. Main character energy for your refresh schedule 💖
Format Definition: this property is defined by the following notation:
refresh = "REFRESH-INTERVAL" refreshparam
":" dur-value CRLF
;consisting of a positive duration of time.
refreshparam = *(
;
; The following is REQUIRED,
; but MUST NOT occur more than once.
;
(";" "VALUE" "=" "DURATION") /
;
; The following is OPTIONAL,
; and MAY occur more than once.
;
(";" other-param)
;
)Example: the following is an example of this property:
REFRESH-INTERVAL;VALUE=DURATION:P1W5.8. SOURCE Property 🛰️
Property Name: SOURCE
Purpose: this property identifies a URI where calendar data can be refreshed from. Think of it as the original home of your calendar 🏡
Value Type: URI -- no default
Property Parameters: IANA and non-standard property parameters can be specified on this property.
Conformance: this property can be specified once in an iCalendar object.
Description: this property identifies a location where a client can retrieve updated data for the calendar. Clients SHOULD honor any specified "REFRESH-INTERVAL" value when periodically retrieving data 🫶 Also, this one is NOT the same as "URL"! "URL" is for an alternative representation of the calendar data, not where the data originally lives. Don't mix them up bestie 🙈
Format Definition: this property is defined by the following notation:
source = "SOURCE" sourceparam ":" uri CRLF
sourceparam = *(";" other-param)Example: the following is an example of this property:
SOURCE;VALUE=URI:https://example.com/holidays.ics5.9. COLOR Property 🎨
Property Name: COLOR
Purpose: this property specifies a color used for displaying the calendar, event, todo, or journal data ✨
Value Type: TEXT
Property Parameters: IANA and non-standard property parameters can be specified on this property.
Conformance: this property can be specified once in an iCalendar object or in "VEVENT", "VTODO", or "VJOURNAL" calendar components.
Description: this property specifies a color that clients MAY use when presenting the relevant data to a user. Typically, this would appear as the "background" color of events or tasks 🍓 The value is a case-insensitive color name taken from the CSS3 set of names, defined in Section 4.3 of [W3C.REC-css3-color-20110607]. So "turquoise" and "TURQUOISE" both slay 💅
Format Definition: this property is defined by the following notation:
color = "COLOR" colorparam ":" text CRLF
; Value is CSS3 color name
colorparam = *(";" other-param)Example: the following is an example of this property:
COLOR:turquoise5.10. IMAGE Property 📸
Property Name: IMAGE
Purpose: this property specifies an image associated with the calendar or a calendar component 🌷
Value Type: URI or BINARY -- no default. The value MUST be data with a media type of "image" or refer to such data. No random files, we only want images 🙅♀️
Property Parameters: IANA, non-standard, display, inline encoding, and value data type property parameters can be specified on this property. The format type parameter can be specified on this property and is RECOMMENDED for inline binary-encoded content information 💜
Conformance: this property can be specified multiple times in an iCalendar object or in "VEVENT", "VTODO", or "VJOURNAL" calendar components.
Description: this property specifies an image for an iCalendar object or a calendar component, either via a URI or directly with inline data. Calendar user agents can use it when presenting the calendar data to a user 🌸 You can have multiple properties for alternative sets of images with, for example, varying media subtypes, resolutions, or sizes, since MAY be used here. When multiple properties are present, calendar user agents SHOULD display only one of them, picking the one that provides the most appropriate image quality, or display none. The "DISPLAY" parameter is used to indicate the intended display mode for the image. The "ALTREP" parameter, defined in [RFC5545], can be used to provide a "clickable" image where the URI in the parameter value can be "launched" by a click on the image in the calendar user agent 👆✨
Format Definition: this property is defined by the following notation:
image = "IMAGE" imageparam
(
(
";" "VALUE" "=" "URI"
":" uri
) /
(
";" "ENCODING" "=" "BASE64"
";" "VALUE" "=" "BINARY"
":" binary
)
)
CRLF
imageparam = *(
;
; The following is OPTIONAL for a URI value,
; RECOMMENDED for a BINARY value,
; and MUST NOT occur more than once.
;
(";" fmttypeparam) /
;
; The following are OPTIONAL,
; and MUST NOT occur more than once.
;
(";" altrepparam) / (";" displayparam) /
;
; The following is OPTIONAL,
; and MAY occur more than once.
;
(";" other-param)
;
)Example: the following is an example of this property:
IMAGE;VALUE=URI;DISPLAY=BADGE;FMTTYPE=image/png:h
ttp://example.com/images/party.png5.11. CONFERENCE Property ✨
okay bestie, the CONFERENCE property is literally the "here's how to join the call" property 📞💖
- Property Name:
CONFERENCE - Purpose: This property gives you the info you need to get into a conferencing system. 🎀
- Value Type: URI, with no default. 🦋
- Property Parameters: You can use the IANA, non-standard, feature, and label property parameters on this one. 💅
- Conformance: You can add this property multiple times to a
VEVENTorVTODOcalendar component. 🌈
Okay so the vibe here is that attendees of a meeting or task need a way in, and this property is how they get it 🫶 It can be a phone dial-in with the access codes already included (like a tel: URI [RFC3966], or a sip: or sips: URI [RFC3261]). It can be a web video chat (like an http: or https: URI [RFC7230]). It can even be an instant messaging group chat room (like an xmpp: URI [RFC5122]) 💬 If there isn't a specific URI for the conferencing system, you can use a data: URI [RFC2397] that holds a text description instead 🧚
Also, a conference can be a two-way channel or a one-way "broadcast feed," and both are totally valid 📡✨
The "FEATURE" property parameter describes the key capabilities of the conference system. This helps a client pick the one with the level of interaction you actually want out of a bunch of CONFERENCE properties 🔥
The "LABEL" property parameter adds extra details about how the URI should be used. For example, the moderator and the attendee of a teleconference could have different URIs or access codes. You can use "LABEL" to tag each CONFERENCE property so everyone knows which is which 🏷️💜
The "LANGUAGE" property parameter can specify the language of the text values used with this property (as per Section 3.2.10 of [RFC5545]) 🌸
Here's the formal grammar 🤓 (copy it exactly, it's literally the spec):
conference = "CONFERENCE" confparam ":" uri CRLF
confparam = *(
;
; The following is REQUIRED,
; but MUST NOT occur more than once.
;
(";" "VALUE" "=" "URI") /
;
; The following are OPTIONAL,
; and MUST NOT occur more than once.
;
(";" featureparam) / (";" labelparam) /
(";" languageparam ) /
;
; The following is OPTIONAL,
; and MAY occur more than once.
;
(";" other-param)
;
)Here are some examples, look at them being iconic 😭
CONFERENCE;VALUE=URI;FEATURE=PHONE,MODERATOR;
LABEL=Moderator dial-in:tel:+1-412-555-0123,,,654321
CONFERENCE;VALUE=URI;FEATURE=PHONE;
LABEL=Attendee dial-in:tel:+1-412-555-0123,,,555123
CONFERENCE;VALUE=URI;FEATURE=PHONE;
LABEL=Attendee dial-in:tel:+1-888-555-0456,,,555123
CONFERENCE;VALUE=URI;FEATURE=CHAT;
LABEL=Chat room:xmpp:chat-123@conference.example.com
CONFERENCE;VALUE=URI;FEATURE=AUDIO,VIDEO;
LABEL=Attendee dial-in:https://chat.example.com/audio?id=1234566. Property Parameters 🎀
6.1. DISPLAY Property Parameter 🖼️
- Parameter Name:
DISPLAY - Purpose: This tells you the different ways an image for a calendar or component can be shown 💖
Here's the grammar:
displayparam = "DISPLAY" "=" displayval *("," displayval)
displayval = ("BADGE" / ; image inline with the title of the
; event
"GRAPHIC" / ; a full image replacement for the event
; itself
"FULLSIZE" / ; an image that is used to enhance the
; event
"THUMBNAIL" / ; a smaller variant of "FULLSIZE" to be
; used when space for the image is
; constrained
x-name / ; Experimental type
iana-token) ; Other IANA-registered type
;
; Default is BADGEOkay so this parameter MAY be on "IMAGE" properties. If it's not there, the default "BADGE" MUST be used 🙈 The value tells the client how it should present the image to the user, and that's the whole job ✨
The values are registered with IANA as per Section 9.3.1. You can add new ones following the procedure in Section 8.2.1 of [RFC5545] 🌈
Now the important part. Servers and clients MUST handle x-name and iana-token values they don't recognize by not displaying any image at all 💀 No guessing, no random pictures, just nothing. Iconic restraint 🫡
Example:
IMAGE;VALUE=URI;DISPLAY=BADGE,THUMBNAIL;FMTTYPE=image/png:https://exa
mple.com/images/weather-cloudy.png6.2. EMAIL Property Parameter 📧
- Parameter Name:
EMAIL - Purpose: This specifies an email address you can use to identify or contact an organizer or attendee 🦋
Grammar time:
emailparam = "EMAIL" "=" param-valueOkay, the EMAIL parameter MAY be on "ORGANIZER" or "ATTENDEE" properties 💜 It's useful when the calendar user address (the value of those properties) isn't something recipients could easily match up, like an address book entry. The value is an email address that's easy to match, so recipients can also just email the calendar user as a backup way to reach them 📬
If a recipient's calendar app lets them save contact info based on the "ORGANIZER" or "ATTENDEE" properties, those apps SHOULD use any "EMAIL" parameter value as the contact's email address instead of the mailto: calendar user address in the property value 🍓 And calendar user agents SHOULD NOT include an "EMAIL" parameter when its value matches the calendar user address in the property value. No doubling up, bestie 🙅♀️
Example:
ATTENDEE;CN=Cyrus Daboo;EMAIL=cyrus@example.com:mailto:opaque-toke
n-1234@example.com6.3. FEATURE Property Parameter 🎬
- Parameter Name:
FEATURE - Purpose: This specifies one or more features of a conference or broadcast system ✨
The grammar:
featureparam = "FEATURE" "=" featuretext *("," featuretext)
featuretext = ("AUDIO" / ; Audio capability
"CHAT" / ; Chat or instant messaging
"FEED" / ; Blog or Atom feed
"MODERATOR" / ; Moderator dial-in code
"PHONE" / ; Phone conference
"SCREEN" / ; Screen sharing
"VIDEO" / ; Video capability
x-name / ; Experimental type
iana-token) ; Other IANA-registered typeThis parameter MAY be on the "CONFERENCE" property, and you can list multiple values 🫶 The "MODERATOR" value means the property is specific to the owner or initiator of the conference. Its URI is the one that "activates" the system, like a "moderator" access code that's different from the "regular" one 👑
Examples:
CONFERENCE;VALUE=URI;FEATURE=AUDIO:rtsp://audio.example.com/
event
CONFERENCE;VALUE=URI;FEATURE=AUDIO,VIDEO:https://video-chat.exam
ple.com/;group-id=12346.4. LABEL Property Parameter 🏷️
- Parameter Name:
LABEL - Purpose: This provides a human-readable label 💖
Grammar:
labelparam = "LABEL" "=" param-valueThis parameter MAY be on the "CONFERENCE" property. Other iCalendar extensions are expected to reuse it on their own new properties too, so clients MUST expect to find it on lots of different properties 🌈 It gives people a readable label so they can tell apart similar properties, or get extra info from properties that don't explain themselves. The "LANGUAGE" property parameter can set the language of the text in the parameter value (as per Section 3.2.10 of [RFC5545]) 🌸
Example:
CONFERENCE;VALUE=URI;FEATURE=VIDEO;
LABEL="Web video chat, access code=76543";
:https://video-chat.example.com/;group-id=12347. Security Considerations 🔐
Okay bestie, this part is serious, so listen up 🫶
Several of the new properties and parameters in this spec let you reference "external" URIs. Care MUST be taken when you access data at external URIs, because malicious content could be sitting there 😭 Clients SHOULD make sure calendar users have granted suitable permission before those URIs get dereferenced 🛡️
The "REFRESH-INTERVAL" property could be abused by an attacker to make a client flood the server hosting the calendar with rapid requests, for example by setting a duration of just one second. That could eat up resources on the client or server and lead to denial-of-service attacks on the server 💀 Clients MUST ensure that they throttle requests to the server to a reasonable rate. In most cases, updating a public calendar once per day would be enough 🌙 If "REFRESH-INTERVAL" is any less than that, clients SHOULD warn the calendar user and let them override it with a longer value 🙋♀️
The "CONFERENCE" property can include a "FEATURE" property parameter with a "MODERATOR" value. In some cases, the access code the owner or initiator of a conference uses might be private to that one person. Clients and servers MUST ensure that such properties are not sent to attendees of a scheduled component 🤫🔒
Both the "COLOR" and "IMAGE" properties are likely to be used by calendar users to show off their own personal view of the calendar data 🎨 But attackers could also use these properties to make a confusing display in a calendar user agent 😵 When such properties show up in calendar data that came from other calendar users (for example through a scheduling message, or a "public" calendar subscription), it's advisable for the client to give the receiving calendar user the option to remove or adjust them as the data is imported into their calendar system 🧹
This specification also changes the recommendations on how "UID" property values are constructed, so they leak less information that might be security sensitive 🙈
Security considerations in [RFC5545] and [RFC5546] MUST also be adhered to. No skipping those, periodt 💅
8. Privacy Considerations 🔐✨
okay so bestie, this section is lowkey SO important. Several of the new properties and parameters here let you reference "external" URIs, and every time a client fetches one, somebody could be tracking it. That's a privacy leak, no cap. Clients SHOULD make sure calendar users have given suitable permission before they dereference those URIs 🫶. And if you're a calendar publisher who wants to protect your subscribers, you MUST use HTTP with Transport Layer Security [RFC7230] (https: URIs instead of http: URIs) for calendar data and ancillary stuff like images 🔒💖.
Conferencing is another vibe. Users are basically relying on the privacy policies of whatever conferencing system is reached through the CONFERENCE property 🎀. These systems can totally uniquely identify and log who shows up to a conference and how active they are, or aren't, so it's giving surveillance 👀. Calendar user agents SHOULD keep track of which conferencing systems get used and warn the user the first time a new one is about to be used 🚨. This matters even more if the client auto "dials in" when the event start time hits 📞.
Okay, the REFRESH-INTERVAL thing is sneaky 🦋. If a publisher gives different calendar users different REFRESH-INTERVAL values, they can uniquely identify each refresh from each user's client and track their activity and IP address over time 💀. To fix this, clients SHOULD add or subtract some random amount of time from the published REFRESH-INTERVAL value when they actually refresh 🎲🌸.
This spec also changes how UID property values are constructed so they leak less privacy-sensitive info 🙈💜.
And finally, the privacy considerations in [RFC5545] and [RFC5546] MUST also be adhered to 📚. No skipping!
9. IANA Considerations 📋🌈
9.1. Property Registrations
This document defines the following new iCalendar properties 🦋. IANA has registered them in the "Properties" registry defined in Section 8.3.2 of [RFC5545]. IANA has also added a reference to this document wherever the properties originally defined in RFC 5545 got updated by this document 💅.
+------------------+---------+--------------------------------------+
| Property | Status | Reference |
+------------------+---------+--------------------------------------+
| NAME | Current | RFC 7986, Section 5.1 |
| DESCRIPTION | Current | RFC 5545, Section 3.8.1.5; RFC 7986, |
| | | Section 5.2 |
| UID | Current | RFC 5545, Section 3.8.4.7; RFC 7986, |
| | | Section 5.3 |
| LAST-MODIFIED | Current | RFC 5545, Section 3.8.7.3 RFC 7986, |
| | | Section 5.4 |
| URL | Current | RFC 5545, Section 3.8.4.6; RFC 7986, |
| | | Section 5.5 |
| CATEGORIES | Current | RFC 5545, Section 3.8.1.2; RFC 7986, |
| | | Section 5.6 |
| REFRESH-INTERVAL | Current | RFC 7986, Section 5.7 |
| SOURCE | Current | RFC 7986, Section 5.8 |
| COLOR | Current | RFC 7986, Section 5.9 |
| IMAGE | Current | RFC 7986, Section 5.10 |
| CONFERENCE | Current | RFC 7986, Section 5.11 |
+------------------+---------+--------------------------------------+9.2. Parameter Registrations
This document defines the following new iCalendar property parameters 🎀. IANA has registered these in the "Parameters" registry defined in Section 8.3.3 of [RFC5545] ✨.
+--------------------+---------+-----------------------+
| Property Parameter | Status | Reference |
+--------------------+---------+-----------------------+
| DISPLAY | Current | RFC 7986, Section 6.1 |
| EMAIL | Current | RFC 7986, Section 6.2 |
| FEATURE | Current | RFC 7986, Section 6.3 |
| LABEL | Current | RFC 7986, Section 6.4 |
+--------------------+---------+-----------------------+9.3. Property Parameter Value Registries
IANA has created two new registries for iCalendar elements: the "Display Types" registry and the "Feature Types" registry 🧚. Additional codes MAY be used, provided the process and template described in Sections 8.2.1 and 8.2.6 of [RFC5545] are used to register them 💖.
9.3.1. Display Types Registry
The following table has been used to initialize the "Display Types" registry 🌸.
+--------------+---------+-----------------------+
| Display Type | Status | Reference |
+--------------+---------+-----------------------+
| BADGE | Current | RFC 7986, Section 6.1 |
| GRAPHIC | Current | RFC 7986, Section 6.1 |
| FULLSIZE | Current | RFC 7986, Section 6.1 |
| THUMBNAIL | Current | RFC 7986, Section 6.1 |
+--------------+---------+-----------------------+9.3.2. Feature Types Registry
The following table has been used to initialize the "Feature Types" registry 🦋.
+--------------+---------+-----------------------+
| Feature Type | Status | Reference |
+--------------+---------+-----------------------+
| AUDIO | Current | RFC 7986, Section 6.3 |
| CHAT | Current | RFC 7986, Section 6.3 |
| FEED | Current | RFC 7986, Section 6.3 |
| MODERATOR | Current | RFC 7986, Section 6.3 |
| PHONE | Current | RFC 7986, Section 6.3 |
| SCREEN | Current | RFC 7986, Section 6.3 |
| VIDEO | Current | RFC 7986, Section 6.3 |
+--------------+---------+-----------------------+10. References 📚💜
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009,
<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-css3-color-20110607]
Celik, T., Lilley, C., and D. Baron, "CSS Color Module
Level 3", World Wide Web Consortium Recommendation
REC-css3-color-20110607, June 2011,
<https://www.w3.org/TR/2011/REC-css3-color-20110607>.10.2. Informative References
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998,
<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",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<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
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.Acknowledgments 🫶🌟
Thanks to the following individuals for feedback: Bernard Desruisseaux, Mike Douglass, Lucia Fedorova, Ken Murchison, Arnaud Quillaud, and Dave Thewlis 💖.
This specification came about via discussions at the Calendaring and Scheduling Consortium 🎀.
Author's Address 🖋️
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
United States of America
Email: cyrus@daboo.name
URI: http://www.apple.com/That's the whole thing, bestie! 🌈💅✨
📦 where this page comes from
- ietf: rfc7986 2016-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms