idnits 2.17.1 draft-ietf-calsify-rfc2447bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 835. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 842. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 848. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages -- Found 22 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2006) is 6522 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-2047' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'RFC-2048' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC-2049' is defined on line 764, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 1652 (ref. '8BITMIME') (Obsoleted by RFC 6152) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Document: draft-ietf-calsify-rfc2447bis-02.txt A. Melnikov 3 Intended category: Standard Track Editor 4 Expires: December 2006 June 2006 6 iCalendar Message-Based Interoperability Protocol 7 (iMIP) 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 A revised version of this draft document will be submitted to the RFC 33 editor as a Draft Standard for the Internet Community. Discussion 34 and suggestions for improvement are requested, and should be sent to 35 the CALSIFY Mailing list . 36 Distribution of this document is unlimited. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document, iCalendar Message-Based Interoperability Protocol 45 (iMIP), specifies a binding from the iCalendar Transport-independent 46 Interoperability Protocol (iTIP) to Internet email-based transports. 47 Calendaring entries defined by the iCalendar Object Model (iCAL) are 48 composed using constructs from RFC 2822, RFC 2045, RFC 2046, 50 RFC 2447bis iMIP March 2006 52 RFC 2047, RFC 2048 and RFC 2049. 54 This document is a product of Calendaring and Scheduling Standards 55 Simplification (calsify) working group. More information about the 56 IETF CALSIFY working group activities can be found on the IETF web 57 site at . 59 RFC 2447bis iMIP March 2006 61 Table of Contents 63 1 INTRODUCTION........................................................2 64 1.1 RELATED MEMOS ...................................................2 65 1.2 FORMATTING CONVENTIONS ..........................................3 66 1.3 TERMINOLOGY .....................................................4 67 2 MIME MESSAGE FORMAT BINDING.........................................4 68 2.1 MIME MEDIA TYPE .................................................4 69 2.2 SECURITY ........................................................4 70 2.2.1 Authorization ...............................................4 71 2.2.2 Authentication ..............................................5 72 2.2.3 Confidentiality .............................................5 73 2.3 [RFC-2822] ADDRESSES ............................................5 74 2.4 CONTENT TYPE ....................................................5 75 2.5 CONTENT-TRANSFER-ENCODING .......................................6 76 2.6 CONTENT-DISPOSITION .............................................6 77 3 SECURITY CONSIDERATIONS.............................................7 78 4 EXAMPLES............................................................8 79 4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8 80 4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8 81 4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9 82 4.4 MULTIPLE SIMILAR COMPONENTS ....................................10 83 4.5 MULTIPLE MIXED COMPONENTS ......................................11 84 4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY ....................13 85 5 RECOMMENDED PRACTICES..............................................14 86 5.1 USE OF CONTENT AND MESSAGE IDS .................................14 87 6 REFERENCES.........................................................15 88 7 EDITOR'S ADDRESSES.................................................16 89 8 FULL COPYRIGHT STATEMENT...........................................XX 90 9 INTELLECTUAL PROPERTY..............................................XX 91 1 Introduction 93 This binding document provides the transport specific information 94 necessary to convey iCalendar Transport-independent Interoperability 95 Protocol (iTIP) over MIME as defined in [RFC-2822] and [RFC-2045]. 97 1.1 Related Memos 99 Implementers will need to be familiar with several other memos that, 100 along with this memo, form a framework for Internet calendaring and 101 scheduling standards. 103 This document, [iMIP], specifies an Internet email binding for iTIP. 105 [iCAL] - specifies a core specification of objects, data types, 106 properties and property parameters; 108 RFC 2447bis iMIP March 2006 110 [iTIP] - specifies an interoperability protocol for scheduling 111 between different implementations; 113 This memo does not attempt to repeat the specification of concepts or 114 definitions from these other memos. Where possible, references are 115 made to the memo that provides for the specification of these 116 concepts or definitions. 118 1.2 Formatting Conventions 120 The mechanisms defined in this memo are defined in prose. In order to 121 refer to elements of the calendaring and scheduling model, core 122 object or interoperability protocol defined in [iCAL] and [iTIP] some 123 formatting conventions have been used. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC-2119]. 129 Calendaring and scheduling roles are referred to in quoted-strings of 130 text with the first character of each word in upper case. For 131 example, "Organizer" refers to a role of a "Calendar User" within the 132 scheduling protocol defined by [iTIP]. 134 Calendar components defined by [iCAL] are referred to with 135 capitalized, quoted-strings of text. All calendar components start 136 with the letter "V". For example, "VEVENT" refers to the event 137 calendar component, "VTODO" refers to the to-do calendar component 138 and "VJOURNAL" refers to the daily journal calendar component. 140 Scheduling methods defined by [iTIP] are referred to with 141 capitalized, quoted-strings of text. For example, "REQUEST" refers to 142 the method for requesting a scheduling calendar component be created 143 or modified, "REPLY" refers to the method a recipient of a request 144 uses to update their status with the "Organizer" of the calendar 145 component. 147 Properties defined by [iCAL] are referred to with capitalized, 148 quoted-strings of text, followed by the word "property". For example, 149 "ATTENDEE" property refers to the iCalendar property used to convey 150 the calendar address of a calendar user. 152 Property parameters defined by [iCAL] are referred to with lower 153 case, quoted-strings of text, followed by the word "parameter". For 154 example, "value" parameter refers to the iCalendar property parameter 155 used to override the default data type for a property value. 157 RFC 2447bis iMIP March 2006 159 1.3 Terminology 161 The email terms used in this memo are defined in [RFC-2822] and 162 [RFC-2045]. The calendaring and scheduling terms used in this memo 163 are defined in [iCAL] and [iTIP]. 165 2 MIME Message Format Binding 167 This section defines the message binding to the MIME electronic mail 168 transport. 170 The sections below refer to the "originator" and the "respondent" of 171 an iMIP message. Typically, the originator is the "Organizer" of an 172 event. The respondent is an "Attendee" of the event. 174 The [RFC-2822] "Reply-To" header typically contains the email address 175 of the originator or respondent of an event. However, this cannot be 176 guaranteed as Mail User Agents (MUA) are not required to enforce iMIP 177 semantics. 179 2.1 MIME Media Type 181 A MIME entity containing content information formatted according to 182 this document will be referenced as a "text/calendar" content type. 183 It is assumed that this content type will be transported through a 184 MIME electronic mail transport. 186 2.2 Security 188 This section addresses several aspects of security including 189 Authentication, Authorization and Confidentiality. Authentication and 190 confidentiality can be achieved using [RFC-1847] that specifies the 191 Security Multiparts for MIME. This framework defines new content 192 types and subtypes of multipart: signed and encrypted. Each contains 193 two body parts: one for the protected data and another for the 194 control information necessary to remove the protection. 196 2.2.1 Authorization 198 In [iTIP] messages, only the "Organizer" is authorized to modify or 199 cancel calendar entries they organize. That is, spoof@xyz.example.net 200 is not allowed to modify or cancel a meeting that was organized by 201 a@example.com. Furthermore, only the respondent has the authorization 202 to indicate their status to the "Organizer". That is, the "Organizer" 203 must ignore an [iTIP] message from spoof@xyz.example.net that 204 declines a meeting invitation for b@example.com. 206 RFC 2447bis iMIP March 2006 208 Implementations of iMIP SHOULD verify the authenticity of the creator 209 of an iCalendar object before taking any action. The methods for 210 doing this are presented later in this document. 212 [RFC-1847] Message flow in iTIP supports someone working on behalf of 213 a "Calendar User" through use of the "sent-by" parameter that is 214 associated with the "ATTENDEE" and "ORGANIZER" properties. However, 215 there is no mechanism to verify whether or not a "Calendar User" has 216 authorized someone to work on their behalf. It is left to 217 implementations to provide mechanisms for the "Calendar Users" to 218 make that decision. 220 2.2.2 Authentication 222 Authentication can be performed using an implementation of [RFC-1847] 223 "multipart/signed" that supports public/private key certificates. 224 Authentication is possible only on messages that have been signed. 225 Authenticating an unsigned message may not be reliable. 227 2.2.3 Confidentiality 229 To ensure confidentiality using iMIP implementations should utilize 230 encryption compliant with [RFC-1847]. The protocol does not restrict 231 a "Calendar User Agent" (CUA) from forwarding iCalendar objects to 232 other users or agents. 234 2.3 [RFC-2822] Addresses 236 The calendar address specified within the "ATTENDEE" property in an 237 iCalendar object MUST be a fully qualified, [RFC-2822] address 238 specification for the corresponding "Organizer" or "Attendee" of the 239 "VEVENT" or "VTODO". 241 Because [iTIP] does not preclude "Attendees" from forwarding 242 "VEVENTS" or "VTODOS" to others, the [RFC-2822] "Sender" value may 243 not equal that of the "Organizer". Additionally, the "Organizer" or 244 "Attendee" cannot be reliably inferred by the [RFC-2822] "Sender" or 245 "Reply-to" values of an iMIP message. The relevant address MUST be 246 ascertained by opening the "text/calendar" MIME body part and 247 examining the "ATTENDEE" and "ORGANIZER" properties. 249 2.4 Content Type 251 A MIME body part containing content information that conforms to this 252 document MUST have an [RFC-2045] "Content-Type" value of 253 "text/calendar". The [RFC-2045] "Content-Type" header field MUST also 254 include the type parameter "method". The value MUST be the same as 255 the value of the "METHOD" calendar property within the iCalendar 257 RFC 2447bis iMIP March 2006 259 object. This means that a MIME message containing multiple iCalendar 260 objects with different method values must be further encapsulated 261 with a "multipart/mixed" MIME entity. This will allow each of the 262 iCalendar objects to be encapsulated within their own "text/calendar" 263 MIME entity. 265 Note that according to [iCAL] the default character set for iCalendar 266 objects is UTF-8 [UTF-8]. However the default character set for a 267 "text/*" MIME entity [RFC-2046] is US-ASCII. Thus a "charset" 268 parameter MUST be present if the iCalendar object contains characters 269 that are not part of the US-ASCII character set. [RFC-2046] discusses 270 the selection of an appropriate "charset" value. 272 The optional "component" parameter defines the iCalendar component 273 type contained within the iCalendar object. 275 The following is an example of this header field with a value that 276 indicates an event message. 278 Content-Type: text/calendar; method=request; charset=UTF-8; 279 component=vevent 281 The "text/calendar" content type allows for the scheduling message 282 type to be included in a MIME message with other content information 283 (i.e., "multipart/mixed") or included in a MIME message with a clear- 284 text, human-readable form of the scheduling message (i.e., 285 "multipart/alternative"). 287 In order to permit the information in the scheduling message to be 288 understood by MIME user agents (UA) that do not support the 289 "text/calendar" content type, scheduling messages SHOULD be sent with 290 an alternative, human-readable form of the information. 292 Note that "multiple/alternative" MUST NOT be used to represent two 293 slightly different iCalendar objects, for example two VEVENT with 294 alternative starting times. 296 <> 300 Any receiving UA compliant with this specification MUST be able to 301 process "text/calendar" body parts enclosed within "multipart/*". 302 Note that a "multipart/mixed" MIME message can include multiple 303 "text/calendar" components. The receiving UA MUST be able to process 304 all of them. 306 2.5 Content-Transfer-Encoding 308 RFC 2447bis iMIP March 2006 310 Unless iMIP message is transported over 8-bit clean transport (such 311 as SMTP [8BITMIME]), a transfer encoding such as quoted-printable or 312 base64 [RFC-2045] MUST be used for iCalendar objects containing any 313 characters that are not part of the US-ASCII character set. 315 <> 317 2.6 Content-Disposition 319 Implementations MAY include a "Content-Disposition" header field to 320 define a file name for an iCalendar object. However, the handling of 321 a MIME part MUST be based on its [RFC-2045] "Content-Type" and not on 322 the extension specified in the "Content-Disposition", as different 323 email malware is known to trick User Agents into misinterpreting 324 content of messages by specifying a file extension in the Content- 325 Disposition header field that doesn't correspond to the value of 326 Content-Type header field. 328 RFC 2447bis iMIP March 2006 330 3 Security Considerations 332 The security threats that applications must address when implementing 333 iTIP are detailed in [iTIP]. Two spoofing threats are identified: 334 Spoofing the "Organizer", and Spoofing an "Attendee". To address 335 these threats, the originator of an iCalendar object must be 336 authenticated by a recipient. Once authenticated, a determination can 337 be made as to whether or not the originator is authorized to perform 338 the requested operation. Compliant applications MUST support signing 339 and encrypting text/calendar attachments using a mechanism based on 340 Security Multiparts for MIME [RFC-1847] to facilitate the 341 authentication the originator of the iCalendar object. 342 Implementations MAY provide a means for users to disable signing and 343 encrypting. The steps are described below: 345 1. The iCalendar object MUST be signed by the "Organizer" sending an 346 update or the "Attendee" sending a reply. 348 2. Using the compliant security mechanism with [RFC-1847], determine 349 who signed the iCalendar object. This is the "signer". Note that the 350 signer is not necessarily the person sending an e-mail message since 351 an e-mail message can be forwarded. 353 3. Correlate the signer to an "ATTENDEE" property in the iCalendar 354 object. If the signer cannot be correlated to an "ATTENDEE" property, 355 ignore the message. 357 4. Determine whether or not the "ATTENDEE" is authorized to perform 358 the operation as defined by [iTIP]. If the conditions are not met, 359 ignore the message. 361 5. If all the above conditions are met, the message can be processed. 363 To address the confidentiality security threats, signed iMIP messages 364 SHOULD be encrypted by a mechanism based on Security Multiparts for 365 MIME [RFC-1847]. 367 It is possible to receive iMIP messages sent by someone working on 368 behalf of another "Calendar User". This is determined by examining 369 the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" 370 property. [iCAL] and [iTIP] provide no mechanism to verify that a 371 "Calendar User" has authorized someone else to work on their behalf. 372 To address this security issue, <>. 377 A security consideration associated with use of Content-Disposition 379 RFC 2447bis iMIP March 2006 381 header field is described in section 2.6. 383 RFC 2447bis iMIP March 2006 385 4 Examples 387 4.1 Single Component With An ATTACH Property 389 This minimal message shows how an iCalendar object references an 390 attachment. The attachment is accessible via its URL. 392 From: sman@netscape.example.com 393 To: stevesil@microsoft.example.com 394 Subject: Phone Conference 395 Mime-Version: 1.0 396 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 397 Content-Transfer-Encoding: 7bit 399 BEGIN:VCALENDAR 400 PRODID:-//ACME/DesktopCalendar//EN 401 METHOD:REQUEST 402 VERSION:2.0 403 BEGIN:VEVENT 404 ORGANIZER:mailto:sman@netscape.example.com 405 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.example.com 406 ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com 407 DTSTAMP:19970611T190000Z 408 DTSTART:19970701T210000Z 409 DTEND:19970701T230000Z 410 SUMMARY:Phone Conference 411 DESCRIPTION:Please review the attached document. 412 UID:calsvr.example.com-873970198738777 413 ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc 414 STATUS:CONFIRMED 415 END:VEVENT 416 END:VCALENDAR 418 4.2 Using Multipart Alternative for Low Fidelity Clients 420 This example shows how a client can emit a multipart message that 421 includes both a plain text version as well as the full iCalendar 422 object. Clients that do not support text/calendar will still be 423 capable of rendering the plain text representation. 425 From: foo1@example.com 426 To: foo2@example.com 427 Subject: Phone Conference 428 Mime-Version: 1.0 429 Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360" 431 --01BD3665.3AF0D360 432 Content-Type: text/plain;charset=us-ascii 434 RFC 2447bis iMIP March 2006 436 Content-Transfer-Encoding: 7bit 438 This is an alternative representation of a TEXT/CALENDAR MIME Object 439 When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT 440 Where: 441 Organizer: foo1@example.com 442 Summary: Phone Conference 444 --01BD3665.3AF0D360 445 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 446 Content-Transfer-Encoding: 7bit 448 BEGIN:VCALENDAR 449 PRODID:-//ACME/DesktopCalendar//EN 450 METHOD:REQUEST 451 VERSION:2.0 452 BEGIN:VEVENT 453 ORGANIZER:mailto:foo1@example.com 454 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 455 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 456 DTSTAMP:19970611T190000Z 457 DTSTART:19970701T170000Z 458 DTEND:19970701T173000Z 459 SUMMARY:Phone Conference 460 UID:calsvr.example.com-8739701987387771 461 SEQUENCE:0 462 STATUS:CONFIRMED 463 END:VEVENT 464 END:VCALENDAR 466 --01BD3665.3AF0D360 468 4.3 Single Component With An ATTACH Property and Inline Attachment 470 This example shows how a message containing an iCalendar object 471 references an attached document. The reference is made using a 472 Content-id (CID). Thus, the iCalendar object and the document are 473 packaged in a multipart/related encapsulation. 475 From: foo1@example.com 476 To: foo2@example.com 477 Subject: Phone Conference 478 Mime-Version: 1.0 479 Content-Type: multipart/related; boundary="boundary-example-1" 481 --boundary-example-1 483 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 485 RFC 2447bis iMIP March 2006 487 Content-Transfer-Encoding: 7bit 488 Content-Disposition: attachment; filename="event.vcs" 490 BEGIN:VCALENDAR 491 PRODID:-//ACME/DesktopCalendar//EN 492 METHOD:REQUEST 493 VERSION:2.0 494 BEGIN:VEVENT 495 ORGANIZER:mailto:foo1@example.com 496 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 497 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 498 DTSTAMP:19970611T190000Z 499 DTSTART:19970701T180000Z 500 DTEND:19970701T183000Z 501 SUMMARY:Phone Conference 502 UID:calsvr.example.com-8739701987387771 503 ATTACH:cid:123456789@example.com 504 SEQUENCE:0 505 STATUS:CONFIRMED 506 END:VEVENT 507 END:VCALENDAR 509 --boundary-example-1 510 Content-Type: application/msword; name="FieldReport.doc" 511 Content-Transfer-Encoding: base64 512 Content-Disposition: attachment; filename="FieldReport.doc" 513 Content-ID: <123456789@example.com> 515 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 516 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// 517 ... 519 --boundary-example-1-- 521 4.4 Multiple Similar Components 523 Multiple iCalendar components of the same type can be included in the 524 iCalendar object when the METHOD is the same for each component. 526 From: foo1@example.com 527 To: foo2@example.com 528 Subject: Summer Company Holidays 529 Mime-Version: 1.0 530 Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII 531 Content-Transfer-Encoding: 7bit 532 Content-Disposition: attachment; filename="event.vcs" 534 RFC 2447bis iMIP March 2006 536 BEGIN:VCALENDAR 537 PRODID:-//ACME/DESKTOPCALENDAR//EN 538 METHOD:PUBLISH 539 VERSION:2.0 540 BEGIN:VEVENT 541 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 542 DTSTAMP:19970611T150000Z 543 DTSTART:19970701T150000Z 544 DTEND:19970701T230000Z 545 SUMMARY:Company Picnic 546 DESCRIPTION:Food and drink will be provided 547 UID:CALSVR.EXAMPLE.COM-873970198738777-1 548 SEQUENCE:0 549 STATUS:CONFIRMED 550 END:VEVENT 551 BEGIN:VEVENT 552 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 553 DTSTAMP:19970611T190000Z 554 DTSTART:19970715T150000Z 555 DTEND:19970715T230000Z 556 SUMMARY:Company Bowling Tournament 557 DESCRIPTION:We have 10 lanes reserved 558 UID:CALSVR.EXAMPLE.COM-873970198738777-2 559 SEQUENCE:0 560 STATUS:CONFIRMED 561 END:VEVENT 562 END:VCALENDAR 564 4.5 Multiple Mixed Components 566 Different component types must be encapsulated in separate iCalendar 567 objects. 569 From: foo1@example.com 570 To: foo2@example.com 571 Subject: Phone Conference 572 Mime-Version: 1.0 573 Content-Type: multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 575 This is a multi-part message in MIME format. 577 ----FEE3790DC7E35189CA67CE2C 578 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 579 Content-Transfer-Encoding: 7bit 580 Content-Disposition: attachment; filename="event1.vcs" 582 RFC 2447bis iMIP March 2006 584 BEGIN:VCALENDAR 585 PRODID:-//ACME/DesktopCalendar//EN 586 METHOD:REQUEST 587 VERSION:2.0 588 BEGIN:VEVENT 589 ORGANIZER:mailto:foo1@example.com 590 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 591 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 592 DTSTAMP:19970611T190000Z 593 DTSTART:19970701T210000Z 594 DTEND:19970701T230000Z 595 SUMMARY:Phone Conference 596 DESCRIPTION:Discuss what happened at the last meeting 597 UID:calsvr.example.com-8739701987387772 598 SEQUENCE:0 599 STATUS:CONFIRMED 600 END:VEVENT 601 END:VCALENDAR 603 ----FEE3790DC7E35189CA67CE2C 604 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 605 Content-Transfer-Encoding: 7bit 606 Content-Disposition: attachment; filename="todo1.vcs" 608 BEGIN:VCALENDAR 609 PRODID:-//ACME/DesktopCalendar//EN 610 METHOD:REQUEST 611 VERSION:2.0 612 BEGIN:VTODO 613 DUE:19970701T090000-0700 614 ORGANIZER:mailto:foo1@example.com 615 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com 616 ATTENDEE;RSVP=YES:mailto:foo2@example.com 617 SUMMARY:Phone Conference 618 DESCRIPTION:Discuss a new location for the company picnic 619 UID:calsvr.example.com-td-8739701987387773 620 SEQUENCE:0 621 STATUS:NEEDS ACTION 622 END:VEVENT 623 END:VCALENDAR 625 ----FEE3790DC7E35189CA67CE2C 627 RFC 2447bis iMIP March 2006 629 4.6 Detailed Components With An ATTACH Property 631 This example shows the format of a message containing a group meeting 632 between three individuals. The multipart/related encapsulation is 633 used because the iCalendar object contains an ATTACH property that 634 uses a CID to reference the attachment. 636 From: foo1@example.com 637 MIME-Version: 1.0 638 To: foo2@example.com,foo3@example.com 639 Subject: REQUEST - Phone Conference 640 Content-Type: multipart/related;boundary="--FEE3790DC7E35189CA67CE2C" 642 ----FEE3790DC7E35189CA67CE2C 643 Content-Type: multipart/alternative; 644 boundary="--00FEE3790DC7E35189CA67CE2C00" 646 ----00FEE3790DC7E35189CA67CE2C00 647 Content-Type: text/plain; charset=us-ascii 648 Content-Transfer-Encoding: 7bit 650 When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT 651 Where: 652 Organizer: foo1@example.com 653 Summary: Let's discuss the attached document 655 ----00FEE3790DC7E35189CA67CE2C00 657 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII; 658 Component=vevent 659 Content-Transfer-Encoding: 7bit 660 Content-Disposition: attachment; filename="event.vcs" 662 BEGIN:VCALENDAR 663 PRODID:-//ACME/DesktopCalendar//EN 664 PROFILE:REQUEST 665 PROFILE-VERSION:1.0 666 VERSION:2.0 667 BEGIN:VEVENT 668 ORGANIZER:foo1@example.com 669 ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com 670 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com 671 ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com 672 DTSTAMP:19970611T190000Z 673 DTSTART:19970621T170000Z 674 DTEND:199706211T173000Z 675 SUMMARY:Let's discuss the attached document 676 UID:calsvr.example.com-873970198738777-8aa 678 RFC 2447bis iMIP March 2006 680 ATTACH:cid:calsvr.example.com-12345aaa 681 SEQUENCE:0 682 STATUS:CONFIRMED 683 END:VEVENT 684 END:VCALENDAR 686 ----00FEE3790DC7E35189CA67CE2C00 688 ----FEE3790DC7E35189CA67CE2C 689 Content-Type: application/msword; name="FieldReport.doc" 690 Content-Transfer-Encoding: base64 691 Content-Disposition: attachment; filename="FieldReport.doc" 692 Content-ID: 694 R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq 695 AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd 696 riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i 697 ZnJY6J 698 ... 700 ----FEE3790DC7E35189CA67CE2C 702 5 Recommended Practices 704 This section outlines a series of recommended practices when using a 705 messaging transport to exchange iCalendar objects. 707 5.1 Use of Content and Message IDs 709 The [iCAL] specification makes frequent use of the URI for data types 710 in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. 711 Two forms of URIs are Message ID (MID) and Content ID (CID). These 712 are defined in [RFC-2392]. Although [RFC-2392] allows referencing 713 messages or MIME body parts in other MIME entities or stores, it is 714 strongly recommended that iMIP implementations include all referenced 715 messages and body parts in a single MIME entity. Simply put, if an 716 iCalendar object contains CID or MID references to other messages or 717 body parts, implementations should ensure that these messages and/or 718 body parts are transmitted with the iCalendar object. If they are not 719 there is no guarantee that the receiving CUA will have the access or 720 the authorization to view those objects. 722 RFC 2447bis iMIP March 2006 724 6 IANA Considerations 726 Registration of text/calendar MIME Media Type is done in [iCal]. 728 This document doesn't require any additional actions from IANA. 730 7 References 732 7.1 Normative References 734 [iCAL] Desruisseaux, B., (Ed.), "Internet Calendaring and 735 Scheduling Core Object Specification (iCalendar)", work in progress, 736 draft-ietf-calsify-rfc2445bis-XX.txt (Updated RFC 2445) 738 [iTIP] Daboo, C., "iCalendar Transport-Independent 739 Interoperability Protocol (iTIP)", work in progress, draft-ietf- 740 calsify-2446bis-XX.txt (Updates RFC 2446) 742 [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April 743 2001. 745 [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, 746 "Security Multiparts for MIME: Multipart/Signed and 747 Multipart/Encrypted", RFC 1847, October 1995. 749 [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 750 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 751 2045, November 1996. 753 [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 754 Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. 756 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 757 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 758 November 1996. 760 [RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 761 Internet Mail Extensions (MIME) - Part Four: Registration 762 Procedures", RFC 2048, January 1997. 764 [RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 765 Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 766 2049, November 1996. 768 [RFC-2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 769 Locators", RFC 2392, August 1998. 771 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 773 RFC 2447bis iMIP March 2006 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 778 STD 63, RFC 3629, November 2003. 780 7.2 Informative References 782 [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 783 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, 784 July 1994. 786 RFC 2447bis iMIP March 2006 788 8 Editor's Addresses 790 The following address information is provided in a vCard v3.0, 791 Electronic Business Card, format. 793 BEGIN:VCARD 794 VERSION:3.0 795 N:Melnikov;Alexey 796 FN:Alexey Melnikov 797 ORG:Isode Ltd. 798 ADR;TYPE=WORK,POSTAL,PARCEL:;;5 Castle Business Village, 799 36 Station Road;Hampton;Middlesex;TW12 2BX;UK 800 EMAIL;TYPE=INTERNET:Alexey.Melnikov@isode.com 801 END:VCARD 803 RFC 2447bis iMIP March 2006 805 9. Full Copyright Statement 807 Copyright (C) The Internet Society (2006). 809 This document is subject to the rights, licenses and restrictions 810 contained in BCP 78, and except as set forth therein, the authors 811 retain all their rights. 813 This document and the information contained herein are provided on an 814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 816 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 817 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 818 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 821 Acknowledgement 823 Funding for the RFC Editor function is currently provided by the 824 Internet Society. 826 10. Intellectual Property 828 The IETF takes no position regarding the validity or scope of any 829 Intellectual Property Rights or other rights that might be claimed to 830 pertain to the implementation or use of the technology described in 831 this document or the extent to which any license under such rights 832 might or might not be available; nor does it represent that it has 833 made any independent effort to identify any such rights. Information 834 on the procedures with respect to rights in RFC documents can be 835 found in BCP 78 and BCP 79. 837 Copies of IPR disclosures made to the IETF Secretariat and any 838 assurances of licenses to be made available, or the result of an 839 attempt made to obtain a general license or permission for the use of 840 such proprietary rights by implementers or users of this 841 specification can be obtained from the IETF on-line IPR repository at 842 http://www.ietf.org/ipr. 844 The IETF invites any interested party to bring to its attention any 845 copyrights, patents or patent applications, or other proprietary 846 rights that may cover technology that may be required to implement 847 this standard. Please address the information to the IETF at ietf- 848 ipr@ietf.org. 850 Appendix A. Changes since RFC 2447. 852 RFC 2447bis iMIP March 2006 854 Updated references. Split them into Normative and Informative. 856 Updated examples to use example.com/example.net domains. 858 Corrected usage of RFC 2119 language. 860 Clarified that charset=UTF-8 is required, unless the calendar can be 861 entirely represented in US-ASCII. 863 Clarified that 7-bit content transfer encodings should be used unless 864 the calendar object is known to be transferred over 8-bit clean 865 transport. 867 Clarified that file extension specified in the Content-Disposition 868 header field is not to be used to override the Content-Type MIME 869 type. 871 Disallow use of "multiple/alternative" for slightly different 872 representations of the same calendar. 874 <>