idnits 2.17.1 draft-ietf-calsch-imip-04.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 15 longer pages, the longest (page 2) being 62 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 ([ICAL], [ICMS], [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048], [RFC-2049], [RFC-822], [ITIP]), 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 213: '... implementations SHOULD verify the aut...' RFC 2119 keyword, line 239: '...iCalendar object MUST be a fully quali...' RFC 2119 keyword, line 247: '...relevant address MUST be ascertained b...' RFC 2119 keyword, line 254: '...document MUST have a Content-Type valu...' RFC 2119 keyword, line 256: '...value MUST be the same as the value of...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 13, 1998) is 9541 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? 'ITIP' on line 687 looks like a reference -- Missing reference section? 'ICAL' on line 680 looks like a reference -- Missing reference section? 'RFC-822' on line 691 looks like a reference -- Missing reference section? 'RFC-2045' on line 701 looks like a reference -- Missing reference section? 'RFC-2047' on line 708 looks like a reference -- Missing reference section? 'RFC-2048' on line 712 looks like a reference -- Missing reference section? 'RFC-2049' on line 32 looks like a reference -- Missing reference section? 'RFC-2046' on line 705 looks like a reference -- Missing reference section? 'ICMS' on line 684 looks like a reference -- Missing reference section? 'IRIP' on line 116 looks like a reference -- Missing reference section? 'RFC 2119' on line 133 looks like a reference -- Missing reference section? 'RFC-1847' on line 694 looks like a reference -- Missing reference section? 'RFC1847' on line 340 looks like a reference -- Missing reference section? 'CHST' on line 677 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Frank Dawson/Lotus 2 Internet Draft Steve Mansour/Netscape 3 Steve Silverberg/Microsoft 4 Expires six months after March 13, 1998 6 iCalendar Message-Based Interoperability Protocol 7 (iMIP) 9 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months. 16 Internet-Drafts may be updated, replaced, or made obsolete by other 17 documents at any time. It is not appropriate to use Internet-Drafts as 18 reference material or to cite them other than as a "working draft" or 19 "work in progress". 21 To learn the current status of any Internet-Draft, please check the 1id- 22 abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 Distribution of this document is unlimited. 28 Abstract 29 This document specifies a binding from the iCalendar Transport- 30 independent Interoperability Protocol [ITIP] to Internet email-based 31 transports. Calendaring entries defined by the iCalendar Object Model 32 [ICAL] are composed using constructs from [RFC-822], [RFC-2045], [RFC- 33 2046], [RFC-2047], [RFC-2048] and [RFC-2049]. 35 This document is based on the calendaring and scheduling model defined 36 by [ICMS]. 38 This document is based on discussions within the Internet Engineering 39 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 40 More information about the IETF CALSCH working group activities can be 41 found on the IMC web site at http://www.imc.org, the IETF web site at 42 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the 43 references within this document for further information on how to access 44 these various documents. 46 Distribution of this document is unlimited. Comments and suggestions for 47 improvement should be sent to the authors. 49 Copyright (C) The Internet Society 1998. All Rights Reserved. 51 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 52 March 13, 1998 54 Table of Contents 56 1 INTRODUCTION.........................................................2 58 1.1 RELATED MEMOS ....................................................3 59 1.2 FORMATTING CONVENTIONS ...........................................3 60 1.3 TERMINOLOGY ......................................................4 62 2 MIME MESSAGE FORMAT BINDING..........................................4 64 2.1 MIME MEDIA TYPE ..................................................4 65 2.2 SECURITY .........................................................4 66 2.2.1 Authorization ................................................4 67 2.2.2 Authentication ...............................................5 68 2.2.3 Confidentiality ..............................................5 69 2.3 RFC-822 ADDRESSES ................................................5 70 2.4 CONTENT TYPE .....................................................6 71 2.5 CONTENT-TRANSFER-ENCODING ........................................6 72 2.6 CONTENT-DISPOSITION ..............................................6 74 3 SECURITY CONSIDERATIONS..............................................7 76 4 EXAMPLES.............................................................8 78 4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY .........................8 79 4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS .............8 80 4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ...9 81 4.4 MULTIPLE SIMILAR COMPONENTS .....................................10 82 4.5 MULTIPLE MIXED COMPONENTS .......................................11 83 4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY .....................12 85 5 BIBLIOGRAPHY........................................................13 87 6 AUTHOR'S ADDRESS....................................................14 89 7 FULL COPYRIGHT STATEMENT............................................15 91 1 Introduction 93 This binding document provides the transport specific information 94 necessary convey iCalendar Transport-independent Interoperability 95 Protocol [ITIP] over MIME as defined in [RFC-822] and [RFC-2045]. 97 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 98 March 13, 1998 100 1.1 Related Memos 102 Implementers will need to be familiar with several other memos that, 103 along with this memo, form a framework for Internet calendaring and 104 scheduling standards. 106 This document - specifies an Internet email binding for [ITIP]. 108 [ICMS] - specifies a common terminology and abstract; 110 [ICAL] - specifies a core specification of objects, data types, 111 properties and property parameters; 113 [ITIP] - specifies an interoperability protocol for scheduling between 114 different implementations; 116 [IRIP] - specifies an Internet real time protocol binding for [ITIP]. 118 This memo does not attempt to repeat the specification of concepts or 119 definitions from these other memos. Where possible, references are made 120 to the memo that provides for the specification of these concepts or 121 definitions. 123 1.2 Formatting Conventions 125 The mechanisms defined in this memo are defined in prose. In order to 126 refer to elements of the calendaring and scheduling model, core object 127 or interoperability protocol defined in [ICMS], [ICAL] and [ITIP] some 128 formatting conventions have been used. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC 2119]. 134 Calendaring and scheduling roles described by [ICMS] are referred to in 135 quoted-strings of text with the first character of each word in upper 136 case. For example, "Organizer" refers to a role of a "Calendar User" 137 within the scheduling protocol defined by [ITIP]. 139 Calendar components defined by [ICAL] are referred to with capitalized, 140 quoted-strings of text. All calendar components start with the letter 141 "V". For example, "VEVENT" refers to the event calendar component, 142 "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to 143 the daily journal calendar component. 145 Scheduling methods defined by [ITIP] are referred to with capitalized, 146 quoted-strings of text. For example, "REQUEST" refers to the method for 147 requesting a scheduling calendar component be created or modified, 148 "REPLY" refers to the method a recipient of a request uses to update 149 their status with the "Organizer" of the calendar component. 151 Properties defined by [ICAL] are referred to with capitalized, quoted- 152 strings of text, followed by the word "property". For example, 153 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 154 March 13, 1998 156 "ATTENDEE" property refers to the iCalendar property used to convey the 157 calendar address of a calendar user. 159 Property parameters defined by [ICAL] are referred to with lower case, 160 quoted-strings of text, followed by the word "parameter". For example, 161 "value" parameter refers to the iCalendar property parameter used to 162 override the default data type for a property value. 164 1.3 Terminology 166 The email terms used in this memo are defined in [RFC-822] and [RFC- 167 2045]. The calendaring and scheduling terms used in this memo are 168 defined in [ICMS], [ICAL] and [ITIP]. 170 2 MIME Message Format Binding 172 This section defines the message binding to the MIME electronic mail 173 transport. 175 The sections below refer to the "originator" and the "respondent" of an 176 iMIP message. Typically, the originator is the "Organizer" of an event. 177 The respondent is an "Attendee" of the event. 179 The Reply-To header typically contains the email address of the 180 originator or respondent of an event. However, this cannot be guaranteed 181 as Mail User Agents (MUA) are not required to enforce iMIP semantics. 183 2.1 MIME Media Type 185 A MIME entity containing content information formatted according to this 186 document will be referenced as a "text/calendar" content type. It is 187 assumed that this content type will be transported through a MIME 188 electronic mail transport. 190 2.2 Security 192 This section addresses several aspects of security including 193 Authentication, Authorization and Confidentiality. Authentication and 194 confidentiality can be achieved using [RFC-1847] that specifies the 195 Security Multiparts for MIME. This framework defines new content types 196 and subtypes of multipart: signed and encrypted. Each contains two body 197 parts: one for the protected data and another for the control 198 information necessary to remove the protection. 200 2.2.1 Authorization 202 In [ITIP] messages, only the "Organizer" is authorized to modify or 203 cancel calendar entries they organize. That is, spoof@xyz.com is not 204 allowed to modify or cancel a meeting that was organized by 205 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 206 March 13, 1998 208 a@example.com. Furthermore, only the respondent has the authorization to 209 indicate their status to the "Organizer". That is, the "Organizer" must 210 ignore an [ITIP] message from spoof@xyz.com that declines a meeting 211 invitation for b@example.com. 213 IMIP implementations SHOULD verify the authenticity of the sender of an 214 iCalendar object before taking any action. 216 ITIP message flow supports someone working on behalf of a "Calendar 217 User" through use of the "sent-by" parameter which is associated with 218 the "ATTENDEE" and "ORGANIZER" properties. However, there is no 219 mechanism to verify whether or not a "Calendar User" has authorized 220 someone to work on their behalf. It is left to implementations to 221 provide mechanisms for the "Calendar Users" to make that decision. 223 2.2.2 Authentication 225 Authentication can be performed using an implementation of [RFC-1847] 226 Multipart/signed that supports public/private key certificates. 227 Authentication is possible only on messages that have been signed. 228 Authenticating an unsigned message may not be reliable. 230 2.2.3 Confidentiality 232 To ensure confidentiality using iMIP implementations should utilize 233 [RFC-1847] compliant encryption. The protocol does not restrict a CUA 234 from forwarding Requests or Responses to other users or agents. 236 2.3 RFC-822 Addresses 238 The calendar address specified within the "ATTENDEE" property in an 239 iCalendar object MUST be a fully qualified, RFC-822 address 240 specification for the corresponding "Organizer" or "Attendee" of the 241 "VEVENT" or "VTODO". 243 Because [ITIP] does not preclude "Attendees" from forwarding "VEVENTS" 244 or "VTODOS" to others, the [RFC-822] "Sender" value may not equal that 245 of the "Organizer". Additionally, the "Organizer" or "Attendee" cannot 246 be reliably inferred by the [RFC-822] "Sender" or "Reply-to" values of 247 an IMIP message. The relevant address MUST be ascertained by opening 248 the "text/calendar" MIME body part and examining the "ATTENDEE" and 249 "ORGANIZER" properties. 251 2.4 Content Type 253 A MIME body part containing content information that conforms to this 254 document MUST have a Content-Type value of "text/calendar". The content 255 type header field must also include the type parameter "method". The 256 value MUST be the same as the value of the "METHOD" calendar property 257 within the iCalendar object. This means that a MIME message containing 258 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 259 March 13, 1998 261 multiple iCalendar objects with different method values must be further 262 encapsulated with a "multipart/mixed" MIME entity. This will allow each 263 of the iCalendar objects to be encapsulated within their own 264 "text/calendar" MIME entity. 266 A CHARSET parameter MUST be present when the "text/calendar" is used. 267 [RFC-2046] discusses the selection of an appropriate CHARSET value. 269 The optional Content-Type COMPONENT parameter defines the iCalendar 270 component type contained within the iCalendar object. 272 The following is an example of this header field with a value that 273 indicates an event message. 275 Content-Type:text/calendar; method=request; charset=UTF-8; 276 component=vevent 278 The "text/calendar" content type allows for the scheduling message type 279 to be included in a MIME message with other content information (i.e., 280 multipart/mixed) or included in a MIME message with a clear-text, human- 281 readable form of the scheduling message (i.e., multipart/alternative). 283 In order to permit the information in the scheduling message to be 284 understood by MIME user agents (UA) that do not support the 285 text/calendar content type, scheduling messages SHOULD be sent with an 286 alternative, human-readable form of the information. 288 2.5 Content-Transfer-Encoding 290 Note that the default character set for iCalendar objects is UTF-8. A 291 transfer encoding SHOULD be used for iCalendar objects containing any 292 characters that are not part of the US-ASCII character set. 294 2.6 Content-Disposition 296 The handling of a MIME part should be based on its "Content-Type". 297 However, this is not guaranteed to work in all environments. Some 298 environments handle MIME attachments based on their file type or 299 extension. To operate correctly in these environments, implementations 300 may wish to include a "Content-Disposition" property to define a file 301 name. 303 3 Security Considerations 305 [ITIP] details the security threats that applications must address when 306 implementing ITIP. Two spoofing threats are identified: Spoofing the 307 "Organizer", and Spoofing an "Attendee". To address these threats, the 308 originator of an iCalendar object must be authenticated by a recipient. 309 Once authenticated, a determination can be made as to whether or not the 310 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 311 March 13, 1998 313 originator is authorized to perform the requested operation. Compliant 314 applications MUST support signing and encrypting text/calendar 315 attachments using a mechanism based on Security Multiparts for MIME 316 [RFC1847] to facilitate the authentication the originator of the 317 iCalendar object. Implementations MAY provide a means for users to 318 disable signing and encrypting. The steps are described below: 320 1. The iCalendar object must be signed by the "Organizer" sending an 321 update or the "Attendee" sending a reply. 323 2. Using the RFC1847-compliant security mechanism, determine who signed 324 the iCalendar object. This is the "signer". Note that the signer is not 325 necessarily the person sending an e-mail message. An e-mail message can 326 be forwarded. 328 3. Correlate the "signer" to an "ATTENDEE" property in the iCalendar 329 object. If the signer cannot be correlated to an "ATTENDEE" property, 330 ignore the message. 332 4. Determine whether or not the "ATTENDEE" is authorized to perform the 333 operation as defined by [ITIP]. If the conditions are not met, ignore 334 the message. 336 5. If all the above conditions are met, the message can be processed. 338 To address the confidentiality security threats, signed IMIP messages 339 SHOULD be encrypted by a mechanism based on Security Multiparts for MIME 340 [RFC1847]. 342 It is possible to receive IMIP messages sent by someone working on 343 behalf of another "Calendar User". This is determined by examining the 344 "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" property. 345 [ICAL] and [ITIP] provide no mechanism to verify that a "Calendar User" 346 has authorized someone else to work on their behalf. To address this 347 security issue, implementations MUST provide mechanisms for the 348 "Calendar Users" to make that decision before applying changes from 349 someone working on behalf of a "Calendar User". 351 4 Examples 353 4.1 Single Component With An ATTACH Property 355 This minimal message shows how an iCalendar object references an 356 attachment. The attachment is accessible via its URL. 358 From: sman@netscape.com 359 To: stevesil@microsoft.com 360 Subject: Phone Conference 361 Mime-Version: 1.0 362 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 363 Content-Transfer-Encoding: 7bit 364 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 365 March 13, 1998 367 BEGIN:VCALENDAR 368 PRODID:-//ACME/DesktopCalendar//EN 369 METHOD:REQUEST 370 VERSION:2.0 371 BEGIN:VEVENT 372 ORGANIZER:mailto:sman@netscape.com 373 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com 374 ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.com 375 DTSTAMP:19970611T190000Z 376 DTSTART:19970701T210000Z 377 DTEND:19970701T230000Z 378 SUMMARY:Phone Conference 379 DESCRIPTION:Please review the attached document. 380 UID:www.acme.com-873970198738777 381 ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc 382 SEQUENCE:0 383 STATUS:CONFIRMED 384 END:VEVENT 385 END:VCALENDAR 387 4.2 Using Multipart Alternative for Low Fidelity Clients 389 This example shows how a client can emit a multipart message that 390 includes both a plain text version as well as the full iCalendar object. 391 Clients that do not support text/calendar will still be capable of 392 rendering the plain text representation. 394 From: foo1@example.com 395 To: foo2@example.com 396 Subject: Phone Conference 397 Mime-Version: 1.0 398 Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360" 400 --01BD3665.3AF0D360 401 Content-Type: text/plain;charset=us-ascii 402 Content-Transfer-Encoding: 7bit 404 This is an alternative representation of a TEXT/CALENDAR MIME Object 405 When: 7/1/1997 1:00PM PDT - 7/1/97 3:00 PM PDT 406 Where: 407 Organizer: foo1@example.com 408 Summary: Phone Conference 410 --01BD3665.3AF0D360 411 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 412 Content-Transfer-Encoding: 7bit 414 BEGIN:VCALENDAR 415 PRODID:-//ACME/DesktopCalendar//EN 416 METHOD:REQUEST 417 VERSION:2.0 418 BEGIN:VEVENT 419 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 420 March 13, 1998 422 ORGANIZER:mailto:foo1@example.com 423 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 424 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 425 DTSTAMP:19970611T190000Z 426 DTSTART:19970701T170000Z 427 DTEND:19970701T173000Z 428 SUMMARY:Phone Conference 429 UID:www.acme.com-8739701987387771 430 ATTACH:cid:123456789@example.com 431 SEQUENCE:0 432 STATUS:CONFIRMED 433 END:VEVENT 434 END:VCALENDAR 436 --01BD3665.3AF0D360 438 4.3 Single Component With An ATTACH Property and Inline Attachment 440 This example shows how a message containing an iCalendar object 441 references an attached document. The reference is made using a Content- 442 id (CID). Thus, the iCalendar object and the document are packaged in a 443 multipart/related encapsulation. 445 From: foo1@example.com 446 To: foo2@example.com 447 Subject: Phone Conference 448 Mime-Version: 1.0 449 Content-Type: multipart/related; boundary="boundary-example-1"; 450 type=text/calendar 452 --boundary-example-1 454 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 455 Content-Transfer-Encoding: 7bit 456 Content-Disposition: attachment; filename="event.vcs" 458 BEGIN:VCALENDAR 459 PRODID:-//ACME/DesktopCalendar//EN 460 METHOD:REQUEST 461 VERSION:2.0 462 BEGIN:VEVENT 463 ORGANIZER:mailto:foo1@example.com 464 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 465 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 466 DTSTAMP:19970611T190000Z 467 DTSTART:19970701T180000Z 468 DTEND:19970701T173000Z 469 SUMMARY:Phone Conference 470 UID:www.acme.com-8739701987387771 471 ATTACH:cid:123456789@example.com 472 SEQUENCE:0 473 STATUS:CONFIRMED 474 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 475 March 13, 1998 477 END:VEVENT 478 END:VCALENDAR 480 --boundary-example-1 481 Content-Type: application/msword; name="FieldReport.doc" 482 Content-Transfer-Encoding: base64 483 Content-Disposition: inline; filename="FieldReport.doc" 484 Content-ID: <123456789@example.com> 486 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 487 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////etc. 488 .. 490 --boundary-example-1-- 492 4.4 Multiple Similar Components 494 Multiple iCalendar components of the same type can be included in the 495 iCalendar object when the METHOD is the same for each component. 497 From: foo1@example.com 498 To: foo2@example.com 499 Subject: Phone Conference 500 Mime-Version: 1.0 501 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 502 Content-Transfer-Encoding: 7bit 503 Content-Disposition: attachment; filename="event.vcs" 505 BEGIN:VCALENDAR 506 PRODID:-//ACME/DESKTOPCALENDAR//EN 507 METHOD:REQUEST 508 VERSION:2.0 509 BEGIN:VEVENT 510 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 511 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:MAILTO:FOO1@EXAMPLE.COM 512 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:MAILTO:FOO2@EXAMPLE.COM 513 DTSTAMP:19970611T190000Z 514 DTSTART:19970701T210000Z 515 DTEND:19970701T230000Z 516 SUMMARY:PHONE CONFERENCE 517 DESCRIPTION:DISCUSS THE CONTENTS OF THE ATTACHED DOCUMENT 518 UID:WWW.ACME.COM-873970198738777-1 519 SEQUENCE:0 520 STATUS:CONFIRMED 521 END:VEVENT 522 BEGIN:VEVENT 523 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:MAILTO:FOO1@EXAMPLE.COM 524 ATTENDEE;RSVP=YES:MAILTO:FOO1@EXAMPLE.COM 525 ATTENDEE;RSVP=YES:MAILTO:FOO2@EXAMPLE.COM 526 DTSTAMP:19970611T190000Z 527 DTSTART:19970701T210000Z 528 DTEND:19970701T230000Z 529 SUMMARY:FOLLOW-UP PHONE CONFERENCE 530 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 531 March 13, 1998 533 DESCRIPTION:DISCUSS THE CONTENTS OF THE ATTACHED DOCUMENT 534 UID:WWW.ACME.COM-873970198738777-2 535 SEQUENCE:0 536 STATUS:CONFIRMED 537 END:VEVENT 538 END:VCALENDAR 540 4.5 Multiple Mixed Components 542 Different component types must be encapsulated in separate iCalendar 543 objects. 545 From: foo1@example.com 546 To: foo2@example.com 547 Subject: Phone Conference 548 Mime-Version: 1.0 549 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 551 This is a multi-part message in MIME format. 553 ----FEE3790DC7E35189CA67CE2C 554 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 555 Content-Transfer-Encoding: quoted-printable 556 Content-Disposition: attachment; filename="event1.vcs" 558 BEGIN:VCALENDAR 559 PRODID:-//ACME/DesktopCalendar//EN 560 METHOD:REQUEST 561 VERSION:2.0 562 BEGIN:VEVENT 563 ORGANIZER:mailto:foo1@example.com 564 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 565 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 566 DTSTAMP:19970611T190000Z 567 DTSTART:19970701T210000Z 568 DTEND:19970701T230000Z 569 SUMMARY:Phone Conference 570 DESCRIPTION:Discuss what happened at the last meeting 571 UID:www.acme.com-8739701987387772 572 SEQUENCE:0 573 STATUS:CONFIRMED 574 END:VEVENT 575 END:VCALENDAR 577 ----FEE3790DC7E35189CA67CE2C 578 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 579 Content-Transfer-Encoding:7bit 580 Content-Disposition: attachment; filename="todo1.vcs" 582 BEGIN:VCALENDAR 583 PRODID:-//ACME/DesktopCalendar//EN 584 METHOD:REQUEST 585 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 586 March 13, 1998 588 VERSION:2.0 589 BEGIN:VTODO 590 DUE:19970701T090000-0700 591 ORGANIZER:mailto:foo1@example.com 592 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 593 ATTENDEE;RSVP=YES:mailto:foo2@example.com 594 SUMMARY:Phone Conference 595 DESCRIPTION:Discuss where to have the company picnic 596 UID:www.acme.com-td-8739701987387773 597 SEQUENCE:0 598 STATUS:NEEDS ACTION 599 END:VEVENT 600 END:VCALENDAR 602 ----FEE3790DC7E35189CA67CE2C 604 4.6 Detailed Components With An ATTACH Property 606 This example shows the format of a message containing a group meeting 607 between three individuals. The multipart/related encapsulation is used 608 because the iCalendar object contains an ATTACH property that uses a CID 609 to reference the attachment. 611 From: foo1@example.com 612 MIME-Version: 1.0 613 To: foo2@example.com,foo3@example.com 614 Subject: REQUEST - Phone Conference 615 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 617 This is a multi-part message in MIME format. 619 ----FEE3790DC7E35189CA67CE2C 620 Content-Type: text/plain; charset=us-ascii 621 Content-Transfer-Encoding: 7bit 623 When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT 624 Where: 625 Organizer: foo1@example.com 626 Summary: Let's discuss the attached document 628 ----FEE3790DC7E35189CA67CE2C 629 Content-Type: multipart/related; boundary="boundary-example-2"; 630 type=text/calendar 632 --boundary-example-2 633 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII; 634 Component=vevent 635 Content-Transfer-Encoding: 7bit 636 Content-Disposition: attachment; filename="event.vcs" 638 BEGIN:VCALENDAR 639 PRODID:-//ACME/DesktopCalendar//EN 640 PROFILE:REQUEST 641 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 642 March 13, 1998 644 PROFILE-VERSION:1.0 645 VERSION:2.0 646 BEGIN:VEVENT 647 ORGANIZER:foo1@example.com 648 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com 649 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 650 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com 651 DTSTAMP:19970611T190000Z 652 DTSTART:19970621T190000Z 653 DTEND:199706211T210000Z 654 SUMMARY:Let's discuss the attached document 655 UID:www.acme.com-873970198738777 656 ATTACH:cid:www.acme.com-12345aaa 657 SEQUENCE:0 658 STATUS:CONFIRMED 659 END:VEVENT 660 END:VCALENDAR 662 --boundary-example-2 663 Content-Type: application/msword; name="FieldReport.doc" 664 Content-Transfer-Encoding: base64 665 Content-Disposition: inline; filename="FieldReport.doc" 666 Content-ID: 668 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 669 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////etc. 670 .. 672 --boundary-example-2-- 673 ----FEE3790DC7E35189CA67CE2C-- 675 5 Bibliography 677 [CHST] Character Sets, ftp://ftp.isi.edu/in- 678 notes/iana/assignments/character-sets 680 [ICAL] "Internet Calendaring and Scheduling Core Object Specification - 681 iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- 682 drafts/draft-ietf-calsch-ical-04.txt. 684 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 685 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-02.txt. 687 [ITIP] "iCalendar Transport-Independent Interoperability Protocol (iTIP) 688 : Scheduling Events, Busy Time, To-dos and Journal Entries ", Internet- 689 Draft, October 1997, http://www.imc.org/draft-ietf-calsch-itip-01.txt. 691 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 692 Messages", STD 11, RFC-822, August 1982. 694 [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security 695 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC- 696 1847, October 1995. 698 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 699 March 13, 1998 701 [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 702 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC- 703 2045, November 1996. 705 [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 706 Extensions (MIME) - Part Two: Media Types", RFC-2046, November 1996. 708 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 709 Part Three: Message Header Extensions for Non-ASCII Text", RFC-2047, 710 November 1996. 712 [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet Mail 713 Extensions (MIME) - Part Four: Registration Procedures", RFC-2048, 714 January 1997. 716 6 Author's Address 718 The following address information is provided in a vCard v2.1, 719 Electronic Business Card, format. 721 BEGIN:VCARD 722 FN:Frank Dawson 723 ORG:Lotus Development Corporation 724 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-3502;USA 725 TEL;WORK;MSG:+1-919-676-9515 726 TEL;WORK;FAX:+1-919-676-9564 727 EMAIL;INTERNET:fdawson@earthlink.net 728 URL:http://home.earthlink.net/~fdawson 729 END:VCARD 731 BEGIN:VCARD 732 FN:Steve Mansour 733 ORG:Netscape Communications Corporation 734 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 735 View;CA;94043;USA 736 TEL;WORK;MSG:+1-650-937-2378 737 TEL;WORK;FAX:+1-650-937-2103 738 EMAIL;INTERNET:sman@netscape.com 739 END:VCARD 741 BEGIN:VCARD 742 FN:Steve Silverberg 743 ORG:Microsoft Corporation 744 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 745 Redmond;WA;98052-6399;USA 746 TEL;WORK;MSG:+1-425-936-9277 747 TEL;WORK;FAX:+1-425-936-8019 748 EMAIL;INTERNET:stevesil@Microsoft.com 749 END:VCARD 750 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 751 March 13, 1998 753 The iCalendar Object is a result of the work of the Internet Engineering 754 Task Force Calendaring and scheduling Working Group. The chairman of 755 that working group is: 757 BEGIN:VCARD 758 FN:Anik Ganguly 759 ORG:OnTime, Inc. 760 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 761 Highway;Southfield;MI;48075;USA 762 TEL;WORK;MSG:+1-810-559-5955 763 TEL;WORK;FAX:+1-810-559-5034 764 EMAIL;INTERNET:anik@ontime.com 765 END:VCARD 767 7 Full Copyright Statement 769 "Copyright (C) The Internet Society (date). All Rights Reserved. 771 This document and translations of it may be copied and furnished to 772 others, and derivative works that comment on or otherwise explain it or 773 assist in its implementation may be prepared, copied, published and 774 distributed, in whole or in part, without restriction of any kind, 775 provided that the above copyright notice and this paragraph are included 776 on all such copies and derivative works. However, this document itself 777 may not be modified in any way, such as by removing the copyright notice 778 or references to the Internet Society or other Internet organizations, 779 except as needed for the purpose of developing Internet standards in 780 which case the procedures for copyrights defined in the Internet 781 Standards process must be followed, or as required to translate it into 782 languages other than English. 784 The limited permissions granted above are perpetual and will not be 785 revoked by the Internet Society or its successors or assigns. 787 This document and the information contained herein is provided on an "AS 788 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 789 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 790 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 791 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 792 FITNESS FOR A PARTICULAR PURPOSE.