Network Working Group A. Niemi
Internet-Draft Nokia
Intended status: Standards Track M. Garcia-Martin
Expires: December 14, 2007 Nokia Siemens Networks
June 12, 2007
Multi-party Instant Message (IM) Sessions Using the Message Session
Relay Protocol (MSRP)
draft-ietf-simple-chat-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 14, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Message Session Relay Protocol (MSRP) defines a mechanism for
sending instant messages within a peer-to-peer session, negotiated
using the Session Initiation Protocol (SIP) and the Session
Description Protocol (SDP). This document defines the necessary
tools for establishing multi-party instant messaging (IM) sessions,
or chat rooms, with MSRP.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 1]
Internet-Draft Multiparty MSRP June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations and Requirements . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
5. Creating, Joining, and Deleting a Chat Room . . . . . . . . . 8
5.1. Creating a Chat Room . . . . . . . . . . . . . . . . . . . 8
5.2. Joining a Chat Room . . . . . . . . . . . . . . . . . . . 8
5.3. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . 9
5.4. Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 10
6. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Using Nicknames within a Conference . . . . . . . . . . . 12
6.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 14
6.3. Mapping Nicknames to Other Identities . . . . . . . . . . 14
6.4. Nicknames in the Conference Event Package . . . . . . . . 15
6.5. Nicknames and Multiple SIP Addresses of Record . . . . . . 15
7. Sending and Receiving Instant Messages . . . . . . . . . . . . 16
7.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 16
7.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 17
8. Sidebars . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 19
9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 21
9.3. Sending a regular message to the chat room . . . . . . . . 23
9.4. Sending a private message to a participant . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Niemi & Garcia-Martin Expires December 14, 2007 [Page 2]
Internet-Draft Multiparty MSRP June 2007
1. Introduction
The Message Session Relay Protocol (MSRP)
[I-D.ietf-simple-message-sessions] defines a mechanism for sending a
series of instant messages within a session. The Session Initiation
Protocol (SIP) [RFC3261] in combination with the Session Description
Protocol (SDP) [RFC3264] allows for two peers to establish and manage
such sessions.
In another application of SIP, a user agent can join in a multi-party
session or conference that is hosted by a specialized user agent
called a conference focus [RFC4353]. Such a conference can naturally
involve an MSRP session as one of possibly many media components. It
is the responsibility of an entity handling the media to relay
instant messages received from one participant to the rest of the
participants in the conference.
Several such systems already exist in the Internet. Participants in
a chat room can be identified with a pseudonym or nickname, and
decide whether their real identity is disclosed to other
participants. Participants can also use a rich set of features, such
as the ability to send private instant messages to one or more
participants, and the ability to establish sub-conferences with one
or more of the participants within the existing conference. They
also allow combining instant messaging with other media components,
such as voice, video, whiteboarding, screen sharing, and file
transfer.
Such conferences are already available today with other technologies
different than MSRP. For example, Internet Relay Chat (IRC)
[RFC2810], Extensible Messaging and Presence Protocol [RFC3920] based
chat rooms, and many other proprietary systems provide this kind of
functionality. It makes sense to specify equivalent functionality
for MSRP-based systems to both provide competitive features as well
as enable interworking between the systems.
This document defines requirements, conventions, and extensions for
providing private messages and nickname management in centralized
conferences with MSRP. This document, however, does not specify
functionality that can be used in conference with media different
than MSRP. This memo uses the SIP Conferencing Framework [RFC4353]
as a design basis. It also aims to be compatible with the
Centralized Conferencing Framework [I-D.ietf-xcon-framework]. It is
expected that future mechanisms will be developed for providing
similar functionality in generic conferences, i.e., where the media
is not only restricted to MSRP. The mechanisms described in this
document provide a future compatible short-term solution for MSRP
centralized conferences.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 3]
Internet-Draft Multiparty MSRP June 2007
2. Terminology
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, BCP 14
[RFC2119], and indicate requirement levels for compliant
implementations.
This memo deals with a particular case of tightly coupled SIP
conferences where the media exchanged consist of session-based
instant messaging. Unless otherwise noted, we use the terminology
defined in the SIP Conferencing Framework [RFC4353] applied to the
scope of this document. In addition to that terminology, we
introduce some new terms:
Nickname: a pseudonym or descriptive name associated to a
participant.
Nickname URI: A SIP URI issued by an administrative domain, whose
userpart is effectively a nickname. See more information in
Section 6.
Session-based Instant Messaging Conference: an instance of a
tightly coupled conference, in which the media exchanged between
the participants consist of (among others) MSRP based instant
messages. Also known as a chat room.
Chat Room: a synonym for session-based instant messaging
conference.
Chat Room URI: a URI that identifies a particular chat room in a
conference server. Since a chat room is a specialized conference
of instant messages, in the context of this document, a chat room
URI is a synonym of a conference URI.
Conference Server: a (possibly decomposed) server that provides
multipart text conference services. It is also the combination of
a conference focus and an MSRP switch.
Sender: the conference participant that originally created an
instant message and sent it to the chat room for delivery.
Recipient: the destination conference participant(s). This
defaults to the full conference participant list, minus the IM
Sender.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 4]
Internet-Draft Multiparty MSRP June 2007
MSRP switch: a media level entity that receives MSRP messages and
delivers them to the other conference participants. An MSRP
switch has a similar role to a conference mixer with the exception
that an MSRP switch does not actually "mix" together different
input media streams; it merely relays the messages between
participants.
Private Instant Message: an instant message sent in a chat room
whose intended recipient is something other than the default. The
recipient of a private IM can either be one specific conference
participant, or a subset of the full participant list. A private
IM is usually rendered distinctly from the rest of the IMs, as to
indicate that the message was a private communication.
3. Motivations and Requirements
Although conference frameworks describing many types of conferencing
applications already exist, such as the Framework and Data Model for
Centralized Conferencing [I-D.ietf-xcon-framework] and the SIP
Conferencing Framework [RFC4353], the exact details of session-based
instant messaging conferences are not well-defined at the moment.
To allow interoperable chat implementations, for both conference-
aware, and conference-unaware user agents, certain conventions for
MSRP conferences need to be defined. It also seems beneficial to
provide a set of features that enhance the baseline multiparty MSRP
in order to be able to create systems that have functionality on par
with existing chat systems, as well as enable building interworking
gateways to these existing chat systems.
We define the following requirements:
REQ-1: A basic requirement is the existence of a multiparty
conference, where participants can join and leave the
conference and get instant messages exchanged to the rest of
the participants.
REQ-2: The conference must have the ability to host other media in
addition to MSRP, as well as multiple streams of MSRP.
REQ-3: A conference participant must be able to determine the
identities of the sender and recipient of the received IMs.
REQ-4: A conference participant must be able to determine the
recipient of the received message. For instance, the
recipient of the message might be the entire conference, a
conference sidebar or a single participant of the conference
Niemi & Garcia-Martin Expires December 14, 2007 [Page 5]
Internet-Draft Multiparty MSRP June 2007
(i.e., a private message).
REQ-5: It must be possible to send a message to a single
participant, or a subset of the conference participants
(i.e., a private instant message).
REQ-6: It must be possible to set up a sidebar session with one or
more participants of the chat room.
REQ-7: A conference participant may have a nickname or pseudonym
associated with their real identity.
REQ-8: It must be possible for a participant to change their
nickname during the progress of the conference.
REQ-9: It must be possible that a participant is only known by
their nickname and not their real identity to the rest of
the conference.
REQ-10: It must be possible for the MSRP switch itself to send IMs
to the conference (e.g., message of the day, welcome
messages, server is shutting down, etc.)
REQ-11: It must be possible for participants to learn the
capabilities support of the features described in this
document (and perhaps others).
4. Overview of Operation
In order to set up a conference, one must first be created. Users
wishing to host a conference themselves can of course do just that;
their user agents simply morph from an ordinary user agent into a
special purpose one called a conference focus. Another, commonly
used setup is one where a dedicated node in the network functions as
a conference focus.
Each chat room has an identity of its own: a SIP URI that
participants use to join the conference, e.g., by sending an INVITE
request. The conference focus processes the invitations, and as
such, maintains SIP dialogs with each participant. In an instant
messaging conference, or chat room, MSRP is one of the established
media streams. Each conference participant establishes an MSRP
session with an MSRP switch, which is a special purpose MSRP
application. The MSRP switch is similar to a conference mixer in
that it handles media sessions with each of the participants and
bridges these streams together. However, unlike a conference mixer,
the MSRP switch merely relays messages between participants but
Niemi & Garcia-Martin Expires December 14, 2007 [Page 6]
Internet-Draft Multiparty MSRP June 2007
doesn't actually mix the streams in any way. The system is
illustrated in Figure 1.
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
Figure 1: Multiparty MSRP in a Centralized Conference
Typically conference participants also subscribe to the conference
event package [RFC4575] to gather information about the conference
roster in the form of conference state notifications. For example,
participants can learn about other participants' identities.
All messages in the chat room use the 'Message/CPIM' wrapper content
type [RFC3862], so that it is possible to distinguish between private
and regular messages. When a participant wants to send an instant
message to the conference, it constructs an MSRP SEND request and
submits it to the MSRP switch including a regular payload (e.g., a
Message/CPIM message that contains a text, html, an image, etc.).
The Message/CPIM To header is set to the chat room URI. The switch
then fans out the SEND request to all of the other participants using
their existing MSRP sessions.
A participant can also send a private instant message addressed to
one or more conference participants whose identities have been
learnt, e.g., via a notification from the conference event package
[RFC4575]. In this case the sender creates an MSRP SEND request with
a Message/CPIM body whose To or Cc headers contain not the chat room
Niemi & Garcia-Martin Expires December 14, 2007 [Page 7]
Internet-Draft Multiparty MSRP June 2007
URI but one or more nickname URIs or participant URIs. The MSRP
switch then fans out the SEND request to each of the participants
listed in the To or Cc headers of the Message/CPIM body.
We extend the current MSRP negotiation that takes place in SDP
[RFC4566] to allow participants to learn whether the chat room
supports and is willing to accept (e.g., due to local policy
restrictions) certain MSRP functions defined in this memo, such as
nicknames or private messaging.
Naturally, when a participant wishes to leave a chat room, it sends a
SIP BYE request to the conference focus and disconnects.
5. Creating, Joining, and Deleting a Chat Room
5.1. Creating a Chat Room
Since we consider a chat room a particular type of conference where
one of the offered media happens to be MSRP, the methods defined by
the SIP Conference Framework [RFC4353] for creating conferences are
directly applicable to a chat room.
Once a chat room is created, it is identified by a SIP URI, like any
other conference.
5.2. Joining a Chat Room
Participants usually join the conference by sending an INVITE request
to the conference URI. As long as the conference policy allows, the
INVITE request is accepted by the focus and the user is brought into
the conference. Participants are aware that the peer is a focus due
to the presence of the "isfocus" feature tag [RFC3840] in the Contact
header field of the 200-class response to the INVITE request.
Participants are also aware that the mixer is an MSRP switch due to
the presence of an additional 'message' media type and either TCP/
MSRP or TCP/TLS/MSRP as the protocol field in the SDP [RFC4566]
media-line.
The conference focus of a chat room MUST include support for a
Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by
setting the 'accept-types' MSRP media line attribute in the SDP offer
or answer to include 'Message/CPIM'.
Note that the 'Message/CPIM' wrapper is used to carry the sender
information that, otherwise, it will not be available to the
recipient. Additionally, 'Message/CPIM' wrapper carries the
recipient information (e.g., To and Cc: headers).
Niemi & Garcia-Martin Expires December 14, 2007 [Page 8]
Internet-Draft Multiparty MSRP June 2007
The conference focus of a chat room MUST learn the chatroom
capabilities of each participant that joins the chat room, and MUST
inform the MSRP mixer of such support. This is to prevent that the
MSRP mixer distributes private messages to participants who do not
support private messaging.
5.3. The SDP 'chatroom' attribute
There are a handful of use cases where a participant would like to
learn the chatroom capabilities supported by the MSRP switch and the
chat room. For example, a participant would like to learn if the
MSRP switch supports private messaging, otherwise, the participant
may send what he believes is a private instant message addressed to a
few participants, but since the MSRP switch does not support the
functions specified in this memo, the message gets eventually
distributed to all the participants of the chat room.
The reverse case also exists. A participant, say Alice, whose user
agent does not support the extensions defined by this document joins
the chat room. The MSRP switch learns that Alice application does
not support private messaging nor nicknames. If another participant,
say Bob, sends a private message to Alice, the MSRP switch does not
distribute it to Alice, because Alice is not able to differentiate it
from a regular message sent to the whole roster. Further more, if
Alice replied to this message, she would do it to the whole roster.
Because of this, the MSRP mixer keeps also track of users who do not
support the extensions defined in this document.
In another scenario, the policy of a chat room may indicate that
certain functions are not allowed. For example, the policy may
indicate that nicknames or private messages are not allowed.
In order to provide the user with a good chatroom experience, we
define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a
media-level attribute that MAY be included in conjunction with and
MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP"
or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the
intersection of support and chatroom local policy allowance for a
number of functions specified in this document. Specifically, we
provide the means for indicating support to use nicknames and private
messaging.
The 'chatroom' SDP attribute has the following syntax:
chatroom = chatroom-label ":" chat-token *(SP chat-token)
chatroom-label = "chatroom"
chat-token = (nicknames-token | private-msg-token | token)
nicknames-token = "nicknames"
Niemi & Garcia-Martin Expires December 14, 2007 [Page 9]
Internet-Draft Multiparty MSRP June 2007
private-msg-token = "private-messages"
A conference focus that includes the 'nicknames' token in the session
description is signalling that the MSRP switch supports and the
chatroom allows to use the procedures specified in Section 6. A
conference focus that includes the 'private-messages' in the SDP
description is signalling that the MSRP switch supports and the
chatroom allows to use the procedures specified in Section 7.2.
Example of the 'chatroom' attribute for an MSRP media stream that
indicates the acceptance of nicknames and private messages:
a=chatroom:nickname private-messages
5.4. Deleting a Chat Room
As with creating a conference, the methods defined by the SIP
Conference Framework [RFC4353] for deleting a conference are directly
applicable to a chat room.
Deleting a chat room is an action that heavily depends on the policy
of the chat room. The policy can determine that the chat room is
deleted when the creator leaves the conference, or with any out of
band mechanism.
6. Nicknames
A common characteristic of existing chat room services is that
participants have the ability to identify themselves with a nickname
to the rest of the participants of the conference. This provides a
layer of anonymity, whereby the conference server authenticates the
participant, but still allows the participant to keep anonymity of
his SIP URI towards the rest of the participants without downgrading
his services. Specifically, anonymous participants are able to
receive private instant messages through the conference server from
other participants without revealing their SIP URI.
Nicknames are a useful construct in many use cases, of which MSRP
chat is but one example. Nicknames are an alternate form of
identity, associated with a URI (which may be an Address of Record,
or anonymous URI, or some other URI). It is not a 'display-name',
but it is used somewhat like a display name. Nicknames may be long
lived, or may be temporary. Nicknames are scoped within a domain,
and are unique within that domain. Users need to reserve a nickname
in a domain prior to its utilization. The domain issuing nicknames
need not be the domain of the AoR, but could be. Another useful
domain to temporarily reserve nicknames is the domain of the
Niemi & Garcia-Martin Expires December 14, 2007 [Page 10]
Internet-Draft Multiparty MSRP June 2007
conference server.
We take the approach of representing a nickname as a SIP (or SIPS)
URI. Since nicknames are issued by a domain, and scoped to that
domain, the form of nickname in protocol operations is
"sip:nickname@domain". A domain issues a nickname and provides it to
a user for his disposal.
The conference server (MSRP chat server) may have policies associated
with nicknames. It may not accept nicknames at all for the ongoing
conference. Or it may accept nicknames issued by a variety of
domains, or it may restrict the domains it accepts nicknames from.
It may, for example only allow nicknames it issues itself.
Nicknames are typically used for displaying purposes. The endpoint's
user interface would typically display the user part of the nickname
URI, but will not display the domain part of a nickname. This could
lead to a situation where multiple nicknames have the same user part,
with different domain parts. They are unique, but the user interface
may have to display the nicknames with decorations to show them as
unique, "Bob(3)" for example.
Operations on nicknames include:
o Reservation of a nickname: granting exclusive usage rights of a
nickname to a given SIP AoR. Effectively, the reservation of a
nickname implies mapping a nickname to a SIP AoR. Reservations
can be temporarily or permanent.
o Validation of a nickname by the domain that reserved it and issued
it. Validation is an official confirmation from the domain that
the issued the nickname, that the nickname is associated with the
claimed SIP AoR.
o Putting a nickname into operation within a conversation or chat.
Effectively, it requires the MSRP mixer to be able to receive MSRP
SEND requests addressed to a nickname and route them to the holder
of the nickname.
This document describes a simple form of temporarily reservation of a
nickname with the domain of the conference server using the putting
in use mechanism. In particular, this specification does not provide
a general mechanism for domains issuing nicknames, other than the
domain of the conference server. Additionally, this document
describes one mechanism for putting a nickname into operation.
We define a nickname as a SIP or SIPS URI, as follows:
Niemi & Garcia-Martin Expires December 14, 2007 [Page 11]
Internet-Draft Multiparty MSRP June 2007
Nickname = nickname-URI
An example of a nickname is:
sip:Alice%20in%20wonderland@example.com
The user part of the URI contains the nickname reserved by the user,
subject to the percentage encoding rules of the SIP grammar. The
user part of the URI is used for rendering purposes. The complete
Nickname URI is used for routing of private messages, as we describe
later. This requires that the conference server maintains a table
for correlation of nickname URIs, SIP URIs and MSRP sessions
pertaining to a participant.
Let us take a look at an example of a nickname built by the chat room
server. Assume the chat room URI is responsible for reserving
nicknames for the domain 'example.com'. A user whose nickname is
'nordic%20guy' gets represented with a nickname URI of
'sip:nordic%20guy@example.com'.
An interesting property of this approach is that nickname URIs do not
really resolve to the SIP UA or real identity of the user. Instead,
they resolve elsewhere, for example, the conference server, or some
other host of the administrative domain that issues the nickname.
The entity that reserves the nickname (e.g., the conference server)
and the owner of the nickname are able to map nickname URIs to their
corresponding SIP URI of the user. Other participants can use the
conference server as an intermediary for delivery of private messages
addressed to any of the nickname URIs of the chat room.
6.1. Using Nicknames within a Conference
As indicated earlier, this specification provides a mechanism for the
conference server to temporarily reserve a nickname to a user, and
for putting them into operation in the conference. The mechanism
provides the participant with a nickname at the user's disposal for
the duration of time the participant is logged into the chat room.
The mechanism is based on a NICKNAME MSRP method (see below) and a
new "Use-Nickname" header. Note that other mechanisms may exists
(for example, a web page reservation system), although they are
outside the scope of this document.
A conference participant who has established an MSRP session with an
MSRP switch, where the MSRP switch has indicated the support and
availability of nicknames with the 'nicknames' token in the
'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP
switch. The NICKNAME request MUST include a new Use-Nickname header
that contains the nickname URI that the participant wants to reserve.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 12]
Internet-Draft Multiparty MSRP June 2007
An MSRP switch that receives a NICKNAME request containing a
nicknames in the Use-Nickname header field SHOULD first verify
whether the policy of the chat room allows the nickname
functionality. If is not allowed, the MSRP switch MUST answer with a
501 response.
If the policy of the chatroom allows the usage of nicknames, the MSRP
switch then validates the nickname URI against the authenticated URI
that the user participant provided when he joined the session, (e.g.,
a SIP URI). The participant's authenticated identity can be derived
after a successful HTTP Digest Authentication, or be included in a
trusted SIP P-Asserted-Identity header field, included in a valid SIP
Identity header field, or derived from any other present or future
SIP authentication mechanism.
Once the MSRP switch has validated that the participant is entitled
to use the nickname, the MSRP switch maps the nickname URI with the
participant's own authenticated URI and its MSRP session. Then the
MSRP switch answers to the MSRP NICKNAME request with a 200 response.
The reservation of a nickname can fail, e.g., if the NICKNAME request
contains a malformed or non-existent Use-Nickname header field, or if
the same nickname is already in use by another participant. The
validation can also fail, e.g., if the Use-Nickname header contains a
nickname URI for which the conference server has no authority and the
conference server does not have the means to validate the nickname
from the domain that issued it. In any of these cases, if the MSRP
switch cannot validate a nickname towards an authenticated identity,
the MSRP switch MUST answer with a newly defined 423 response. The
semantics of the 423 response are: "Nickname usage failed; the
nickname is not allocated to this user".
Typically participants will reserve a nickname as soon as they join
the chat room, prior to sending any messages. During the duration of
the session, participants can replace their current nickname by
issuing a new MSRP NICKNAME request that contains a new nickname in
the Use-Nickname header. If the response is successful, e.g., a 200
response, then the old nickname is discarded and the new nickname is
in brought into use. A response different than a 200 indicates that
the transaction failed, in which case the old nickname (if any) is
still in use and at the participant's disposal, and the new nickname
is not used.
As indicated earlier, this specification defines a new MSRP header
field: "Use-Nickname". The Use-Nickname header field carries a
single nickname (i.e., a SIP/SIPS URI) and SHOULD be included in
NICKNAME requests. URIs included in the Use-Nickname header field
MUST be formatted according to the conventions for nickname URIs.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 13]
Internet-Draft Multiparty MSRP June 2007
The syntax of the NICKNAME method and the "Use-Nickname" header field
is built upon the MSRP formal syntax
[I-D.ietf-simple-message-sessions] and the SIP formal syntax
[RFC3261]:
ext-method =/ NICKNAMEm
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header is specified in RFC XXXX
; name-addr is specified in RFC 3261
Use-Nickname = "Use-Nickname" ":" name-addr
The 'name-addr' ABNF in RFC 3261 allows an optional 'display-name' to
prepend the actual URI. For the purpose of conveying nicknames,
display-names MUST NOT be used, because the username part of a
nickname URI provides its rendering property. If the display-name is
included in an Use-Nickname header field, it SHOULD be ignored.
Implementations are RECOMMENDED to use only the user part of the
nickname URI for rendering purposes.
6.2. Modifying a Nickname
Typically participants will reserve a nickname as soon as they join
the chat room, prior to sending any messages. But it is also
possible for participants to modify their own nicknames and replace
them it a new one at any time during the duration of the MSRP
session. Modification of the nickname is not different from the
initial reservation and usage of a nickname, thus the NICKNAME method
is used as described in Section 6.1.
If a NICKNAME request that attempts to modify the current nickname of
the user for some reason fails, the current nickname stays in effect.
A new nickname comes into effect and the old one is released only
after a NICKNAME request is accepted with a 200 repsonse.
6.3. Mapping Nicknames to Other Identities
The MSRP switch maintains a mapping table that correlates, for a
given user, their nickname, SIP URI, and MSRP session ID. This
correlation is valid for the duration of the session (unless
mechanisms specified elsewhere exists to provide long-lasting
nicknames). Thus, at the dismissal of the session the MSRP switch
should dispose the nickname and make it available to other
participants.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 14]
Internet-Draft Multiparty MSRP June 2007
6.4. Nicknames in the Conference Event Package
Typically the conference focus acts as a notifier of the SIP
conference event package [RFC4575]. The conference focus MAY notify
subscribers of the nickname allocated to a given participant. We
define an extension to the conference event package to include
nicknames. The extension defines a new <nickname> element as a child
element of the existing <user> element. The <nickname> element
includes an 'entity' attribute that contains the nickname URI. A
child <display-name> element contains the display name of the
nickname.
TO BE DONE: include a formal definition of the <nickname>
extension to the conference event package.
6.5. Nicknames and Multiple SIP Addresses of Record
This section provides additional considerations related to the
relation of nicknames and addresses of records.
As we indicated earlier, nicknames are represented as SIP URIs.
There are no distinctions in the URI that can differentiate a
nickname from a regular Address of Record allocated to a user. In
other words, nicknames and Addresses of Record share the same address
space. Then it is possible that a user tries to put in operation a
nickname URI which is allocated to another user. A policy in the
MSRP mixer determines whether avoidance of collisions between
nicknames and regular Addresses of Record is enforced. In
particular, the model supported by this specification, where
nicknames are issued by the domain of the conference server, makes
easy for the conference server to avoid collision with regular
Addresses of Records.
In another scenario, it is possible that a user, identified by a SIP
Address of Record, joins a conference of instant messages from two or
more different SIP UAs. Then the user can issue the MSRP NICKNAME
method from each of these UAs, and he can try to use the same
nickname from each of the different UAs. A policy in the conference
server determines whether a user who is participating in the
conference from various UAs is allowed to use the same nickname
across those UAs. In case the policy allows it, when the MSRP switch
received a private message addressed to this nickname, the MSRP
switch MUST send a copy of the message through each MSRP session
where the user is using this nickname.
Similarly, the conference server can have a policy that requires a
user who is logged from different UAs to select a different nickname
from a different UA. In other words, once a nickname has been
Niemi & Garcia-Martin Expires December 14, 2007 [Page 15]
Internet-Draft Multiparty MSRP June 2007
reserved for a user, the user can only use it once at the same time.
This case does not impose an additional requirement to the MSRP
mixer: if the MSRP mixer receives a private message addressed to a
nickname, the message is routed through the MSRP session where the
nickname is used.
7. Sending and Receiving Instant Messages
7.1. Regular Messages
This section describes the conventions used to send and receive
instant messages that are addressed to all the participants in the
chat room. These are sent over a regular MSRP SEND request that
contains a Message/CPIM wrapper [RFC3862] that in turn contains the
desired payload (e.g., text, image, video-clip, etc.).
When a chat room participant wishes to send an instant message to all
the other participants in the chat room, he constructs an MSRP SEND
request that MUST contain a top-level wrapper of type 'Message/CPIM'
[RFC3862]. The actual instant message payload inside 'Message/CPIM'
MAY be of any type negotiated in the SDP 'accepted-types' attribute
according to the MSRP rules.
The sender SHOULD populate the From header of the Message/CPIM
wrapper with a proper identity by which the user is recognized in the
conference. Identities that can be used (among others) are:
o A SIP URI [RFC3261] representing the participant's address-of-
record
o A tel URI [RFC3966] representing the participant's telephone
number
o An IM URI [RFC3860] representing the participant's instant
messaging address
o A nickname URI formatted according to the rules indicated in
Section 6 and allocated for the user.
If the sender of the message wants to remain anonymous to the rest of
the participants, and providing that the policy of the conference
allows anonymous participation, the creator SHOULD populate the From
header of the Message/CPIM body with an anonymous identity, e.g.,
using the "anonymous" SIP URI as described in RFC 3261 [RFC3261]
Section 8.1.1.3. or using a nickname URI (see Section 6) that has
been allocated to the user.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 16]
Internet-Draft Multiparty MSRP June 2007
The sender MUST populate the To header field of the Message/CPIM body
with the chat room URI.
An MSRP switch that receives a SEND request from a participant SHOULD
first verify that the From header field of the Message/CPIM wrapper
is correctly populated with a valid URI as indicated earlier. If the
URI included in the From header field of the Message/CPIM wrapper is
not valid (e.g, because it does not "belong" to the user), then the
MSRP switch MUST generate a 403 response and MUST NOT forward the
SEND request to any of the participants. Otherwise, the MSRP switch
SHOULD generate a 200 response according to the MSRP rules for
response generation.
Then the MSRP switch should inspect the To header field of the
Message/CPIM wrapper. If the To header field of the Message/CPIM
wrapper contains the chat room URI, the MSRP switch can generate a
copy of the SEND request to each of the participants in the
conference except the sender. The MSRP switch MUST NOT modify any of
the bodies included in the received SEND request. Note that the MSRP
switch does not need to wait for the reception of the complete MSRP
chunk or MSRP message before it starts the distribution to the rest
of the participants. Instead, once the MSRP switch has received the
headers of the Message/CPIM body it SHOULD start the distribution
process.
An MSRP endpoint that receives a SEND request from an MSRP switch
containing a Message/CPIM wrapper SHOULD first inspect the To header
field of the Message/CPIM body. If the To header field is set to the
chat room URI, then it is a regular message that has been distributed
to all the participants in the conference. Then the MSRP endpoint
SHOULD inspect the From header field of the Message/CPIM body to
identify the sender. The From header field will include a URI that
identifies the sender. The endpoint might have also received further
identity information through a subscription to the SIP conference
event package [RFC4575].
7.2. Private Messages
This section describes the conventions used to send and receive
private instant messages, i.e., instant messages that are addressed
to one or more selected participants of the chat room rather to all
of them. A private instant message is sent over a regular MSRP SEND
request that contains a Message/CPIM wrapper [RFC3862] which contains
the desired payload (e.g., text, image, video-clip, etc.), according
to the procedures of RFC 3862 [RFC3862].
When a chat room participant wishes to send a private instant message
to one or more participants in the chat room, he constructs an MSRP
Niemi & Garcia-Martin Expires December 14, 2007 [Page 17]
Internet-Draft Multiparty MSRP June 2007
SEND request that MUST contain a top-level wrapper of type 'Message/
CPIM' [RFC3862]. The actual instant message payload inside 'Message/
CPIM' MAY be of any type negotiated in the SDP 'accepted-types'
attribute according to the MSRP rules.
The sender SHOULD populate the From header of the Message/CPIM
wrapper with a proper identity by which the user is recognized in the
conference as indicated for regular instant messages. Then the
sender MUST populate the To header field and MAY populate the Cc
header field of the Message/CPIM with the identity of intended
recipients. These identities include SIP, TEL, and IM URIs, and
nickname URIs (see Section 6) typically learnt from the information
received in notifications of the conference event package [RFC4575].
As for regular messages, an MSRP switch that receives a SEND request
from a participant SHOULD first verify that the From header field of
the Message/CPIM wrapper is correctly populated with a valid URI as
indicated earlier. If the URI included in the From header field of
the Message/CPIM wrapper is not valid (e.g, because it does not
"belong" to the user), then the MSRP switch MUST generate a 403
response and MUST NOT forward the SEND request to any of the
participants. Otherwise, the MSRP switch SHOULD generate a 200
response according to the MSRP rules for response generation.
Then the MSRP switch MUST inspect the To header field of the Message/
CPIM wrapper. If the To header field of the Message/CPIM wrapper
does not contain the chatroom URI the MSRP switch inspects the URIs
included in both the To and Cc headers. For each URI found there,
the MSRP switch first searches for support for private messages from
the intended recipient. If the recipient does not support private
messages, the MSRP switch does not forward the message to that
recipient. For each of the remaining intended recipients, the MSRP
switch searches in its mapping table to find the MSRP session
established towards the user's MSRP endpoint. Once a match is found
the MSRP switch MUST create a SEND request on that MSRP session and
MUST copy the contents (e.g., the whole Message/CPIM wrapper and its
bodies) to a SEND request and send it over that MSRP session.
There might be situations where one or more URIs included in the To
or Cc headers of the Message/CPIM wrapper cannot resolve to existing
MSRP sessions, e.g., due to a mistyped URI or because the recipient
has abandoned the chat room. In this case it might be benefitial for
the sender to become aware of which recipients the MSRP switch failed
to resolve. To support this case we define a new MSRP response code
427. This response code is not used in MSRP responses, but as part
of the REPORT status code. Note that the 427 status code in a REPORT
request merely indicates a failure in resolving a URI to an active
MSRP session, and it does not indicate whether the SEND request was
Niemi & Garcia-Martin Expires December 14, 2007 [Page 18]
Internet-Draft Multiparty MSRP June 2007
successfully received by any of the recipients (it might be still
possible that a URI resolves to an active MSRP session but the SEND
request cannot be delivered due to congestion, failure of the TCP
connection, or any failure at the recipient's MSRP endpoint).
If the MSRP switch cannot resolve any of the URIs included in the To
or Cc headers, and the Failure-Report header field of the SEND
request was either not present in the original request, or had a
value of "yes", the MSRP switch MUST generate a REPORT request to the
sender. The Status header field MUST be set to 427. The REPORT
request MUST include a Message/CPIM wrapper, with the original From
header field included in the SEND request, and the To and Cc header
fields containing the subset of failed-to-resolve URIs included in
the To and Cc header fields of original Message/CPIM wrapper,
respectively.
An MSRP endpoint that receives a SEND request from an MSRP switch
containing a Message/CPIM wrapper SHOULD first inspect the To header
field of the Message/CPIM body. If the To header field is not set to
the chat room URI, then it is a private message that has been
distributed to only selected participants in the conference
(addressed in the To and Cc headers of the Message/CPIM body). Then
the MSRP endpoint SHOULD inspect the From header field of the
Message/CPIM body to identify the sender. The From header field will
include a URI that identifies the sender. The endpoint might have
also received further identity information through a subscription to
the SIP conference event package [RFC4575].
8. Sidebars
This document does not provide any protocol means to create,
manipulate, or send messages to sidebars. In many cases, a sidebar
is a logical subgroup of participants which exists only in each of
the recipients endpoints. Sending a message to the sidebar is
modelled as a private message addressed to each of the members of the
sidebar. As such, it is to possible to re-create the 'sidebar user
experience' totally in the endpoints by correlating collections of
private messages, thus, this document does not create any sidebar-
specific mechanism.
9. Examples
9.1. Joining a chat room
Figure 6 presents a flow diagram where Alice joins a chat room by
sending an INVITE request. This INVITE request contains a session
Niemi & Garcia-Martin Expires December 14, 2007 [Page 19]
Internet-Draft Multiparty MSRP June 2007
description that includes the chatroom extensions defined in this
document.
Alice Conference focus
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
Figure 6: Flow diagram of a user joining a chat room
F1: Alice constructs an SDP description that includes an MSRP media
stream. She also indicates her support for the chatroom extensions
defined in this document. She sends the INVITE request to the
chatroom server.
INVITE sip:chatroom22@chat.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: [length]
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
a=chatroom:nickname private-messages
Figure 7: INVITE request containing an SDP offer with chatroom
extensions
F2: The chatroom server accepts the session establishment. It
includes the 'isfocus' and other relevant feature tags in the Contact
header field of the response. The chatroom server also builds an SDP
answer that also that forces the reception of messages wrapped in
message/cpim envelops. It also includes the the chatroom attribute
Niemi & Garcia-Martin Expires December 14, 2007 [Page 20]
Internet-Draft Multiparty MSRP June 2007
with the allowed extensions.
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: [length]
v=0
o=chat 2890844527 2890844527 IN IP4 chat.example.com
s=-
c=IN IP4 chat.example.com
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
a=chatroom:nickname private-messages
Figure 8: 200 (OK) response including chatroom extensions
F3: The session established is acknowledged (details not shown).
9.2. Setting up a nickname
Figure 9 shows an example of Alice setting up a nickname. Her first
proposal is not accepted because the proposed nickname is already in
use. Her second proposal is accepted.
Alice MSRP mixer
| |
|(1) (MSRP) NICKNAME |
|----------------------->|
|(2) (MSRP) 423 |
|<-----------------------|
|(3) (MSRP) NICKNAME |
|----------------------->|
|(4) (MSRP) 200 |
|<-----------------------|
| |
Figure 9: Flow diagram of a user setting up her nickname
Niemi & Garcia-Martin Expires December 14, 2007 [Page 21]
Internet-Draft Multiparty MSRP June 2007
F1: Alice sends an MSRP NICKNAME request that contains her proposed
nicknames in the Set-Nickname header field.
MSRP d93kswow NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: <sip:Alice%20the%great@example.com>
-------d93kswow$
Figure 10: MSRP NICKNAME request with an initial nickname proposal
F2: The MSRP mixer analyzes the existing allocation of nicknames and
detects that the nickname identified by the URI
sip:Alice%20the%20great@example.com is already in used by another
participant. The MSRP mixer answers with a 423 response.
MSRP d93kswow 423 Nickname usage failed
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
Figure 11: MSRP 423 response
F3: Alice receives the response. She proposes a new nickname in a
second NICKNAME request.
MSRP 09swk2d NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: <sip:Alice%20in%20wonderland@example.com>
-------09swk2d$
Figure 12: MSRP NICKNAME request with a second nickname proposal
F4: The MRSP mixer accepts the nickname proposal and answers with a
200 response.
MSRP 09swk2d 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------09swk2d$
Figure 13: MSRP NICKNAME request
Niemi & Garcia-Martin Expires December 14, 2007 [Page 22]
Internet-Draft Multiparty MSRP June 2007
9.3. Sending a regular message to the chat room
Figure 14 depicts a flow diagram where Alice is sending a regular
message addressed to the chat room. The MSRP mixer distributes the
message to the rest of the participants.
Alice MSRP mixer Bob Charlie
| | | |
| (1) (MSRP) SEND | | |
|--------------------->| (3) (MSRP) SEND | |
| (2) (MSRP) 200 |----------------------->| |
|<---------------------| (4) (MSRP) SEND | |
| |------------------------------->|
| | (5) (MSRP) 200 OK | |
| |<-----------------------| |
| | (6) (MSRP) 200 OK | |
| |<------------------------------ |
| | | |
| | | |
Figure 14: Sending a regular message to the chat room
F1: Alice builds a text message and wraps it in a CPIM message. She
addresses the CPIM message to the chat room. She encloses the result
in an MSRP SEND request and sends it to the MSRP mixer via the
existing TCP connection.
MSRP 3490visdm SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 99s9s2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:Alice%20in%20wonderland@example.com>
DateTime: 2007-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------3490visdm$
Figure 15: Instant message addressed to all participants in the chat
room
F2: The MSRP mixer acknowledges the reception of the SEND request
with a 200 (OK) response.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 23]
Internet-Draft Multiparty MSRP June 2007
MSRP 3490visdm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: 99s9s2
Byte-Range: 1-*/*
-------3490visdm$
Figure 16: 200 (OK) response
F3: The MSRP mixer creates a new MSRP SEND request that contains the
received message/cpim body and sends it to Bob.
MSRP 490ej23 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: 304sse2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:Alice%20in%20wonderland@example.com>
DateTime: 2007-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------490ej23$
Figure 17: Instant message sent to all participants
The rest of the message flows are analogous to the previous. They
are not shown here.
9.4. Sending a private message to a participant
Figure 18 depicts a flow diagram where Alice is sending a private
message addressed to Bob's nickname. The MSRP mixer distributes the
message only to Bob.
Alice MSRP mixer Bob Charlie
| | | |
| (1) (MSRP) SEND | | |
|--------------------->| (3) (MSRP) SEND | |
| (2) (MSRP) 200 |----------------------->| |
|<---------------------| (4) (MSRP) SEND | |
| |------------------------------->|
| | | |
| | | |
Niemi & Garcia-Martin Expires December 14, 2007 [Page 24]
Internet-Draft Multiparty MSRP June 2007
Figure 18: Sending a private message to Bob
F1: Alice builds a text message and wraps it in a CPIM message. She
addresses the CPIM message to the Bob's nickname, which she learnt
from a notification in the conference event package. She encloses
the result in an MSRP SEND request and sends it to the MSRP mixer via
the existing TCP connection.
MSRP 6959ssdf SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: okj3kw
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:Bob%20the%20great@example.com>
From: <sip:Alice%20in%20wonderland@example.com>
DateTime: 2007-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------6959ssdf$
Figure 19: Private instant message addressed to one participant
F2: The MSRP mixer acknowledges the reception of the SEND request
with a 200 (OK) response.
MSRP 6959ssdfm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: okj3kw
Byte-Range: 1-*/*
-------6959ssdfm$
Figure 20: 200 (OK) response
F3: The MSRP mixer creates a new MSRP SEND request that contains the
received message/cpim body and sends it only to Bob. Bob can
distinguish the sender in the From header of the CPIM message. He
also identifies this as a private message due to the To CPIM header.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 25]
Internet-Draft Multiparty MSRP June 2007
MSRP 9v9s2 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: d9fghe982
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:Bob%20the%20great@example.com>
From: <sip:Alice%20in%20wonderland@example.com>
DateTime: 2007-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------9v9s2$
Figure 21: Private instant message sent to Bob
Flow F4 is not shown.
10. IANA Considerations
TBD.
11. Security Considerations
This document proposes extensions to the Message Session Relay
Protocol [I-D.ietf-simple-message-sessions]. Therefore, the security
considerations of such document apply to this document as well.
In general, messages sent to a multi-party session based messaging
focus are not deem to expose any security threat. Nevertheless, if a
participant wants to avoid eavesdropping from non authorized
entities, it should send those messages a TLS [RFC4346] transport
connection, as allowed by MSRP.
12. Contributors
This work would have never been possible without the fruitful
discussions in the SIMPLE WG mailing list, specially with Brian Rosen
(Neustar) and Paul Kyzivat (Cisco), who provided extensive review and
improvements throughout the document.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 26]
Internet-Draft Multiparty MSRP June 2007
13. Acknowledgements
The authors want to thank Eva Leppanen, Adamu Haruna, and Adam Roach
for providing comments.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3860] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-19 (work in progress),
February 2007.
14.2. Informative References
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.
Niemi & Garcia-Martin Expires December 14, 2007 [Page 27]
Internet-Draft Multiparty MSRP June 2007
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[I-D.ietf-xcon-framework]
Barnes, M., "A Framework for Centralized Conferencing",
draft-ietf-xcon-framework-08 (work in progress), May 2007.
Authors' Addresses
Aki Niemi
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
Email: aki.niemi@nokia.com
Miguel A. Garcia-Martin
Nokia Siemens Networks
P.O.Box 6
Nokia Siemens Networks, FIN 02022
Finland
Email: miguel.garcia@nsn.com
Niemi & Garcia-Martin Expires December 14, 2007 [Page 28]
Internet-Draft Multiparty MSRP June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Niemi & Garcia-Martin Expires December 14, 2007 [Page 29]
