Network Working Group A. Niemi
Internet-Draft M. Garcia-Martin
Expires: January 19, 2006 Nokia
July 18, 2005
Multi-party Instant Message (IM) Sessions using the Message Session
Relay Protocol (MSRP)
draft-niemi-simple-chat-03
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 January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 message (IM) sessions, or
chat rooms, using the centralized conferencing model.
Niemi & Garcia-Martin Expires January 19, 2006 [Page 1]
Internet-Draft Multiparty MSRP July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations and Requirements . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
5. Detailed Specification . . . . . . . . . . . . . . . . . . . . 7
5.1 Creating a Chat Room . . . . . . . . . . . . . . . . . . . 7
5.2 Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 8
5.3 Conference Participant Behavior . . . . . . . . . . . . . 8
5.3.1 Sending Instant Messages . . . . . . . . . . . . . . . 8
5.3.2 Sending Private Instant Messages . . . . . . . . . . . 9
5.3.3 Requesting Reports . . . . . . . . . . . . . . . . . . 10
5.3.4 Receiving Instant Messages . . . . . . . . . . . . . . 11
5.3.5 Receiving Private Instant Messages . . . . . . . . . . 11
5.4 MSRP Switch Behavior . . . . . . . . . . . . . . . . . . . 11
5.4.1 Relaying Instant Messages . . . . . . . . . . . . . . 12
5.4.2 Relaying Private Instant Messages . . . . . . . . . . 12
5.4.3 Generating reports . . . . . . . . . . . . . . . . . . 13
6. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Provisioning Nicknames . . . . . . . . . . . . . . . . . . 14
6.2 Modifying a Nickname . . . . . . . . . . . . . . . . . . . 14
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 The MSRP DISTSEND method . . . . . . . . . . . . . . . . . 15
7.2 The MSRP Distribution Header Field . . . . . . . . . . . . 15
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1 Normative References . . . . . . . . . . . . . . . . . . . 15
11.2 Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Niemi & Garcia-Martin Expires January 19, 2006 [Page 2]
Internet-Draft Multiparty MSRP July 2005
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 [I-D.ietf-sipping-conferencing-framework].
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 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.
The aim of this document is to define requirements, conventions and
extensions for enabling features similar to many of these existing
systems in the Internet, e.g., Internet Relay Chat (IRC) [RFC2810]
and Extensible Messaging and Presence Protocol [RFC3920] based chat
rooms.
This memo uses the SIP Conferencing Framework [I-D.ietf-sipping-
conferencing-framework] as a design base.
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 [I-D.ietf-sipping-
conferencing-framework] applied to the scope of this document. In
addition to that terminology, we introduce some new terms:
Niemi & Garcia-Martin Expires January 19, 2006 [Page 3]
Internet-Draft Multiparty MSRP July 2005
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.
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.
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.barnes-xcon-framework] and the SIP
Conferencing Framework [I-D.ietf-sipping-conferencing-framework], 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.
A number of requirements that enrich the session based messaging
conferences have already been described in Requirements for Instant
Messaging in 3GPP Wireless Systems [I-D.niemi-simple-im-wireless-
reqs] or the Advanced Instant Messaging Requirements for the Session
Niemi & Garcia-Martin Expires January 19, 2006 [Page 4]
Internet-Draft Multiparty MSRP July 2005
Initiation Protocol [I-D.rosenberg-simple-messaging-requirements].
In addition, we define the following requirements:
REQ-1: The conference must have the ability to host other media in
addition to MSRP, as well as multiple streams of MSRP.
REQ-2: A conference participant must be able to determine the
identities of the sender and recipient of the received IMs.
REQ-3: 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
(i.e., a private message).
REQ-4: 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-5: It must be possible to set up a sidebar session with one or
more participants of the chat room.
REQ-6: A conference participant may have a nickname or pseudonym
associated with their real identity.
REQ-7: It must be possible for a participant to change their
nickname during the progress of the conference.
OPEN ISSUE: This requirement (and the one above it) is not
strictly an IM conference issue. In principle,
participants of any conferences should be able to use a
nickname, and change their nickname in the course of the
conference.
REQ-8: 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-9: 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-10: A chat room, or a chat room sidebar must be able to be
characterized with a topic whose purpose is to identify the
subject of conversation.
Niemi & Garcia-Martin Expires January 19, 2006 [Page 5]
Internet-Draft Multiparty MSRP July 2005
REQ-11: A user with the appropriate privileges must be able to set
and/or modify the topic of the chat room, or chat room
sidebar.
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 conference has an identity, a SIP URI that participants use to
join the conference, e.g., by sending an INVITE. The conference
focus processes the invitations, and as such maintains SIP dialogs
with all of the participants. In an instant messaging conference, or
chat room, one of the media streams offered is MSRP. Each conference
participant establishes an MSRP session with an MSRP switch, which is
a special purpose MSRP client. The MSRP switch is similar to a
conference mixer, in that it is 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 doesn't actually mix the streams in any way.
The system is illustrated in Figure 1.
Niemi & Garcia-Martin Expires January 19, 2006 [Page 6]
Internet-Draft Multiparty MSRP July 2005
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
Figure 1: Multiparty MSRP in a Centralized Conference
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. The switch then fans out the SEND to all of the other
participants, using their MSRP sessions. A participant can also send
a private communication by constructing an MSRP DISTSEND request with
an appropriate recipient and submitting it to the MSRP switch. The
switch will distribute the private message only to the indicated
recipient rather than the full conference roster. If private
communication is not supported (e.g., due to being disallowed by
conference policy) the switch will not accept the DISTSEND method.
All messages in the chat room use the 'message/cpim' wrapper content
type [RFC3862], which enables identification of the message sender,
intended recipient(s) and possible recipients of carbon-copies. Any
MIME type can be included inside the wrapper type, e.g., 'text/
plain', 'text/html', 'image/jpeg' etc.
When a participant wishes to leave a chat room, it sends a SIP BYE
request to the conference focus and disconnects.
More specific description of conference control functions are TBD.
Niemi & Garcia-Martin Expires January 19, 2006 [Page 7]
Internet-Draft Multiparty MSRP July 2005
5. Detailed Specification
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 [I-D.ietf-sipping-conferencing-
framework] 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. 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 an MSRP switch due to
the presence of the 'message' media type and either TCP/MSRP or TCP/
TLS/MSRP as the protocol field in the SDP [RFC2327] media-line.
The conference focus of a chat room MUST insist on a Message/CPIM
[RFC3862] top-level wrapper for the MSRP messages by setting the
'accept-wrapped-types' attribute in the SDP offer or answer to
include 'message/cpim'. It SHOULD also set the 'accept-types'
attribute to '*', to indicate that any MIME type can be sent, unless
the conference policy mandates certain types only.
Note that 'message/cpim' is used to carry sender and recipient
information for each instant message. The CPIM header will
contain the sender, recipient(s) and any recipients of a carbon-
copy.
5.2 Deleting a Chat Room
As with creating a conference, the methods defined by the SIP
Conference Framework [I-D.ietf-sipping-conferencing-framework] 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.
5.3 Conference Participant Behavior
5.3.1 Sending Instant Messages
MSRP provides the SEND primitive that allows a sender to transport an
instant message to the recipient. When a chat room participant
Niemi & Garcia-Martin Expires January 19, 2006 [Page 8]
Internet-Draft Multiparty MSRP July 2005
wishes to send an instant message to the chat room, it constructs a
SEND request. The contents of the message MUST be encapsulated using
the top-level wrapper of type 'message/cpim' [RFC3862]. The actual
instant message payload inside 'message/cpim' MAY be of any type
listed in the 'accept-types' attribute of the conference focus' SDP
answe, e.g., text/plain, text/html, etc.
A conference-aware participant that sends a session based instant
message to an MSRP switch 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 participan't telephone number
o An IM URI [RFC3860] representing the participant's instant
messaging address
If the creator 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 include an
anonymous identity, e.g., using the "anonymous" SIP URI as described
in RFC 3261 [RFC3261] Section 8.1.1.3.
A conference-aware participant that sends a session based instant
message addressed to the chat room MUST set the To header of the
Message/CPIM header to the SIP URI [RFC3261] of the conference focus,
or to the URI of the participant(s) for which the instant message is
targeted.
Note that this URI can be any URI by which the recipient
participant is known in the conference. It can also be the
anonymous URI type, as discussed above.
5.3.2 Sending Private Instant Messages
Sending of MSRP messages to a reduced set of the participants of the
conference requires a new MSRP method 'DISTSEND', and a new header
field 'Distribution'.
SEND cannot be used because in case the MSRP switch does not
support private instant messages, the sender of the message will
expect an error response, and instead of the message being
distributed to the default recipient, which is the entire
Niemi & Garcia-Martin Expires January 19, 2006 [Page 9]
Internet-Draft Multiparty MSRP July 2005
conference roster.
The new header Distribution contains a list of participants that the
creator wants the MSRP switch to distribute the message. This list
of participants is a subset of the participants of the conference,
whose identities have been learnt as part of the conference
procedures, for instance, by inspecting the From header of Message/
CPIM bodies previously received by the endpoint, or by information
acquired through a subscription to the conference event package
[I-D.ietf-sipping-conference-package]. Additionally, the
Distribution header can contain SIP URIs, such as the SIP URI of a
sidebar conference or one participant.
5.3.2.1 The MSRP DISTSEND method
We define a new MSRP 'DISTSEND' method. The semantics associated to
this method is to distribute the payload to a reduced set of
participants of the conference, rather than the whole set. The
actual list of recipients is included in a Distribution
(Section 5.3.2.2) header field.
DISTSEND method is governed exactly by the same rules as the existing
SEND method in MSRP, with the exception that the intended
distribution of the message is expressed in the Distribution header
field. DISTSEND requests MUST contain a Distribution header field,
and MAY contain any other MSRP header field that is appropriate for
the SEND method.
The syntax of DISTSEND method is described in Section 7.
5.3.2.2 The MSRP Distribution header field
We define a new MSRP Distribution header field, whose purpose is to
convey a list of recipients of the MSRP message. The list can
include any permanent or temporary identifier, including but not
restricted to, SIP URIs, tel URIs, MSRP URLs, nicknames, etc.
The syntax of the Distribution header field is described in
Section 7.
The mechanism described in this section is used to deliver a message
to a subset of the participants of the conference. The subset can be
indicated by the URI of a sidebar conference, or any other identifier
of a participant, including temporary identifiers (such as MSRP URLs)
and non routable identifiers (such as nicknames).
A conference-aware participant that sends an MSRP message to a subset
of the participants of the conference MUST create a DISTSEND request,
Niemi & Garcia-Martin Expires January 19, 2006 [Page 10]
Internet-Draft Multiparty MSRP July 2005
whose From-Path, To-Path and other possible header fields are created
as a regular SEND request. The MSRP endpoint MUST include a
Distribution header field that contains the list of recipients of the
message. This list MUST be include only a subset of the participants
of the conference or a URI that represents a sidebar conference.
Then the MSRP endpoint SHOULD include a Message/CPIM wrapper. The To
and Cc headers of it MUST include an identifier of the visible
recipients, according to the semantics of To and Cc (note that
invisible recipients are only listed in the MSRP Distribution
header). The From header of the Message/CPIM SHOULD include the same
information as described in Section 5.3.1.
5.3.3 Requesting Reports
An MSRP endpoint might be interesting in receiving chronological
information of the place in a sequence of MSRP messages where the
endpoint-created message has been distributed to the recipients. For
instance, and endpoint may require to insert sent messages in a
sequence of received messages, so that the user has a time
representation of the point in time at which a sent message has been
distributed, and the relative order of that message in the sequence
of other messages sent by other participants.
A possible implementation of that requirement consist of the MSRP
switch sending a copy of the message also to the creator of the
message. However, we believe this might not be efficient, e.g., if
the payload of the message is substantially large.
Instead, an MSRP endpoint that requires to receive information of the
sequence in which a message has been distributed MAY include a
Report-Success header field with the values set to "yes" in either a
SEND or DISTSEND request.
An MSRP endpoint receiving a REPORT request for one of those messages
can correlate the sequence of the sent message within the thread of
conversation, and the endpoint may provide a visual representation of
the sent message within the rest of the messages.
5.3.4 Receiving Instant Messages
Both conference-aware and conference-unaware participants will
receive MSRP SEND requests that contains a Message/CPIM message from
an MSRP switch. The From header contains the identity of the creator
of the message, in any available format. The To and Cc headers
contain the intended recipient list, which can either be the SIP URI
of the focus or the SIP URI of a sidebar conference, or any other URI
of any participant in the conference.
Niemi & Garcia-Martin Expires January 19, 2006 [Page 11]
Internet-Draft Multiparty MSRP July 2005
5.3.5 Receiving Private Instant Messages
Both conference-aware and conference-unaware participants will
receive MSRP DISTSEND requests that contains a Message/CPIM message
from an MSRP switch. The From header contains the identity of the
creator of the message, in any available format. The To and Cc
headers contain the intended recipient list, which can be any URI of
any participant in the conference.
Conference-unaware clients that do not understand the DISTSEND method
SHOULD return an appropriate error response. Upon receiving such an
error response, the MSRP switch will from then on suppress sending
any private instant messages to that participant.
We use this behavior in order to make sure private communications
are duly marked as private in the participant's MSRP client
implementations. It is notally unacceptable that a private
instant message sent to a conference-unaware recipient becomes the
topic of discussion of the full roster by mistake.
5.4 MSRP Switch Behavior
An MSRP switch can receive messages sent from either conference-aware
participants or conference-unaware participants. The switch receives
either DISTSEND or SEND request that includes a Message/CPIM wrapped
instant messages.
It is assumed that the MSRP switch is able to map an identity that
the participant is using to identify themselves in the conference and
the corresponding MSRP session. In order to do that, the conference
focus needs to maintain a mapping table between the conference
participant identities and the MSRP session(s). A mapping is
inserted into the table when a participant joins the conference, and
the mappings are indexed using the identity that is visible to the
conference roster, e.g.., the identity carried in the conference
event package [I-D.ietf-sipping-conference-package].
5.4.1 Relaying Instant Messages
Upon receiving a complete SEND request or the last chunk of a SEND
request, the MSRP switch performs the following steps:
o Else, if the content type is not 'message/cpim' the MSRP switch
aborts, and returns a 415 (Wrapper Type Unacceptable or Missing).
o The MSRP switch MUST make sure that the identity carried in the
'From' heder field of Message/CPIM wrapper in the received SEND
Niemi & Garcia-Martin Expires January 19, 2006 [Page 12]
Internet-Draft Multiparty MSRP July 2005
request is one that the sender is authorized to use.
By 'authorized' we mean that the participant has joined the
conference using that same identity, and is also known by the
other participants by that same identity.
o If not, the switch MUST reject the SEND request.
o The MSRP switch MUST create another SEND request for each of the
other conference participants, containing the body or bodies
included in the received SEND request. Then the MSRP switch sends
the newly generated SEND request to each of the recipients.
o The MSRP switch MAY need to re-chunk the outgoing SEND requests,
as part of the general procedure for chunking SEND requests.
Unless mentioned otherwise, outgoing MSRP SEND requests generated at
the MSRP switch are governed by the general procedures for creating
SEND requests specified in the MSRP specification [I-D.ietf-simple-
message-sessions].
5.4.2 Relaying Private Instant Messages
Upon receiving a complete DISTSEND request or the last chunk of a
DISTSEND request, the MSRP switch performs the following steps:
o If the chat room disallows private instant messages, the MSRP
switch MUST generate a 501 response and drop the message. A
DISTSEND message MUST NOT be distributed to the full conference
roster.
Whether a chat room allows private messages is a policy
decision and should be configurable by the conference creator.
o Else, if the content type is not 'message/cpim' the MSRP switch
aborts, and returns a 415 (Wrapper Type Unacceptable or Missing).
o Else, the MSRP switch MUST make sure that the identity carried in
the 'From' heder field of Message/CPIM wrapper in the received
DISTSEND request is one that the sender is authorized to use.
o If the switch is unable to resolve all of the URIs in the
Distribution header field to actual conference participants, or
the header field is missing, the switch MUST disregard the
unresolved URIs.
o The MSRP switch sends the received DISTSEND out to all of the
conference participants whose URI is listed in Distribution header
Niemi & Garcia-Martin Expires January 19, 2006 [Page 13]
Internet-Draft Multiparty MSRP July 2005
field. It MUST NOT send the Distribution header field to the
listed participants.
OPEN ISSUE: Alternatively, we could use the Message/CPIM To and
Cc header fields.
The MSRP switch MAY need to re-chunk the outgoing DISTSEND requests,
as part of the general procedure for chunking SEND requests.
5.4.3 Generating reports
The MSRP procedures for generating reports apply for both received
SEND and DISTSEND requests. On receiving a complete or the last
chunk of a SEND or DISTSEND request with a Report-Success header
field value set to "yes", the MSRP switch SHOULD inject a REPORT
request back to the creator preserving the order the REPORT in the
sequence of other distributed SEND or DISTSEND messages to that
endpoint.
To indicate failure to resolve one or more of the recipients in the
'Distribution' header field, the Status header field value SHOULD
contain a "000" namespace, a "481" short-status, and a "Unable to
Resolve Distribution" reason phrase. This REPORT request MUST also
contain a Distribution header field that lists all the URIs that the
MSRP switch was not able to resolve.
6. Nicknames
[Editor's note: this chapter needs strengthening.]
A common characteristic of existing chat room servers is that
participants have the ability to identify themselves with a nickname
to the rest of the participants in a conference. This provides a
layer of anonymity, whereby the user is authenticated and identified
by the chat room server, but not by participants of the chat room.
A nickname is a URI that serves for the purposes of identifying a
participant to the rest of the participants of the conference. It
isn't necessarily a URI that resolves to the user outside of a
specific conference, e.g., the "anonyous" SIP URI discssed earlier.
One option to satisfy an aspect of nicknames is using the display
name, with a real identity as the URI. A nickname in the display
name offers a pseudonym that anyone can map to a real identity, thus
not satisfying the anonymity requirements.
Another option is to use a nicknaming service, that allows allocating
nickname URIs to users. Using such a URI in a conference in effect
Niemi & Garcia-Martin Expires January 19, 2006 [Page 14]
Internet-Draft Multiparty MSRP July 2005
anonymizes the user, but still allows the user to be reached outside
the chat room using the same identity.
6.1 Provisioning Nicknames
OPEN ISSUE: Is this in scope for the work, or should the
discussion of how nicknames are provisioned (including avoiding
colliding display names) be included in this draft?
6.2 Modifying a Nickname
OPEN ISSUE: This seems like a feature that is required in all
conferneces, or even normal one-to-one calls.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 2234 [RFC2234] and extends the format
syntax of MSRP [I-D.ietf-simple-message-sessions].
7.1 The MSRP DISTSEND method
DISTSENDm = %x44.49.53.54.53.45.4E.44 ; DISTSEND in caps
Method =/ DISTSENDm
7.2 The MSRP Distribution Header Field
headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
header =/ Distribution
Distribution = "Distribution:" SP recipient-URI *( SP recipient-URI)
recipient-URI = addr-spec / telephone-uri / absolute-URI
addr-spec is imported from RFC 3261 [RFC3261].
telephone-uri is imported from RFC 3966 [RFC3966].
absolute-URI is imported from RFC 3986 [RFC3986].
Niemi & Garcia-Martin Expires January 19, 2006 [Page 15]
Internet-Draft Multiparty MSRP July 2005
8. Examples
TBD.
9. IANA Considerations
This document does not include any IANA considerations.
10. Security Considerations
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 [RFC2246] transport
connection, as allowed by MSRP.
11. References
11.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[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.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Niemi & Garcia-Martin Expires January 19, 2006 [Page 16]
Internet-Draft Multiparty MSRP July 2005
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[I-D.ietf-sipping-conferencing-framework]
Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol",
draft-ietf-sipping-conferencing-framework-05 (work in
progress), May 2005.
[I-D.barnes-xcon-framework]
Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencing", draft-barnes-xcon-framework-02
(work in progress), February 2005.
[I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-10 (work in progress),
February 2005.
11.2 Informative References
[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.
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[I-D.niemi-simple-im-wireless-reqs]
Niemi, A., "Requirements for Instant Messaging in 3GPP
Wireless Systems", draft-niemi-simple-im-wireless-reqs-02
(work in progress), October 2003.
[I-D.rosenberg-simple-messaging-requirements]
Rosenberg, J., "Advanced Instant Messaging Requirements
for the Session Initiation Protocol (SIP)",
draft-rosenberg-simple-messaging-requirements-01 (work in
progress), February 2004.
[I-D.ietf-sipping-conference-package]
Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
Niemi & Garcia-Martin Expires January 19, 2006 [Page 17]
Internet-Draft Multiparty MSRP July 2005
draft-ietf-sipping-conference-package-12 (work in
progress), July 2005.
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
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 480 4586
Email: miguel.an.garcia@nokia.com
Niemi & Garcia-Martin Expires January 19, 2006 [Page 18]
Internet-Draft Multiparty MSRP July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niemi & Garcia-Martin Expires January 19, 2006 [Page 19]