Internet DRAFT - draft-pessi-calsch-isip
draft-pessi-calsch-isip
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"
"http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt">
<iCalendar>
<vcalendar method="PUBLISH" version="2.0">
<vevent>
<organizer>sip:john.doe@example.com</organizer>
<attendee cutype=room>sip:conference-ds76fhzxq3@example.com
</attendee>
<attendee role=chair partstat=accepted>sip:alice@example.com
</attendee>
<attendee partstat=accepted>sip:bob@example.com</attendee>
<attendee partstat=declined>sip:fubar.com</attendee>
<dtstamp>20020611t190000z</dtstamp>
<dtstart>20020701t210000z</dtstart>
<dtend>20020701t230000z</dtend>
<summary>IP telephony conference</summary>
<description>Review of foo.xml.</description>
<uid>calsvr.example.com-873970198738777</uid>
<attach>ftp://ftp.bar.com/pub/docs/foo.xml</attach>
<status>confirmed</status>
</vevent>
</vcalendar>
</iCalendar>
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"
"http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt">
<iCalendar>
<vcalendar method="REQUEST"
version="2.0"
prodid="-//HandGen//NONSGML vGen v1.0//EN">
<vevent>
<organizer>sip:foo1@example.com</organizer>
<attendee>role=chair;attstat=accepted:sip:foo1@example.com
</attendee>
<attendee>rsvp=yes;type=individual:sip:foo2@example.com
</attendee>
<dtstamp>20020611t190000z</dtstamp>
<dtstart>20020701t170000z</dtstart>
<dtend>20020701t173000z</dtend>
<summary>phone conference</summary>
<uid>calsvr.example.com-8739701987387771</uid>
<sequence>0</sequence>
<status>confirmed</status>
</vevent>
Pessi & Mela Expires April 28, 2003 [Page 8]
Internet-Draft iSIP October 2002
</vcalendar>
</iCalendar>
--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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"
"http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt">
<iCalendar>
<vcalendar method="PUBLISH"
version="2.0"
prodid="-//HandGen//NONSGML vGen v1.0//EN">
<vevent>
<organizer>sip:foo1@example.com</organizer>
<dtstamp>20020611t150000z</dtstamp>
<dtstart>20020701t150000z</dtstart>
<dtend>20020701t230000z</dtend>
<summary>company picnic</summary>
<description>food and drink will be provided</description>
<uid>calsvr.example.com-873970198738777-1</uid>
<sequence>0</sequence>
<status>confirmed</status>
</vevent>
<vevent>
<organizer>sip:foo1@example.com</organizer>
<dtstamp>20020611t190000z</dtstamp>
<dtstart>20020715t150000z</dtstart>
<dtend>20020715t230000z</dtend>
<summary>company bowling tournament</summary>
<description>we have 10 lanes reserved</description>
<uid>calsvr.example.com-873970198738777-2</uid>
<sequence>0</sequence>
<status>confirmed</status>
</vevent>
</vcalendar>
</iCalendar>
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: <sip:john.doe@example.com>
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"
"http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt">
Pessi & Mela Expires April 28, 2003 [Page 10]
Internet-Draft iSIP October 2002
<iCalendar>
<vcalendar method="REQUEST"
version="2.0"
prodid="-//HandGen//NONSGML vGen v1.0//EN">
<vevent>
<organizer>sip:foo1@example.com</organizer>
<attendee role=chair attstat=accepted>sip:foo1@example.com</attendee>
<attendee rsvp=yes type=individual>sip:foo2@example.com</attendee>
<dtstamp>20020611t190000z</dtstamp>
<dtstart>20020701t210000z</dtstart>
<dtend>20020701t230000z</dtend>
<summary>IP telephony conference</summary>
<description>discuss what happened at the last meeting</description>
<uid>calsvr.example.com-8739701987387772</uid>
<sequence>0</sequence>
<status>confirmed</status>
</vevent>
</vcalendar>
</iCalendar>
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: <sip:john.doe@example.com>
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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar SYSTEM "xcal.dtd" [
<!ENTITY adoe.ifb SYSTEM
"http://www.host.com/calendar/busytime/adoe.ifb" NDATA BINARY>
]>
<iCalendar>
<vcalendar version="2.0"
prodid="-//hacksw/handcal//NONSGML 1.0//EN">
<vfreebusy>
<uid>20020313T133000@ical1.host.com</uid>
<dtstamp>20020104T133010Z</dtstamp>
<organizer>sip:alice.doe@host.com</organizer>
<dtstart>20020313T141711Z</dtstart>
<dtend>20020410T141711Z</dtend>
<url uri="adoe.ifb" />
<freebusy>20020314T233000Z/20020315T003000Z</freebusy>
<freebusy>20020316T153000Z/20020316T163000Z</freebusy>
<freebusy>20020318T030000Z/20020318T040000Z</freebusy>
</vfreebusy>
</vcalendar>
</iCalendar>
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]
