idnits 2.17.1 draft-ietf-calsch-imip-03.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 13 longer pages, the longest (page 1) being 63 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. RFC 2119 keyword, line 199: '...iCalendar object MUST be a fully quali...' RFC 2119 keyword, line 201: '..."Attendee" of the "VEVENT" or "VTODO". The address MUST be the [RFC-822] address for the calendaring and scheduling mailbox for the...' RFC 2119 keyword, line 209: '... [RFC-822] "Sender" or "Reply-to" values. Instead, it MUST be derived...' RFC 2119 keyword, line 215: '... design document MUST have a Content-T...' RFC 2119 keyword, line 216: '...ype header field MUST also include the...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: included on all such copies and derivative works. However, this document itself MAY NOT be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. -- The 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 (November 21, 1997) is 9643 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 600 looks like a reference -- Missing reference section? 'ICAL' on line 592 looks like a reference -- Missing reference section? 'RFC-822' on line 605 looks like a reference -- Missing reference section? 'RFC-2045' on line 612 looks like a reference -- Missing reference section? 'RFC-2046' on line 616 looks like a reference -- Missing reference section? 'RFC-2047' on line 619 looks like a reference -- Missing reference section? 'RFC-2048' on line 623 looks like a reference -- Missing reference section? 'RFC-2049' on line 37 looks like a reference -- Missing reference section? 'ICMS' on line 596 looks like a reference -- Missing reference section? 'IRIP' on line 79 looks like a reference -- Missing reference section? 'RFC-1847' on line 608 looks like a reference -- Missing reference section? 'ICSM' on line 164 looks like a reference -- Missing reference section? 'RFC1847' on line 309 looks like a reference -- Missing reference section? 'CHST' on line 589 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 17 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 November 21, 1997 7 iCalendar Message-Based Interoperability Protocol 8 (iMIP) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 andits working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced, or made obsolete by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Distribution of this document is unlimited. 31 Abstract 33 This document specifies a binding from the iCalendar Transport- 34 independent Interoperability Protocol [ITIP] to Internet email-based 35 transports. Calendaring entries defined by the iCalendar Object Model 36 [ICAL] are composed using constructs from [RFC-822], [RFC-2045], 37 [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049]. 39 This document is based on the calendaring and scheduling model 40 defined by [ICMS]. 42 This document is based on discussions within the Internet Engineering 43 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 44 More information about the IETF CALSCH working group activities can 45 be found on the IMC website at http://www.imc.org, the IETF website 46 at http://www.ietf.org/html.charters/calsch-charter.html. Refer to 47 the references within this document for further information on how to 48 access these various documents. 50 Distribution of this document is unlimited. Comments and suggestions 51 for improvement should be sent to the authors. 53 Dawson/Mansour/Silverberg 1 Expires May 1998 54 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 55 November 21, 1997 57 1 Introduction 59 This binding document provides the transport specific information 60 necessary convey iCalendar Transport-independent Interoperability 61 Protocol [ITIP] over MIME as defined in [RFC-822] and [RFC-2045]. 63 1.1 Related Memos 65 Implementors will need to be familar with several other memos that, 66 along with this memo, form a framework for Internet calendaring and 67 scheduling standards. 69 This document - specifies an Internet email binding for [ITIP]. 71 [ICMS] - specifies a common terminology and abstract; 73 [ICAL] - specifies a core specification of objects, data types, 74 properties and property parameters; 76 [ITIP] - specifies an interoperability protocol for scheduling 77 between different implementations; 79 [IRIP] - specifies an Internet real time protocol binding for [ITIP]. 81 This memo does not attempt to repeat the specification of concepts or 82 definitions from these other memos. Where possible, references are 83 made to the memo that provides for the specification of these 84 concepts or definitions. 86 1.2 Formatting Conventions 88 The mechanisms defined in this memo are defined in propose. In order 89 to refer to elements of the calendaring and scheduling model, core 90 object or interoperability protocol defined in [ICMS], [ICAL] and 91 [ITIP] some formatting conventions have been used. 93 Calendaring and scheduling roles defined by [ICMS] are referred to in 94 quoted-strings of text with the first character of each word in upper 95 case. For example, "Organizer" refers to a role of a "Calendar User" 96 within the scheduling protocol defined by [ITIP] 98 Calendar components defined by [ICAL] are referred to with 99 capitalized, quoted-strings of text. All calendar components start 100 with the letter "V". For example, "VEVENT" refers to the event 101 calendar component, "VTODO" refers to the to-do calendar component 102 and "VJOURNAL" refers to the daily journal calendar component. 104 Scheduling methods defined by [ITIP] are referred to with 105 capitalized, quoted-strings of text. For example, "REQUEST" refers to 106 the method for requesting a scheduling calendar component be created 107 or modified, "REPLY" refers to the method a recipient of a request 108 uses to update their status with the "Organizer" of the calendar 109 component. 111 Dawson/Mansour/Silverberg 2 Expires May 1998 112 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 113 November 21, 1997 115 Properties defined by [ICAL] are referred to with capitalized, 116 quoted-strings of text, followed by the word "property". For example, 117 "ATTENDEE" property refers to the iCalendar property used to convey 118 the calendar address of a calendar user. 120 Property parameters defined by [ICAL] are referred to with lower 121 case, quoted-strings of text, followed by the word "parameter". For 122 example, "value" parameter refers to the iCalendar property parameter 123 used to override the default data type for a property value. 125 1.3 Terminology 127 The email terms used in this memo are defined in [RFC-822] and [RFC- 128 2045]. The calendaring and scheduling terms used in this memo are 129 defined in [ICMS], [ICAL] and [ITIP] 131 2 MIME Message Format Binding 133 This section defines the message binding to the MIME electronic mail 134 transport. 136 The sections below refer to the "originator" and the "respondent" of 137 an iMIP message. Typically, the originator is the owner or oganizer 138 of an event. The respondent is an attendee of the event. 140 In a well-organized email message the Reply-To header contains the 141 email address of the originator or respondent of an event. However, 142 this cannot be guaranteed as Mail User Agents (MUA) are not required 143 to enforce iMIP semantics. 145 2.1 MIME Media Type 147 A MIME entity containing content information formatted according to 148 this design document will be referenced as a "text/calendar" content 149 type. It is assumed that this content type will be transported 150 through a MIME electronic mail transport. 152 2.2 Security 154 This section addresses several aspects of security including 155 Authentication, Authorization and Confidentiality. Authentication and 156 confidentiality can be achieved using [RFC-1847] which specifies the 157 Security Multiparts for MIME. This framework defines new content 158 types and subtypes of multipart: signed and encrypted. Each contains 159 two body parts: one for the protected data and another for the 160 control information necessary to remove the protection. 162 2.2.1 Authorization 164 Per the [ICSM], only the organizer has authorization to modify or 165 cancel calendar entries they organize. That is, spoof@xyz.com should 166 not be able to modify or cancel a meeting that was organized by 167 a@xyz.com. Furthermore, only the respondent has the authorization to 168 indicate their status to the organizer. That is, spoof@xyz.com should 170 Dawson/Mansour/Silverberg 3 Expires May 1998 171 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 172 November 21, 1997 174 not be able to tell the organizer that b@xyz.com declines a meeting 175 invitation. 177 Hence, iMIP implementations must verify the authenticity of the 178 sender of an iCalendar object before taking any action. This could be 179 done by utilizing a Multipart/signed implementation of either 180 PGP/MIME or S/MIME. 182 2.2.2 Authentication 184 Authentication can be performed using an implementation of [RFC-1847] 185 Multipart/signed that supports public/private key certificates. 186 However, since most MUAs provide for the forwarding of messages, the 187 organizer of an event and the sender of the message may be different. 188 Therefore authentication may not be possible. 190 2.2.3 Confidentiality 192 To ensure confidentiality using iMIP implementations should utilize 193 [RFC-1847] compliant encryption. The protocol does not restrict a CUA 194 from forwarding Requests or Responses to other users or agents. 196 2.3 RFC-822 Addresses 198 The calendar address specified within the "ATTENDEE" property in an 199 iCalendar object MUST be a fully qualified, RFC-822 address 200 specification for the corresponding "Owner", "Organizer" or 201 "Attendee" of the "VEVENT" or "VTODO". The address MUST be the [RFC- 202 822] address for the calendaring and scheduling mailbox for the 203 attendee. 205 Because [ITIP] does not preclude "Attendees" from forwarding 206 "VEVENTS" or "VTODOS" to others, the [RFC-822] "Sender" value may not 207 equal that of the organizer. In these cases, authentication cannot be 208 verified. Additionally, the "Organizer" cannot be inferred by the 209 [RFC-822] "Sender" or "Reply-to" values. Instead, it MUST be derived 210 by opening the proper text/calendar MIME body part. 212 2.4 Content Type 214 A MIME body part containing content information that conforms to this 215 design document MUST have a Content-Type value of "text/calendar". 216 The content type header field MUST also include the type parameter 217 "method". The parameter value MUST be one of the message types 218 defined by this method. The value MUST also be the same as the value 219 of the METHOD calendar property within the iCalendar object. This 220 means that if a MIME message containing multiple iCalendar objects 221 with different method values, then they must be further encapsulated 222 with a "multipart/mixed" MIME entity. This will allow each of the 223 iCalendar objects to be encapsulated within their own "text/calendar" 224 MIME entity. 226 A CHARSET parameter MUST be present when the "text/calendar" is used. 227 RFC-2046 discusses the selection of an appropriate CHARSET value. 229 Dawson/Mansour/Silverberg 4 Expires May 1998 230 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 231 November 21, 1997 233 The optional Content-Type COMPONENT parameter defines the iCalendar 234 component type contained within the iCalendar object. 236 The following is an example of this header field with a value that 237 indicates an event message. 239 Content-Type:text/calendar; method=request; charset=UTF-8; 240 component=vevent 242 The "text/calendar" content type allows for the scheduling message 243 type to be included in a MIME message with other content information 244 (i.e., multipart/mixed) or included in a MIME message with a clear- 245 text, human-readable form of the scheduling message (i.e., 246 multipart/alternative). 248 In order to permit the information in the scheduling message to be 249 understood by MIME user agents (UA) that do not support the 250 text/calendar content type, scheduling messages should be sent with 251 an alternative, human-readable form of the information. 253 2.5 Content-Transfer-Encoding 255 Note that the default character set for iCalendar objects is UTF-8. A 256 transfer encoding SHOULD be used for iCalendar objects containing any 257 characters that are not part of the US-ASCII character set. 259 Content-Transfer-Encoding:quoted-printable 261 3 Security Considerations 263 [ITIP] details the security threats that applications must address 264 when implementing ITIP. Two spoofing threats are identified: 265 Spoofing the "Organizer", and Spoofing an "Attendee". To address 266 these threats, the originator of an iCalendar object must be 267 authenticated by a recipient. Once authenticated, a determination 268 can be made as to whether or not the originator is authorized to 269 perform the requested operation. Applications requiring protection 270 from this type of threat SHOULD sign text/calendar attachments using 271 a mechanism based on Security Multiparts for MIME [RFC1847] to 272 facilitate the authentication the originator of the iCalendar object. 273 The steps are described below: 275 1. The iCalendar object must be signed by the "Organizer" sending an 276 update or the "Attendee" sending a reply. 278 2. Using the RFC1847-compliant security mechanism, determine who 279 signed the iCalendar object. This is the "signer". Note that the 280 signer is not necessarily the person sending an e-mail message. An 281 e-mail message can be forwarded. 283 3. Correlate the "signer" to an "ATTENDEE" property in the iCalendar 284 object. If the signer cannot be correlated to an "ATTENDEE" 285 property, ignore the message. 287 Dawson/Mansour/Silverberg 5 Expires May 1998 288 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 289 November 21, 1997 291 4. Determine whether or not the "ATTENDEE" is authorized to perform 292 the operation. ITIP states: 294 (a) the "Organizer" is the only person authorized to make changes 295 to an existing "VEVENT", "VTODO", "VJOURNAL" calendar component 296 and redistribute the updates to the "Attendees" 298 (b) an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL" calendar 299 component is the only person authorized to update any parameter 300 associated with their "ATTENDEE" property and send it to the 301 "Organizer" 303 If these conditions are not met, ignore the message. 305 5. If all the above conditions are met, the message can be processed. 307 To address the confidentiality security threats, IMIP messages MAY be 308 encrypted by a mechanism based on Security Multiparts for MIME 309 [RFC1847]. 311 4 Examples 313 4.1 Single Component With An ATTACH Property 315 This minimal message shows a how a an iCalendar object references an 316 attachment. The attachment is accessible by anyone via its URL. 318 From: sman@netscape.com 319 To: stevesil@microsoft.com 320 Subject: Phone Conference 321 Mime-Version: 1.0 322 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 323 Content-Transfer-Encoding: 7bit 325 BEGIN:VCALENDAR 326 PRODID:-//ACME/DesktopCalendar//EN 327 METHOD:REQUEST 328 VERSION:2.0 329 BEGIN:VEVENT 330 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:MAILTO: 331 MAILTO:sman@netscape.com 332 ATTENDEE;RSVP=YES;EXPECT=REQUEST:MAILTO: 333 MAILTO:stevesil@microsoft.com 334 DTSTAMP:19970611T190000Z 335 DTSTART:19970701T100000-0700 336 DTEND:19970701T103000-0700 337 SUMMARY:Phone Conference 338 DESCRIPTION:Please review the attached document. 339 UID:www.acme.com-873970198738777 340 ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc 341 SEQUENCE:0 342 STATUS:CONFIRMED 343 END:VEVENT 344 END:VCALENDAR 346 Dawson/Mansour/Silverberg 6 Expires May 1998 347 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 348 November 21, 1997 350 4.2 Single Component With An ATTACH Property and Inline Attachment 352 This example shows how a message containing an iCalendar object 353 references an attached document. The reference is made using a 354 Content-id (CID). Thus, the iCalendar object and the document are 355 packaged in a multipart/related encapsulation. 357 From: foo1@bar.net 358 To: foo2@bar.net 359 Subject: Phone Conference 360 Mime-Version: 1.0 361 Content-Type: multipart/related; boundary="boundary-example-1"; 362 type=text/calendar 364 --boundary-example-1 366 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 367 Content-Transfer-Encoding: quoted-printable 368 Content-Disposition: attachment; filename="event.vcs" 370 BEGIN:VCALENDAR 371 PRODID:-//ACME/DesktopCalendar//EN 372 METHOD:REQUEST 373 VERSION:2.0 374 BEGIN:VEVENT 375 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:MAILTO:foo1@bar.net 376 ATTENDEE;RSVP=YES;EXPECT=REQUEST; 377 TYPE=INDIVIDUAL:MAILTO:foo2@bar.net 378 DTSTAMP:19970611T190000Z 379 DTSTART:19970701T100000-0700 380 DTEND:19970701T103000-0700 381 SUMMARY:Phone Conference 382 UID:www.acme.com-8739701987387771 383 ATTACH:cid:123456789@example.com 384 SEQUENCE:0 385 STATUS:CONFIRMED 386 END:VEVENT 387 END:VCALENDAR 389 --boundary-example-1 390 Content-Type: application/msword; name="FieldReport.doc" 391 Content-Transfer-Encoding: base64 392 Content-Disposition: inline; filename="FieldReport.doc" 393 Content-ID: <123456789@example.com> 395 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 396 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////e 397 tc... 399 --boundary-example-1-- 401 Dawson/Mansour/Silverberg 7 Expires May 1998 402 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 403 November 21, 1997 405 4.3 Multiple Similar Components 407 Multiple iCalendar components can be included in the iCalendar object 408 when the METHOD is the same for each component. 410 From: foo1@bar.net 411 To: foo2@bar.net 412 Subject: Phone Conference 413 Mime-Version: 1.0 414 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 415 Content-Transfer-Encoding: quoted-printable 416 Content-Disposition: attachment; filename="event.vcs" 418 BEGIN:VCALENDAR 419 PRODID:-//ACME/DesktopCalendar//EN 420 METHOD:REQUEST 421 VERSION:2.0 422 BEGIN:VEVENT 423 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:MAILTO:foo1@bar.net 424 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:MAILTO:foo2@bar.net 425 DTSTAMP:19970611T190000Z 426 DTSTART:19970701T100000-0700 427 DTEND:19970701T103000-0700 428 SUMMARY:Phone Conference 429 DESCRIPTION:Discuss the contents of the attached document 430 UID:www.acme.com-873970198738777 431 SEQUENCE:0 432 STATUS:CONFIRMED 433 END:VEVENT 434 BEGIN:VEVENT 435 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:MAILTO:foo1@bar.net 436 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:MAILTO:foo2@bar.net 437 DTSTAMP:19970611T190000Z 438 DTSTART:19970801T100000-0700 439 DTEND:19970801T103000-0700 440 SUMMARY:Follow-up Phone Conference 441 DESCRIPTION:Discuss the contents of the attached document 442 UID:www.acme.com-873970198738777 443 SEQUENCE:0 444 STATUS:CONFIRMED 445 END:VEVENT 446 END:VCALENDAR 448 4.4 Multiple Mixed Components 450 Different component types must be encapsulated in separate iCalendar 451 objects. 453 From: foo1@bar.net 454 To: foo2@bar.net 455 Subject: Phone Conference 456 Mime-Version: 1.0 457 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 459 Dawson/Mansour/Silverberg 8 Expires May 1998 460 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 461 November 21, 1997 463 This is a multi-part message in MIME format. 464 ----FEE3790DC7E35189CA67CE2C 465 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 466 Content-Transfer-Encoding: quoted-printable 467 Content-Disposition: attachment; filename="event1.vcs" 469 BEGIN:VCALENDAR 470 PRODID:-//ACME/DesktopCalendar//EN 471 METHOD:REQUEST 472 VERSION:2.0 473 BEGIN:VEVENT 474 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:MAILTO:foo1@bar.net 475 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:MAILTO:foo2@bar.net 476 DTSTAMP:19970611T190000Z 477 DTSTART:19970701T100000-0700 478 DTEND:19970701T103000-0700 479 SUMMARY:Phone Conference 480 DESCRIPTION:Discuss what happened at the last meeting 481 UID:www.acme.com-8739701987387772 482 SEQUENCE:0 483 STATUS:CONFIRMED 484 END:VEVENT 485 END:VCALENDAR 487 ----FEE3790DC7E35189CA67CE2C 488 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 489 Content-Transfer-Encoding:8bit 490 Content-Disposition: attachment; filename="event2.vcs" 492 BEGIN:VCALENDAR 493 PRODID:-//ACME/DesktopCalendar//EN 494 METHOD:REQUEST 495 VERSION:2.0 496 BEGIN:VTODO 497 DUE:19970701T090000-0700 498 SUMMARY:Phone Conference 499 DESCRIPTION:Discuss where to have the company picnic 500 UID:www.acme.com-td-8739701987387773 501 SEQUENCE:0 502 STATUS:CONFIRMED 503 END:VEVENT 504 END:VCALENDAR 506 ----FEE3790DC7E35189CA67CE2C 508 4.5 Detailed Components With An ATTACH Property 510 This example shows the format of a message containing a group meeting 511 between three individuals. The multipart/related encapsulation is 512 used because the iCalendar object contains an ATTACH property that 513 uses a CID to reference the attachment. 515 From: foo1@example.com 517 Dawson/Mansour/Silverberg 9 Expires May 1998 518 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 519 November 21, 1997 521 MIME-Version: 1.0 522 To: foo2@example.com,foo3@example.com 523 Subject: REQUEST - Phone Conference 524 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 526 This is a multi-part message in MIME format. 527 ----FEE3790DC7E35189CA67CE2C 528 Content-Type: text/plain; charset=us-ascii 529 Content-Transfer-Encoding: 7bit 531 Event REQUEST 533 Decription: 534 Let's discuss the attached document 536 Begin: July 1, 1997 10:00 PDT 537 End: July 1, 1997 10:30 PDT 538 ----FEE3790DC7E35189CA67CE2C 539 Content-Type: multipart/related; boundary="boundary-example-2"; 540 type=text/calendar 542 --boundary-example-2 543 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII; 544 Component=vevent 545 Content-Transfer-Encoding: quoted-printable 546 Content-Disposition: attachment; filename="event.vcs" 548 BEGIN:VCALENDAR 549 PRODID:-//ACME/DesktopCalendar//EN 550 PROFILE:REQUEST 551 PROFILE-VERSION:1.0 552 VERSION:2.0 553 BEGIN:VEVENT 554 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:MAILTO:foo1@example.com 555 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL: 556 MAILTO:foo2@example.com 557 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL: 558 MAILTO:foo3@example.com 559 DTSTAMP:19970611T190000Z 560 DTSTART:19970701T100000-0700 561 DTEND:19970701T103000-0700 562 SUMMARY:Let's discuss the attached document 563 UID:www.acme.com-873970198738777 564 ATTACH:cid:www.acme.com-12345aaa 565 SEQUENCE:0 566 STATUS:CONFIRMED 567 END:VEVENT 568 END:VCALENDAR 570 --boundary-example-2 571 Content-Type: application/msword; name="FieldReport.doc" 572 Content-Transfer-Encoding: base64 573 Content-Disposition: inline; filename="FieldReport.doc" 574 Content-ID: 576 Dawson/Mansour/Silverberg 10 Expires May 1998 577 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 578 November 21, 1997 580 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 581 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////e 582 tc... 584 --boundary-example-2-- 585 ----FEE3790DC7E35189CA67CE2C-- 587 5 Bibliography 589 [CHST] Character Sets, ftp://ftp.isi.edu/in- 590 notes/iana/assignments/character-sets 592 [ICAL] "Internet Calendaring and Scheduling Core Object Specification 593 - iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- 594 drafts/draft-ietf-calsch-ical-04.txt. 596 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, 597 July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod- 598 02.txt. 600 [ITIP] "iCalendar Transport-Independent Interoperability Protocol 601 (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", 602 Internet-Draft, October 1997, http://www.imc.org/draft-ietf-calsch- 603 itip-01.txt. 605 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 606 Text Messages", STD 11, RFC-822, August 1982. 608 [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security 609 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC- 610 1847, October 1995. 612 [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 613 Extensions (MIME) - Part One: Format of Internet Message Bodies", 614 RFC-2045, November 1996. 616 [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 617 Extensions (MIME) - Part Two: Media Types", RFC-2046, November 1996. 619 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 620 Part Three: Message Header Extensions for Non-ASCII Text", RFC-2047, 621 November 1996. 623 [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet 624 Mail Extensions (MIME) - Part Four: Registration Procedures", RFC- 625 2048, January 1997. 627 6 Author's Address 629 The following address information is provided in a vCard v2.1, 630 Electronic Business Card, format. 632 Dawson/Mansour/Silverberg 11 Expires May 1998 633 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 634 November 21, 1997 636 BEGIN:VCARD 637 FN:Frank Dawson 638 ORG:Lotus Development Corporation 639 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- 640 3502;USA 641 TEL;WORK;MSG:+1-919-676-9515 642 TEL;WORK;FAX:+1-919-676-9564 643 EMAIL;INTERNET:fdawson@earthlink.net 644 URL:http://home.earthlink.net/~fdawson 645 END:VCARD 647 BEGIN:VCARD 648 FN:Steve Mansour 649 ORG:Netscape Communications Corporation 650 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 651 View;CA;94043;USA 652 TEL;WORK;MSG:+1-415-937-2378 653 TEL;WORK;FAX:+1-415-428-4059 654 EMAIL;INTERNET:sman@netscape.com 655 END:VCARD 657 BEGIN:VCARD 658 FN:Steve Silverberg 659 ORG:Microsoft Corporation 660 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 661 Redmond;WA;98052-6399;USA 662 TEL;WORK;MSG:+1-206-936-9277 663 TEL;WORK;FAX:+1-206-936-8019 664 EMAIL;INTERNET:stevesil@Exchange.Microsoft.com 665 END:VCARD 667 The iCalendar Object is a result of the work of the Internet 668 Engineering Task Force Calendaring and scheduling Working Group. The 669 chairman of that working group is: 671 BEGIN:VCARD 672 FN:Anik Ganguly 673 ORG:OnTime, Inc. 674 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 675 Highway;Southfield;MI;48075;USA 676 TEL;WORK;MSG:+1-810-559-5955 677 TEL;WORK;FAX:+1-810-559-5034 678 EMAIL;INTERNET:anik@ontime.com 679 END:VCARD 681 7 Full Copyright Statement 683 "Copyright (C) The Internet Society (date). All Rights Reserved. 685 This document and translations of it MAY be copied and furnished to 686 others, and derivative works that comment on or otherwise explain it 687 or assist in its implmentation MAY be prepared, copied, published and 688 distributed, in whole or in part, without restriction of any kind, 689 provided that the above copyright notice and this paragraph are 691 Dawson/Mansour/Silverberg 12 Expires May 1998 692 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 693 November 21, 1997 695 included on all such copies and derivative works. However, this 696 document itself MAY NOT be modified in any way, such as by removing 697 the copyright notice or references to the Internet Society or other 698 Internet organizations, except as needed for the purpose of 699 developing Internet standards in which case the procedures for 700 copyrights defined in the Internet Standards process MUST be 701 followed, or as required to translate it into languages other than 702 English. 704 The limited permissions granted above are perpetual and will not be 705 revoked by the Internet Society or its successors or assigns. 707 This document and the information contained herein is provided on an 708 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 709 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 710 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 711 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 712 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 714 Dawson/Mansour/Silverberg 13 Expires May 1998