Individual Submission P. Pessi INTERNET-DRAFT M. Mela Expires: September 1, 2003 Nokia March 2003 iCalendar SIP-Based Interoperability Protocol (draft-pessi-ical-isip-01) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 28, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document, proposes a binding from the abstract iCalendar Transport-independent Interoperability Protocol (iTIP) using Session Initiation Protocol (SIP) as transport and SIP/SIPS URIs as addresses. This document proposes using the iTIP objects as a MIME payload format with SIP. iTIP is an abstract transport protocol for exchanging calendaring information between calendar systems using the iCalendar, Internet Calendaring and Scheduling Core Object Specification defined by RFC 2445. SIP is a application-layer signaling protocol for creating, modifying, and terminating multimedia sessions, retrieving user presence and sending instant messages. 1 Introduction and Motivation This binding document provides the transport specific information necessary to convey iCalendar Transport-independent Interoperability Protocol (iTIP) over SIP as a MIME payload as defined in [SIP] and [RFC-2045]. Pessi & Mela Expires May 13, 2003 [Page 1] Internet-Draft iSIP October 2002 The goal of this document is to extend the iCalendar framework so that it can be used to describe Internet multimedia conferences and chat rooms. The iCalendar provides means to provide descriptions, identify participants, their roles and other resources for meetings taking place on the Internet as well as in the real world. The XML iCalendar information can easily be transmitted over SIP instant messages [SIP-IM] just as Internet e-mail is used today. However, when SIP addresses are used to identify the attendees and other meeting resources, the addresses can directly be used to contact participants in and to establish conferences in real time. Other applications may also include availability and timezone information. For example, if callee's SIP telephone returns his freebusy and timezone information, the caller's SIP user-agent can automatically determine suitable time to retry the call. This kind of information can also be included in the SIP event documents. The mapping from iTIP methods and SIP message types is simple. Any iTIP method can be sent within the message body of SIP MESSAGE request. However, a iTIP PUBLISH method can be sent within the message body of any SIP message that can be delivered from UA to UA. In other words, CANCEL requests and responses to them as well as hop-by-hop ACK requests may not include a iCalendar object. In some use cases [CPIM] instant messaging (IM) URIs and [RFC-2806] telephone (TEL) URIs can be used as calendar user addresses in addition to the SIP URIs. 1.1 Related Documents Implementers will need to be familiar with several other memos that form the existing framework for Internet calendaring and scheduling standards. This document, [iSIP], proposes a SIP binding for iTIP; [iCAL] - specifies a core specification of objects, data types, properties and property parameters; [iTIP] - specifies an interoperability protocol for scheduling between different implementations; [iMIP] - specifies an Internet email binding for iTIP; [SIP] - specifies SIP, Session Initiation Protocol; and [SIP-IM] - specifies an extension to SIP for delivering instant messages. This document does not attempt to repeat the specification of concepts or definitions from these other documents. Where possible, references are made to the document that provides for the Pessi & Mela Expires September 1, 2003 [Page 2] Internet-Draft iSIP March 2003 specification of the concepts or definitions. 1.2 Terminology The SIP-related terms used in this document are defined in [SIP, SIP-IM]. The MIME-related terms used in this document are defined in [RFC2045]. The calendaring and scheduling terms used in this document are defined in [iCAL] and [iTIP]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2 SIP Message Format Binding This section defines the iCalendar message binding to the SIP message bodies. SIP messages can carry their content in the form of MIME body parts. The sections below refer to the "originator" and the "recipient" of an iSIP message. Typically, the originator is the "Organizer" of an event. The respondent is an "Attendee" of the event. The [SIP] "From", "To", "Contact", "Reply-To" or [SIP-PRIV] "Remote-Party-ID" headers typically contains the SIP address of the originator or respondent of an event. However, this cannot be guaranteed as SIP user-agents are not required to enforce iTIP semantics. 2.1 SIP Requests and Responses The vCalendar requests are typically included in SIP MESSAGE requests. A response to a vCalendar request is not usually included in the SIP response message, but a separate SIP MESSAGE is used for sending the response. Other SIP requests and responses MAY be used to PUBLISH iCalendar components. 2.2 Security This section addresses several aspects of security including Authentication, Authorization and Confidentiality. Authentication and confidentiality is achieved using normal SIP means, e.g., using S/MIME [RFC-1847, RFC-2630, RFC-2633]. 2.2.1 Authorization In [iTIP] messages, only the "Organizer" is authorized to modify or cancel calendar entries they organize. That is, sip:spoof@xyz.com is not allowed to modify or cancel a meeting that was organized by im:a@example.com. Furthermore, only the respondent has the Pessi & Mela Expires September 1, 2003 [Page 3] Internet-Draft iSIP March 2003 authorization to indicate their status to the "Organizer". That is, the "Organizer" must ignore an [iTIP] message from sip:spoof@xyz.com that declines a meeting invitation for im:b@example.com. Implementations of iSIP SHOULD verify the authenticity of the creator of an iCalendar object before taking any action. The methods for doing this are presented later in this document. Message flow in iTIP supports someone working on behalf of a "Calendar User" through use of the "sent-by" attribute that is associated with the "ATTENDEE" and "ORGANIZER" elements. However, there is no mechanism to verify whether or not a "Calendar User" has authorized someone to work on their behalf. It is left to implementations to provide mechanisms for the "Calendar Users" to make that decision. 2.2.2 Authentication Authentication can be performed using an implementation of [RFC-1847] "multipart/signed" that supports public/private key certificates. Authentication is possible only on messages that have been signed. Authenticating an unsigned message may not be reliable. 2.2.3 Confidentiality To ensure confidentiality using iSIP implementations should utilize S/MIME-compliant encryption. The protocol does not restrict a "Calendar User Agent" (CUA) from forwarding iCalendar objects to other users or agents. 2.3 Attendee Addresses The calendar address specified within the "attendee" element in an iCalendar object SHOULD be a valid SIP URI [RFC3261] address for the corresponding "Organizer" or "Attendee" element of the "vevent", "vtodo", or "vfreebusy" elements. OPEN ISSUE: In which circumstances [tel] telephone tel: or (CPIM) instant messaging (im:) URLs can be used? Because [iTIP] does not preclude "attendees" from forwarding "vevents" or "vtodos" to others, the apparent originator address may not equal that of the "Organizer". Additionally, the "Organizer" or "Attendee" cannot be reliably inferred by the [SIP] "From", "Contact", "Remote-Party-ID" or "Reply-to" values of an iSIP message. The relevant address MUST be ascertained by opening the "text/calendar" MIME body part and examining the "ATTENDEE" and "ORGANIZER" properties. Pessi & Mela Expires September 1, 2003 [Page 4] Internet-Draft iSIP March 2003 2.4 Content Type A MIME body part containing content information that conforms to this document MUST have an "Content-Type" header field of "text/calendar". The "Content-Type" header field SHOULD also include the type parameters "method" and "component". The "method" contains a single iTIP method name which MUST correspond to the value of the "METHOD" attribute of the vCalendar elements within the iCalendar object. The "component" parameter is also a quoted, comma-separated list and it defines the iCalendar component types contained within the iCalendar object. The following is an example of this header field with a value that indicates an event message. Content-Type: text/calendar;method="REQUEST" ;component="VEVENT,VTODO" The "text/calendar" content type allows for the scheduling message type to be included as a MIME multipart message body with other content information (i.e., "multipart/mixed") or included in a MIME message with a clear-text, human-readable form of the scheduling message (i.e., "multipart/alternative"). This can be done in order to permit the information in the scheduling message to be understood by SIP user agents (UA) that do not support the "text/calendar" content type. 2.5 Content-Transfer-Encoding Note that the default character set for XML iCalendar objects is UTF-8. As SIP protocol can handle binary message bodies, transfer encoding MUST NOT be used for iCalendar objects. Gateways from MIME-compliant protocols to SIP MUST remove any Content-Transfer- Encoding prior to delivering the iCalendar object to SIP. 2.6 Content-Disposition The SIP User-Agents determine how to interpret a message body part based on the Content-Disposition header field. The default "disposition-type" for SIP is "render", indicating that the body part should be displayed or otherwise rendered to the user. OPEN ISSUE: Does calendar objects warrant a disposition-type of their own, for example, if the calendar object should be handled by calendar application without any user intervention? 3 Security Considerations The security threats that applications must address when implementing iTIP are detailed in [iTIP]. Two spoofing threats are identified: Spoofing the "Organizer", and Spoofing an "Attendee". To address these threats, the originator of an iCalendar object must be Pessi & Mela Expires September 1, 2003 [Page 5] Internet-Draft iSIP March 2003 authenticated by a recipient. Once authenticated, a determination can be made as to whether or not the originator is authorized to perform the requested operation. Compliant applications MUST support signing and encrypting text/calendar attachments using a mechanism based on S/MIME [RFC-2633, RFC-1847] to facilitate the authentication the originator of the iCalendar object. Implementations MAY provide a means for users to disable signing and encrypting. The steps are described below: 1. The iCalendar object MUST be signed by the "Organizer" when sending an update or the "Attendee" when sending a reply. 2. Using the S/MIME, determine who signed the iCalendar object. This is the "signer". Note that the signer is not necessarily the person that sent the SIP message. 3. Correlate the signer to an "ATTENDEE" property in the iCalendar object. If the signer cannot be correlated to an "ATTENDEE" property, ignore the message. 4. Determine whether or not the "ATTENDEE" is authorized to perform the operation as defined by [iTIP]. If the conditions are not met, ignore the message. 5. If all the above conditions are met, the message can be processed. To address the confidentiality security threats, signed iSIP messages SHOULD be encrypted by a mechanisms based on S/MIME [RFC-1847, RFC-2633]. It is possible to receive iSIP messages sent by someone working on behalf of another "Calendar User". This is determined by examining the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" property. [iCAL] and [iTIP] provide no mechanism to verify that a "Calendar User" has authorized someone else to work on their behalf. To address this security issue, implementations MUST provide mechanisms for the "Calendar Users" to make that decision before applying changes from someone working on behalf of a "Calendar User". 4 Examples 4.1 Single Component With An ATTACH Property This minimal message shows how an iCalendar object references an attachment. The attachment is accessible via its URL. C->S MESSAGE sip:conference.example.com SIP/2.0 From: sip:john.doe@example.com To: sip:conference-ds76fhzxq3@example.com Call-ID: 12345-0xffffff@example.com CSeq: 1 MESSAGE Pessi & Mela Expires September 1, 2003 [Page 6] Internet-Draft iSIP March 2003 Content-Length: ... Content-Type: text/calendar;method=REQUEST;component=VEVENT BEGIN:VCALENDAR PRODID:-//HandGen//NONSGML vGen v1.0//EN METHOD:PUBLISH VERSION:2.0 BEGIN:VEVENT ORGANIZER:sip:john.doe@example.com ATTENDEE;CUTYPE=ROOM:sip:conference-ds76fhzxq3@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:sip:alice@example.com ATTENDEE;PARTSTAT=ACCEPTED:sip:bob@example.com ATTENDEE;PARTSTAT=DECLINED:sip:fubar.com DTSTAMP:20020611T190000Z DTSTART:20020701T210000Z DTEND:20020701T230000Z SUMMARY:IP telephony conference DESCRIPTION:Review of foo.xml. UID:calsvr.example.com-873970198738777 ATTACH:ftp://ftp.bar.com/pub/docs/foo.xml STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.2 Using Multipart Alternative for Low Fidelity Clients This example shows how a client can emit a multipart message that includes both a plain text version as well as the full iCalendar object. Clients that do not support "text/calendar" will still be capable of rendering the plain text representation. C->S MESSAGE sip:conference.example.com SIP/2.0 From: sip:john.doe@example.com To: sip:conference-ds76fhzxq3@example.com Call-ID: 12345-0xffffff@example.com CSeq: 1 MESSAGE Content-Length: ... Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360" --01BD3665.3AF0D360 Content-Type: text/plain This is an alternative representation of a XML iCalendar object. When: 7/1/2002 10:00AM PDT - 7/1/97 10:30AM PDT Where: Organizer: sip:foo1@example.com Summary: IP Telephony Conference --01BD3665.3AF0D360 Content-Type: text/calendar;method=REQUEST;component=VEVENT Pessi & Mela Expires September 1, 2003 [Page 7] Internet-Draft iSIP March 2003 BEGIN:VCALENDAR PRODID:-//HandGen//NONSGML vGen v1.0//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:sip:foo1@example.com ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:sip:foo1@example.com ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:sip:foo2@example.com DTSTAMP:20020611T190000Z DTSTART:20020701T170000Z DTEND:20020701T173000Z SUMMARY:phone conference UID:calsvr.example.com-8739701987387771 SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR --01BD3665.3AF0D360 4.3 Multiple Similar Components Multiple iCalendar components of the same type can be included in the iCalendar object when the METHOD is the same for each component. C->S MESSAGE sip:conference.example.com SIP/2.0 From: sip:john.doe@example.com To: sip:conference-ds76fhzxq3@example.com Call-ID: 12345-0xffffff@example.com CSeq: 1 MESSAGE Content-Length: ... Content-Type: text/calendar;method=PUBLISH BEGIN:VCALENDAR METHOD:PUBLISH VERSION:2.0 PRODID:-//HandGen//NONSGML vGen v1.0//EN BEGIN:VEVENT ORGANIZER:sip:foo1@example.com DTSTAMP:20020611T150000Z DTSTART:20020701T150000Z DTEND:20020701T230000Z SUMMARY:company picnic DESCRIPTION:food and drink will be provided UID:calsvr.example.com-873970198738777-1 SEQUENCE:0 STATUS:CONFIRMED END:VEVENT BEGIN:VEVENT ORGANIZER:sip:foo1@example.com DTSTAMP:20020611T190000Z DTSTART:20020715T150000Z Pessi & Mela Expires September 1, 2003 [Page 8] Internet-Draft iSIP March 2003 DTEND:20020715T230000Z SUMMARY:company bowling tournament DESCRIPTION:we have 10 lanes reserved UID:calsvr.example.com-873970198738777-2 SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.4 Receiving conference information when joining to one When joining a conference, the conferencing application server attachs conference information to its response's multipart MIME payload. C->S INVITE sip:conference.example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com From: sip:john.doe@example.com To: sip:conference-ds76fhzxq3@example.com Call-ID: 12345-0xffffff@example.com CSeq: 1 INVITE Accept: application/sdp, text/calendar, text/html Content-Type: application/sdp Content-Length: ... v=0 o=john 0 0 IN IP4 0.0.0.0 s=sline m=audio 0 RTP/AVP 98 0 8 a=rtpmap:98 AMR/8000 m=video 0 * S->C SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com From: sip:conference-ds76fhzxq3@example.com> To: Call-ID: 12345-0xffffff@example.com CSeq: 1 INVITE Content-Disposition: session Content-Type: multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" Content-Length: ... ----FEE3790DC7E35189CA67CE2C Content-Type: application/sdp Content-Disposition: session v=0 o=watson 4858949 4858949 IN IP4 192.1.2.3 s=Conference going m=audio 0 RTP/AVP 98 0 8 a=rtpmap:98 AMR/8000 Pessi & Mela Expires September 1, 2003 [Page 1] Internet-Draft iSIP March 2003 m=video 0 * ----FEE3790DC7E35189CA67CE2C Content-Type: text/calendar;method=REQUEST Content-Disposition: render BEGIN:VCALENDAR METHOD:REQUEST VERSION:2.0 PRODID:-//HandGen//NONSGML vGen v1.0//EN BEGIN:VEVENT ORGANIZER:sip:foo1@example.com ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:sip:foo1@example.com ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:sip:foo2@example.com DTSTAMP:20020611T190000Z DTSTART:20020701T210000Z DTEND:20020701T230000Z SUMMARY:IP telephony conference DESCRIPTION:discuss what happened at the last meeting UID:calsvr.example.com-8739701987387772 SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.5 The callee include FREEBUSY reachability information in response The callee responds with 486 Busy Here and sends a FREEBUSY object with reachability information in the payload. C->S INVITE sip:example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com From: sip:john.doe@example.com To: sip:alice.doe@example.com Call-ID: 12345-0xffffff@example.com CSeq: 1 INVITE Accept: application/sdp, text/calendar, text/html Content-Type: application/sdp Content-Length: ... v=0 o=john 0 0 IN IP4 0.0.0.0 s=sline m=audio 0 RTP/AVP 98 0 8 a=rtpmap:98 AMR-WB/16000 m=video 0 * S->C SIP/2.0 SIP 486 Busy Here Via: SIP/2.0/UDP proxy.example.com From: sip:alice.doe@example.com> To: Pessi & Mela Expires September 1, 2003 [Page 10] Internet-Draft iSIP March 2003 Call-ID: 12345-0xffffff@example.com CSeq: 1 INVITE Content-Type: text/calendar;method=PUBLISH Content-Length: ... BEGIN:VCALENDAR PRODID:-//hacksw/handcal//NONSGML 1.0//EN METHOD:PUBLISH VERSION:2.0 BEGIN:FREEBUSY UID:20020313T133000@ical1.host.com DTSTAMP:20020104T133010Z ORGANIZER:sip:alice.doe@host.com DTSTART:20020313T141711Z DTEND:20020410T141711Z URL:http://www.host.com/calendar/busytime/adoe.ifb FREEBUSY:20020314T233000Z/20020315T003000Z FREEBUSY:20020316T153000Z/20020316T163000Z FREEBUSY:20020318T030000Z/20020318T040000Z END:VFREEBUSY END:VCALENDAR 5 Recommended Practices This section outlines a series of recommended practices when using a SIP to exchange iCalendar objects. 5.1 Use of Content and Message IDs The [iCAL] specification makes frequent use of the URI for data types in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. Two forms of URIs are Message ID (MID) and Content ID (CID). These are defined in [RFC-2111]. Although [RFC-2111] allows referencing messages or MIME body parts in other MIME entities or stores, it is strongly recommended that iSIP implementations include all referenced messages and body parts in a single MIME entity. Simply put, if an iCalendar object contains CID or MID references to other messages or body parts, implementations should ensure that these messages and/or body parts are transmitted with the iCalendar object. If they are not there is no guarantee that the receiving "CU" will have the access or the authorization to view those objects. 6 Bibliography [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998. [iTIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998. Pessi & Mela Expires September 1, 2003 [Page 11] Internet-Draft iSIP March 2003 [iMIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998. [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. [SIP] Rosenberg, J. et al, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [SIP-IM] Campbell, B. (ed), J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging". RFC 3428, December 2002. [SIP-PRIV] Andreasen, F., et al, "SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks", draft-ietf-sip-privacy-05.txt (work in progress), March 2002. [CPIM] Crocker, D. et al, "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-cpim-03 (work in progress), August 2002. [PIDF] Sugano, H. et al, "Presence Information Data Format", draft-ietf-impp-cpim-pidf-05.txt (work in progress), May 2002. [SYNCML] SyncML Intitiative, "SyncML Represenation Protocol", http://www.syncml.org/docs/syncml_represent_v11_20020215.pdf, February 2002. [RFC-2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) - Part Four: Registration Pessi & Mela Expires September 1, 2003 [Page 12] Internet-Draft iSIP March 2003 Procedures", RFC 2048, January 1997. [RFC-2111] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2111, March 1997. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [RFC-2633] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [xCAL] Dawson, F. et al, "iCalendar DTD Document (xCal)", draft-ietf-calsch-many-xcal-02 (work in progress), July 2002. 7 Authors' Addresses Pekka Pessi Nokia EMail: Pekka.Pessi@nokia.com Phone: +358 504 836 404 Martti Mela Nokia EMail: Martti.Mela@nokia.com Phone: +358 504 836 460 Pessi & Mela Expires September 1, 2003 [Page 13]