idnits 2.17.1 draft-ietf-calsch-imip-06.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 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 ([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 83: '...5 RECOMMENDED PRACTICES..................' RFC 2119 keyword, line 204: '...ntations of iMIP SHOULD verify the aut...' RFC 2119 keyword, line 233: '...iCalendar object MUST be a fully qualified, [RFC-822] address...' RFC 2119 keyword, line 241: '...relevant address MUST be ascertained b...' RFC 2119 keyword, line 248: '...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 (August 25, 1998) is 9376 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 679 looks like a reference -- Missing reference section? 'RFC-2045' on line 686 looks like a reference -- Missing reference section? 'RFC-2047' on line 693 looks like a reference -- Missing reference section? 'RFC-2048' on line 697 looks like a reference -- Missing reference section? 'RFC-2049' on line 33 looks like a reference -- Missing reference section? 'RFC-2046' on line 690 looks like a reference -- Missing reference section? 'ICMS' on line 672 looks like a reference -- Missing reference section? 'RFC-2119' on line 129 looks like a reference -- Missing reference section? 'RFC-1847' on line 682 looks like a reference -- Missing reference section? 'RFC-2111' on line 701 looks like a reference -- Missing reference section? 'CHST' on line 665 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 August 25, 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 learn the current status of any Internet-Draft, please check the 1id- 23 abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 Distribution of this document is unlimited. 29 Abstract 30 This document, [iMIP], specifies a binding from the iCalendar Transport- 31 independent Interoperability Protocol (iTIP) to Internet email-based 32 transports. Calendaring entries defined by the iCalendar Object Model 33 [iCAL] are composed using constructs from [RFC-822], [RFC-2045], [RFC- 34 2046], [RFC-2047], [RFC-2048] and [RFC-2049]. 36 This document is based on the calendaring and scheduling model defined 37 by [ICMS]. 39 This document is based on discussions within the Internet Engineering 40 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 41 More information about the IETF CALSCH working group activities can be 42 found on the IMC web site at http://www.imc.org, the IETF web site at 43 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the 44 references within this document for further information on how to access 45 these various documents. 47 Distribution of this document is unlimited. Comments and suggestions for 48 improvement should be sent to the authors. 50 Copyright (C) The Internet Society 1998. All Rights Reserved. 52 Table of Contents 54 1 INTRODUCTION.........................................................3 56 1.1 RELATED MEMOS ....................................................3 57 1.2 FORMATTING CONVENTIONS ...........................................3 58 1.3 TERMINOLOGY ......................................................4 60 2 MIME MESSAGE FORMAT BINDING..........................................4 62 2.1 MIME MEDIA TYPE ..................................................4 63 2.2 SECURITY .........................................................4 64 2.2.1 Authorization ................................................5 65 2.2.2 Authentication ...............................................5 66 2.2.3 Confidentiality ..............................................5 67 2.3 [RFC-822] ADDRESSES ..............................................5 68 2.4 CONTENT TYPE .....................................................6 69 2.5 CONTENT-TRANSFER-ENCODING ........................................7 70 2.6 CONTENT-DISPOSITION ..............................................7 72 3 SECURITY CONSIDERATIONS..............................................7 74 4 EXAMPLES.............................................................8 76 4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY .........................8 77 4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS .............8 78 4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ...9 79 4.4 MULTIPLE SIMILAR COMPONENTS .....................................10 80 4.5 MULTIPLE MIXED COMPONENTS .......................................11 81 4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY .....................12 83 5 RECOMMENDED PRACTICES...............................................14 85 5.1 USE OF CONTENT AND MESSAGE IDS ..................................14 87 6 BIBLIOGRAPHY........................................................14 89 7 AUTHORS ADDRESSES...................................................15 91 8 FULL COPYRIGHT STATEMENT............................................16 92 1 Introduction 94 This binding document provides the transport specific information 95 necessary convey iCalendar Transport-independent Interoperability 96 Protocol (iTIP) over MIME as defined in [RFC-822] and [RFC-2045]. 98 1.1 Related Memos 100 Implementers will need to be familiar with several other memos that, 101 along with this memo, form a framework for Internet calendaring and 102 scheduling standards. 104 This document, [iMIP], specifies an Internet email binding for iTIP. 106 [ICMS] - specifies a common terminology and abstract; 108 [iCAL] - specifies a core specification of objects, data types, 109 properties and property parameters; 111 [iTIP] - specifies an interoperability protocol for scheduling between 112 different implementations; 114 This memo does not attempt to repeat the specification of concepts or 115 definitions from these other memos. Where possible, references are made 116 to the memo that provides for the specification of these concepts or 117 definitions. 119 1.2 Formatting Conventions 121 The mechanisms defined in this memo are defined in prose. In order to 122 refer to elements of the calendaring and scheduling model, core object 123 or interoperability protocol defined in [ICMS], [iCAL] and [iTIP] some 124 formatting conventions have been used. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC-2119]. 130 Calendaring and scheduling roles described by [ICMS] are referred to in 131 quoted-strings of text with the first character of each word in upper 132 case. For example, "Organizer" refers to a role of a "Calendar User" 133 within the scheduling protocol defined by [iTIP]. 135 Calendar components defined by [iCAL] are referred to with capitalized, 136 quoted-strings of text. All calendar components start with the letter 137 "V". For example, "VEVENT" refers to the event calendar component, 138 "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to 139 the daily journal calendar component. 141 Scheduling methods defined by [iTIP] are referred to with capitalized, 142 quoted-strings of text. For example, "REQUEST" refers to the method for 143 requesting a scheduling calendar component be created or modified, 144 "REPLY" refers to the method a recipient of a request uses to update 145 their status with the "Organizer" of the calendar component. 147 Properties defined by [iCAL] are referred to with capitalized, quoted- 148 strings of text, followed by the word "property". For example, 149 "ATTENDEE" property refers to the iCalendar property used to convey the 150 calendar address of a calendar user. 152 Property parameters defined by [iCAL] are referred to with lower case, 153 quoted-strings of text, followed by the word "parameter". For example, 154 "value" parameter refers to the iCalendar property parameter used to 155 override the default data type for a property value. 157 1.3 Terminology 159 The email terms used in this memo are defined in [RFC-822] and [RFC- 160 2045]. The calendaring and scheduling terms used in this memo are 161 defined in [ICMS], [iCAL] and [iTIP]. 163 2 MIME Message Format Binding 165 This section defines the message binding to the MIME electronic mail 166 transport. 168 The sections below refer to the "originator" and the "respondent" of an 169 iMIP message. Typically, the originator is the "Organizer" of an event. 170 The respondent is an "Attendee" of the event. 172 The [RFC-822] "Reply-To" header typically contains the email address of 173 the originator or respondent of an event. However, this cannot be 174 guaranteed as Mail User Agents (MUA) are not required to enforce iMIP 175 semantics. 177 2.1 MIME Media Type 179 A MIME entity containing content information formatted according to this 180 document will be referenced as a "text/calendar" content type. It is 181 assumed that this content type will be transported through a MIME 182 electronic mail transport. 184 2.2 Security 186 This section addresses several aspects of security including 187 Authentication, Authorization and Confidentiality. Authentication and 188 confidentiality can be achieved using [RFC-1847] that specifies the 189 Security Multiparts for MIME. This framework defines new content types 190 and subtypes of multipart: signed and encrypted. Each contains two body 191 parts: one for the protected data and another for the control 192 information necessary to remove the protection. 194 2.2.1 Authorization 196 In [iTIP] messages, only the "Organizer" is authorized to modify or 197 cancel calendar entries they organize. That is, spoof@xyz.com is not 198 allowed to modify or cancel a meeting that was organized by 199 a@example.com. Furthermore, only the respondent has the authorization to 200 indicate their status to the "Organizer". That is, the "Organizer" must 201 ignore an [iTIP] message from spoof@xyz.com that declines a meeting 202 invitation for b@example.com. 204 Implementations of iMIP SHOULD verify the authenticity of the creator of 205 an iCalendar object before taking any action. The methods for doing this 206 are presented later in this document. 208 [RFC-1847] Message flow in iTIP supports someone working on behalf of a 209 "Calendar User" through use of the "sent-by" parameter that is 210 associated with the "ATTENDEE" and "ORGANIZER" properties. However, 211 there is no mechanism to verify whether or not a "Calendar User" has 212 authorized someone to work on their behalf. It is left to 213 implementations to provide mechanisms for the "Calendar Users" to make 214 that decision. 216 2.2.2 Authentication 218 Authentication can be performed using an implementation of [RFC-1847] 219 "multipart/signed" that supports public/private key certificates. 220 Authentication is possible only on messages that have been signed. 221 Authenticating an unsigned message may not be reliable. 223 2.2.3 Confidentiality 225 To ensure confidentiality using iMIP implementations should utilize 226 [RFC-1847]-compliant encryption. The protocol does not restrict a 227 "Calendar User Agent" (CUA) from forwarding iCalendar objects to other 228 users or agents. 230 2.3 [RFC-822] Addresses 232 The calendar address specified within the "ATTENDEE" property in an 233 iCalendar object MUST be a fully qualified, [RFC-822] address 234 specification for the corresponding "Organizer" or "Attendee" of the 235 "VEVENT" or "VTODO". 237 Because [iTIP] does not preclude "Attendees" from forwarding "VEVENTS" 238 or "VTODOS" to others, the [RFC-822] "Sender" value may not equal that 239 of the "Organizer". Additionally, the "Organizer" or "Attendee" cannot 240 be reliably inferred by the [RFC-822] "Sender" or "Reply-to" values of 241 an iMIP message. The relevant address MUST be ascertained by opening 242 the "text/calendar" MIME body part and examining the "ATTENDEE" and 243 "ORGANIZER" properties. 245 2.4 Content Type 247 A MIME body part containing content information that conforms to this 248 document MUST have an [RFC-2045] "Content-Type" value of 249 "text/calendar". The [RFC-2045] "Content-Type" header field must also 250 include the type parameter "method". The value MUST be the same as the 251 value of the "METHOD" calendar property within the iCalendar object. 252 This means that a MIME message containing multiple iCalendar objects 253 with different method values must be further encapsulated with a 254 "multipart/mixed" MIME entity. This will allow each of the iCalendar 255 objects to be encapsulated within their own "text/calendar" MIME entity. 257 A "charset" parameter MUST be present if the iCalendar object contains 258 characters that are not part of the US-ASCII character set. [RFC-2046] 259 discusses the selection of an appropriate "charset" value. 261 The optional "component" parameter defines the iCalendar component type 262 contained within the iCalendar object. 264 The following is an example of this header field with a value that 265 indicates an event message. 267 Content-Type:text/calendar; method=request; charset=UTF-8; 268 component=vevent 270 The "text/calendar" content type allows for the scheduling message type 271 to be included in a MIME message with other content information (i.e., 272 "multipart/mixed") or included in a MIME message with a clear-text, 273 human-readable form of the scheduling message (i.e., 274 "multipart/alternative"). 276 In order to permit the information in the scheduling message to be 277 understood by MIME user agents (UA) that do not support the 278 "text/calendar" content type, scheduling messages SHOULD be sent with an 279 alternative, human-readable form of the information. 281 2.5 Content-Transfer-Encoding 283 Note that the default character set for iCalendar objects is UTF-8. A 284 transfer encoding SHOULD be used for iCalendar objects containing any 285 characters that are not part of the US-ASCII character set. 287 2.6 Content-Disposition 289 The handling of a MIME part should be based on its [RFC-2045] "Content- 290 Type". However, this is not guaranteed to work in all environments. 292 Some environments handle MIME attachments based on their file type or 293 extension. To operate correctly in these environments, implementations 294 may wish to include a "Content-Disposition" property to define a file 295 name. 297 3 Security Considerations 299 The security threats that applications must address when implementing 300 iTIP are detailed in [iTIP]. Two spoofing threats are identified: 301 Spoofing the "Organizer", and Spoofing an "Attendee". To address these 302 threats, the originator of an iCalendar object must be authenticated by 303 a recipient. Once authenticated, a determination can be made as to 304 whether or not the originator is authorized to perform the requested 305 operation. Compliant applications MUST support signing and encrypting 306 text/calendar attachments using a mechanism based on Security Multiparts 307 for MIME [RFC-1847] to facilitate the authentication the originator of 308 the iCalendar object. Implementations MAY provide a means for users to 309 disable signing and encrypting. The steps are described below: 311 1. The iCalendar object MUST be signed by the "Organizer" sending an 312 update or the "Attendee" sending a reply. 314 2. Using the [RFC-1847]-compliant security mechanism, determine who 315 signed the iCalendar object. This is the "signer". Note that the signer 316 is not necessarily the person sending an e-mail message since an e-mail 317 message can be forwarded. 319 3. Correlate the signer to an "ATTENDEE" property in the iCalendar 320 object. If the signer cannot be correlated to an "ATTENDEE" property, 321 ignore the message. 323 4. Determine whether or not the "ATTENDEE" is authorized to perform the 324 operation as defined by [iTIP]. If the conditions are not met, ignore 325 the message. 327 5. If all the above conditions are met, the message can be processed. 329 To address the confidentiality security threats, signed iMIP messages 330 SHOULD be encrypted by a mechanism based on Security Multiparts for MIME 331 [RFC-1847]. 333 It is possible to receive iMIP messages sent by someone working on 334 behalf of another "Calendar User". This is determined by examining the 335 "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" property. 336 [iCAL] and [iTIP] provide no mechanism to verify that a "Calendar User" 337 has authorized someone else to work on their behalf. To address this 338 security issue, implementations MUST provide mechanisms for the 339 "Calendar Users" to make that decision before applying changes from 340 someone working on behalf of a "Calendar User". 342 4 Examples 344 4.1 Single Component With An ATTACH Property 346 This minimal message shows how an iCalendar object references an 347 attachment. The attachment is accessible via its URL. 349 From: sman@netscape.com 350 To: stevesil@microsoft.com 351 Subject: Phone Conference 352 Mime-Version: 1.0 353 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 354 Content-Transfer-Encoding: 7bit 356 BEGIN:VCALENDAR 357 PRODID:-//ACME/DesktopCalendar//EN 358 METHOD:REQUEST 359 VERSION:2.0 360 BEGIN:VEVENT 361 ORGANIZER:mailto:sman@netscape.com 362 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com 363 ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.com 364 DTSTAMP:19970611T190000Z 365 DTSTART:19970701T210000Z 366 DTEND:19970701T230000Z 367 SUMMARY:Phone Conference 368 DESCRIPTION:Please review the attached document. 369 UID:calsvr.example.com-873970198738777 370 ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc 371 STATUS:CONFIRMED 372 END:VEVENT 373 END:VCALENDAR 375 4.2 Using Multipart Alternative for Low Fidelity Clients 377 This example shows how a client can emit a multipart message that 378 includes both a plain text version as well as the full iCalendar object. 379 Clients that do not support text/calendar will still be capable of 380 rendering the plain text representation. 382 From: foo1@example.com 383 To: foo2@example.com 384 Subject: Phone Conference 385 Mime-Version: 1.0 386 Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360" 388 --01BD3665.3AF0D360 389 Content-Type: text/plain;charset=us-ascii 390 Content-Transfer-Encoding: 7bit 392 This is an alternative representation of a TEXT/CALENDAR MIME Object 393 When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT 394 Where: 395 Organizer: foo1@example.com 396 Summary: Phone Conference 398 --01BD3665.3AF0D360 399 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 400 Content-Transfer-Encoding: 7bit 402 BEGIN:VCALENDAR 403 PRODID:-//ACME/DesktopCalendar//EN 404 METHOD:REQUEST 405 VERSION:2.0 406 BEGIN:VEVENT 407 ORGANIZER:mailto:foo1@example.com 408 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 409 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 410 DTSTAMP:19970611T190000Z 411 DTSTART:19970701T170000Z 412 DTEND:19970701T173000Z 413 SUMMARY:Phone Conference 414 UID:calsvr.example.com-8739701987387771 415 SEQUENCE:0 416 STATUS:CONFIRMED 417 END:VEVENT 418 END:VCALENDAR 420 --01BD3665.3AF0D360 422 4.3 Single Component With An ATTACH Property and Inline Attachment 424 This example shows how a message containing an iCalendar object 425 references an attached document. The reference is made using a Content- 426 id (CID). Thus, the iCalendar object and the document are packaged in a 427 multipart/related encapsulation. 429 From: foo1@example.com 430 To: foo2@example.com 431 Subject: Phone Conference 432 Mime-Version: 1.0 433 Content-Type: multipart/related; boundary="boundary-example-1"; 434 type=text/calendar 436 --boundary-example-1 438 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 439 Content-Transfer-Encoding: 7bit 440 Content-Disposition: attachment; filename="event.vcs" 442 BEGIN:VCALENDAR 443 PRODID:-//ACME/DesktopCalendar//EN 444 METHOD:REQUEST 445 VERSION:2.0 446 BEGIN:VEVENT 447 ORGANIZER:mailto:foo1@example.com 448 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 449 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 450 DTSTAMP:19970611T190000Z 451 DTSTART:19970701T180000Z 452 DTEND:19970701T183000Z 453 SUMMARY:Phone Conference 454 UID:calsvr.example.com-8739701987387771 455 ATTACH:cid:123456789@example.com 456 SEQUENCE:0 457 STATUS:CONFIRMED 458 END:VEVENT 459 END:VCALENDAR 461 --boundary-example-1 462 Content-Type: application/msword; name="FieldReport.doc" 463 Content-Transfer-Encoding: base64 464 Content-Disposition: inline; filename="FieldReport.doc" 465 Content-ID: <123456789@example.com> 467 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 468 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// 469 ... 471 --boundary-example-1-- 473 4.4 Multiple Similar Components 475 Multiple iCalendar components of the same type can be included in the 476 iCalendar object when the METHOD is the same for each component. 478 From: foo1@example.com 479 To: foo2@example.com 480 Subject: Summer Company Holidays 481 Mime-Version: 1.0 482 Content-Type:text/calendar; method=PUBLISH; charset=US-ASCII 483 Content-Transfer-Encoding: 7bit 484 Content-Disposition: attachment; filename="event.vcs" 486 BEGIN:VCALENDAR 487 PRODID:-//ACME/DESKTOPCALENDAR//EN 488 METHOD:PUBLISH 489 VERSION:2.0 490 BEGIN:VEVENT 491 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 492 DTSTAMP:19970611T150000Z 493 DTSTART:19970701T150000Z 494 DTEND:19970701T230000Z 495 SUMMARY:Company Picnic 496 DESCRIPTION:Food and drink will be provided 497 UID:CALSVR.EXAMPLE.COM-873970198738777-1 498 SEQUENCE:0 499 STATUS:CONFIRMED 500 END:VEVENT 501 BEGIN:VEVENT 502 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 503 DTSTAMP:19970611T190000Z 504 DTSTART:19970715T150000Z 505 DTEND:19970715T230000Z 506 SUMMARY:Company Bowling Tournament 507 DESCRIPTION:We have 10 lanes reserved 508 UID:CALSVR.EXAMPLE.COM-873970198738777-2 509 SEQUENCE:0 510 STATUS:CONFIRMED 511 END:VEVENT 512 END:VCALENDAR 514 4.5 Multiple Mixed Components 516 Different component types must be encapsulated in separate iCalendar 517 objects. 519 From: foo1@example.com 520 To: foo2@example.com 521 Subject: Phone Conference 522 Mime-Version: 1.0 523 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 525 This is a multi-part message in MIME format. 527 ----FEE3790DC7E35189CA67CE2C 528 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 529 Content-Transfer-Encoding: 7bit 530 Content-Disposition: attachment; filename="event1.vcs" 532 BEGIN:VCALENDAR 533 PRODID:-//ACME/DesktopCalendar//EN 534 METHOD:REQUEST 535 VERSION:2.0 536 BEGIN:VEVENT 537 ORGANIZER:mailto:foo1@example.com 538 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 539 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 540 DTSTAMP:19970611T190000Z 541 DTSTART:19970701T210000Z 542 DTEND:19970701T230000Z 543 SUMMARY:Phone Conference 544 DESCRIPTION:Discuss what happened at the last meeting 545 UID:calsvr.example.com-8739701987387772 546 SEQUENCE:0 547 STATUS:CONFIRMED 548 END:VEVENT 549 END:VCALENDAR 550 ----FEE3790DC7E35189CA67CE2C 551 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 552 Content-Transfer-Encoding:7bit 553 Content-Disposition: attachment; filename="todo1.vcs" 555 BEGIN:VCALENDAR 556 PRODID:-//ACME/DesktopCalendar//EN 557 METHOD:REQUEST 558 VERSION:2.0 559 BEGIN:VTODO 560 DUE:19970701T090000-0700 561 ORGANIZER:mailto:foo1@example.com 562 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 563 ATTENDEE;RSVP=YES:mailto:foo2@example.com 564 SUMMARY:Phone Conference 565 DESCRIPTION:Discuss a new location for the company picnic 566 UID:calsvr.example.com-td-8739701987387773 567 SEQUENCE:0 568 STATUS:NEEDS ACTION 569 END:VEVENT 570 END:VCALENDAR 572 ----FEE3790DC7E35189CA67CE2C 574 4.6 Detailed Components With An ATTACH Property 576 This example shows the format of a message containing a group meeting 577 between three individuals. The multipart/related encapsulation is used 578 because the iCalendar object contains an ATTACH property that uses a CID 579 to reference the attachment. 581 From: foo1@example.com 582 MIME-Version: 1.0 583 To: foo2@example.com,foo3@example.com 584 Subject: REQUEST - Phone Conference 585 Content-Type:multipart/related;boundary="--FEE3790DC7E35189CA67CE2C" 587 ----FEE3790DC7E35189CA67CE2C 588 Content-Type: multipart/alternative; 589 boundary="--00FEE3790DC7E35189CA67CE2C00" 591 ----00FEE3790DC7E35189CA67CE2C00 592 Content-Type: text/plain; charset=us-ascii 593 Content-Transfer-Encoding: 7bit 595 When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT 596 Where: 597 Organizer: foo1@example.com 598 Summary: Let's discuss the attached document 600 ----00FEE3790DC7E35189CA67CE2C00 602 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII; 603 Component=vevent 604 Content-Transfer-Encoding: 7bit 605 Content-Disposition: attachment; filename="event.vcs" 607 BEGIN:VCALENDAR 608 PRODID:-//ACME/DesktopCalendar//EN 609 PROFILE:REQUEST 610 PROFILE-VERSION:1.0 611 VERSION:2.0 612 BEGIN:VEVENT 613 ORGANIZER:foo1@example.com 614 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com 615 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 616 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com 617 DTSTAMP:19970611T190000Z 618 DTSTART:19970621T170000Z 619 DTEND:199706211T173000Z 620 SUMMARY:Let's discuss the attached document 621 UID:calsvr.example.com-873970198738777-8aa 622 ATTACH:cid:calsvr.example.com-12345aaa 623 SEQUENCE:0 624 STATUS:CONFIRMED 625 END:VEVENT 626 END:VCALENDAR 628 ----00FEE3790DC7E35189CA67CE2C00 630 ----FEE3790DC7E35189CA67CE2C 631 Content-Type: application/msword; name="FieldReport.doc" 632 Content-Transfer-Encoding: base64 633 Content-Disposition: inline; filename="FieldReport.doc" 634 Content-ID: 636 R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94XqAG 637 4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH 638 5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J. 639 .. 641 ----FEE3790DC7E35189CA67CE2C 643 5 Recommended Practices 645 This section outlines a series of recommended practices when using a 646 messaging transport to exchange iCalendar objects. 648 5.1 Use of Content and Message IDs 650 The [iCAL] specification makes frequent use of the URI for data types in 651 properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. Two 652 forms of URIs are Message ID (MID) and Content ID (CID). These are 653 defined in [RFC-2111]. Although [RFC-2111] allows referencing messages 654 or MIME body parts in other MIME entities or stores, it is strongly 655 recommended that iMIP implementations include all referenced messages 656 and body parts in a single MIME entity. Simply put, if an iCalendar 657 object contains CID or MID references to other messages or body parts, 658 implementations should ensure that these messages and/or body parts are 659 transmitted with the iCalendar object. If they are not there is no 660 guarantee that the receiving "CU" will have the access or the 661 authorization to view those objects. 663 6 Bibliography 665 [CHST] Character Sets, ftp://ftp.isi.edu/in- 666 notes/iana/assignments/character-sets 668 [iCAL] "Internet Calendaring and Scheduling Core Object Specification - 669 iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- 670 drafts/draft-ietf-calsch-ical-07.txt. 672 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 673 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-03.txt. 675 [iTIP] "iCalendar Transport-Independent Interoperability Protocol (iTIP) 676 : Scheduling Events, Busy Time, To-dos and Journal Entries ", Internet- 677 Draft, October 1997, http://www.imc.org/draft-ietf-calsch-itip-04.txt. 679 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 680 Messages", STD 11, RFC-822, August 1982. 682 [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security 683 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC- 684 1847, October 1995. 686 [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 687 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC- 688 2045, November 1996. 690 [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 691 Extensions (MIME) - Part Two: Media Types", RFC-2046, November 1996. 693 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 694 Part Three: Message Header Extensions for Non-ASCII Text", RFC-2047, 695 November 1996. 697 [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet Mail 698 Extensions (MIME) - Part Four: Registration Procedures", RFC-2048, 699 January 1997. 701 [RFC-2111] E. Levinson, "Content-ID and Message-ID Uniform Resource 702 Locators", RFC-2111, March 1997. 704 7 Authors Addresses 706 The following address information is provided in a vCard v2.1, 707 Electronic Business Card, format. 709 BEGIN:VCARD 710 VERSION:2.1 711 FN:Frank Dawson 712 ORG:Lotus Development Corporation 713 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford 714 Drive;Raleigh;NC;27613-3502;USA 715 TEL;WORK;MSG:+1-919-676-9515 716 TEL;WORK;FAX:+1-919-676-9564 717 EMAIL;INTERNET:fdawson@earthlink.net 718 URL:http://home.earthlink.net/~fdawson 719 END:VCARD 721 BEGIN:VCARD 722 VERSION:2.1 723 FN:Steve Mansour 724 ORG:Netscape Communications Corporation 725 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 726 View;CA;94043;USA 727 TEL;WORK;MSG:+1-650-937-2378 728 TEL;WORK;FAX:+1-650-937-2103 729 EMAIL;INTERNET:sman@netscape.com 730 END:VCARD 732 BEGIN:VCARD 733 VERSION:2.1 734 FN:Steve Silverberg 735 ORG:Microsoft Corporation 736 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 737 Redmond;WA;98052-6399;USA 738 TEL;WORK;MSG:+1-425-936-9277 739 TEL;WORK;FAX:+1-425-936-8019 740 EMAIL;INTERNET:stevesil@Microsoft.com 741 END:VCARD 743 The iCalendar Object is a result of the work of the Internet Engineering 744 Task Force Calendaring and scheduling Working Group. The chairman of 745 that working group is: 747 BEGIN:VCARD 748 VERSION:2.1 749 FN:Anik Ganguly 750 ORG:OnTime, Inc. 751 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 752 Highway;Southfield;MI;48075;USA 753 TEL;WORK;MSG:+1-810-559-5955 754 TEL;WORK;FAX:+1-810-559-5034 755 EMAIL;INTERNET:anik@ontime.com 756 END:VCARD 758 8 Full Copyright Statement 760 "Copyright (C) The Internet Society (1998). All Rights Reserved. 762 This document and translations of it may be copied and furnished to 763 others, and derivative works that comment on or otherwise explain it or 764 assist in its implementation may be prepared, copied, published and 765 distributed, in whole or in part, without restriction of any kind, 766 provided that the above copyright notice and this paragraph are included 767 on all such copies and derivative works. However, this document itself 768 may not be modified in any way, such as by removing the copyright notice 769 or references to the Internet Society or other Internet organizations, 770 except as needed for the purpose of developing Internet standards in 771 which case the procedures for copyrights defined in the Internet 772 Standards process must be followed, or as required to translate it into 773 languages other than English. 775 The limited permissions granted above are perpetual and will not be 776 revoked by the Internet Society or its successors or assigns. 778 This document and the information contained herein is provided on an "AS 779 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 780 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 781 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 782 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 783 FITNESS FOR A PARTICULAR PURPOSE.