From: http://www.ietf.org/internet-drafts/draft-pessi-calsch-isip-00.txt CALSCH WG P. Pessi INTERNET-DRAFT M. Mela Expires: April 28, 2003 Nokia October 2002 iCalendar SIP-Based Interoperability Protocol (draft-pessi-calsch-isip-00) 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 XML iCalendar or xCal as a mandatory payload format with SIP. XML iCalendar is an XML DTD that corresponds to 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 April 28, 2003 [Page 1] Internet-Draft iSIP October 2002 The goal of this document is to extend the iCalendar framework describing 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, the iCalendar URIs can directly be used to establish conferences. OPEN ISSUE: It would be beneficial to include the capabilities or preferences related to a particular SIP URI in the xCal documents [LONNFORS]. However, the current xCal specification explicitly prohibits using extension namespaces with xCal documents because desired 1:1 mapping between standard and XML iCalendar formats. We would argue that this restriction is too limiting and would rather provide a possibility to map between XML namespaces and experimental or IANA-registered parameters. 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 presence documents [PIDF]. The XML iCalendar components could also be included in the XML-based event documents. For example, a person would like to include his vCard [RFC2426] in his presence document [PIDF], and a conferencing server could include a VEVENT [RFC2445] component in the conferencing conference information document [CALLPKG]. 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. Pessi & Mela Expires April 28, 2003 [Page 2] Internet-Draft iSIP October 2002 This memo does not attempt to repeat the specification of concepts or definitions from these other memos. Where possible, references are made to the memo that provides for the 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 memo 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]. Pessi & Mela Expires April 28, 2003 [Page 3] Internet-Draft iSIP October 2002 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 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. Pessi & Mela Expires April 28, 2003 [Page 4] Internet-Draft iSIP October 2002 The relevant address MUST be ascertained by opening the "application/calendar+xml" MIME body part and examining the "ATTENDEE" and "ORGANIZER" properties. 2.4 Content Type A MIME body part containing content information that conforms to this document MUST have an "Content-Type" header field of "application/calendar+xml". 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. OPEN ISSUE: Currently, the installed base of CUAs integrated with SIP and using standard iCalendar is roughly zero. So it seems reasonable to us to restrict SIP applications to use XML iCalendar only, as this could reduce the additional complexity in typical SIP applications that already use large number of XML-based documents [PIDF, CONF-INFO]. Converting between XML and standard iCalendar [RFC2445] formats would only be required when a SIP UA needs to import or export iCalendar objects from standard-iCalendar-based CUA. Already, this happens using XML-based synchronization protocols like SyncML The following is an example of this header field with a value that indicates an event message. Content-Type: application/calendar+xml ;method="REQUEST" ;component="VEVENT,VTODO" The "application/calendar+xml" 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"). In order to permit the information in the scheduling message to be understood by SIP user agents (UA) that do not support the "application/calendar+xml" content type, scheduling messages MAY be sent with an alternative, human-readable form of the information. 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. Pessi & Mela Expires April 28, 2003 [Page 5] Internet-Draft iSIP October 2002 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 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 application/calendar+xml 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 Pessi & Mela Expires April 28, 2003 [Page 6] Internet-Draft iSIP October 2002 "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 Content-Length: ... Content-Type: application/calendar+xml;method=REQUEST; component=VEVENT sip:john.doe@example.com sip:conference-ds76fhzxq3@example.com sip:alice@example.com sip:bob@example.com sip:fubar.com 20020611t190000z 20020701t210000z 20020701t230000z IP telephony conference Review of foo.xml. calsvr.example.com-873970198738777 ftp://ftp.bar.com/pub/docs/foo.xml confirmed Pessi & Mela Expires April 28, 2003 [Page 7] Internet-Draft iSIP October 2002 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 application/calendar+xml 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: application/calendar+xml ;method=REQUEST ;component=VEVENT sip:foo1@example.com role=chair;attstat=accepted:sip:foo1@example.com rsvp=yes;type=individual:sip:foo2@example.com 20020611t190000z 20020701t170000z 20020701t173000z phone conference calsvr.example.com-8739701987387771 0 confirmed Pessi & Mela Expires April 28, 2003 [Page 8] Internet-Draft iSIP October 2002 --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:application/calendar+xml ;method=PUBLISH sip:foo1@example.com 20020611t150000z 20020701t150000z 20020701t230000z company picnic food and drink will be provided calsvr.example.com-873970198738777-1 0 confirmed sip:foo1@example.com 20020611t190000z 20020715t150000z 20020715t230000z company bowling tournament we have 10 lanes reserved calsvr.example.com-873970198738777-2 0 confirmed Pessi & Mela Expires April 28, 2003 [Page 9] Internet-Draft iSIP October 2002 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, application/calendar+xml, 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-Type: multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" Content-Length: ... ----FEE3790DC7E35189CA67CE2C Content-Type: application/sdp 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 m=video 0 * ----FEE3790DC7E35189CA67CE2C Content-Type: application/calendar+xml ;method=REQUEST Pessi & Mela Expires April 28, 2003 [Page 10] Internet-Draft iSIP October 2002 sip:foo1@example.com sip:foo1@example.com sip:foo2@example.com 20020611t190000z 20020701t210000z 20020701t230000z IP telephony conference discuss what happened at the last meeting calsvr.example.com-8739701987387772 0 confirmed 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 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: Call-ID: 12345-0xffffff@example.com CSeq: 1 INVITE Content-Type: application/calendar+xml ;method=PUBLISH Content-Length: ... Pessi & Mela Expires April 28, 2003 [Page 11] Internet-Draft iSIP October 2002 ]> 20020313T133000@ical1.host.com 20020104T133010Z sip:alice.doe@host.com 20020313T141711Z 20020410T141711Z 20020314T233000Z/20020315T003000Z 20020316T153000Z/20020316T163000Z 20020318T030000Z/20020318T040000Z 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. [xCAL] Dawson, F. et al, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998. Pessi & Mela Expires April 28, 2003 [Page 12] Internet-Draft iSIP October 2002 [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. [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), "Session Initiation Protocol Extension for Instant Messaging", draft-ietf-sip-message-07 (work in progress), September 2002. [SIP-PRIV] Marshall, W. 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. [CALLPKG] Rosenberg, J., H. Schulzrinne, "SIP Event Packages for Call Leg and Conference State", draft-rosenberg-sip-call-package-01 (work in progress), September 2002. [LONNFORS] Lonnfors, M., K. Kiss, "SIMPLE PIDF callee capabilities extension", draft-lonnfors-pidf-callee-capabilities-ext-00 (work in progress), October 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 Pessi & Mela Expires April 28, 2003 [Page 13] Internet-Draft iSIP October 2002 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 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. 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 April 28, 2003 [Page 14]