Individual Submission P. Pessi, M. Mela INTERNET-DRAFT Nokia Expires: December 24, 2003 June 2003 iCalendar SIP-Based Interoperability Protocol (draft-pessi-ical-isip-02) 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 December 24, 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. The iTIP objects are used 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 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 December 24, 2003 [Page 1] Internet-Draft iSIP June 2003 The goal of this document is to re-use 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 iCalendar information can easily be transmitted over SIP instant messages [SIP-IM] just as Internet e-mail is used today. The iSIP is very similar to the e-mail binding of iTIP [iMIP]. The only significant change is in the addressing. iMIP uses e-mail addresses, iSIP allows also use of SIP or SIPS URIs. When SIP addresses are used to identify the attendees and other meeting resources, the addresses can directly be used to contact participants and to establish conferences. 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. There is simple mapping from iTIP methods to SIP message types. Any iTIP method can be sent within the message body of SIP MESSAGE request. However, an iTIP PUBLISH method can be sent within the message body of any SIP message that can be delivered from UA to UA. This excludes CANCEL requests and responses to them as well as hop-by-hop ACK requests from including an iCalendar object. 1.1 Applicability of iSIP This section describes how iSIP may be useful within Internet. iSIP is used by systems whose main purpose is to set up communication sessions using Session Initiation Protocol (SIP). iSIP can be used to exchange calendaring information between such systems, when the main purpose of that exchange is to agree on suitable time, virtual venue and participants for a future SIP-based communication session. iSIP can be used to publish calendaring information when the main purpose is to announce availability of a person or a device for a SIP-based communication sessions, or to announce participant roles or resources available within a communication session. iSIP does not replace iMAP or CAP as a protocol for exchanging generic calendaring information. On the contrary, entities using iSIP may use iMAP or CAP when the instant delivery of a SIP message is not possible, e.g., because a recipient is not available at the moment. 1.2 Related Documents Implementers will need to be familiar with several other memos that form the existing framework for SIP and Internet calendaring and scheduling standards. Pessi & Mela Expires December 24, 2003 [Page 2] Internet-Draft iSIP June 2003 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; [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 specification of the concepts or definitions. 1.3 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 MIME body parts as their content. The sections below refer to the "originator" and the "respondent" 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 iTIP requests are included in SIP MESSAGE requests. A response to a iTIP request MUST NOT be included in the SIP response message, but a separate SIP MESSAGE MUST be used for sending the response. Other SIP requests and responses MAY be used to send iTIP PUBLISH requests of iCalendar components. Pessi & Mela Expires December 24, 2003 [Page 3] Internet-Draft iSIP June 2003 2.3 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] as specified in [RFC-3261]. 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 sip: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 sip: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" parameter that is associated with the "ATTENDEE" and "ORGANIZER" properties. 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 of the "ORGANIZER" or "ATTENDEE" property in an iCalendar object SHOULD be a valid SIP or SIPS URI [RFC3261] address in the "VEVENT", "VTODO", or "VFREEBUSY" components. If the calendar user agent has a valid SIP address,the "ORGANIZER" or "ATTENDEE" property MUST contain the SIP or SIP URI of the calendar user as property value. When the calendar user agent has also a valid e-mail address, the MAILTO URI SHOULD be included as a "sent-by" Pessi & Mela Expires December 24, 2003 [Page 4] Internet-Draft iSIP June 2003 parameter. Examples: ORGANIZER;SENT-BY="mailto:pessi@iki.fi":sips:pessi@iki.fi RESOURCE;CUTYPE=RESOURCE:sip:camera-1@iptel.research.nokia.com 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", "P-Asserted-Identity" or "Reply-To" header values of a SIP message. The relevant address MUST be ascertained by opening the "text/calendar" MIME body part and examining the "ATTENDEE" and "ORGANIZER" properties. 2.3.1 Gatewaying iSIP Messages Outside SIP When an iSIP message is forwarded to an another messaging system, such as CPIM-compliant instant messaging system or e-mail, the gateway between SIP and the non-SIP messaging system usually just forwards the message contents unmodified sans the transfer encoding required by the non-SIP messaging system. OPEN ISSUE: Presumably such a gateway usually inserts a return address to the message. The return address typically points to the gateway, so that gateway can forward any replies to the original sender of the message. 2.4 Content-Transfer-Encoding The default character set for 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.5 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" parameter of the vCalendar components 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. A "charset" parameter MUST be present if the iCalendar object contains characters that are not part of the US-ASCII character set. Pessi & Mela Expires December 24, 2003 [Page 5] Internet-Draft iSIP June 2003 The default character set for iCalendar objects is UTF-8. 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.6 Content-Disposition The SIP User-Agents determine how to interpret a message body or 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. If the application requires that the iSIP message is properly processed, the Content-Disposition header MAY also contain a "handling" parameter with value "required" indicating that the receiving user-agent is to reject the request with 415 Unsupported Media Type if the "text/calendar" MIME type is not understood. 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 text/calendar attachments using a mechanism based on S/MIME and [RFC2633, RFC1847, RFC3261] 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 Pessi & Mela Expires December 24, 2003 [Page 6] Internet-Draft iSIP June 2003 object. In case of SIP or SIPS URI, the signer should match with the concatenation of the "userinfo" "@" and "domainname" portions of the URI. 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 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 Pessi & Mela Expires December 24, 2003 [Page 7] Internet-Draft iSIP June 2003 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 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 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 Pessi & Mela Expires December 24, 2003 [Page 8] Internet-Draft iSIP June 2003 --01BD3665.3AF0D360-- 4.3 Multiple Similar Components Multiple iCalendar components of the same type can be included in the iCalendar object when the PUBLISH METHOD is used 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 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 attaches 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 Pessi & Mela Expires December 24, 2003 [Page 9] Internet-Draft iSIP June 2003 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 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 Pessi & Mela Expires December 24, 2003 [Page 10] Internet-Draft iSIP June 2003 SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR ----FEE3790DC7E35189CA67CE2C 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: 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 Pessi & Mela Expires December 24, 2003 [Page 11] Internet-Draft iSIP June 2003 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. [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. [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. Pessi & Mela Expires December 24, 2003 [Page 12] Internet-Draft iSIP June 2003 [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 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. Pessi & Mela Expires December 24, 2003 [Page 13] Internet-Draft iSIP June 2003 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 A Changes since -01 Added applicability statement. Clarified rules regarding cal-address when a CUA has both mailto: and sip: URLs. Added explicit requirement not to send response to a iTIP request in a SIP response message. Removed remnants of references to xCal. Aligned restrictions on iSIP contents with those of iMIP. Pessi & Mela Expires December 24, 2003 [Page 14]