RFC 2447
iCalendar Message-Based Interoperability Protocol (iMIP)
RFC 2447: iCalendar Message-Based Interoperability Protocol (iMIP) 💌
okay bestie, this is RFC 2447 and it's giving calendar invites inside email 📅✨ It was written by F. Dawson (Lotus), S. Mansour (Netscape), and S. Silverberg (Microsoft), and it's dated November 1998. It's a Standards Track doc, so it's meant to be implemented 💅 The header doesn't list any RFC it obsoletes or updates, so it's a standalone glow-up 🦋
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice 🎀
Copyright (C) The Internet Society (1998). All Rights Reserved. 💜
Abstract 🧚
Okay so this document, [iMIP], is the bridge between the iCalendar Transport-independent Interoperability Protocol (iTIP) and Internet email-based transports 📨 Calendaring entries defined by the iCalendar Object Model [iCAL] get put together using pieces from [RFC-822], [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049]. It's so iconic 😭
This document came out of discussions in the IETF Calendaring and Scheduling (CALSCH) working group. You can find more on the IMC web site at http://www.imc.org, and on the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Check the references in this document for how to get to all of these other docs 🔥
Table of Contents 🍓
1 INTRODUCTION........................................................2
1.1 RELATED MEMOS ...................................................2
1.2 FORMATTING CONVENTIONS ..........................................3
1.3 TERMINOLOGY .....................................................4
2 MIME MESSAGE FORMAT BINDING.........................................4
2.1 MIME MEDIA TYPE .................................................4
2.2 SECURITY ........................................................4
2.2.1 Authorization ...............................................4
2.2.2 Authentication ..............................................5
2.2.3 Confidentiality .............................................5
2.3 [RFC-822] ADDRESSES .............................................5
2.4 CONTENT TYPE ....................................................5
2.5 CONTENT-TRANSFER-ENCODING .......................................6
2.6 CONTENT-DISPOSITION .............................................6
3 SECURITY CONSIDERATIONS.............................................7
4 EXAMPLES............................................................8
4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8
4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8
4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9
4.4 MULTIPLE SIMILAR COMPONENTS ....................................10
4.5 MULTIPLE MIXED COMPONENTS ......................................11
4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY ....................13
5 RECOMMENDED PRACTICES..............................................14
5.1 USE OF CONTENT AND MESSAGE IDS .................................14
6 BIBLIOGRAPHY.......................................................15
7 AUTHORS' ADDRESSES.................................................16
8 FULL COPYRIGHT STATEMENT...........................................181. Introduction 🌸
This binding doc gives you the transport-specific info you need to convey iCalendar Transport-independent Interoperability Protocol (iTIP) over MIME, as defined in [RFC-822] and [RFC-2045] 💖
1.1. Related Memos 📚
Implementers are going to need to know a few other memos too. Together with this one, they make up the framework for Internet calendaring and scheduling standards 🦋
This document, [iMIP], is the Internet email binding for iTIP 💌
- [iCAL] specifies the core stuff: objects, data types, properties, and property parameters ✨
- [iTIP] specifies an interoperability protocol for scheduling between different implementations 🤝
This memo doesn't try to re-explain concepts or definitions from those other memos. Wherever it can, it points you to the memo that already specifies them 🫶
1.2. Formatting Conventions 💅
The mechanisms in this memo are defined in prose. To talk about the calendaring and scheduling model, the core objects, and the interoperability protocol from [iCAL] and [iTIP], a few formatting conventions get used 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119] 🔥
Calendaring and scheduling roles get written in quoted strings, with the first letter of each word capitalized. For example, "Organizer" is a role of a "Calendar User" in the scheduling protocol defined by [iTIP] 👑
Calendar components defined by [iCAL] get written as capitalized, quoted strings too. Every calendar component starts with the letter "V" 💜 For example, "VEVENT" is the event component, "VTODO" is the to-do component, and "VJOURNAL" is the daily journal component 📅
Scheduling methods defined by [iTIP] are also capitalized, quoted strings. For example, "REQUEST" is the method for asking for a scheduling calendar component to be created or modified 🙌 And "REPLY" is the method a recipient uses to update their status with the "Organizer" of the calendar component 💫
Properties defined by [iCAL] are capitalized, quoted strings followed by the word "property". For example, the "ATTENDEE" property is the iCalendar property used to convey a calendar user's calendar address 🧚
Property parameters defined by [iCAL] are lowercase, quoted strings followed by the word "parameter". For example, the "value" parameter is the iCalendar property parameter used to override the default data type for a property value 🌈
1.3. Terminology 🍓
The email terms used in this memo come from [RFC-822] and [RFC-2045]. The calendaring and scheduling terms come from [iCAL] and [iTIP] ✨
2. MIME Message Format Binding 💌
This section defines the message binding to the MIME electronic mail transport 📨
The sections below talk about the "originator" and the "respondent" of an iMIP message. Usually, the originator is the "Organizer" of an event, and the respondent is an "Attendee" of that event 🦋
The [RFC-822] "Reply-To" header usually holds the email address of the originator or respondent of an event. But that can't be guaranteed, since Mail User Agents (MUA) aren't required to enforce iMIP semantics 🙈
2.1. MIME Media Type 🎀
A MIME entity that contains content information formatted according to this document will be referenced as a text/calendar content type. This content type is assumed to be transported through a MIME electronic mail transport 💖
2.2. Security 🔐
This section covers a few parts of security: Authentication, Authorization, and Confidentiality 👑 Authentication and confidentiality can be done with [RFC-1847], which specifies Security Multiparts for MIME. That framework defines new content types and multipart subtypes: signed and encrypted. Each one has two body parts: one for the protected data, and one for the control info needed to remove the protection 🔥
2.2.1. Authorization 🚫
Okay, this one's important 😭 In [iTIP] messages, only the "Organizer" is authorized to modify or cancel the calendar entries they organize. So spoof@xyz.com is not allowed to modify or cancel a meeting organized by a@example.com. Also, only the respondent has the authorization to indicate their status to the "Organizer". That means the "Organizer" must ignore an [iTIP] message from spoof@xyz.com that declines a meeting invitation for b@example.com 💀
Implementations of iMIP SHOULD verify the authenticity of the creator of an iCalendar object before taking any action. The methods for doing this are covered later in this document 🫶
[RFC-1847] message flow in iTIP supports someone working on behalf of a "Calendar User" through the "sent-by" parameter, which is attached to the "ATTENDEE" and "ORGANIZER" properties. But there's no mechanism to verify whether a "Calendar User" has actually authorized someone to work on their behalf. So it's left up to implementations to give "Calendar Users" a way to make that call 💅
2.2.2. Authentication 🔑
Authentication can be done with an implementation of the [RFC-1847] multipart/signed that supports public/private key certificates. Authentication only works on messages that have been signed. Authenticating an unsigned message may not be reliable 🌸
2.2.3. Confidentiality 🤫
To make sure confidentiality holds up, iMIP implementations should utilize [RFC-1847]-compliant encryption. The protocol doesn't stop a "Calendar User Agent" (CUA) from forwarding iCalendar objects to other users or agents 💜
2.3. [RFC-822] Addresses 📬
The calendar address in the "ATTENDEE" property of an iCalendar object MUST be a fully qualified [RFC-822] address specification for the corresponding "Organizer" or "Attendee" of the "VEVENT" or "VTODO" 💖
Because [iTIP] doesn't stop "Attendees" from forwarding "VEVENTS" or "VTODOS" to other people, the [RFC-822] "Sender" value may not match the "Organizer". And you can't reliably figure out the "Organizer" or "Attendee" from the [RFC-822] "Sender" or "Reply-to" values of an iMIP message either 🙈 The relevant address MUST be found by opening the text/calendar MIME body part and checking the "ATTENDEE" and "ORGANIZER" properties 🔍✨
2.4 Content Type 🎀
okay bestie, so any MIME body part with iCalendar content that follows this doc MUST be labelled text/calendar 💖 The Content-Type header also has to include the method type parameter, and its value MUST match the value of the METHOD calendar property inside the iCalendar object ✨ That means if one MIME message has several iCalendar objects with different method values, it must be wrapped in a multipart/mixed entity so each object gets its own text/calendar MIME entity 🫶
A charset parameter MUST be present if the iCalendar object has any characters outside US-ASCII 🌸 [RFC-2046] talks about picking the right charset value, so go read that if you're unsure 🙈
The component parameter is optional 🧚 It tells you which iCalendar component type lives inside the object.
Here's what the header looks like for an event message, no cap it's so clean 💅
Content-Type:text/calendar; method=request; charset=UTF-8;
component=veventSo text/calendar lets a scheduling message ride along with other content in a multipart/mixed message, or sit inside a multipart/alternative message next to a clear-text, human-readable version of the same scheduling message 🦋
Now, the real lowkey vibe check: MIME user agents that don't know text/calendar still need to understand the message 😭 So scheduling messages SHOULD be sent with an alternative, human-readable version of the info 🍓
2.5 Content-Transfer-Encoding 💜
Quick reminder that the default character set for iCalendar objects is UTF-8 ✨ If the object has any characters that aren't US-ASCII, a transfer encoding SHOULD be used for it 🫶
2.6 Content-Disposition 🦋
Handling for a MIME part should be based on its Content-Type 🌈 BUT ngl, that's not guaranteed everywhere 💀 Some environments look at the file type or extension instead. So if you want things to work in those places, implementations may wish to include a Content-Disposition property that sets a file name 🎀
3 Security Considerations 🔐
Okay this part is SERIOUS, bestie 😭 The security threats you need to handle when implementing iTIP are laid out in [iTIP] ✨ Two spoofing threats show up there: spoofing the "Organizer" and spoofing an "Attendee" 👀 To deal with these, a recipient must authenticate the originator of an iCalendar object. Once that's done, they can figure out whether the originator is actually allowed to do the requested operation 💅
Compliant applications MUST support signing and encrypting text/calendar attachments with a mechanism based on Security Multiparts for MIME [RFC-1847], so the originator can be authenticated 🔥 Implementations MAY give users a way to turn signing and encrypting off 🙈 Here's how it goes:
- The iCalendar object MUST be signed by the "Organizer" sending an update or the "Attendee" sending a reply 🖊️
- Using the [RFC-1847]-compliant security mechanism, work out who signed the iCalendar object. That's the "signer" 🔍 Heads up that the signer isn't always the person who sent the email, because emails can get forwarded 📨
- Match the signer to an
ATTENDEEproperty in the iCalendar object. If you can't match them, ignore the message 🚫 - Check whether that
ATTENDEEis authorized to do the operation defined by [iTIP]. If the conditions aren't met, ignore the message 🙅♀️ - If all of the above checks out, the message can be processed ✨
For the confidentiality threats, signed iMIP messages SHOULD be encrypted with a mechanism based on Security Multiparts for MIME [RFC-1847] 🔒
Now the plot twist 😱 It's possible to get iMIP messages sent by someone acting on behalf of another "Calendar User". You can tell by checking the sent-by parameter on the relevant ORGANIZER or ATTENDEE property. [iCAL] and [iTIP] don't give any way to verify that a "Calendar User" actually authorized someone else to act for them 💀 So to fix this security hole, implementations MUST provide mechanisms that let "Calendar Users" make that decision before applying changes from someone acting on their behalf 👑
4 Examples 🧚
4.1 Single Component With An ATTACH Property 📎
This minimal message shows how an iCalendar object points to an attachment ✨ The attachment is reachable through its URL 🔗
From: sman@netscape.com
To: stevesil@microsoft.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:sman@netscape.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Please review the attached document.
UID:calsvr.example.com-873970198738777
ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR4.2 Using Multipart Alternative for Low Fidelity Clients 🌈
This example is about a client sending a multipart message that has both a plain text version AND the full iCalendar object 🫶 Clients that don't support text/calendar can still show the plain text part, which is so thoughtful 🥹
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360"
--01BD3665.3AF0D360
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit
This is an alternative representation of a TEXT/CALENDAR MIME Object
When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
Where:
Organizer: foo1@example.com
Summary: Phone Conference
--01BD3665.3AF0D360
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T170000Z
DTEND:19970701T173000Z
SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
--01BD3665.3AF0D3604.3 Single Component With An ATTACH Property and Inline Attachment 🍓
This one shows an iCalendar object that refers to an attached document 📄 The reference uses a Content-id (CID), so the iCalendar object and the document get packed together in a multipart/related encapsulation 🎀
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1";
type=text/calendar
--boundary-example-1
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T180000Z
DTEND:19970701T183000Z
SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771
ATTACH:cid:123456789@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
--boundary-example-1
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <123456789@example.com>
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
--boundary-example-1--4.4 Multiple Similar Components 💅
You can put several iCalendar components of the same type in one iCalendar object, as long as the METHOD is the same for each one 🌸
From: foo1@example.com
To: foo2@example.com
Subject: Summer Company Holidays
Mime-Version: 1.0
Content-Type:text/calendar; method=PUBLISH; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DESKTOPCALENDAR//EN
METHOD:PUBLISH
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:MAILTO:FOO1@EXAMPLE.COM
DTSTAMP:19970611T150000Z
DTSTART:19970701T150000Z
DTEND:19970701T230000Z
SUMMARY:Company Picnic
DESCRIPTION:Food and drink will be provided
UID:CALSVR.EXAMPLE.COM-873970198738777-1
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
ORGANIZER:MAILTO:FOO1@EXAMPLE.COM
DTSTAMP:19970611T190000Z
DTSTART:19970715T150000Z
DTEND:19970715T230000Z
SUMMARY:Company Bowling Tournament
DESCRIPTION:We have 10 lanes reserved
UID:CALSVR.EXAMPLE.COM-873970198738777-2
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR4.5 Multiple Mixed Components 👑
Different component types have to go into separate iCalendar objects 🧩
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C"
This is a multi-part message in MIME format.
----FEE3790DC7E35189CA67CE2C
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event1.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Discuss what happened at the last meeting
UID:calsvr.example.com-8739701987387772
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
----FEE3790DC7E35189CA67CE2C
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding:7bit
Content-Disposition: attachment; filename="todo1.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VTODO
DUE:19970701T090000-0700
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES:mailto:foo2@example.com
SUMMARY:Phone Conference
DESCRIPTION:Discuss a new location for the company picnic
UID:calsvr.example.com-td-8739701987387773
SEQUENCE:0
STATUS:NEEDS ACTION
END:VEVENT
END:VCALENDAR
----FEE3790DC7E35189CA67CE2C4.6 Detailed Components With An ATTACH Property 🎀
okay so this example is a group meeting for three people, and it's giving a full multipart/related moment 💅 The iCalendar object has an ATTACH property that points to the attachment with a CID, so the whole message gets wrapped in multipart/related. bestie this is the one that actually shows how all the parts connect 🦋
From: foo1@example.com
MIME-Version: 1.0
To: foo2@example.com,foo3@example.com
Subject: REQUEST - Phone Conference
Content-Type:multipart/related;boundary="--FEE3790DC7E35189CA67CE2C"
----FEE3790DC7E35189CA67CE2C
Content-Type: multipart/alternative;
boundary="--00FEE3790DC7E35189CA67CE2C00"
----00FEE3790DC7E35189CA67CE2C00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT
Where:
Organizer: foo1@example.com
Summary: Let's discuss the attached document
----00FEE3790DC7E35189CA67CE2C00
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII;
Component=vevent
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970621T170000Z
DTEND:199706211T173000Z
SUMMARY:Let's discuss the attached document
UID:calsvr.example.com-873970198738777-8aa
ATTACH:cid:calsvr.example.com-12345aaa
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
----00FEE3790DC7E35189CA67CE2C00
----FEE3790DC7E35189CA67CE2C
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <calsvr.example.com-12345aaa>
R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94XqAG
4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH
5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J.
----FEE3790DC7E35189CA67CE2C5 Recommended Practices 🌸
okay this section is basically a list of recommended practices for when you're sending iCalendar objects through a messaging transport 📬 it's giving good habits energy
5.1 Use of Content and Message IDs 🔗
so the [iCAL] spec uses URIs for data types a lot, in properties like "DESCRIPTION", "ATTACH", "CONTACT" and more ✨ two of those forms are Message ID (MID) and Content ID (CID), and both are defined in [RFC-2111]. here's the tea: [RFC-2111] lets you point at messages or MIME body parts sitting in other MIME entities or stores, but it is strongly recommended that iMIP implementations include all referenced messages and body parts in a single MIME entity 🫶 basically, if an iCalendar object has CID or MID references to other messages or body parts, implementations should make sure those get sent along with the iCalendar object. if they don't, there's no guarantee the receiving "CU" will have the access or the authorization to view them 😭
6 Bibliography 📚
[CHST] Character Sets, ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets
[iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification - iCalendar", RFC
2445, November 1998.
[iTIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
"iCalendar Transport-Independent Interoperability Protocol
(iTIP): Scheduling Events, Busy Time, To-dos and Journal
Entries", RFC 2446, November 1998.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part Two: Media Types", RFC 2046,
November 1996.
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) - Part Four: Registration
Procedures", RFC 2048, January 1997.
[RFC-2111] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2111, March 1997.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.7 Authors' Addresses 💌
these are the authors' contact details, all stored as vCard v3.0 (electronic business cards) 💼
BEGIN:VCARD
VERSION:3.0
N:Dawson;Frank
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford
Drive;Raleigh;NC;27613-3502;USA
TEL;TYPE=WORK,MSG:+1-919-676-9515
TEL;TYPE=WORK,FAX:+1-919-676-9564
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Mansour;Steve
FN:Steve Mansour
ORG:Netscape Communications Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain
View;CA;94043;USA
TEL;TYPE=WORK,MSG:+1-650-937-2378
TEL;TYPE=WORK,FAX:+1-650-937-2103
EMAIL;TYPE=INTERNET:sman@netscape.com
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Silverberg;Steve
FN:Steve Silverberg
ORG:Microsoft Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;TYPE=WORK,MSG:+1-425-936-9277
TEL;TYPE=WORK,FAX:+1-425-936-8019
EMAIL;TYPE=INTERNET:stevesil@Microsoft.com
END:VCARDthe iCalendar Object came out of the work of the Internet Engineering Task Force Calendaring and scheduling Working Group 🎉 the chairs of that group are:
BEGIN:VCARD
VERSION:3.0
N:Ganguly;Anik
FN:Anik Ganguly
ORG:Open Text Inc.
ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
Livonia;MI;48152;USA
TEL;TYPE=WORK,MSG:+1-734-542-5955
EMAIL;TYPE=INTERNET:ganguly@acm.org
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Moskowitz;Robert
FN:Robert Moskowitz
EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
END:VCARD8. Full Copyright Statement ⚖️
the legal bit, so read it carefully, bestie 🙈 here's the official copyright text, kept word for word:
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.📦 where this page comes from
- ietf: rfc2447 1998-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms