Network Working Group A. Niemi
Internet-Draft M. Garcia-Martin
Expires: July 1, 2004 Nokia
January 2004
Multi-party Message Sessions using the Message Session Relay Protocol
(MSRP)
draft-niemi-simple-chat-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 July 1, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Message Session Relay Protocol (MSRP) defines a mechanism for
sending instant messages within a session, established using the
Session Initiation Protocol (SIP). This document describes how MSRP
can be used to create multi-party message sessions using the tightly
coupled conferencing model. It defines conventions and extensions for
enabling features similar to many existing services in the Internet,
e.g., Internet Relay Chat (IRC) based chat rooms, such as setting up
nicknames, sending private messages to a subset of the multy-party
conferece, etc.
Niemi & Garcia-Martin Expires July 1, 2004 [Page 1]
Internet-Draft Multiparty MSRP January 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Document Conventions . . . . . . . . . . . . . . . . . . . . 3
1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multiparty Message Sessions and Conferencing . . . . . . . . 4
4.1 Creating/deleting a chat room . . . . . . . . . . . . . . . 4
4.2 Sending and receiving messages within a chat room . . . . . 5
4.3 Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3.1 Representation of a nickname . . . . . . . . . . . . . . . . 6
4.3.2 Provision of nicknames to the focus . . . . . . . . . . . . 7
4.3.3 Procedures at the focus with respect nicknames . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
5.1 MIME Registration for application/nickname-info+xml . . . . 12
5.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:nickname-info . . . . . . . . . . . . 13
5.3 Schema Registration . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Niemi & Garcia-Martin Expires July 1, 2004 [Page 2]
Internet-Draft Multiparty MSRP January 2004
1. Introduction
The Message Session Relay Protocol (MSRP) [12] defines a mechanism
for sending a series of Instant Messages within a session. The
Session Initiation Protocol (SIP) [6] allows for two peers to set up
such a session.
In another application of SIP, a user agent can join in a multi-party
session or a conference that is hosted by a specialized user agent
called a conference focus [11]. Such a conference can naturally
involve an MSRP session as media, where an Instant Message received
from one participant is relayed to all the other participants.
Such a multi-party Instant Messaging would typically be referred to
as a chat room. Several of these types of chat rooms already exist in
the Internet. Some of these chat rooms include a rich set of
features, such as the ability of a participant to send private
messages to one or more participants, or to establish sub-conferences
within the existing conference.
The aim of this document is to define conventions and extensions for
enabling features similar to many of these existing applications in
the Internet, e.g., Internet Relay Chat (IRC) based chat rooms. This
memo uses the SIP Conferencing Framework [11] as a design base to
define a set of extensions to SIP and SDP that enrich session based
messaging conferences.
1.1 Document Conventions
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 [1] and
indicate requirement levels for compliant implementations.
1.2 Definitions
This memo deals with a particular case of tightly coupled SIP
conferences where the media exchanged consist of session based
messaging. Unless otherwise noted, we use the terminology defined in
the SIP Conferencing Framework [11] applied to the scope of this
document. In addition to that terminology, we introduce some new
terms:
Nickname: a descriptive name associated to a participant. A nickname
is non-routable pseudonym that the participant chooses for the
purpose of additional identification towards the rest of the
participants.
Niemi & Garcia-Martin Expires July 1, 2004 [Page 3]
Internet-Draft Multiparty MSRP January 2004
Session based message conference: a particular case of a tightly
coupled SIP conference (as defined by the SIP Conferencing
Framework [11]) where the media exchanged between the participants
consist of session based instant messages transported with MSRP.
Session based message mixer: a particular case of a mixer (as
defined by the SIP Conferencing Framework [11]) where the media
exchanged to or from the participants consist of session based
instant messages transported with MSRP.
Private instant message: an instant message whose intended list of
destinations is a subset of the participants, rather than all the
participants of the conference.
2. Motivation
As SIP already provides a Conferencing Framework [11] that can be
utilized in many types of conferencing applications, it seems
beneficial to provide a set of features that when used specifically
with MSRP, enhance the Instant Messaging conferences in order to
compete in functionality with existing systems.
3. Requirements
Requirements that enrich the session based messaging conferences have
been already described in Requirements for Instant Messaging in 3GPP
Wireless Systems [9] or the Advanced Instant Messaging Requirements
for the Session Initiation Protocol [10].
4. Multiparty Message Sessions and Conferencing
4.1 Creating/deleting a chat room
Since we consider a chat room a particular type of conferences where
the media happens to be session based messaging (MSRP), the methods
defined by the SIP Conference Framework to create and delete
conferences are applicable to the session based message conferences.
Once a session based message conference is created, the conference is
identified by a URI, like any other conference. Participants are
aware that the peer is a focus due to the presence of the "isfocus"
feature tag in the Contact header field of the 2xx-class response to
the INVITE request. Participants are also aware that the mixer is a
session based messaging mixer due to the presence of the message
media type and the MSRP protocol in the SDP.
In a one-to-one MSRP session, received Instant Messages are
identified by the transport connection on which they arrive. In a
chat room, where a single transport connection to the conference
mixer is used for receiving Instant Messages from all of the other
Niemi & Garcia-Martin Expires July 1, 2004 [Page 4]
Internet-Draft Multiparty MSRP January 2004
conference participants, this is not sufficient. Each message needs
to carry in it an identifier of the sender of the message.
This is accomplished using the 'message/cpim' MIME type, as defined
in [7]. The conference focus MUST insist on using the 'message/cpim'
as the top-level wrapper type in the SDP, as defined in [12].
4.2 Sending and receiving messages within a chat room
MSRP provides for the existence of a SEND primitive that allows a
sender to transport an instant message to the receiver. The actual is
enclosed in a body. MSRP mandates implementations to support the
message/cpim format. A participant that sends an MSRP SEND request to
a session based message focus SHOULD enclose the contents of the
actual message in a message/cpim MIME-type format. The message/cpim
format allows to wrap other message formats such as text/plain, text/
html, etc.
NOTE: Wrapping the actual contents into a message/cpim provides
the session based messaging focus with better CPIM compatibility.
Additionally, the focus may need to distribute copies of the
messages to the rest of the participants in a message/cpim format,
thus, if the sender sends the message already in message/cpim
format the focus is relieved from the task of doing format
conversion.
A participant that sends an session based instant message to the
conference mixer SHOULD include her nickname in the From header of
the message/cpim wrapper (see the nicknames discussion in Section
Section 4.3.
A participant that sends an session based instant message addressed
to the conference MUST set the To header of the message/cpim to the
conference URI.
A participant that sends a session based private instant message to
one or more participants of the conference MUST include the nickname
of the each of the intended receivers in either the To or Cc headers
of the message/cpim.
OPEN ISSUE: the paragraph above assumes that the participant
receives somehow the nicknames of each of the participants. Is
this assumption valid? Will the conference package have elements
to include nicknames? Or shall we define that extension?
4.3 Nicknames
A common characteristic of existing focuses is that participants have
Niemi & Garcia-Martin Expires July 1, 2004 [Page 5]
Internet-Draft Multiparty MSRP January 2004
the ability to identify themselves with a nickname to the rest of the
participants in a conference. A nickname is a string of characters
that serves for the purpose of identifying a participant to the rest
of the participants of the conference. A nickname can match the
participant name, or identify any characteristic, but it can be any
other string that is not associated with the participant at all. A
nickname can be also a collection of characters that do not make
sense in any language, as a mechanism to provide some anonymity of
the nickname.
Users are allowed to choose any nickname of their wish when they join
the conference. The only prerequisite is that the nickname is not
already in used by another participant. The nickname ought to be
unique within the set of conference instances managed by the focus.
This property allows a participant to join several conferences in the
same and still keep the same nickname across all those conferences.
Note that we don't require a nickname to be globally unique, but just
locally unique within the focus.
Nicknames are non-routable identifiers. A participant of a conference
cannot derive the SIP URI or IP address out of the nickname chosen by
another participant. Certainly the focus binds nicknames with their
respective SIP URIs, however, this binding exists only in the focus
and is not visible to the participants of the conference. This
property allows also a participant to send a private instant message
to a second participant who is identified only by her nickname.
4.3.1 Representation of a nickname
A nickname is syntactically defined as the combination of a display
name and an IM URI. The IM URI [8] may be a non-routable URI, since
the purpose of the URI is not to identify a SIP entity. This avoids
routing based on the contents of a nickname. A non routable URI may
be created by appending ".invalid" to an existing domain name.
We define conventions that allow to a sender to include a nickname in
the From, To or Cc headers of a message/cpim document. These headers
are already defined in the CPIM message format [7] with the following
syntax:
From-header = "From" ": " [ Formal-name ] "<" URI ">"
To-header = "To" ": " [ Formal-name ] "<" URI ">"
Cc-header = "cc" ": " [ Formal-name ] "<" URI ">"
A non-routable IM URI follows the format of a Network Access
Identifier (NAI) (RFC 2486) [3]. Appending the domain ".invalid" to a
NAI can make it non-routable. We chose an IM URI rather than a SIP
URI since the purpose of the URI is not to identify a SIP entity.
Niemi & Garcia-Martin Expires July 1, 2004 [Page 6]
Internet-Draft Multiparty MSRP January 2004
Examples of nickname:
"Prince of the snow" <im:johnny@example.com.invalid>
A nickname is scoped to be valid in the focus address space. The
focus maintains a binding between nicknames and SIP URIs that allows
to route private instant messages to the appropriate participant.
However, this binding is not visible outside the focus, in
particular, it is not visible to the participants of the conference.
We represent nicknames in the From, To and Cc headers in the message/
cpim. If the message is a addressed to the whole conference, the To
header of the CPIM message contains the conference URI. If the
message is a private message address to a subset of the participants,
To and Cc headers include the nickname of each of the intended
recipients. The following examples shows a CPIM private message sent
from a participant to a subset of the conference participants.
Content-Type: message/cpim
From: "Prince of the snow" <im:johnny@example.com.invalid>
To: "Blue Arrow" <im:bluearrow@example.com.invalid>
To: "Daisy" <im:daisy@example.com.invalid>
Cc: "Hook" <im:doe@example.com.invalid>
DateTime: 2004-01-28T15:43:00-02:00
Content-Type: text/plain
Content-ID: <092380923@foo.com>
This is an example of a private instant message
4.3.2 Provision of nicknames to the focus
A participant of a conference controlled by a particular focus can
setup his nickname by any means outside the scope of this document.
For instance, the participant can log into a web page where he
authenticates and sets up his nickname.
We also provide a mechanism that allows a participant to setup his
nickname interactively with the focus. The mechanism is based on the
exchange of XML "application/nickname-info+xml" documents. We define
the "application/nickname-info+xml" in Section Section 4.3.2.1.
The mechanism is inspired in the SDP offer/answer model, but instead,
we define an XML "application/nickname-info+xml" offer/answer model.
Any SIP request or responde can carry an "application/
nickname-info+xml" offer document, where the oferer express a request
Niemi & Garcia-Martin Expires July 1, 2004 [Page 7]
Internet-Draft Multiparty MSRP January 2004
to set her nickname. The focus response with an XML "application/
nickname-info+xml" answer where it authorizes or denies the request,
or makes another suggestion.
4.3.2.1 The application/nickname-info+xml data format
We define a nickname information XML document that is used to
request, setup, and suggest other nicknames to a focus. Users of this
specifications MUST support the "application/nickname-info+xml" data
format and MAY support other data formats. As a consequence, the
Accept header field in SIP messages MUST contain the "application/
nickname-info+xml" and MAY contain other types capable of
representing a nickname.
Nickname information is an XML document that MUST be well-formed and
SHOULD be valid. Nickname information documents MUST be based on XML
1.0 and MUST be encoded using UTF-8. This specification makes use of
XML namespaces for identifying Nickname information documents. The
namespace URI for elements defined by this specification is a URN
[2], using the namespace identifier 'ietf' defined by RFC 2648 [4]
and extended by [13]. This URN is:
urn:ietf:params:xml:ns:nickname-info
A Nickname information document begins with the root element tag
"nickname-info" that contains a "version" attribute and an "entity"
attribute
The first time an offerer crates an offer, it initializes the
"version" attribute to 0. Every time either the offerer or the answer
crates a new offer or answer based on a previous document, it
increments the version number by one. Versions are scoped by the pair
of participant and focus.
The "entity" attribute identifies the participant's URI whose
nickname is being set. Most focuses will contain policy that
disallows the own SIP URI to modify her own nickname, however
policies are outside the scope of this memo.
The "nickname-info" element contains a series of zero or more
"nickname" child elements
The "nickname" element contains information on a particular nickname.
It has a two mandatory attributes, "id" and "state". The "id"
attribute provides a single string that can be used as an identifier
for this nickname. The "id" is created the first time the nickname is
used. The "state" attribute carries the state of the nickname.
Possible values are "suggested", indicating that the participant
suggest a nickname for the entity; "confirmed", indicating that the
Niemi & Garcia-Martin Expires July 1, 2004 [Page 8]
Internet-Draft Multiparty MSRP January 2004
focus has confirmed that the nickname is unique and allocated to the
entity; "denied" indicating that the focus does not authorize the
usage of the nickname. In case the state is set to denied, an
optional "reason" attribute can further indicate the reason of
denial: "in-use" if the suggested nickname is already in use, or
"policy" to indicate that the focus has some policy that denies the
nickname (e.g., offensive word).
The "nickname" element contains a "display-name" child element that
contains the nickname display string that most application will
render to the user. The "nickname" element can also contain a "uri">
child element. A participant MUST NOT set the "uri" element. The
focus SHOULD set it to a non-routable IM URI that belongs to the
address space of the focus. A participant SHOULD use his URI in the
From header of a message/cpim message when it sends an instant
message.
4.3.2.2 XML schema
The following is the schema for the application/nickname-info+xml
type:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:nickname-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:nickname-info"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="nickname-info">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:nickname" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version"
type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
Niemi & Garcia-Martin Expires July 1, 2004 [Page 9]
Internet-Draft Multiparty MSRP January 2004
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="nickname">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:display-name"
minOccurs="1" maxOccurs="1"/>
<xs:element ref="tns:uri"
minOccurs="1" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="suggested"/>
<xs:enumeration value="confirmed"/>
<xs:enumeration value="denied"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="reason" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="in-use"/>
<xs:enumeration value="policy"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="display-name" type="xs:string"/>
<xs:element name="uri" type="xs:anyURI"/>
</xs:schema>
4.3.2.3 Examples
A participant has joined a session based messaging conference. She
wants to setup a nickname, so she sends a SIP request that includes
the following "application/nickname-info+xml" body. The document does
not contain a URI, since URIs are set by the focus, it only contains
the display name part of the nickname. The state is set to
"suggested" since this is only a suggestion that needs to be
confirmed by the focus.
Niemi & Garcia-Martin Expires July 1, 2004 [Page 10]
Internet-Draft Multiparty MSRP January 2004
<?xml version="1.0"?>
<nickname-info xmlns="urn:ietf:params:xml:ns:nickname-info"
version="0"
entity="sip:blue@example.com">
<nickname id="486586ds" state="suggested">
<display-name>Daisy</display-name>
</nickname>
</nickname-info>
Let's assume that the nickname is taken by another user. The focus
sends a new XML body in a SIP message, where it steps up the version
number in the document. The state of the nickname is set to "denied"
and a "reason" is set to "in-use". The focus also suggest similar
nicknames that are "available" for the participant to choose. The XML
is:
<?xml version="1.0"?>
<nickname-info xmlns="urn:ietf:params:xml:ns:nickname-info"
version="1"
entity="sip:blue@example.com">
<nickname id="486586ds" state="denied" reason="in-use"/>
<nickname id="d82ms938" state="available">
<display-name>Daisy44</display-name>
</nickname>
<nickname id="bkid92as" state="available">
<display-name>Daisy49</display-name>
</nickname>
</nickname-info>
The participant decides not to take any of the suggestions, but
instead suggests a new nickname. She also steps up the version
number.
<?xml version="1.0"?>
<nickname-info xmlns="urn:ietf:params:xml:ns:nickname-info"
version="2"
entity="sip:blue@example.com">
<nickname id="m239wd4" state="suggested">
<display-name>Blue Arrow</display-name>
</nickname>
</nickname-info>
The focus of the conference verifies that the nickname is not in use
by any other participant of any other conference. It internally binds
the nickname with the SIP and MSRP URIs of the user. The focus steps
up the version number, allocates an IM URI and returns the new
Niemi & Garcia-Martin Expires July 1, 2004 [Page 11]
Internet-Draft Multiparty MSRP January 2004
information in the XML body.
<?xml version="1.0"?>
<nickname-info xmlns="urn:ietf:params:xml:ns:nickname-info"
version="3"
entity="sip:blue@example.com">
<nickname id="m239wd4" state="confirmed">
<display-name>Blue Arrow</display-name>
<uri>im:bluearrow@example.com.invalid</uri>
</nickname>
</nickname-info>
4.3.3 Procedures at the focus with respect nicknames
Here we should describe that the focus verifies that the From header
in the CPIM message is allocated to the user and keeps it in the CPIM
message that sends to the rest of the participants.
5. IANA Considerations
This document registers a new MIME type "application/
nickname-info+xml" and new XML namespace.
5.1 MIME Registration for application/nickname-info+xml
MIME media type name: application
MIME subtype name: nickname-info+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [5].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [5].
Security considerations: See Section 10 of RFC 3023 [5] and Section 6
of this specification.
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has been
used to support SIP applications in a multi-party session based
Niemi & Garcia-Martin Expires July 1, 2004 [Page 12]
Internet-Draft Multiparty MSRP January 2004
messaging environment.
Additional Information:
Magic Number: None
File Extension: .nin or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Miguel
Garcia<miguel.an.garcia@nokia.com>
Intended usage: COMMON
Author/Change controller: The IETF.
5.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:nickname-info
This section registers a new XML namespace, as per the guidelines in
[13].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:nickname-info.
Registrant Contact: IETF, SIMPLE working group,<simple@ietf.org>,
Miguel Garcia, <miguel.an.garcia@nokia.com>.
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Nickname Information Namespace</title>
</head>
<body>
<h1>Namespace for Nickname Information</h1>
<h2>application/nickname-info+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
Niemi & Garcia-Martin Expires July 1, 2004 [Page 13]
Internet-Draft Multiparty MSRP January 2004
END
5.3 Schema Registration
This specification registers a schema, as per the guidelines in [13].
URI: please assign.
Registrant Contact: IETF, SIMPLE working group,<simple@ietf.org>,
Miguel Garcia, <miguel.an.garcia@nokia.com>.
XML: The XML can be found in Section 4.3.2.2.
6. Security Considerations
In general, messages sent to a multy-party session based messaging
focus are not deem to expose any security threat. Nevertheles, if a
participant wants to avoid eavesdropping from non authorized
entities, it should send those messages a TLS transport connection,
as allowed by MSRP.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging:
Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in
progress), January 2003.
[8] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
draft-ietf-impp-im-04 (work in progress), October 2003.
Niemi & Garcia-Martin Expires July 1, 2004 [Page 14]
Internet-Draft Multiparty MSRP January 2004
Informative References
[9] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless
Systems", draft-niemi-simple-im-wireless-reqs-02 (work in
progress), October 2003.
[10] Rosenberg, J., "Advanced Instant Messaging Requirements for the
Session Initiation Protocol (SIP)",
draft-rosenberg-simple-messaging-requirements-00 (work in
progress), December 2002.
[11] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-01 (work in
progress), October 2003.
[12] Campbell, B., "Instant Message Sessions in SIMPLE",
draft-ietf-simple-message-sessions-02 (work in progress),
October 2003.
[13] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003.
Authors' Addresses
Aki Niemi
Nokia
P.O. Box 321
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Miguel A. Garcia-Martin
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 480 4586
EMail: miguel.an.garcia@nokia.com
Niemi & Garcia-Martin Expires July 1, 2004 [Page 15]
Internet-Draft Multiparty MSRP January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Niemi & Garcia-Martin Expires July 1, 2004 [Page 16]
Internet-Draft Multiparty MSRP January 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niemi & Garcia-Martin Expires July 1, 2004 [Page 17]