idnits 2.17.1 draft-ietf-calsch-imip-01.txt: -(181): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. == There are 5 instances of lines with non-ascii characters in the document. == 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 3) being 67 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 212: '...iCalendar object MUST be a fully quali...' RFC 2119 keyword, line 214: '...DO". The address MUST be the RFC 822 a...' RFC 2119 keyword, line 218: '..."Reply-to" value MUST be the same as t...' RFC 2119 keyword, line 229: '... Instead, it MUST be derived by open...' RFC 2119 keyword, line 235: '... design document MUST have a Content-T...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 219 looks like a reference -- Missing reference section? 'ICAL' on line 569 looks like a reference -- Missing reference section? 'RFC-822' on line 598 looks like a reference -- Missing reference section? 'RFC-2045' on line 611 looks like a reference -- Missing reference section? 'RFC-2046' on line 615 looks like a reference -- Missing reference section? 'RFC-2047' on line 622 looks like a reference -- Missing reference section? 'RFC-2048' on line 626 looks like a reference -- Missing reference section? 'RFC-2049' on line 37 looks like a reference -- Missing reference section? 'ICMS' on line 573 looks like a reference -- Missing reference section? 'IRIP' on line 79 looks like a reference -- Missing reference section? 'ICSM' on line 164 looks like a reference -- Missing reference section? 'ID-UTF8' on line 594 looks like a reference -- Missing reference section? 'RFC-1847' on line 601 looks like a reference -- Missing reference section? 'RFC-2112' on line 605 looks like a reference -- Missing reference section? 'RFC-2015' on line 608 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 September12, 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 March 1998 54 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 55 September 12, 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 March 1998 112 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 113 September 12, 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 168 Dawson/Mansour/Silverberg 3 Expires March 1998 169 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 170 September 12, 1997 172 a@xyz.com. Furthermore, only the respondent has the authorization to 173 indicate their status to the organizer. That is, spoof@xyz.com should 174 not be able to tell the organizer that b@xyz.com declines a meeting 175 invitation. 177 [Editors note: this does not address issues around a calendar user 178 assigning someone else as a delegate to accept or decline meetings on 179 their behalf. For example, suppose an event invitation is sent to Joe 180 (joe@x.com). Mary (mary@x.com), Joe�s administrative assistant, 181 accepts the meeting on Joe�s behalf. How is this handled in the iTIP 182 realm? Should the "From:" and/or "Reply-To" fields contain joe@x.com 183 or mary@x.com? How is the organizer of the meeting to know that Mary 184 can accept meetings on Joe�s behalf?] 186 Hence, iMIP implementations must verify the authenticity of the 187 sender of an iCalendar object before taking any action. This could be 188 done by utilizing a Multipart/signed implementation of either 189 PGP/MIME or S/MIME. 191 [Editors note: this needs further clarification. How do you do this? 192 The certificate owner must be somehow correlated to the organizer or 193 the respondent. How is this done?] 195 2.2.2 Authentication 197 Authentication can be performed using an implementation of RFC 1847 198 Multipart/signed that supports public/private key certificates. 199 However, since most MUAs provide for the forwarding of messages, the 200 organizer of an event and the sender of the message may be different. 201 Therefore authentication may not be possible. 203 2.2.3 Confidentiality 205 To ensure confidentiality using iMIP implementations should utilize 206 RFC 1847 compliant encryption. The protocol does not restrict a CUA 207 from forwarding Requests or Responses to other users or agents. 209 2.3 RFC 822 Addresses 211 The calendar address specified within the "ATTENDEE" property in an 212 iCalendar object MUST be a fully qualified, RFC 822 address for the 213 corresponding "Owner", "Organizer" or "Attendee" of the "VEVENT" or 214 "VTODO". The address MUST be the RFC 822 address for the calendaring 215 and scheduling mailbox for the attendee. 217 For purposes of authentication and authorization the RFC 822 "Sender" 218 and "Reply-to" value MUST be the same as the address value for the 219 "Organizer". Because [ITIP] does not preclude "Attendees" from 220 forwarding "VEVENTS" or "VTODOS" to others, the RFC-822 "Sender" 221 value may not equal that of the organizer. In these cases, 222 authentication cannot be verified. Additionally, the "Organizer" 223 cannot be inferred by the RFC-822 "Sender" or "Reply-to" values. 225 Dawson/Mansour/Silverberg 4 Expires March 1998 226 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 227 September 12, 1997 229 Instead, it MUST be derived by opening the proper text/calendar MIME 230 body part. 232 2.4 Content Type 234 A MIME body part containing content information that conforms to this 235 design document MUST have a Content-Type value of "text/calendar". 236 The content type header field MUST also include the type parameter 237 "method". The parameter value MUST be one of the message types 238 defined by this method. The value MUST also be the same as the value 239 of the METHOD calendar property within the iCalendar object. This 240 means that if a MIME message containing multiple iCalendar objects 241 with different method values, then they must be further encapsulated 242 with a "multipart/mixed" MIME entity. This will allow each of the 243 iCalendar objects to be encapsulated within their own "text/calendar" 244 MIME entity. 246 The Content-Type CHARSET parameter MUST appear in any MIME entity 247 encapsulating an iCalendar object conforming to this design document. 248 The CHARSET parameter value MUST be "UTF-8" or some other valid 249 character set. The reason for this is that in [iCal] the default 250 character set is UTF-8. 252 The optional Content-Type COMPONENT parameter defines the iCalendar 253 component type contained within the iCalendar object. 255 The following is an example of this header field with a value that 256 indicates an event request message. 258 Content-Type:text/calendar; method=request; charset=UTF-8; 259 component=vevent 261 The "text/calendar" content type allows for the scheduling message 262 type to be included in a MIME message with other content information 263 (i.e., multipart/mixed) or included in a MIME message with a clear- 264 text, human-readable form of the scheduling message (i.e., 265 multipart/alternative). 267 In order to permit the information in the scheduling message to be 268 understood by MIME user agents (UA) that do not support the 269 text/calendar content type, scheduling messages should be sent with 270 an alternative, human-readable form of the information. 272 2.5 Content-Transfer-Encoding 274 Note that the default character set for iCalendar objects is UTF-8 275 and a transfer encoding may be required. 277 Content-Transfer-Encoding:quoted-printable 279 2.6 Content-Description 281 The Content-Description header is optional. 283 Dawson/Mansour/Silverberg 5 Expires March 1998 284 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 285 September 12, 1997 287 Content-Description: iCalendar REQUEST for an event 289 3 Examples 291 In the examples below, the iCalendar object does not specify a 292 character set, it is assumed to be UTF-8. Quoted-printable has been 293 used to keep the message human readable. 295 3.1 Single Component With An ATTACH Property 297 This minimal message shows a how a an iCalendar object references an 298 attachment. The attachment is accessible by anyone via its URL. 300 From: sman@netscape.com 301 To: stevesil@microsoft.com 302 Subject: Phone Conference 303 Mime-Version: 1.0 304 Content-Type:text/calendar; method=REQUEST; charset=UTF-8 305 Content-Transfer-Encoding:quoted-printable 307 BEGIN:VCALENDAR 308 PRODID:-//ACME/DesktopCalendar//EN 309 METHOD:REQUEST 310 VERSION:2.0 311 BEGIN:VEVENT 312 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:sman@netscape.com 313 ATTENDEE;RSVP=YES;EXPECT=REQUEST:stevesil@microsoft.com 314 DTSTAMP:19970611T190000Z 315 DTSTART:19970701T100000-0700 316 DTEND:19970701T103000-0700 317 SUMMARY:Phone Conference 318 DESCRIPTION:Please review the attached document. 319 UID:www.acme.com-873970198738777 320 ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc 321 SEQUENCE:0 322 STATUS:CONFIRMED 323 END:VEVENT 324 END:VCALENDAR 326 3.2 Single Component With An ATTACH Property and Inline Attachment 328 This example shows how a message containing an iCalendar object 329 references an attached document. The reference is made using a 330 Content-id (CID). Thus, the iCalendar object and the document are 331 packaged in a multipart/related encapsulation. 333 From: foo1@bar.net 334 To: foo2@bar.net 335 Subject: Phone Conference 336 Mime-Version: 1.0 337 Content-Type: multipart/related; boundary="boundary-example-1"; 339 Dawson/Mansour/Silverberg 6 Expires March 1998 340 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 341 September 12, 1997 343 type=text/calendar 345 --boundary-example-1 347 Content-Type:text/calendar; method=REQUEST; charset=UTF-8 348 Content-Transfer-Encoding: quoted-printable 349 Content-Disposition: attachment; filename="event.vcs" 351 BEGIN:VCALENDAR 352 PRODID:-//ACME/DesktopCalendar//EN 353 METHOD:REQUEST 354 VERSION:2.0 355 BEGIN:VEVENT 356 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net 357 ATTENDEE;RSVP=YES;EXPECT=REQUEST; 358 TYPE=INDIVIDUAL:foo2@bar.net 359 DTSTAMP:19970611T190000Z 360 DTSTART:19970701T100000-0700 361 DTEND:19970701T103000-0700 362 SUMMARY:Phone Conference 363 UID:www.acme.com-873970198738777 364 ATTACH:cid:www.acme.com-12345aaa 365 SEQUENCE:0 366 STATUS:CONFIRMED 367 END:VEVENT 368 END:VCALENDAR 370 --boundary-example-1 371 Content-Type: application/msword; name="FieldReport.doc" 372 Content-Transfer-Encoding: base64 373 Content-Disposition: inline; filename="FieldReport.doc" 374 Content-ID: 376 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 377 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////e 378 tc... 380 --boundary-example-1-- 382 3.3 Multiple Similar Components 384 Multiple iCalendar components can be included in the iCalendar object 385 when the METHOD is the same for each component. 387 From: foo1@bar.net 388 To: foo2@bar.net 389 Subject: Phone Conference 390 Mime-Version: 1.0 391 Content-Type:text/calendar; method=REQUEST; charset=UTF-8 392 Content-Transfer-Encoding: quoted-printable 393 Content-Disposition: attachment; filename="event.vcs" 395 BEGIN:VCALENDAR 397 Dawson/Mansour/Silverberg 7 Expires March 1998 398 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 399 September 12, 1997 401 PRODID:-//ACME/DesktopCalendar//EN 402 METHOD:REQUEST 403 VERSION:2.0 404 BEGIN:VEVENT 405 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net 406 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:foo2@bar.net 407 DTSTAMP:19970611T190000Z 408 DTSTART:19970701T100000-0700 409 DTEND:19970701T103000-0700 410 SUMMARY:Phone Conference 411 DESCRIPTION:Discuss the contents of the attached document 412 UID:www.acme.com-873970198738777 413 SEQUENCE:0 414 STATUS:CONFIRMED 415 END:VEVENT 416 BEGIN:VEVENT 417 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net 418 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:foo2@bar.net 419 DTSTAMP:19970611T190000Z 420 DTSTART:19970801T100000-0700 421 DTEND:19970801T103000-0700 422 SUMMARY:Follow-up Phone Conference 423 DESCRIPTION:Discuss the contents of the attached document 424 UID:www.acme.com-873970198738777 425 SEQUENCE:0 426 STATUS:CONFIRMED 427 END:VEVENT 428 END:VCALENDAR 430 3.4 Multiple Mixed Components 432 Different component types must be encapsulated in separate iCalendar 433 objects. 435 From: foo1@bar.net 436 To: foo2@bar.net 437 Subject: Phone Conference 438 Mime-Version: 1.0 439 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 441 This is a multi-part message in MIME format. 442 ----FEE3790DC7E35189CA67CE2C 443 Content-Type:text/calendar; method=REQUEST; charset=UTF-8 444 Content-Transfer-Encoding: quoted-printable 445 Content-Disposition: attachment; filename="event.vcs" 447 BEGIN:VCALENDAR 448 PRODID:-//ACME/DesktopCalendar//EN 449 METHOD:REQUEST 450 VERSION:2.0 451 BEGIN:VEVENT 452 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net 454 Dawson/Mansour/Silverberg 8 Expires March 1998 455 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 456 September 12, 1997 458 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:foo2@bar.net 459 DTSTAMP:19970611T190000Z 460 DTSTART:19970701T100000-0700 461 DTEND:19970701T103000-0700 462 SUMMARY:Phone Conference 463 DESCRIPTION:Discuss the contents of the attached document 464 UID:www.acme.com-873970198738777 465 SEQUENCE:0 466 STATUS:CONFIRMED 467 END:VEVENT 468 END:VCALENDAR 470 ----FEE3790DC7E35189CA67CE2C 471 Content-Type:text/calendar; method=REQUEST; charset=UTF-8 472 Content-Transfer-Encoding:8bit 473 Content-Disposition: attachment; filename="event.vcs" 475 BEGIN:VCALENDAR 476 PRODID:-//ACME/DesktopCalendar//EN 477 METHOD:REQUEST 478 VERSION:2.0 479 BEGIN:VTODO 480 DUE:19970701T090000-0700 481 SUMMARY:Phone Conference 482 DESCRIPTION:Discuss the contents of the attached document 483 UID:www.acme.com-td-873970198738777 484 SEQUENCE:0 485 STATUS:CONFIRMED 486 END:VEVENT 487 END:VCALENDAR 489 ----FEE3790DC7E35189CA67CE2C 491 3.5 Detailed Components With An ATTACH Property 493 This example shows the format of a message containing a group meeting 494 between three individuals. The multipart/related encapsulation is 495 used because the iCalendar object contains an ATTACH property that 496 uses a CID to reference the attachment. 498 From: Steve Mansour 499 MIME-Version: 1.0 500 To: Steve Silverberg , 501 Frank Dawson 502 Subject: REQUEST - Phone Conference 503 Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 505 This is a multi-part message in MIME format. 506 ----FEE3790DC7E35189CA67CE2C 507 Content-Type: text/plain; charset=us-ascii 508 Content-Transfer-Encoding: 7bit 510 Event REQUEST 512 Dawson/Mansour/Silverberg 9 Expires March 1998 513 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 514 September 12, 1997 516 Decription: 517 Let�s discuss the attached document 519 Begin: July 1, 1997 10:00 PDT 520 End: July 1, 1997 10:30 PDT 521 ----FEE3790DC7E35189CA67CE2C 522 Content-Type: multipart/related; boundary="boundary-example-2"; 523 type=text/calendar 525 --boundary-example-2 526 Content-Type:text/calendar; method=REQUEST; charset=UTF-8; 527 Component=vevent 528 Content-Transfer-Encoding: quoted-printable 529 Content-Disposition: attachment; filename="event.vcs" 531 BEGIN:VCALENDAR 532 PRODID:-//ACME/DesktopCalendar//EN 533 PROFILE:REQUEST 534 PROFILE-VERSION:1.0 535 VERSION:2.0 536 BEGIN:VEVENT 537 ATTENDEE;ROLE=OWNER;STATUS=ACCEPTED:foo1@bar.net 538 ATTENDEE;RSVP=YES;EXPECT=REQUEST;TYPE=INDIVIDUAL:foo2@bar.net 539 DTSTAMP:19970611T190000Z 540 DTSTART:19970701T100000-0700 541 DTEND:19970701T103000-0700 542 SUMMARY:Let�s discuss the attached document 543 UID:www.acme.com-873970198738777 544 ATTACH:cid:www.acme.com-12345aaa 545 SEQUENCE:0 546 STATUS:CONFIRMED 547 END:VEVENT 548 END:VCALENDAR 550 --boundary-example-2 551 Content-Type: application/msword; name="FieldReport.doc" 552 Content-Transfer-Encoding: base64 553 Content-Disposition: inline; filename="FieldReport.doc" 554 Content-ID: 556 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 557 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////e 558 tc... 560 --boundary-example-2-- 561 ----FEE3790DC7E35189CA67CE2C-- 563 Dawson/Mansour/Silverberg 10 Expires March 1998 564 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 565 September 12, 1997 567 4 Bibliography 569 [ICAL] "Internet Calendaring and Scheduling Core Object Specification 570 - iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- 571 drafts/draft-ietf-calsch-ical-02.txt. 573 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, 574 July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod- 575 00.txt. 577 [iTIP] This currently includes the following three documents that are 578 being merged into a single iTIP document. 580 1. "iCalendar Transport-Independent Interoperability Protocol 581 (iTIP) - Part 1: Scheduling Events and Busytime", Internet- 582 Draft, July 1997, http://www.imc.org/draft-ietf-calsch-itip- 583 part1-00.txt. 585 2. "iCalendar Transport-Independent Interoperability Protocol 586 (iTIP) - Part 2: Scheduling To-dos", Internet-Draft, July 1997, 587 http://www.imc.org/draft-ietf-calsch-itip-part2-00.txt 589 3. "iCalendar Transport-Independent Interoperability Protocol 590 (iTIP) - Part 3: Scheduling Journal Entries", Internet-Draft, 591 July 1997, http://www.imc.org/draft-ietf-calsch-itip-part3- 592 00.txt 594 [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", 595 Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft- 596 yergeau-utf8-01.txt. 598 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 599 Messages", STD 11, RFC 822, August 1982. 601 [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security 602 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 603 1847, October 1995. 605 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," 606 RFC 2112, March 1997. 608 [RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)," 609 RFC 2015, October 1996. 611 [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 612 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 613 2045, November 1996. 615 [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 616 Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. 618 Dawson/Mansour/Silverberg 11 Expires March 1998 619 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 620 September 12, 1997 622 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 623 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 624 November 1996. 626 [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet 627 Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 628 2048, January 1997. 630 5 Author's Address 632 The following address information is provided in a vCard v2.1, 633 Electronic Business Card, format. 635 BEGIN:VCARD 636 FN:Frank Dawson 637 ORG:Lotus Development Corporation 638 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- 639 3502;USA 640 TEL;WORK;MSG:+1-919-676-9515 641 TEL;WORK;FAX:+1-919-676-9564 642 EMAIL;INTERNET:fdawson@earthlink.net 643 URL:http://home.earthlink.net/~fdawson 644 END:VCARD 646 BEGIN:VCARD 647 FN:Steve Mansour 648 ORG:Netscape Communications Corporation 649 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 650 View;CA;94043;USA 651 TEL;WORK;MSG:+1-415-937-2378 652 TEL;WORK;FAX:+1-415-428-4059 653 EMAIL;INTERNET:sman@netscape.com 654 END:VCARD 656 BEGIN:VCARD 657 FN:Steve Silverberg 658 ORG:Microsoft Corporation 659 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 660 Redmond;WA;98052-6399;USA 661 TEL;WORK;MSG:+1-206-936-9277 662 TEL;WORK;FAX:+1-206-936-8019 663 EMAIL;INTERNET:stevesil@Exchange.Microsoft.com 664 END:VCARD 666 The iCalendar Object is a result of the work of the Internet 667 Engineering Task Force Calendaring and scheduling Working Group. The 668 chairman of that working group is: 670 BEGIN:VCARD 671 FN:Anik Ganguly 672 ORG:OnTime, Inc. 673 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 674 Highway;Southfield;MI;48075;USA 676 Dawson/Mansour/Silverberg 12 Expires March 1998 677 Internet DraftiCalendar Message-based Interoperability Protocol (iMIP) 678 September 12, 1997 680 TEL;WORK;MSG:+1-810-559-5955 681 TEL;WORK;FAX:+1-810-559-5034 682 EMAIL;INTERNET:anik@ontime.com 683 END:VCARD 685 Dawson/Mansour/Silverberg 13 Expires March 1998