idnits 2.17.1 draft-ietf-calsch-imip-07.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 85: '...5 RECOMMENDED PRACTICES..................' RFC 2119 keyword, line 215: '...ntations of iMIP SHOULD verify the aut...' RFC 2119 keyword, line 244: '...iCalendar object MUST be a fully qualified, [RFC-822] address...' RFC 2119 keyword, line 255: '...relevant address MUST be ascertained b...' RFC 2119 keyword, line 262: '...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 (September 15, 1998) is 9352 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 717 looks like a reference -- Missing reference section? 'RFC-2045' on line 724 looks like a reference -- Missing reference section? 'RFC-2047' on line 731 looks like a reference -- Missing reference section? 'RFC-2048' on line 735 looks like a reference -- Missing reference section? 'RFC-2049' on line 32 looks like a reference -- Missing reference section? 'RFC-2046' on line 728 looks like a reference -- Missing reference section? 'ICMS' on line 710 looks like a reference -- Missing reference section? 'RFC-2119' on line 134 looks like a reference -- Missing reference section? 'RFC-1847' on line 720 looks like a reference -- Missing reference section? 'RFC-2111' on line 739 looks like a reference -- Missing reference section? 'CHST' on line 703 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. -------------------------------------------------------------------------------- 1 Network Working Group Frank Dawson/Lotus 2 Internet Draft Steve Mansour/Netscape 3 Steve Silverberg/Microsoft 4 Expires six months after September 15, 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 ftp.ietf.org (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, [iMIP], 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 September 15, 1998 54 Table of Contents 56 1 INTRODUCTION.........................................................3 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 ................................................5 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 ........................................7 72 2.6 CONTENT-DISPOSITION ..............................................7 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 RECOMMENDED PRACTICES...............................................14 87 5.1 USE OF CONTENT AND MESSAGE IDS ..................................14 89 6 BIBLIOGRAPHY........................................................14 91 7 AUTHORS ADDRESSES...................................................15 93 8 FULL COPYRIGHT STATEMENT............................................16 94 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 95 September 15, 1998 97 1 Introduction 99 This binding document provides the transport specific information 100 necessary convey iCalendar Transport-independent Interoperability 101 Protocol (iTIP) over MIME as defined in [RFC-822] and [RFC-2045]. 103 1.1 Related Memos 105 Implementers will need to be familiar with several other memos that, 106 along with this memo, form a framework for Internet calendaring and 107 scheduling standards. 109 This document, [iMIP], specifies an Internet email binding for iTIP. 111 [ICMS] - specifies a common terminology and abstract; 113 [iCAL] - specifies a core specification of objects, data types, 114 properties and property parameters; 116 [iTIP] - specifies an interoperability protocol for scheduling between 117 different implementations; 119 This memo does not attempt to repeat the specification of concepts or 120 definitions from these other memos. Where possible, references are made 121 to the memo that provides for the specification of these concepts or 122 definitions. 124 1.2 Formatting Conventions 126 The mechanisms defined in this memo are defined in prose. In order to 127 refer to elements of the calendaring and scheduling model, core object 128 or interoperability protocol defined in [ICMS], [iCAL] and [iTIP] some 129 formatting conventions have been used. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC-2119]. 135 Calendaring and scheduling roles described by [ICMS] are referred to in 136 quoted-strings of text with the first character of each word in upper 137 case. For example, "Organizer" refers to a role of a "Calendar User" 138 within the scheduling protocol defined by [iTIP]. 140 Calendar components defined by [iCAL] are referred to with capitalized, 141 quoted-strings of text. All calendar components start with the letter 142 "V". For example, "VEVENT" refers to the event calendar component, 143 "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to 144 the daily journal calendar component. 146 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 147 September 15, 1998 149 Scheduling methods defined by [iTIP] are referred to with capitalized, 150 quoted-strings of text. For example, "REQUEST" refers to the method for 151 requesting a scheduling calendar component be created or modified, 152 "REPLY" refers to the method a recipient of a request uses to update 153 their status with the "Organizer" of the calendar component. 155 Properties defined by [iCAL] are referred to with capitalized, quoted- 156 strings of text, followed by the word "property". For example, 157 "ATTENDEE" property refers to the iCalendar property used to convey the 158 calendar address of a calendar user. 160 Property parameters defined by [iCAL] are referred to with lower case, 161 quoted-strings of text, followed by the word "parameter". For example, 162 "value" parameter refers to the iCalendar property parameter used to 163 override the default data type for a property value. 165 1.3 Terminology 167 The email terms used in this memo are defined in [RFC-822] and [RFC- 168 2045]. The calendaring and scheduling terms used in this memo are 169 defined in [ICMS], [iCAL] and [iTIP]. 171 2 MIME Message Format Binding 173 This section defines the message binding to the MIME electronic mail 174 transport. 176 The sections below refer to the "originator" and the "respondent" of an 177 iMIP message. Typically, the originator is the "Organizer" of an event. 178 The respondent is an "Attendee" of the event. 180 The [RFC-822] "Reply-To" header typically contains the email address of 181 the originator or respondent of an event. However, this cannot be 182 guaranteed as Mail User Agents (MUA) are not required to enforce iMIP 183 semantics. 185 2.1 MIME Media Type 187 A MIME entity containing content information formatted according to this 188 document will be referenced as a "text/calendar" content type. It is 189 assumed that this content type will be transported through a MIME 190 electronic mail transport. 192 2.2 Security 194 This section addresses several aspects of security including 195 Authentication, Authorization and Confidentiality. Authentication and 196 confidentiality can be achieved using [RFC-1847] that specifies the 197 Security Multiparts for MIME. This framework defines new content types 198 and subtypes of multipart: signed and encrypted. Each contains two body 199 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 200 September 15, 1998 202 parts: one for the protected data and another for the control 203 information necessary to remove the protection. 205 2.2.1 Authorization 207 In [iTIP] messages, only the "Organizer" is authorized to modify or 208 cancel calendar entries they organize. That is, spoof@xyz.com is not 209 allowed to modify or cancel a meeting that was organized by 210 a@example.com. Furthermore, only the respondent has the authorization to 211 indicate their status to the "Organizer". That is, the "Organizer" must 212 ignore an [iTIP] message from spoof@xyz.com that declines a meeting 213 invitation for b@example.com. 215 Implementations of iMIP SHOULD verify the authenticity of the creator of 216 an iCalendar object before taking any action. The methods for doing this 217 are presented later in this document. 219 [RFC-1847] Message flow in iTIP supports someone working on behalf of a 220 "Calendar User" through use of the "sent-by" parameter that is 221 associated with the "ATTENDEE" and "ORGANIZER" properties. However, 222 there is no mechanism to verify whether or not a "Calendar User" has 223 authorized someone to work on their behalf. It is left to 224 implementations to provide mechanisms for the "Calendar Users" to make 225 that decision. 227 2.2.2 Authentication 229 Authentication can be performed using an implementation of [RFC-1847] 230 "multipart/signed" that supports public/private key certificates. 231 Authentication is possible only on messages that have been signed. 232 Authenticating an unsigned message may not be reliable. 234 2.2.3 Confidentiality 236 To ensure confidentiality using iMIP implementations should utilize 237 [RFC-1847]-compliant encryption. The protocol does not restrict a 238 "Calendar User Agent" (CUA) from forwarding iCalendar objects to other 239 users or agents. 241 2.3 [RFC-822] Addresses 243 The calendar address specified within the "ATTENDEE" property in an 244 iCalendar object MUST be a fully qualified, [RFC-822] address 245 specification for the corresponding "Organizer" or "Attendee" of the 246 "VEVENT" or "VTODO". 248 Because [iTIP] does not preclude "Attendees" from forwarding "VEVENTS" 249 or "VTODOS" to others, the [RFC-822] "Sender" value may not equal that 250 of the "Organizer". Additionally, the "Organizer" or "Attendee" cannot 251 be reliably inferred by the [RFC-822] "Sender" or "Reply-to" values of 252 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 253 September 15, 1998 255 an iMIP message. The relevant address MUST be ascertained by opening 256 the "text/calendar" MIME body part and examining the "ATTENDEE" and 257 "ORGANIZER" properties. 259 2.4 Content Type 261 A MIME body part containing content information that conforms to this 262 document MUST have an [RFC-2045] "Content-Type" value of 263 "text/calendar". The [RFC-2045] "Content-Type" header field must also 264 include the type parameter "method". The value MUST be the same as the 265 value of the "METHOD" calendar property within the iCalendar object. 266 This means that a MIME message containing multiple iCalendar objects 267 with different method values must be further encapsulated with a 268 "multipart/mixed" MIME entity. This will allow each of the iCalendar 269 objects to be encapsulated within their own "text/calendar" MIME entity. 271 A "charset" parameter MUST be present if the iCalendar object contains 272 characters that are not part of the US-ASCII character set. [RFC-2046] 273 discusses the selection of an appropriate "charset" value. 275 The optional "component" parameter defines the iCalendar component type 276 contained within the iCalendar object. 278 The following is an example of this header field with a value that 279 indicates an event message. 281 Content-Type:text/calendar; method=request; charset=UTF-8; 282 component=vevent 284 The "text/calendar" content type allows for the scheduling message type 285 to be included in a MIME message with other content information (i.e., 286 "multipart/mixed") or included in a MIME message with a clear-text, 287 human-readable form of the scheduling message (i.e., 288 "multipart/alternative"). 290 In order to permit the information in the scheduling message to be 291 understood by MIME user agents (UA) that do not support the 292 "text/calendar" content type, scheduling messages SHOULD be sent with an 293 alternative, human-readable form of the information. 295 2.5 Content-Transfer-Encoding 297 Note that the default character set for iCalendar objects is UTF-8. A 298 transfer encoding SHOULD be used for iCalendar objects containing any 299 characters that are not part of the US-ASCII character set. 301 2.6 Content-Disposition 303 The handling of a MIME part should be based on its [RFC-2045] "Content- 304 Type". However, this is not guaranteed to work in all environments. 306 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 307 September 15, 1998 309 Some environments handle MIME attachments based on their file type or 310 extension. To operate correctly in these environments, implementations 311 may wish to include a "Content-Disposition" property to define a file 312 name. 314 3 Security Considerations 316 The security threats that applications must address when implementing 317 iTIP are detailed in [iTIP]. Two spoofing threats are identified: 318 Spoofing the "Organizer", and Spoofing an "Attendee". To address these 319 threats, the originator of an iCalendar object must be authenticated by 320 a recipient. Once authenticated, a determination can be made as to 321 whether or not the originator is authorized to perform the requested 322 operation. Compliant applications MUST support signing and encrypting 323 text/calendar attachments using a mechanism based on Security Multiparts 324 for MIME [RFC-1847] to facilitate the authentication the originator of 325 the iCalendar object. Implementations MAY provide a means for users to 326 disable signing and encrypting. The steps are described below: 328 1. The iCalendar object MUST be signed by the "Organizer" sending an 329 update or the "Attendee" sending a reply. 331 2. Using the [RFC-1847]-compliant security mechanism, determine who 332 signed the iCalendar object. This is the "signer". Note that the signer 333 is not necessarily the person sending an e-mail message since an e-mail 334 message can be forwarded. 336 3. Correlate the signer to an "ATTENDEE" property in the iCalendar 337 object. If the signer cannot be correlated to an "ATTENDEE" property, 338 ignore the message. 340 4. Determine whether or not the "ATTENDEE" is authorized to perform the 341 operation as defined by [iTIP]. If the conditions are not met, ignore 342 the message. 344 5. If all the above conditions are met, the message can be processed. 346 To address the confidentiality security threats, signed iMIP messages 347 SHOULD be encrypted by a mechanism based on Security Multiparts for MIME 348 [RFC-1847]. 350 It is possible to receive iMIP messages sent by someone working on 351 behalf of another "Calendar User". This is determined by examining the 352 "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" property. 353 [iCAL] and [iTIP] provide no mechanism to verify that a "Calendar User" 354 has authorized someone else to work on their behalf. To address this 355 security issue, implementations MUST provide mechanisms for the 356 "Calendar Users" to make that decision before applying changes from 357 someone working on behalf of a "Calendar User". 359 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 360 September 15, 1998 362 4 Examples 364 4.1 Single Component With An ATTACH Property 366 This minimal message shows how an iCalendar object references an 367 attachment. The attachment is accessible via its URL. 369 From: sman@netscape.com 370 To: stevesil@microsoft.com 371 Subject: Phone Conference 372 Mime-Version: 1.0 373 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 374 Content-Transfer-Encoding: 7bit 376 BEGIN:VCALENDAR 377 PRODID:-//ACME/DesktopCalendar//EN 378 METHOD:REQUEST 379 VERSION:2.0 380 BEGIN:VEVENT 381 ORGANIZER:mailto:sman@netscape.com 382 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com 383 ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.com 384 DTSTAMP:19970611T190000Z 385 DTSTART:19970701T210000Z 386 DTEND:19970701T230000Z 387 SUMMARY:Phone Conference 388 DESCRIPTION:Please review the attached document. 389 UID:calsvr.example.com-873970198738777 390 ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc 391 STATUS:CONFIRMED 392 END:VEVENT 393 END:VCALENDAR 395 4.2 Using Multipart Alternative for Low Fidelity Clients 397 This example shows how a client can emit a multipart message that 398 includes both a plain text version as well as the full iCalendar object. 399 Clients that do not support text/calendar will still be capable of 400 rendering the plain text representation. 402 From: foo1@example.com 403 To: foo2@example.com 404 Subject: Phone Conference 405 Mime-Version: 1.0 406 Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360" 408 --01BD3665.3AF0D360 409 Content-Type: text/plain;charset=us-ascii 410 Content-Transfer-Encoding: 7bit 412 This is an alternative representation of a TEXT/CALENDAR MIME Object 413 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 414 September 15, 1998 416 When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT 417 Where: 418 Organizer: foo1@example.com 419 Summary: Phone Conference 421 --01BD3665.3AF0D360 422 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 423 Content-Transfer-Encoding: 7bit 425 BEGIN:VCALENDAR 426 PRODID:-//ACME/DesktopCalendar//EN 427 METHOD:REQUEST 428 VERSION:2.0 429 BEGIN:VEVENT 430 ORGANIZER:mailto:foo1@example.com 431 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 432 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 433 DTSTAMP:19970611T190000Z 434 DTSTART:19970701T170000Z 435 DTEND:19970701T173000Z 436 SUMMARY:Phone Conference 437 UID:calsvr.example.com-8739701987387771 438 SEQUENCE:0 439 STATUS:CONFIRMED 440 END:VEVENT 441 END:VCALENDAR 443 --01BD3665.3AF0D360 445 4.3 Single Component With An ATTACH Property and Inline Attachment 447 This example shows how a message containing an iCalendar object 448 references an attached document. The reference is made using a Content- 449 id (CID). Thus, the iCalendar object and the document are packaged in a 450 multipart/related encapsulation. 452 From: foo1@example.com 453 To: foo2@example.com 454 Subject: Phone Conference 455 Mime-Version: 1.0 456 Content-Type: multipart/related; boundary="boundary-example-1"; 457 type=text/calendar 459 --boundary-example-1 461 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 462 Content-Transfer-Encoding: 7bit 463 Content-Disposition: attachment; filename="event.vcs" 465 BEGIN:VCALENDAR 466 PRODID:-//ACME/DesktopCalendar//EN 467 METHOD:REQUEST 468 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 469 September 15, 1998 471 VERSION:2.0 472 BEGIN:VEVENT 473 ORGANIZER:mailto:foo1@example.com 474 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 475 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 476 DTSTAMP:19970611T190000Z 477 DTSTART:19970701T180000Z 478 DTEND:19970701T183000Z 479 SUMMARY:Phone Conference 480 UID:calsvr.example.com-8739701987387771 481 ATTACH:cid:123456789@example.com 482 SEQUENCE:0 483 STATUS:CONFIRMED 484 END:VEVENT 485 END:VCALENDAR 487 --boundary-example-1 488 Content-Type: application/msword; name="FieldReport.doc" 489 Content-Transfer-Encoding: base64 490 Content-Disposition: inline; filename="FieldReport.doc" 491 Content-ID: <123456789@example.com> 493 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 494 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// 495 ... 497 --boundary-example-1-- 499 4.4 Multiple Similar Components 501 Multiple iCalendar components of the same type can be included in the 502 iCalendar object when the METHOD is the same for each component. 504 From: foo1@example.com 505 To: foo2@example.com 506 Subject: Summer Company Holidays 507 Mime-Version: 1.0 508 Content-Type:text/calendar; method=PUBLISH; charset=US-ASCII 509 Content-Transfer-Encoding: 7bit 510 Content-Disposition: attachment; filename="event.vcs" 512 BEGIN:VCALENDAR 513 PRODID:-//ACME/DESKTOPCALENDAR//EN 514 METHOD:PUBLISH 515 VERSION:2.0 516 BEGIN:VEVENT 517 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 518 DTSTAMP:19970611T150000Z 519 DTSTART:19970701T150000Z 520 DTEND:19970701T230000Z 521 SUMMARY:Company Picnic 522 DESCRIPTION:Food and drink will be provided 523 UID:CALSVR.EXAMPLE.COM-873970198738777-1 524 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 525 September 15, 1998 527 SEQUENCE:0 528 STATUS:CONFIRMED 529 END:VEVENT 530 BEGIN:VEVENT 531 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 532 DTSTAMP:19970611T190000Z 533 DTSTART:19970715T150000Z 534 DTEND:19970715T230000Z 535 SUMMARY:Company Bowling Tournament 536 DESCRIPTION:We have 10 lanes reserved 537 UID:CALSVR.EXAMPLE.COM-873970198738777-2 538 SEQUENCE:0 539 STATUS:CONFIRMED 540 END:VEVENT 541 END:VCALENDAR 543 4.5 Multiple Mixed Components 545 Different component types must be encapsulated in separate iCalendar 546 objects. 548 From: foo1@example.com 549 To: foo2@example.com 550 Subject: Phone Conference 551 Mime-Version: 1.0 552 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 554 This is a multi-part message in MIME format. 556 ----FEE3790DC7E35189CA67CE2C 557 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 558 Content-Transfer-Encoding: 7bit 559 Content-Disposition: attachment; filename="event1.vcs" 561 BEGIN:VCALENDAR 562 PRODID:-//ACME/DesktopCalendar//EN 563 METHOD:REQUEST 564 VERSION:2.0 565 BEGIN:VEVENT 566 ORGANIZER:mailto:foo1@example.com 567 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 568 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 569 DTSTAMP:19970611T190000Z 570 DTSTART:19970701T210000Z 571 DTEND:19970701T230000Z 572 SUMMARY:Phone Conference 573 DESCRIPTION:Discuss what happened at the last meeting 574 UID:calsvr.example.com-8739701987387772 575 SEQUENCE:0 576 STATUS:CONFIRMED 577 END:VEVENT 578 END:VCALENDAR 579 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 580 September 15, 1998 582 ----FEE3790DC7E35189CA67CE2C 583 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 584 Content-Transfer-Encoding:7bit 585 Content-Disposition: attachment; filename="todo1.vcs" 587 BEGIN:VCALENDAR 588 PRODID:-//ACME/DesktopCalendar//EN 589 METHOD:REQUEST 590 VERSION:2.0 591 BEGIN:VTODO 592 DUE:19970701T090000-0700 593 ORGANIZER:mailto:foo1@example.com 594 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 595 ATTENDEE;RSVP=YES:mailto:foo2@example.com 596 SUMMARY:Phone Conference 597 DESCRIPTION:Discuss a new location for the company picnic 598 UID:calsvr.example.com-td-8739701987387773 599 SEQUENCE:0 600 STATUS:NEEDS ACTION 601 END:VEVENT 602 END:VCALENDAR 604 ----FEE3790DC7E35189CA67CE2C 606 4.6 Detailed Components With An ATTACH Property 608 This example shows the format of a message containing a group meeting 609 between three individuals. The multipart/related encapsulation is used 610 because the iCalendar object contains an ATTACH property that uses a CID 611 to reference the attachment. 613 From: foo1@example.com 614 MIME-Version: 1.0 615 To: foo2@example.com,foo3@example.com 616 Subject: REQUEST - Phone Conference 617 Content-Type:multipart/related;boundary="--FEE3790DC7E35189CA67CE2C" 619 ----FEE3790DC7E35189CA67CE2C 620 Content-Type: multipart/alternative; 621 boundary="--00FEE3790DC7E35189CA67CE2C00" 623 ----00FEE3790DC7E35189CA67CE2C00 624 Content-Type: text/plain; charset=us-ascii 625 Content-Transfer-Encoding: 7bit 627 When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT 628 Where: 629 Organizer: foo1@example.com 630 Summary: Let's discuss the attached document 632 ----00FEE3790DC7E35189CA67CE2C00 634 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII; 635 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 636 September 15, 1998 638 Component=vevent 639 Content-Transfer-Encoding: 7bit 640 Content-Disposition: attachment; filename="event.vcs" 642 BEGIN:VCALENDAR 643 PRODID:-//ACME/DesktopCalendar//EN 644 PROFILE:REQUEST 645 PROFILE-VERSION:1.0 646 VERSION:2.0 647 BEGIN:VEVENT 648 ORGANIZER:foo1@example.com 649 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com 650 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 651 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com 652 DTSTAMP:19970611T190000Z 653 DTSTART:19970621T170000Z 654 DTEND:199706211T173000Z 655 SUMMARY:Let's discuss the attached document 656 UID:calsvr.example.com-873970198738777-8aa 657 ATTACH:cid:calsvr.example.com-12345aaa 658 SEQUENCE:0 659 STATUS:CONFIRMED 660 END:VEVENT 661 END:VCALENDAR 663 ----00FEE3790DC7E35189CA67CE2C00 665 ----FEE3790DC7E35189CA67CE2C 666 Content-Type: application/msword; name="FieldReport.doc" 667 Content-Transfer-Encoding: base64 668 Content-Disposition: inline; filename="FieldReport.doc" 669 Content-ID: 671 R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94XqAG 672 4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH 673 5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J. 674 .. 676 ----FEE3790DC7E35189CA67CE2C 678 5 Recommended Practices 680 This section outlines a series of recommended practices when using a 681 messaging transport to exchange iCalendar objects. 683 5.1 Use of Content and Message IDs 685 The [iCAL] specification makes frequent use of the URI for data types in 686 properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. Two 687 forms of URIs are Message ID (MID) and Content ID (CID). These are 688 defined in [RFC-2111]. Although [RFC-2111] allows referencing messages 689 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 690 September 15, 1998 692 or MIME body parts in other MIME entities or stores, it is strongly 693 recommended that iMIP implementations include all referenced messages 694 and body parts in a single MIME entity. Simply put, if an iCalendar 695 object contains CID or MID references to other messages or body parts, 696 implementations should ensure that these messages and/or body parts are 697 transmitted with the iCalendar object. If they are not there is no 698 guarantee that the receiving "CU" will have the access or the 699 authorization to view those objects. 701 6 Bibliography 703 [CHST] Character Sets, ftp://ftp.isi.edu/in- 704 notes/iana/assignments/character-sets 706 [iCAL] "Internet Calendaring and Scheduling Core Object Specification - 707 iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- 708 drafts/draft-ietf-calsch-ical-07.txt. 710 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 711 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-03.txt. 713 [iTIP] "iCalendar Transport-Independent Interoperability Protocol (iTIP) 714 : Scheduling Events, Busy Time, To-dos and Journal Entries ", Internet- 715 Draft, October 1997, http://www.imc.org/draft-ietf-calsch-itip-04.txt. 717 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 718 Messages", STD 11, RFC-822, August 1982. 720 [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security 721 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC- 722 1847, October 1995. 724 [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 725 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC- 726 2045, November 1996. 728 [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 729 Extensions (MIME) - Part Two: Media Types", RFC-2046, November 1996. 731 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 732 Part Three: Message Header Extensions for Non-ASCII Text", RFC-2047, 733 November 1996. 735 [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet Mail 736 Extensions (MIME) - Part Four: Registration Procedures", RFC-2048, 737 January 1997. 739 [RFC-2111] E. Levinson, "Content-ID and Message-ID Uniform Resource 740 Locators", RFC-2111, March 1997. 742 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 743 September 15, 1998 745 7 Authors Addresses 747 The following address information is provided in a vCard v3.0, 748 Electronic Business Card, format. 750 BEGIN:VCARD 751 VERSION:3.0 752 N:Dawson;Frank 753 FN:Frank Dawson 754 ORG:Lotus Development Corporation 755 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford 756 Drive;Raleigh;NC;27613-3502;USA 757 TEL;WORK;MSG:+1-919-676-9515 758 TEL;WORK;FAX:+1-919-676-9564 759 EMAIL;INTERNET:fdawson@earthlink.net 760 URL:http://home.earthlink.net/~fdawson 761 END:VCARD 763 BEGIN:VCARD 764 VERSION:3.0 765 N:Mansour;Steve 766 FN:Steve Mansour 767 ORG:Netscape Communications Corporation 768 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 769 View;CA;94043;USA 770 TEL;WORK;MSG:+1-650-937-2378 771 TEL;WORK;FAX:+1-650-937-2103 772 EMAIL;INTERNET:sman@netscape.com 773 END:VCARD 775 BEGIN:VCARD 776 VERSION:3.0 777 N:Silverberg;Steve 778 FN:Steve Silverberg 779 ORG:Microsoft Corporation 780 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 781 Redmond;WA;98052-6399;USA 782 TEL;WORK;MSG:+1-425-936-9277 783 TEL;WORK;FAX:+1-425-936-8019 784 EMAIL;INTERNET:stevesil@Microsoft.com 785 END:VCARD 787 The iCalendar Object is a result of the work of the Internet Engineering 788 Task Force Calendaring and scheduling Working Group. The chairmen of 789 that working group are: 791 BEGIN:VCARD 792 VERSION:3.0 793 N:Ganguly;Anik 794 FN:Anik Ganguly 795 ORG:OnTime, Inc. 797 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 798 September 15, 1998 800 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 801 Highway;Southfield;MI;48075;USA 802 TEL;WORK;MSG:+1-810-559-5955 803 TEL;WORK;FAX:+1-810-559-5034 804 EMAIL;INTERNET:anik@ontime.com 805 END:VCARD 807 BEGIN:VCARD 808 VERSION:3.0 809 N:Moskowitz;Robert 810 FN:Robert Moskowitz 811 EMAIL;INTERNET:rgm-ietf@htt-consult.com 812 END:VCARD 814 8 Full Copyright Statement 816 "Copyright (C) The Internet Society (1998). All Rights Reserved. 818 This document and translations of it may be copied and furnished to 819 others, and derivative works that comment on or otherwise explain it or 820 assist in its implementation may be prepared, copied, published and 821 distributed, in whole or in part, without restriction of any kind, 822 provided that the above copyright notice and this paragraph are included 823 on all such copies and derivative works. However, this document itself 824 may not be modified in any way, such as by removing the copyright notice 825 or references to the Internet Society or other Internet organizations, 826 except as needed for the purpose of developing Internet standards in 827 which case the procedures for copyrights defined in the Internet 828 Standards process must be followed, or as required to translate it into 829 languages other than English. 831 The limited permissions granted above are perpetual and will not be 832 revoked by the Internet Society or its successors or assigns. 834 This document and the information contained herein is provided on an "AS 835 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 836 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 837 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 838 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 839 FITNESS FOR A PARTICULAR PURPOSE.