idnits 2.17.1 draft-ietf-calsify-rfc2447bis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2010) is 4970 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) ** Obsolete normative reference: RFC 2368 (ref. 'MAILTO') (Obsoleted by RFC 6068) ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 1652 (ref. '8BITMIME') (Obsoleted by RFC 6152) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Melnikov 3 Document: draft-ietf-calsify-rfc2447bis-11.txt Editor 4 Intended status: Standard Track September 10, 2010 5 Expires: March 2011 7 iCalendar Message-Based Interoperability Protocol 8 (iMIP) 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet 26 Engineering Task Force (IETF), its areas, and its 27 working groups. Note that other groups may also distribute 28 working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of 31 six months and may be updated, replaced, or obsoleted by 32 other documents at any time. It is inappropriate to use 33 Internet-Drafts as reference material or to cite them other 34 than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 A revised version of this draft document will be submitted to the RFC 43 editor as a Draft Standard for the Internet Community. Discussion 44 and suggestions for improvement are requested, and should be sent to 45 the CALSIFY Mailing list . 46 Distribution of this document is unlimited. 48 Copyright Notice 49 RFC 2447bis iMIP September 2010 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Abstract 66 This document, iCalendar Message-Based Interoperability Protocol 67 (iMIP), specifies a binding from the iCalendar Transport-independent 68 Interoperability Protocol (iTIP) to Internet email-based transports. 69 Calendaring entries defined by the iCalendar Object Model (iCalendar) 70 are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 71 2046, RFC 2047 and RFC 2049), and then transported over SMTP. 73 RFC 2447bis iMIP September 2010 75 Table of Contents 77 1 INTRODUCTION........................................................2 78 1.1 RELATED MEMOS ...................................................2 79 1.2 FORMATTING CONVENTIONS ..........................................3 80 1.3 TERMINOLOGY .....................................................4 81 2 MIME MESSAGE FORMAT BINDING.........................................4 82 2.1 MIME MEDIA TYPE .................................................4 83 2.2 SECURITY ........................................................4 84 2.2.1 Authorization ...............................................4 85 2.2.2 Authentication ..............................................5 86 2.2.3 Confidentiality .............................................5 87 2.3 EMAIL ADDRESSES .................................................5 88 2.4 CONTENT TYPE ....................................................5 89 2.5 CONTENT-TRANSFER-ENCODING .......................................6 90 2.6 CONTENT-DISPOSITION .............................................6 91 3 SECURITY CONSIDERATIONS.............................................7 92 4 EXAMPLES............................................................8 93 4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8 94 4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8 95 4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9 96 4.4 MULTIPLE SIMILAR COMPONENTS ....................................10 97 4.5 MULTIPLE MIXED COMPONENTS ......................................11 98 4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY ....................13 99 5 RECOMMENDED PRACTICES..............................................14 100 5.1 USE OF CONTENT AND MESSAGE IDS .................................14 101 6 REFERENCES.........................................................15 102 7 EDITOR'S ADDRESSES.................................................16 103 8 FULL COPYRIGHT STATEMENT...........................................XX 104 9 INTELLECTUAL PROPERTY..............................................XX 106 1 Introduction 108 This binding document provides the transport specific information 109 necessary to convey iCalendar Transport-independent Interoperability 110 Protocol (iTIP) [iTIP] over Internet email (using MIME) as defined in 111 [RFC-5322] and [RFC-2045]. 113 1.1 Related Memos 115 Implementers will need to be familiar with several other memos that, 116 along with this memo, form a framework for Internet calendaring and 117 scheduling standards. 119 This document, [iMIP], specifies an Internet email binding for iTIP. 121 [iCAL] - specifies a core specification of objects, data types, 122 properties and property parameters; 124 RFC 2447bis iMIP September 2010 126 [iTIP] - specifies an interoperability protocol for scheduling 127 between different implementations; 129 This memo does not attempt to repeat the specification of concepts or 130 definitions from these other memos. Where possible, references are 131 made to the memo that provides for the specification of these 132 concepts or definitions. 134 1.2 Formatting Conventions 136 The mechanisms defined in this memo are defined in prose. In order to 137 refer to elements of the calendaring and scheduling model, core 138 object or interoperability protocol defined in [iCAL] and [iTIP] some 139 formatting conventions have been used. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC-2119]. 145 Calendaring and scheduling roles are referred to in quoted-strings of 146 text with the first character of each word in upper case. For 147 example, "Organizer" refers to a role of a "Calendar User" within the 148 scheduling protocol defined by [iTIP]. 150 Calendar components defined by [iCAL] are referred to with 151 capitalized, quoted-strings of text. All calendar components start 152 with the letter "V". For example, "VEVENT" refers to the event 153 calendar component, "VTODO" refers to the to-do calendar component 154 and "VJOURNAL" refers to the daily journal calendar component. 156 Scheduling methods defined by [iTIP] are referred to with 157 capitalized, quoted-strings of text. For example, "REQUEST" refers to 158 the method for requesting a scheduling calendar component be created 159 or modified, "REPLY" refers to the method a recipient of a request 160 uses to update their status with the "Organizer" of the calendar 161 component. 163 Properties defined by [iCAL] are referred to with capitalized, 164 quoted-strings of text, followed by the word "property". For example, 165 "ATTENDEE" property refers to the iCalendar property used to convey 166 the calendar address of a calendar user. 168 Property parameters defined by [iCAL] are referred to with lower 169 case, quoted-strings of text, followed by the word "parameter". For 170 example, "value" parameter refers to the iCalendar property parameter 171 used to override the default data type for a property value. 173 RFC 2447bis iMIP September 2010 175 1.3 Terminology 177 The email terms used in this memo are defined in [RFC-5322] and 178 [RFC-2045]. The calendaring and scheduling terms used in this memo 179 are defined in [iCAL] and [iTIP]. 181 2 MIME Message Format Binding 183 This section defines the message binding to the MIME electronic mail 184 transport. 186 The sections below refer to the "originator" and the "recipient" of 187 an iMIP message. In the case of a "request" method, the originator is 188 the "Organizer" and the recipient is an "Attendee" of the event. In 189 the case of a "response" method, the originator is an "Attendee" and 190 the recipient is the "Organizer" of the event. 192 The [RFC-5322] "Reply-To" header field typically contains the email 193 address of the originator of the scheduling message. However, this 194 cannot be guaranteed because the sender of the iMIP message might not 195 be the originator of the scheduling message and the sender's Mail 196 User Agent (MUA) might not enforce iMIP semantics by translating the 197 originator's address into the "Reply-To" email header field. 199 2.1 MIME Media Type 201 A MIME entity containing content information formatted according to 202 this document will be referenced as a "text/calendar" content type 203 [iCAL]. It is assumed that this content type will be transported 204 through a MIME electronic mail transport. 206 2.2 Security 208 This section addresses several aspects of security including 209 authentication, authorization and confidentiality. Authentication and 210 confidentiality can be achieved using S/MIME [RFC-5750][RFC-5751], 211 which uses Security Multiparts framework for MIME [RFC-1847]. 213 2.2.1 Authorization 215 In [iTIP] messages, only the "Organizer" is authorized to modify or 216 cancel calendar entries she organizes. That is, spoof@xyz.example.net 217 is not allowed to modify or cancel a meeting that was organized by 218 a@example.com. Furthermore, only the respondent has the authorization 219 to indicate their status to the "Organizer". That is, the "Organizer" 220 MUST ignore an [iTIP] message from spoof@xyz.example.net that 221 declines a meeting invitation for b@example.com. 223 RFC 2447bis iMIP September 2010 225 Implementations of iMIP SHOULD verify the authenticity of the creator 226 of an iCalendar object before taking any action. Methods for doing 227 this are presented later in this document. 229 [RFC-1847] Message flow in iTIP supports someone working on behalf of 230 a "Calendar User" through use of the "sent-by" parameter that is 231 associated with the "ATTENDEE" and "ORGANIZER" properties. However, 232 there is no mechanism to verify whether or not a "Calendar User" has 233 authorized someone to work on their behalf. It is left to 234 implementations to provide mechanisms for the "Calendar Users" to 235 make that decision. 237 2.2.2 Authentication 239 Authentication MUST be performed using S/MIME [RFC-5750][RFC-5751]. 240 Authentication is possible only on messages that have been signed. 241 Unauthenticated messages (i.e., unsigned messages) may not be 242 trusted. 244 2.2.3 Confidentiality 246 To ensure confidentiality using iMIP implementations SHOULD utilize 247 encryption specified in S/MIME [RFC-5750][RFC-5751]. iMIP does not 248 restrict a "Calendar User Agent" (CUA) from forwarding iCalendar 249 objects to other users or agents. 251 2.3 Email Addresses 253 The calendar address specified within the "ORGANIZER" and "ATTENDEE" 254 properties in an iCalendar object send using iMIP MUST be a proper 255 "mailto:" [MAILTO] URI specification for the corresponding 256 "Organizer" or "Attendee" of the "VEVENT" or "VTODO". 258 Because [iTIP] does not preclude "Attendees" from forwarding 259 "VEVENTS" or "VTODOS" to others, the [RFC-5322] "Sender" value may 260 not equal that of the "Organizer". Additionally, the "Organizer" or 261 "Attendee" cannot be reliably inferred by the [RFC-5322] "Sender" or 262 "Reply-to" header field values of an iMIP message. The relevant 263 address MUST be ascertained by opening the "text/calendar" MIME body 264 part and examining the "ATTENDEE" and "ORGANIZER" properties. 266 2.4 Content-Type Header Field 268 A MIME body part containing content information that conforms to this 269 document MUST have an [RFC-2045] "Content-Type" value of 270 "text/calendar". The [RFC-2045] "Content-Type" header field MUST also 271 include the type MIME parameter "method". The value MUST be the same 272 (ignoring case) as the value of the "METHOD" property within the 274 RFC 2447bis iMIP September 2010 276 iCalendar object. 278 Note 1: A MIME message containing multiple iCalendar objects with 279 different method values MUST be further encapsulated with a 280 "multipart/mixed" MIME entity [RFC-2046]. This will allow each of the 281 iCalendar objects to be encapsulated within their own "text/calendar" 282 MIME entity. 284 Note 2: A MIME body part of "text/calendar" "Content-Type" that lacks 285 the "method" parameter is not considered to be an iMIP body part and 286 thus is not subject to the requirements specified in this document. 288 Note that according to [iCAL] the default character set for iCalendar 289 objects is UTF-8 [UTF-8]. However the default character set for a 290 "text/*" MIME entity according to [RFC-2046] is US-ASCII. Thus a 291 "charset" MIME parameter MUST be present if the iCalendar object 292 contains characters that can't be represented in US-ASCII character 293 set and, as specified in [iCAL], it MUST have the value "UTF-8". 295 The optional "component" MIME parameter defines the iCalendar 296 component type contained within the iCalendar object. 298 The following is an example of this header field with a value that 299 indicates an event message. 301 Content-Type: text/calendar; method=request; charset=UTF-8; 302 component=vevent 304 The "text/calendar" content type allows for the scheduling message 305 type to be included in a MIME message with other content information 306 (i.e., "multipart/mixed") or included in a MIME message with a clear- 307 text, human-readable form of the scheduling message (i.e., 308 "multipart/alternative" [RFC-2046]). 310 In order to permit the information in the scheduling message to be 311 understood by MIME user agents (UA) that do not support the 312 "text/calendar" content type, scheduling messages SHOULD be sent with 313 an alternative, human-readable form of the information. 315 Note that "multipart/alternative" MUST NOT be used to represent two 316 slightly different iCalendar objects, for example two VEVENT with 317 alternative starting times. 319 CUAs can use other MIME parameters of the Content-Type header field, 320 as well as a language specified in the Content-Language header field 321 [RFC-3282], to pick a "text/calendar" part for processing if a 322 "multipart/alternative" MIME message contains more than one 323 "text/calendar" part. 325 RFC 2447bis iMIP September 2010 327 Any receiving UA compliant with this specification MUST be able to 328 process "text/calendar" body parts enclosed within "multipart/*". 329 Note that a "multipart/mixed" MIME message can include multiple 330 "text/calendar" components. The receiving UA MUST be able to process 331 all of them. 333 2.5 Content-Transfer-Encoding Header Field 335 Unless iMIP message is transported over 8-bit clean transport (such 336 as SMTP [8BITMIME]), a transfer encoding such as quoted-printable or 337 base64 [RFC-2045] MUST be used for iCalendar objects containing any 338 characters that can't be represented in the US-ASCII character set. 339 For example: 341 From: user1@example.com 342 To: user2@example.com 343 Subject: Phone Conference 344 Mime-Version: 1.0 345 Date: Wed, 07 May 2008 21:30:25 +0400 346 Message-ID: <4821E731.5040506@laptop1.example.com> 347 Content-Type: text/calendar; method=REQUEST; charset=UTF-8 348 Content-Transfer-Encoding: quoted-printable 350 BEGIN:VCALENDAR 351 PRODID:-//Example/ExampleCalendarClient//EN 352 METHOD:REQUEST 353 VERSION:2.0 354 BEGIN:VEVENT 355 ORGANIZER:mailto:user1@example.com 356 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com 357 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com 358 DTSTAMP:20080507T170000Z 359 DTSTART:20080701T160000Z 360 DTEND:20080701T163000Z 361 SUMMARY:Phone call to discuss your last visit 362 DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0= 363 =B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0 364 =BE=D0=B9? 365 UID:calsvr.example.com-8739701987387998 366 SEQUENCE:0 367 STATUS:TENTATIVE 368 END:VEVENT 369 END:VCALENDAR 371 2.6 Content-Disposition Header Field 373 Implementations MAY include a "Content-Disposition" header field to 374 define a file name for an iCalendar object. However, the handling of 376 RFC 2447bis iMIP September 2010 378 a MIME part MUST be based on its [RFC-2045] "Content-Type" and not on 379 the extension specified in the "Content-Disposition", as different 380 email malware is known to trick User Agents into misinterpreting 381 content of messages by specifying a file extension in the Content- 382 Disposition header field that doesn't correspond to the value of 383 Content-Type header field. 385 RFC 2447bis iMIP September 2010 387 3 Security Considerations 389 The security threats that applications must address when implementing 390 iTIP are detailed in [iTIP]. In particular two spoofing threats are 391 identified in [iTIP]: Spoofing the "Organizer", and Spoofing an 392 "Attendee". To address these threats, the originator of an iCalendar 393 object must be authenticated by a recipient. Once authenticated, a 394 determination can be made as to whether or not the originator is 395 authorized to perform the requested operation. Compliant applications 396 MUST support signing and encrypting text/calendar body parts using a 397 mechanism based on S/MIME [RFC-5750][RFC-5751] in order to facilitate 398 the authentication of the originator of the iCalendar object (see 399 Section 2.2.2 and 2.2.3). The steps for processing a signed iMIP 400 message are described below: 402 1. Using S/MIME, determine who signed the text/calendar body part 403 containing the iCalendar object. This is the "signer". (Note that 404 the email address of the signer MUST be specified in the rfc822Name 405 field of the subject alternative name extension of the signer 406 certificate, as specified in [RFC-5280], Section 4.1.2.6.) Note that 407 the signer is not necessarily the person sending an e-mail message 408 since an e-mail message can be forwarded. 410 2. Correlate the signer to either an "ATTENDEE" property or to the 411 "ORGANIZER" property in the iCalendar object, based on the method and 412 the calendar component specified in the iCalendar object, as defined 413 in Section 1.4 of [iTIP]. If the signer cannot be correlated to an 414 "ATTENDEE"/"ORGANIZER" property, then actively warn the user 415 controlling the calendar user agent that the iCalendar object is 416 untrusted and encourage the user to ignore the message, but give 417 advanced users the option to (a) view the certificate of the signer 418 and the entire certificate chain (if any) in order to help decide if 419 the signer should be trusted to send the message, and then (b) allow 420 CUA to accept and process the iCalendar object. 422 3. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized 423 to perform the operation as defined by [iTIP]. If the conditions are 424 not met, ignore the message. 426 4. If all the above conditions are met, the message can be processed. 428 S/MIME signing also protects against malicious changes in transit. 430 If calendar confidentiality is required by the sender, signed iMIP 431 messages SHOULD be encrypted by a mechanism based on S/MIME 432 [RFC-5750][RFC-5751]. If iMIP is used within a single ADMD 433 (Administrative Domain) [RFC5598], SMTP STARTTLS [SMTP-TLS] (together 434 with STARTTLS in IMAP/POP [IMAP-POP-TLS]) MAY alternatively be used 436 RFC 2447bis iMIP September 2010 438 to provide calendar confidentiality. 440 Once a signed and/or encrypted iMIP message is received and 441 successfully verified (as detailed above) by a CUA, the CUA SHOULD 442 remember whether the sender of the message is using signing and/or 443 encrypting. If an unsigned iMIP message is received from the same 444 sender later on, the receiving CUA SHOULD warn the receiving user 445 about a possible man-in-the-middle attack and SHOULD ignore the 446 message, unless explicitly overridden by the user. 448 Implementations MAY provide means for users to disable signing and 449 encrypting. 451 It is possible to receive iMIP messages sent by someone working on 452 behalf of another "Calendar User". This is determined by examining 453 the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" 454 property. [iCAL] and [iTIP] provide no mechanism to verify that a 455 "Calendar User" has authorized someone else to work on their behalf. 456 To address this security issue, implementations MUST provide 457 mechanisms for the "Calendar Users" to make that decision before 458 applying changes from someone working on behalf of a "Calendar User". 459 One way to achieve this is to reject iMIP messages sent by users 460 other than the "ORGANIZER" or the "ATTENDEE"s. Alternatively, the 461 receiver could have a list of trusted proxies in 462 its local security policy. And yet another way is to prompt the user 463 for confirmation. 465 iMIP based calendaring is frequently deployed within a single ADMD, 466 with boundary filtering employed to restrict email calendaring flows 467 to be inside the ADMD. This can help in minimizing malicious changes 468 to calendaring messages in transit, as well as in making 469 authorization decisions less risky. 471 A security consideration associated with use of Content-Disposition 472 header field is described in section 2.6. 474 Use of S/MIME makes Security Considerations discussed in 475 [RFC-5750][RFC-5751] relevant to this document. For additional 476 Security Considerations regarding certificate and CRL verification 477 please see [RFC-5280]. 479 RFC 2447bis iMIP September 2010 481 4 Examples 483 4.1 Single Component With An ATTACH Property 485 This minimal message shows how an iCalendar object references an 486 attachment. The attachment is accessible via its URL. 488 From: sman@netscape.example.com 489 To: stevesil@microsoft.example.com 490 Subject: Phone Conference 491 Mime-Version: 1.0 492 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 493 Content-Transfer-Encoding: 7bit 495 BEGIN:VCALENDAR 496 PRODID:-//Example/ExampleCalendarClient//EN 497 METHOD:REQUEST 498 VERSION:2.0 499 BEGIN:VEVENT 500 ORGANIZER:mailto:man@netscape.example.com 501 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:man@netscape.example.com 502 ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com 503 DTSTAMP:19970611T190000Z 504 DTSTART:19970701T210000Z 505 DTEND:19970701T230000Z 506 SUMMARY:Phone Conference 507 DESCRIPTION:Please review the attached document. 508 UID:calsvr.example.com-873970198738777 509 ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc 510 STATUS:CONFIRMED 511 END:VEVENT 512 END:VCALENDAR 514 4.2 Using Multipart Alternative for Low Fidelity Clients 516 This example shows how a client can emit a multipart message that 517 includes both a plain text version as well as the full iCalendar 518 object. Clients that do not support text/calendar will still be 519 capable of rendering the plain text representation. 521 From: foo1@example.com 522 To: foo2@example.com 523 Subject: Phone Conference 524 Mime-Version: 1.0 525 Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360" 527 --01BD3665.3AF0D360 528 Content-Type: text/plain;charset=us-ascii 530 RFC 2447bis iMIP September 2010 532 Content-Transfer-Encoding: 7bit 534 This is an alternative representation of a TEXT/CALENDAR MIME Object 535 When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT 536 Where: 537 Organizer: foo1@example.com 538 Summary: Phone Conference 540 --01BD3665.3AF0D360 541 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 542 Content-Transfer-Encoding: 7bit 544 BEGIN:VCALENDAR 545 PRODID:-//Example/ExampleCalendarClient//EN 546 METHOD:REQUEST 547 VERSION:2.0 548 BEGIN:VEVENT 549 ORGANIZER:mailto:foo1@example.com 550 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com 551 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com 552 DTSTAMP:19970611T190000Z 553 DTSTART:19970701T170000Z 554 DTEND:19970701T173000Z 555 SUMMARY:Phone Conference 556 UID:calsvr.example.com-8739701987387771 557 SEQUENCE:0 558 STATUS:CONFIRMED 559 END:VEVENT 560 END:VCALENDAR 562 --01BD3665.3AF0D360 564 4.3 Single Component With An ATTACH Property 566 This example shows how a message containing an iCalendar object 567 references an attached document. The reference is made using a 568 Content-id (CID). Thus, the iCalendar object and the document are 569 packaged in a multipart/related encapsulation. 571 From: foo1@example.com 572 To: foo2@example.com 573 Subject: Phone Conference 574 Mime-Version: 1.0 575 Content-Type: multipart/related; boundary="boundary-example-1" 577 --boundary-example-1 579 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 581 RFC 2447bis iMIP September 2010 583 Content-Transfer-Encoding: 7bit 584 Content-Disposition: attachment; filename="event.ics" 586 BEGIN:VCALENDAR 587 PRODID:-//Example/ExampleCalendarClient//EN 588 METHOD:REQUEST 589 VERSION:2.0 590 BEGIN:VEVENT 591 ORGANIZER:mailto:foo1@example.com 592 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com 593 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com 594 DTSTAMP:19970611T190000Z 595 DTSTART:19970701T180000Z 596 DTEND:19970701T183000Z 597 SUMMARY:Phone Conference 598 UID:calsvr.example.com-8739701987387771 599 ATTACH:cid:123456789@example.com 600 SEQUENCE:0 601 STATUS:CONFIRMED 602 END:VEVENT 603 END:VCALENDAR 605 --boundary-example-1 606 Content-Type: application/msword; name="FieldReport.doc" 607 Content-Transfer-Encoding: base64 608 Content-Disposition: inline; filename="FieldReport.doc" 609 Content-ID: <123456789@example.com> 611 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA 612 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// 613 ... 615 --boundary-example-1-- 617 4.4 Multiple Similar Components 619 Multiple iCalendar components of the same type can be included in the 620 iCalendar object when the METHOD is the same for each component. 622 From: foo1@example.com 623 To: foo2@example.com 624 Subject: Summer Company Holidays 625 Mime-Version: 1.0 626 Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII 627 Content-Transfer-Encoding: 7bit 628 Content-Disposition: attachment; filename="event.ics" 630 RFC 2447bis iMIP September 2010 632 BEGIN:VCALENDAR 633 PRODID:-//Example/ExampleCalendarClient//EN 634 METHOD:PUBLISH 635 VERSION:2.0 636 BEGIN:VEVENT 637 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 638 DTSTAMP:19970611T150000Z 639 DTSTART:19970701T150000Z 640 DTEND:19970701T230000Z 641 SUMMARY:Company Picnic 642 DESCRIPTION:Food and drink will be provided 643 UID:CALSVR.EXAMPLE.COM-873970198738777-1 644 SEQUENCE:0 645 STATUS:CONFIRMED 646 END:VEVENT 647 BEGIN:VEVENT 648 ORGANIZER:MAILTO:FOO1@EXAMPLE.COM 649 DTSTAMP:19970611T190000Z 650 DTSTART:19970715T150000Z 651 DTEND:19970715T230000Z 652 SUMMARY:Company Bowling Tournament 653 DESCRIPTION:We have 10 lanes reserved 654 UID:CALSVR.EXAMPLE.COM-873970198738777-2 655 SEQUENCE:0 656 STATUS:CONFIRMED 657 END:VEVENT 658 END:VCALENDAR 660 4.5 Multiple Mixed Components 662 Different component types must be encapsulated in separate iCalendar 663 objects. 665 From: foo1@example.com 666 To: foo2@example.com 667 Subject: Phone Conference 668 Mime-Version: 1.0 669 Content-Type: multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" 671 This is a multi-part message in MIME format. 673 ----FEE3790DC7E35189CA67CE2C 674 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 675 Content-Transfer-Encoding: 7bit 676 Content-Disposition: attachment; filename="event1.ics" 678 RFC 2447bis iMIP September 2010 680 BEGIN:VCALENDAR 681 PRODID:-//Example/ExampleCalendarClient//EN 682 METHOD:REQUEST 683 VERSION:2.0 684 BEGIN:VEVENT 685 ORGANIZER:mailto:foo1@example.com 686 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com 687 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com 688 DTSTAMP:19970611T190000Z 689 DTSTART:19970701T210000Z 690 DTEND:19970701T230000Z 691 SUMMARY:Phone Conference 692 DESCRIPTION:Discuss what happened at the last meeting 693 UID:calsvr.example.com-8739701987387772 694 SEQUENCE:0 695 STATUS:CONFIRMED 696 END:VEVENT 697 END:VCALENDAR 699 ----FEE3790DC7E35189CA67CE2C 700 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII 701 Content-Transfer-Encoding: 7bit 702 Content-Disposition: attachment; filename="todo1.ics" 704 BEGIN:VCALENDAR 705 PRODID:-//Example/ExampleCalendarClient//EN 706 METHOD:REQUEST 707 VERSION:2.0 708 BEGIN:VTODO 709 DUE:19970701T160000Z 710 ORGANIZER:mailto:foo1@example.com 711 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com 712 ATTENDEE;RSVP=YES:mailto:foo2@example.com 713 SUMMARY:Phone Conference 714 DESCRIPTION:Discuss a new location for the company picnic 715 UID:calsvr.example.com-td-8739701987387773 716 SEQUENCE:0 717 STATUS:NEEDS-ACTION 718 END:VEVENT 719 END:VCALENDAR 721 ----FEE3790DC7E35189CA67CE2C 723 RFC 2447bis iMIP September 2010 725 4.6 Detailed Components With An ATTACH Property 727 This example shows the format of a message containing a group meeting 728 between three individuals. The multipart/related encapsulation is 729 used because the iCalendar object contains an ATTACH property that 730 uses a CID to reference the attachment. 732 From: foo1@example.com 733 MIME-Version: 1.0 734 To: foo2@example.com,foo3@example.com 735 Subject: REQUEST - Phone Conference 736 Content-Type: multipart/related;boundary="--FEE3790DC7E35189CA67CE2C" 738 ----FEE3790DC7E35189CA67CE2C 739 Content-Type: multipart/alternative; 740 boundary="--00FEE3790DC7E35189CA67CE2C00" 742 ----00FEE3790DC7E35189CA67CE2C00 743 Content-Type: text/plain; charset=us-ascii 744 Content-Transfer-Encoding: 7bit 746 When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT 747 Where: 748 Organizer: foo1@example.com 749 Summary: Let's discuss the attached document 751 ----00FEE3790DC7E35189CA67CE2C00 753 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII; 754 Component=vevent 755 Content-Transfer-Encoding: 7bit 756 Content-Disposition: attachment; filename="event.ics" 758 BEGIN:VCALENDAR 759 PRODID:-//Example/ExampleCalendarClient//EN 760 METHOD:REQUEST 761 VERSION:2.0 762 BEGIN:VEVENT 763 ORGANIZER:foo1@example.com 764 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:foo1@example.com 765 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com 766 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@example.com 767 DTSTAMP:19970611T190000Z 768 DTSTART:19970621T170000Z 769 DTEND:199706211T173000Z 770 SUMMARY:Let's discuss the attached document 771 UID:calsvr.example.com-873970198738777-8aa 772 ATTACH:cid:calsvr.example.com-12345aaa 774 RFC 2447bis iMIP September 2010 776 SEQUENCE:0 777 STATUS:CONFIRMED 778 END:VEVENT 779 END:VCALENDAR 781 ----00FEE3790DC7E35189CA67CE2C00 783 ----FEE3790DC7E35189CA67CE2C 784 Content-Type: application/msword; name="FieldReport.doc" 785 Content-Transfer-Encoding: base64 786 Content-Disposition: inline; filename="FieldReport.doc" 787 Content-ID: 789 R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq 790 AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd 791 riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i 792 ZnJY6J 793 ... 795 ----FEE3790DC7E35189CA67CE2C 797 5 Recommended Practices 799 This section outlines a series of recommended practices when using a 800 messaging transport to exchange iCalendar objects. 802 5.1 Use of Content and Message IDs 804 The [iCAL] specification makes frequent use of the URI for data types 805 in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. 806 Two forms of URIs are Message ID (MID) and Content ID (CID). These 807 are defined in [RFC-2392]. Although [RFC-2392] allows referencing 808 messages or MIME body parts in other MIME entities or stores, it is 809 strongly RECOMMENDED that iMIP implementations include all referenced 810 messages and body parts in a single MIME entity. Simply put, if an 811 iCalendar object contains CID or MID references to other messages or 812 body parts, implementations should ensure that these messages and/or 813 body parts are transmitted with the iCalendar object. If they are 814 not, there is no guarantee that the receiving CUA will have the 815 access or the authorization to view those objects. 817 RFC 2447bis iMIP September 2010 819 6 IANA Considerations 821 Registration of text/calendar MIME Media Type is done in [iCal]. 823 This document doesn't require any additional actions from IANA. 825 7 References 827 7.1 Normative References 829 [iCAL] Desruisseaux, B., (Ed.), "Internet Calendaring and 830 Scheduling Core Object Specification (iCalendar)", RFC 5545. 832 [iTIP] Daboo, C., "iCalendar Transport-Independent 833 Interoperability Protocol (iTIP)", RFC 5546. 835 [RFC-5322] Resnick, P., "Internet Message Format", RFC 5322, October 836 2008. 838 [MAILTO] Hoffmann, P., Masinter, L., and J. Zawinski, "The mailto URL 839 scheme", RFC 2368, June 1998. 841 [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, 842 "Security Multiparts for MIME: Multipart/Signed and 843 Multipart/Encrypted", RFC 1847, October 1995. 845 [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 846 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 847 2045, November 1996. 849 [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 850 Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. 852 [RFC-2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 853 Locators", RFC 2392, August 1998. 855 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, March 1997. 858 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 859 STD 63, RFC 3629, November 2003. 861 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over 862 Transport Layer Security", RFC 3207, February 2002. 864 [IMAP-POP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 865 2595, June 1999. 867 RFC 2447bis iMIP September 2010 869 [RFC-5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 870 Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, 871 January 2010. 873 [RFC-5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 874 Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 875 5751, January 2010. 877 [RFC-5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 878 Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure 879 Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, 880 May 2008. 882 7.2 Informative References 884 [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 885 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, 886 July 1994. 888 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 889 July 2009. 891 [RFC-3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 892 2002. 894 RFC 2447bis iMIP September 2010 896 8 Authors' Addresses 898 Alexey Melnikov (editor) 899 Isode Ltd 900 5 Castle Business Village 901 36 Station Road 902 Hampton, Middlesex TW12 2BX 903 UK 905 Email: Alexey.Melnikov@isode.com 907 RFC 2447bis iMIP September 2010 909 Appendix A. Changes since RFC 2447. 911 Updated references. Split them into Normative and Informative. 913 Updated examples to use example.com/example.net domains. 915 Corrected usage of RFC 2119 language. 917 Clarified that charset=UTF-8 is required, unless the calendar can be 918 entirely represented in US-ASCII. 920 Clarified that 7-bit content transfer encodings should be used unless 921 the calendar object is known to be transferred over 8-bit clean 922 transport. 924 Clarified that file extension specified in the Content-Disposition 925 header field is not to be used to override the Content-Type MIME 926 type. 928 Disallow use of "multipart/alternative" for slightly different 929 representations of the same calendar. 931 Clarified handling of the "method" MIME parameter of the "Content- 932 Type" header field. 934 Clarified that in an iMIP message an ORGANIZER/ATTENDEE property 935 contains a mailto: URI. 937 Fixed examples with ATTENDEE property to use "CUTYPE=" instead of 938 "TYPE=". 940 Clarified that message integrity/confidentiality should be achieved 941 using S/MIME. 943 Additional examples. 945 Improved Security Considerations section. 947 Multiple editorial changes to different sections of the document. 949 Appendix B. Acknowledgements 951 <> 953 The editor of this document wish to thank Frank Dawson, Steve Mansour 954 and Steve Silverberg, the original authors of RFC 2447, as well as 955 the following individuals who have participated in the drafting, 956 review and discussion of this memo: 958 RFC 2447bis iMIP September 2010 960 Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear, 961 Peter Saint-Andre.