idnits 2.17.1 draft-ietf-calsch-imip-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([ICMS], [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048], [RFC-2049], [RFC-822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 88: '...5 RECOMMENDED PRACTICES..................' RFC 2119 keyword, line 218: '...ntations of iMIP SHOULD verify the aut...' RFC 2119 keyword, line 247: '...iCalendar object MUST be a fully qualified, [RFC-822] address...' RFC 2119 keyword, line 258: '...relevant address MUST be ascertained b...' RFC 2119 keyword, line 265: '...document MUST have an [RFC-2045] "Content-Type" value of...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 11, 1998) is 9480 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC-822' on line 720 looks like a reference -- Missing reference section? 'RFC-2045' on line 727 looks like a reference -- Missing reference section? 'RFC-2047' on line 734 looks like a reference -- Missing reference section? 'RFC-2048' on line 738 looks like a reference -- Missing reference section? 'RFC-2049' on line 35 looks like a reference -- Missing reference section? 'RFC-2046' on line 731 looks like a reference -- Missing reference section? 'ICMS' on line 713 looks like a reference -- Missing reference section? 'RFC-2119' on line 137 looks like a reference -- Missing reference section? 'RFC-1847' on line 723 looks like a reference -- Missing reference section? 'RFC-2111' on line 742 looks like a reference -- Missing reference section? 'CHST' on line 706 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Frank Dawson/Lotus 3 Internet Draft Steve Mansour/Netscape 4 Steve Silverberg/Microsoft 5 Expires six months after May 11, 1998 7 iCalendar Message-Based Interoperability Protocol 8 (iMIP) 10 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months. 17 Internet-Drafts may be updated, replaced, or made obsolete by other 18 documents at any time. It is not appropriate to use Internet-Drafts as 19 reference material or to cite them other than as a "working draft" or 20 "work in progress". 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Distribution of this document is unlimited. 31 Abstract 32 This document, [iMIP], specifies a binding from the iCalendar Transport- 33 independent Interoperability Protocol (iTIP) to Internet email-based 34 transports. Calendaring entries defined by the iCalendar Object Model 35 [iCAL] are composed using constructs from [RFC-822], [RFC-2045], [RFC- 36 2046], [RFC-2047], [RFC-2048] and [RFC-2049]. 38 This document is based on the calendaring and scheduling model defined 39 by [ICMS]. 41 This document is based on discussions within the Internet Engineering 42 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 43 More information about the IETF CALSCH working group activities can be 44 found on the IMC web site at http://www.imc.org, the IETF web site at 45 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the 46 references within this document for further information on how to access 47 these various documents. 49 Distribution of this document is unlimited. Comments and suggestions for 50 improvement should be sent to the authors. 52 Copyright (C) The Internet Society 1998. All Rights Reserved. 54 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 55 May 11, 1998 57 Table of Contents 59 1 INTRODUCTION.........................................................3 61 1.1 RELATED MEMOS ....................................................3 62 1.2 FORMATTING CONVENTIONS ...........................................3 63 1.3 TERMINOLOGY ......................................................4 65 2 MIME MESSAGE FORMAT BINDING..........................................4 67 2.1 MIME MEDIA TYPE ..................................................4 68 2.2 SECURITY .........................................................4 69 2.2.1 Authorization ................................................5 70 2.2.2 Authentication ...............................................5 71 2.2.3 Confidentiality ..............................................5 72 2.3 [RFC-822] ADDRESSES ..............................................5 73 2.4 CONTENT TYPE .....................................................6 74 2.5 CONTENT-TRANSFER-ENCODING ........................................7 75 2.6 CONTENT-DISPOSITION ..............................................7 77 3 SECURITY CONSIDERATIONS..............................................7 79 4 EXAMPLES.............................................................8 81 4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY .........................8 82 4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS .............8 83 4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ...9 84 4.4 MULTIPLE SIMILAR COMPONENTS .....................................10 85 4.5 MULTIPLE MIXED COMPONENTS .......................................11 86 4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY .....................12 88 5 RECOMMENDED PRACTICES...............................................14 90 5.1 USE OF CONTENT AND MESSAGE IDS ..................................14 92 6 BIBLIOGRAPHY........................................................14 94 7 AUTHORS ADDRESSES...................................................15 96 8 FULL COPYRIGHT STATEMENT............................................16 97 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 98 May 11, 1998 100 1 Introduction 102 This binding document provides the transport specific information 103 necessary convey iCalendar Transport-independent Interoperability 104 Protocol (iTIP) over MIME as defined in [RFC-822] and [RFC-2045]. 106 1.1 Related Memos 108 Implementers will need to be familiar with several other memos that, 109 along with this memo, form a framework for Internet calendaring and 110 scheduling standards. 112 This document, [iMIP], specifies an Internet email binding for iTIP. 114 [ICMS] - specifies a common terminology and abstract; 116 [iCAL] - specifies a core specification of objects, data types, 117 properties and property parameters; 119 [iTIP] - specifies an interoperability protocol for scheduling between 120 different implementations; 122 This memo does not attempt to repeat the specification of concepts or 123 definitions from these other memos. Where possible, references are made 124 to the memo that provides for the specification of these concepts or 125 definitions. 127 1.2 Formatting Conventions 129 The mechanisms defined in this memo are defined in prose. In order to 130 refer to elements of the calendaring and scheduling model, core object 131 or interoperability protocol defined in [ICMS], [iCAL] and [iTIP] some 132 formatting conventions have been used. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC-2119]. 138 Calendaring and scheduling roles described by [ICMS] are referred to in 139 quoted-strings of text with the first character of each word in upper 140 case. For example, "Organizer" refers to a role of a "Calendar User" 141 within the scheduling protocol defined by [iTIP]. 143 Calendar components defined by [iCAL] are referred to with capitalized, 144 quoted-strings of text. All calendar components start with the letter 145 "V". For example, "VEVENT" refers to the event calendar component, 146 "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to 147 the daily journal calendar component. 149 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 150 May 11, 1998 152 Scheduling methods defined by [iTIP] are referred to with capitalized, 153 quoted-strings of text. For example, "REQUEST" refers to the method for 154 requesting a scheduling calendar component be created or modified, 155 "REPLY" refers to the method a recipient of a request uses to update 156 their status with the "Organizer" of the calendar component. 158 Properties defined by [iCAL] are referred to with capitalized, quoted- 159 strings of text, followed by the word "property". For example, 160 "ATTENDEE" property refers to the iCalendar property used to convey the 161 calendar address of a calendar user. 163 Property parameters defined by [iCAL] are referred to with lower case, 164 quoted-strings of text, followed by the word "parameter". For example, 165 "value" parameter refers to the iCalendar property parameter used to 166 override the default data type for a property value. 168 1.3 Terminology 170 The email terms used in this memo are defined in [RFC-822] and [RFC- 171 2045]. The calendaring and scheduling terms used in this memo are 172 defined in [ICMS], [iCAL] and [iTIP]. 174 2 MIME Message Format Binding 176 This section defines the message binding to the MIME electronic mail 177 transport. 179 The sections below refer to the "originator" and the "respondent" of an 180 iMIP message. Typically, the originator is the "Organizer" of an event. 181 The respondent is an "Attendee" of the event. 183 The [RFC-822] "Reply-To" header typically contains the email address of 184 the originator or respondent of an event. However, this cannot be 185 guaranteed as Mail User Agents (MUA) are not required to enforce iMIP 186 semantics. 188 2.1 MIME Media Type 190 A MIME entity containing content information formatted according to this 191 document will be referenced as a "text/calendar" content type. It is 192 assumed that this content type will be transported through a MIME 193 electronic mail transport. 195 2.2 Security 197 This section addresses several aspects of security including 198 Authentication, Authorization and Confidentiality. Authentication and 199 confidentiality can be achieved using [RFC-1847] that specifies the 200 Security Multiparts for MIME. This framework defines new content types 201 and subtypes of multipart: signed and encrypted. Each contains two body 202 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 203 May 11, 1998 205 parts: one for the protected data and another for the control 206 information necessary to remove the protection. 208 2.2.1 Authorization 210 In [iTIP] messages, only the "Organizer" is authorized to modify or 211 cancel calendar entries they organize. That is, spoof@xyz.com is not 212 allowed to modify or cancel a meeting that was organized by 213 a@example.com. Furthermore, only the respondent has the authorization to 214 indicate their status to the "Organizer". That is, the "Organizer" must 215 ignore an [iTIP] message from spoof@xyz.com that declines a meeting 216 invitation for b@example.com. 218 Implementations of iMIP SHOULD verify the authenticity of the creator of 219 an iCalendar object before taking any action. The methods for doing this 220 are presented later in this document. 222 [RFC-1847] Message flow in iTIP supports someone working on behalf of a 223 "Calendar User" through use of the "sent-by" parameter that is 224 associated with the "ATTENDEE" and "ORGANIZER" properties. However, 225 there is no mechanism to verify whether or not a "Calendar User" has 226 authorized someone to work on their behalf. It is left to 227 implementations to provide mechanisms for the "Calendar Users" to make 228 that decision. 230 2.2.2 Authentication 232 Authentication can be performed using an implementation of [RFC-1847] 233 "multipart/signed" that supports public/private key certificates. 234 Authentication is possible only on messages that have been signed. 235 Authenticating an unsigned message may not be reliable. 237 2.2.3 Confidentiality 239 To ensure confidentiality using iMIP implementations should utilize 240 [RFC-1847]-compliant encryption. The protocol does not restrict a 241 "Calendar User Agent" (CUA) from forwarding iCalendar objects to other 242 users or agents. 244 2.3 [RFC-822] Addresses 246 The calendar address specified within the "ATTENDEE" property in an 247 iCalendar object MUST be a fully qualified, [RFC-822] address 248 specification for the corresponding "Organizer" or "Attendee" of the 249 "VEVENT" or "VTODO". 251 Because [iTIP] does not preclude "Attendees" from forwarding "VEVENTS" 252 or "VTODOS" to others, the [RFC-822] "Sender" value may not equal that 253 of the "Organizer". Additionally, the "Organizer" or "Attendee" cannot 254 be reliably inferred by the [RFC-822] "Sender" or "Reply-to" values of 255 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 256 May 11, 1998 258 an iMIP message. The relevant address MUST be ascertained by opening 259 the "text/calendar" MIME body part and examining the "ATTENDEE" and 260 "ORGANIZER" properties. 262 2.4 Content Type 264 A MIME body part containing content information that conforms to this 265 document MUST have an [RFC-2045] "Content-Type" value of 266 "text/calendar". The [RFC-2045] "Content-Type" header field must also 267 include the type parameter "method". The value MUST be the same as the 268 value of the "METHOD" calendar property within the iCalendar object. 269 This means that a MIME message containing multiple iCalendar objects 270 with different method values must be further encapsulated with a 271 "multipart/mixed" MIME entity. This will allow each of the iCalendar 272 objects to be encapsulated within their own "text/calendar" MIME entity. 274 A "charset" parameter MUST be present if the iCalendar object contains 275 characters that are not part of the US-ASCII character set. [RFC-2046] 276 discusses the selection of an appropriate "charset" value. 278 The optional "component" parameter defines the iCalendar component type 279 contained within the iCalendar object. 281 The following is an example of this header field with a value that 282 indicates an event message. 284 Content-Type:text/calendar; method=request; charset=UTF-8; 285 component=vevent 287 The "text/calendar" content type allows for the scheduling message type 288 to be included in a MIME message with other content information (i.e., 289 "multipart/mixed") or included in a MIME message with a clear-text, 290 human-readable form of the scheduling message (i.e., 291 "multipart/alternative"). 293 In order to permit the information in the scheduling message to be 294 understood by MIME user agents (UA) that do not support the 295 "text/calendar" content type, scheduling messages SHOULD be sent with an 296 alternative, human-readable form of the information. 298 2.5 Content-Transfer-Encoding 300 Note that the default character set for iCalendar objects is UTF-8. A 301 transfer encoding SHOULD be used for iCalendar objects containing any 302 characters that are not part of the US-ASCII character set. 304 2.6 Content-Disposition 306 The handling of a MIME part should be based on its [RFC-2045] "Content- 307 Type". However, this is not guaranteed to work in all environments. 309 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 310 May 11, 1998 312 Some environments handle MIME attachments based on their file type or 313 extension. To operate correctly in these environments, implementations 314 may wish to include a "Content-Disposition" property to define a file 315 name. 317 3 Security Considerations 319 The security threats that applications must address when implementing 320 iTIP are detailed in [iTIP]. Two spoofing threats are identified: 321 Spoofing the "Organizer", and Spoofing an "Attendee". To address these 322 threats, the originator of an iCalendar object must be authenticated by 323 a recipient. Once authenticated, a determination can be made as to 324 whether or not the originator is authorized to perform the requested 325 operation. Compliant applications MUST support signing and encrypting 326 text/calendar attachments using a mechanism based on Security Multiparts 327 for MIME [RFC-1847] to facilitate the authentication the originator of 328 the iCalendar object. Implementations MAY provide a means for users to 329 disable signing and encrypting. The steps are described below: 331 1. The iCalendar object MUST be signed by the "Organizer" sending an 332 update or the "Attendee" sending a reply. 334 2. Using the [RFC-1847]-compliant security mechanism, determine who 335 signed the iCalendar object. This is the "signer". Note that the signer 336 is not necessarily the person sending an e-mail message since an e-mail 337 message can be forwarded. 339 3. Correlate the signer to an "ATTENDEE" property in the iCalendar 340 object. If the signer cannot be correlated to an "ATTENDEE" property, 341 ignore the message. 343 4. Determine whether or not the "ATTENDEE" is authorized to perform the 344 operation as defined by [iTIP]. If the conditions are not met, ignore 345 the message. 347 5. If all the above conditions are met, the message can be processed. 349 To address the confidentiality security threats, signed iMIP messages 350 SHOULD be encrypted by a mechanism based on Security Multiparts for MIME 351 [RFC-1847]. 353 It is possible to receive iMIP messages sent by someone working on 354 behalf of another "Calendar User". This is determined by examining the 355 "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" property. 356 [iCAL] and [iTIP] provide no mechanism to verify that a "Calendar User" 357 has authorized someone else to work on their behalf. To address this 358 security issue, implementations MUST provide mechanisms for the 359 "Calendar Users" to make that decision before applying changes from 360 someone working on behalf of a "Calendar User". 362 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 363 May 11, 1998 365 4 Examples 367 4.1 Single Component With An ATTACH Property 369 This minimal message shows how an iCalendar object references an 370 attachment. The attachment is accessible via its URL. 372 From: sman@netscape.com 373 To: stevesil@microsoft.com 374 Subject: Phone Conference 375 Mime-Version: 1.0 376 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 377 Content-Transfer-Encoding: 7bit 379 BEGIN:VCALENDAR 380 PRODID:-//ACME/DesktopCalendar//EN 381 METHOD:REQUEST 382 VERSION:2.0 383 BEGIN:VEVENT 384 ORGANIZER:mailto:sman@netscape.com 385 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com 386 ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.com 387 DTSTAMP:19970611T190000Z 388 DTSTART:19970701T210000Z 389 DTEND:19970701T230000Z 390 SUMMARY:Phone Conference 391 DESCRIPTION:Please review the attached document. 392 UID:calsvr.example.com-873970198738777 393 ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc 394 STATUS:CONFIRMED 395 END:VEVENT 396 END:VCALENDAR 398 4.2 Using Multipart Alternative for Low Fidelity Clients 400 This example shows how a client can emit a multipart message that 401 includes both a plain text version as well as the full iCalendar object. 402 Clients that do not support text/calendar will still be capable of 403 rendering the plain text representation. 405 From: foo1@example.com 406 To: foo2@example.com 407 Subject: Phone Conference 408 Mime-Version: 1.0 409 Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360" 411 --01BD3665.3AF0D360 412 Content-Type: text/plain;charset=us-ascii 413 Content-Transfer-Encoding: 7bit 415 This is an alternative representation of a TEXT/CALENDAR MIME Object 416 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 417 May 11, 1998 419 When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT 420 Where: 421 Organizer: foo1@example.com 422 Summary: Phone Conference 424 --01BD3665.3AF0D360 425 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 426 Content-Transfer-Encoding: 7bit 428 BEGIN:VCALENDAR 429 PRODID:-//ACME/DesktopCalendar//EN 430 METHOD:REQUEST 431 VERSION:2.0 432 BEGIN:VEVENT 433 ORGANIZER:mailto:foo1@example.com 434 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 435 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 436 DTSTAMP:19970611T190000Z 437 DTSTART:19970701T170000Z 438 DTEND:19970701T173000Z 439 SUMMARY:Phone Conference 440 UID:calsvr.example.com-8739701987387771 441 SEQUENCE:0 442 STATUS:CONFIRMED 443 END:VEVENT 444 END:VCALENDAR 446 --01BD3665.3AF0D360 448 4.3 Single Component With An ATTACH Property and Inline Attachment 450 This example shows how a message containing an iCalendar object 451 references an attached document. The reference is made using a Content- 452 id (CID). Thus, the iCalendar object and the document are packaged in a 453 multipart/related encapsulation. 455 From: foo1@example.com 456 To: foo2@example.com 457 Subject: Phone Conference 458 Mime-Version: 1.0 459 Content-Type: multipart/related; boundary="boundary-example-1"; 460 type=text/calendar 462 --boundary-example-1 464 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 465 Content-Transfer-Encoding: 7bit 466 Content-Disposition: attachment; filename="event.vcs" 468 BEGIN:VCALENDAR 469 PRODID:-//ACME/DesktopCalendar//EN 470 METHOD:REQUEST 471 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 472 May 11, 1998 474 VERSION:2.0 475 BEGIN:VEVENT 476 ORGANIZER:mailto:foo1@example.com 477 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 478 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 479 DTSTAMP:19970611T190000Z 480 DTSTART:19970701T180000Z 481 DTEND:19970701T183000Z 482 SUMMARY:Phone Conference 483 UID:calsvr.example.com-8739701987387771 484 ATTACH:cid:123456789@example.com 485 SEQUENCE:0 486 STATUS:CONFIRMED 487 END:VEVENT 488 END:VCALENDAR 490 --boundary-example-1 491 Content-Type: application/msword; name="FieldReport.doc" 492 Content-Transfer-Encoding: base64 493 Content-Disposition: inline; filename="FieldReport.doc" 494 Content-ID: <123456789@example.com> 496 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 497 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// 498 ... 500 --boundary-example-1-- 502 4.4 Multiple Similar Components 504 Multiple iCalendar components of the same type can be included in the 505 iCalendar object when the METHOD is the same for each component. 507 From: foo1@example.com 508 To: foo2@example.com 509 Subject: Summer Company Holidays 510 Mime-Version: 1.0 511 Content-Type:text/calendar; method=PUBLISH; charset=US-ASCII 512 Content-Transfer-Encoding: 7bit 513 Content-Disposition: attachment; filename="event.vcs" 515 BEGIN:VCALENDAR 516 PRODID:-//ACME/DESKTOPCALENDAR//EN 517 METHOD:PUBLISH 518 VERSION:2.0 519 BEGIN:VEVENT 520 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 521 DTSTAMP:19970611T150000Z 522 DTSTART:19970701T150000Z 523 DTEND:19970701T230000Z 524 SUMMARY:Company Picnic 525 DESCRIPTION:Food and drink will be provided 526 UID:CALSVR.EXAMPLE.COM-873970198738777-1 527 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 528 May 11, 1998 530 SEQUENCE:0 531 STATUS:CONFIRMED 532 END:VEVENT 533 BEGIN:VEVENT 534 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 535 DTSTAMP:19970611T190000Z 536 DTSTART:19970715T150000Z 537 DTEND:19970715T230000Z 538 SUMMARY:Company Bowling Tournament 539 DESCRIPTION:We have 10 lanes reserved 540 UID:CALSVR.EXAMPLE.COM-873970198738777-2 541 SEQUENCE:0 542 STATUS:CONFIRMED 543 END:VEVENT 544 END:VCALENDAR 546 4.5 Multiple Mixed Components 548 Different component types must be encapsulated in separate iCalendar 549 objects. 551 From: foo1@example.com 552 To: foo2@example.com 553 Subject: Phone Conference 554 Mime-Version: 1.0 555 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 557 This is a multi-part message in MIME format. 559 ----FEE3790DC7E35189CA67CE2C 560 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 561 Content-Transfer-Encoding: 7bit 562 Content-Disposition: attachment; filename="event1.vcs" 564 BEGIN:VCALENDAR 565 PRODID:-//ACME/DesktopCalendar//EN 566 METHOD:REQUEST 567 VERSION:2.0 568 BEGIN:VEVENT 569 ORGANIZER:mailto:foo1@example.com 570 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 571 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 572 DTSTAMP:19970611T190000Z 573 DTSTART:19970701T210000Z 574 DTEND:19970701T230000Z 575 SUMMARY:Phone Conference 576 DESCRIPTION:Discuss what happened at the last meeting 577 UID:calsvr.example.com-8739701987387772 578 SEQUENCE:0 579 STATUS:CONFIRMED 580 END:VEVENT 581 END:VCALENDAR 582 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 583 May 11, 1998 585 ----FEE3790DC7E35189CA67CE2C 586 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 587 Content-Transfer-Encoding:7bit 588 Content-Disposition: attachment; filename="todo1.vcs" 590 BEGIN:VCALENDAR 591 PRODID:-//ACME/DesktopCalendar//EN 592 METHOD:REQUEST 593 VERSION:2.0 594 BEGIN:VTODO 595 DUE:19970701T090000-0700 596 ORGANIZER:mailto:foo1@example.com 597 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 598 ATTENDEE;RSVP=YES:mailto:foo2@example.com 599 SUMMARY:Phone Conference 600 DESCRIPTION:Discuss a new location for the company picnic 601 UID:calsvr.example.com-td-8739701987387773 602 SEQUENCE:0 603 STATUS:NEEDS ACTION 604 END:VEVENT 605 END:VCALENDAR 607 ----FEE3790DC7E35189CA67CE2C 609 4.6 Detailed Components With An ATTACH Property 611 This example shows the format of a message containing a group meeting 612 between three individuals. The multipart/related encapsulation is used 613 because the iCalendar object contains an ATTACH property that uses a CID 614 to reference the attachment. 616 From: foo1@example.com 617 MIME-Version: 1.0 618 To: foo2@example.com,foo3@example.com 619 Subject: REQUEST - Phone Conference 620 Content-Type:multipart/related;boundary="--FEE3790DC7E35189CA67CE2C" 622 ----FEE3790DC7E35189CA67CE2C 623 Content-Type: multipart/alternative; 624 boundary="--00FEE3790DC7E35189CA67CE2C00" 626 ----00FEE3790DC7E35189CA67CE2C00 627 Content-Type: text/plain; charset=us-ascii 628 Content-Transfer-Encoding: 7bit 630 When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT 631 Where: 632 Organizer: foo1@example.com 633 Summary: Let's discuss the attached document 635 ----00FEE3790DC7E35189CA67CE2C00 637 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII; 638 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 639 May 11, 1998 641 Component=vevent 642 Content-Transfer-Encoding: 7bit 643 Content-Disposition: attachment; filename="event.vcs" 645 BEGIN:VCALENDAR 646 PRODID:-//ACME/DesktopCalendar//EN 647 PROFILE:REQUEST 648 PROFILE-VERSION:1.0 649 VERSION:2.0 650 BEGIN:VEVENT 651 ORGANIZER:foo1@example.com 652 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com 653 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 654 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com 655 DTSTAMP:19970611T190000Z 656 DTSTART:19970621T170000Z 657 DTEND:199706211T173000Z 658 SUMMARY:Let's discuss the attached document 659 UID:calsvr.example.com-873970198738777-8aa 660 ATTACH:cid:calsvr.example.com-12345aaa 661 SEQUENCE:0 662 STATUS:CONFIRMED 663 END:VEVENT 664 END:VCALENDAR 666 ----00FEE3790DC7E35189CA67CE2C00 668 ----FEE3790DC7E35189CA67CE2C 669 Content-Type: application/msword; name="FieldReport.doc" 670 Content-Transfer-Encoding: base64 671 Content-Disposition: inline; filename="FieldReport.doc" 672 Content-ID: 674 R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94XqAG 675 4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH 676 5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J. 677 .. 679 ----FEE3790DC7E35189CA67CE2C 681 5 Recommended Practices 683 This section outlines a series of recommended practices when using a 684 messaging transport to exchange iCalendar objects. 686 5.1 Use of Content and Message IDs 688 The [iCAL] specification makes frequent use of the URI for data types in 689 properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. Two 690 forms of URIs are Message ID (MID) and Content ID (CID). These are 691 defined in [RFC-2111]. Although [RFC-2111] allows referencing messages 692 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 693 May 11, 1998 695 or MIME body parts in other MIME entities or stores, it is strongly 696 recommended that iMIP implementations include all referenced messages 697 and body parts in a single MIME entity. Simply put, if an iCalendar 698 object contains CID or MID references to other messages or body parts, 699 implementations should ensure that these messages and/or body parts are 700 transmitted with the iCalendar object. If they are not there is no 701 guarantee that the receiving "CU" will have the access or the 702 authorization to view those objects. 704 6 Bibliography 706 [CHST] Character Sets, ftp://ftp.isi.edu/in- 707 notes/iana/assignments/character-sets 709 [iCAL] "Internet Calendaring and Scheduling Core Object Specification - 710 iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- 711 drafts/draft-ietf-calsch-ical-07.txt. 713 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 714 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-03.txt. 716 [iTIP] "iCalendar Transport-Independent Interoperability Protocol (iTIP) 717 : Scheduling Events, Busy Time, To-dos and Journal Entries ", Internet- 718 Draft, October 1997, http://www.imc.org/draft-ietf-calsch-itip-04.txt. 720 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 721 Messages", STD 11, RFC-822, August 1982. 723 [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security 724 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC- 725 1847, October 1995. 727 [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 728 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC- 729 2045, November 1996. 731 [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 732 Extensions (MIME) - Part Two: Media Types", RFC-2046, November 1996. 734 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 735 Part Three: Message Header Extensions for Non-ASCII Text", RFC-2047, 736 November 1996. 738 [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet Mail 739 Extensions (MIME) - Part Four: Registration Procedures", RFC-2048, 740 January 1997. 742 [RFC-2111] E. Levinson, "Content-ID and Message-ID Uniform Resource 743 Locators", RFC-2111, March 1997. 745 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 746 May 11, 1998 748 7 Authors Addresses 750 The following address information is provided in a vCard v2.1, 751 Electronic Business Card, format. 753 BEGIN:VCARD 754 FN:Frank Dawson 755 ORG:Lotus Development Corporation 756 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford 757 Drive;Raleigh;NC;27613-3502;USA 758 TEL;WORK;MSG:+1-919-676-9515 759 TEL;WORK;FAX:+1-919-676-9564 760 EMAIL;INTERNET:fdawson@earthlink.net 761 URL:http://home.earthlink.net/~fdawson 762 END:VCARD 764 BEGIN:VCARD 765 FN:Steve Mansour 766 ORG:Netscape Communications Corporation 767 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 768 View;CA;94043;USA 769 TEL;WORK;MSG:+1-650-937-2378 770 TEL;WORK;FAX:+1-650-937-2103 771 EMAIL;INTERNET:sman@netscape.com 772 END:VCARD 774 BEGIN:VCARD 775 FN:Steve Silverberg 776 ORG:Microsoft Corporation 777 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 778 Redmond;WA;98052-6399;USA 779 TEL;WORK;MSG:+1-425-936-9277 780 TEL;WORK;FAX:+1-425-936-8019 781 EMAIL;INTERNET:stevesil@Microsoft.com 782 END:VCARD 784 The iCalendar Object is a result of the work of the Internet Engineering 785 Task Force Calendaring and scheduling Working Group. The chairman of 786 that working group is: 788 BEGIN:VCARD 789 FN:Anik Ganguly 790 ORG:OnTime, Inc. 791 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 792 Highway;Southfield;MI;48075;USA 793 TEL;WORK;MSG:+1-810-559-5955 794 TEL;WORK;FAX:+1-810-559-5034 795 EMAIL;INTERNET:anik@ontime.com 796 END:VCARD 797 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 798 May 11, 1998 800 8 Full Copyright Statement 802 "Copyright (C) The Internet Society (date). All Rights Reserved. 804 This document and translations of it may be copied and furnished to 805 others, and derivative works that comment on or otherwise explain it or 806 assist in its implementation may be prepared, copied, published and 807 distributed, in whole or in part, without restriction of any kind, 808 provided that the above copyright notice and this paragraph are included 809 on all such copies and derivative works. However, this document itself 810 may not be modified in any way, such as by removing the copyright notice 811 or references to the Internet Society or other Internet organizations, 812 except as needed for the purpose of developing Internet standards in 813 which case the procedures for copyrights defined in the Internet 814 Standards process must be followed, or as required to translate it into 815 languages other than English. 817 The limited permissions granted above are perpetual and will not be 818 revoked by the Internet Society or its successors or assigns. 820 This document and the information contained herein is provided on an "AS 821 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 822 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 823 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 824 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 825 FITNESS FOR A PARTICULAR PURPOSE.