One document matched: draft-niemi-simple-chat-02.txt
Differences from draft-niemi-simple-chat-01.txt
Network Working Group A. Niemi
Internet-Draft M. Garcia-Martin
Expires: August 24, 2005 Nokia
February 20, 2005
Multi-party Message Sessions using the Message Session Relay Protocol
(MSRP)
draft-niemi-simple-chat-02
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Message Session Relay Protocol (MSRP) defines a mechanism for
sending session-based instant messages. The session is negotiated
using the Session Initiation Protocol (SIP) and the Session
Description Protocol (SDP). This document describes a mechanism to
create centralized conferences where MSRP is the media sent between
Niemi & Garcia-Martin Expires August 24, 2005 [Page 1]
Internet-Draft Multiparty MSRP February 2005
participants. Additionally, this document specifies new advanced
MSRP functionality required in centralized conferences, such as a new
MSRP primitive to send private messages through the conference
server, a mechanism to identify users with nicknames, etc.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
6. Multiparty Session Based Instant Messaging Conferencing . . . 6
6.1 Creating/deleting a chat room . . . . . . . . . . . . . . 6
6.2 Detection of an MSRP switch . . . . . . . . . . . . . . . 6
6.3 Procedures at the originating MSRP endpoint of a
conference participant . . . . . . . . . . . . . . . . . . 7
6.3.1 Sending MSRP messages to all the participants of
the conference . . . . . . . . . . . . . . . . . . . . 7
6.3.2 Sending MSRP messages to a reduced set of the
participants of the conference . . . . . . . . . . . . 8
6.3.3 Requesting reports . . . . . . . . . . . . . . . . . . 9
6.4 Procedures at the MSRP switch . . . . . . . . . . . . . . 10
6.4.1 receiving SEND requests . . . . . . . . . . . . . . . 10
6.4.2 receiving DISTSEND requests . . . . . . . . . . . . . 10
6.4.3 Generating reports . . . . . . . . . . . . . . . . . . 11
6.5 Procedures at the recipient MSRP endpoint of a
conference participant . . . . . . . . . . . . . . . . . . 12
7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 Representation of a nickname . . . . . . . . . . . . . . . 13
7.2 Provision of nicknames . . . . . . . . . . . . . . . . . . 14
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 The MSRP DISTSEND method . . . . . . . . . . . . . . . . . 14
8.2 The MSRP Distribution header field . . . . . . . . . . . . 15
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1 Normative References . . . . . . . . . . . . . . . . . . . 16
12.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Niemi & Garcia-Martin Expires August 24, 2005 [Page 2]
Internet-Draft Multiparty MSRP February 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] allows for two peers to set up such a session.
In another application of SIP, a user agent can join in a multi-party
session or 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 media.
The conference focus is responsible for relaying session-based
instant messages received from one participant to all the other
participants.
A session-based instant messaging conference is sometimes also
referred to as a chat room, and the conference focus is sometimes
referred to as the chat room server. Several of these types of
systems already exist in the Internet. Participants in a chat room
can use a rich set of features, such as the ability of sending
private instant messages to one or more participants, or to establish
sub-conferences within the existing conference.
The aim of this document is to define conventions, requirements and
extensions for enabling features similar to many of these existing
applications in the Internet, e.g., Internet Relay Chat (IRC) based
chat rooms. This memo uses the SIP Conferencing Framework [I-D.ietf-
sipping-conferencing-framework] as a design base to define a set of
requirements for protocols such as SIP [RFC3261], SDP [RFC2327], and
MSRP [I-D.ietf-simple-message-sessions] that enrich session based
messaging conferences.
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 [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 August 24, 2005 [Page 3]
Internet-Draft Multiparty MSRP February 2005
Nickname: a descriptive name associated to a participant. A
nickname is non-routable pseudonym that the participant chooses
for the purpose of additional identification towards the rest of
the participants.
Session-based instant messaging conference: a particular case of a
tightly coupled conference (as defined by the SIP Conferencing
Framework [I-D.ietf-sipping-conferencing-framework]) where the
media exchanged between the participants consist of session based
instant messages transported with MSRP [I-D.ietf-simple-message-
sessions]. Typically a session based message conference is
referred to as a chat room>.
Chat room: a synonym of a session-based instant messaging
conference.
Creator or message creator: the user that originally created a
message and sent it to the chat room for further distribution.
The creator can be identified by a SIP URI or a nickname.
MSRP switch: an MSRP endpoint that receives MSRP messages and
redistributes them to each conference participant as appropriate.
An MSRP switch has a similar role as a mixer (as defined by the
SIP Conferencing Framework [I-D.ietf-sipping-conferencing-
framework]), however an MSRP switch does not combine different
input media streams; it merely distributes incoming MSRP messages
to the conference participants.
Private instant message: a session based instant message whose
intended list of destinations is explicitly signaled and is a
subset of the conference participants, rather than all the
participants of the conference.
3. Motivation
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],
conferences of session-based messaging do not seem to be covered in
detail. It seems beneficial to provide a set of features that
enhance conferences for session-based messages in order to compete in
functionality with existing session-based instant messaging
conference systems.
Niemi & Garcia-Martin Expires August 24, 2005 [Page 4]
Internet-Draft Multiparty MSRP February 2005
4. Requirements
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
Initiation Protocol [I-D.rosenberg-simple-messaging-requirements].
In addition, we define the following requirements:
REQ-1: A conference focus may be acting as the focus of a
specialized conference where the media stream is composed of
session-based instant messaging.
REQ-2: It must be possible that participants join or leave a
particular session-based instant messaging conference.
REQ-3: The conference can host other medias than session based
messaging.
REQ-4: It must be possible to inform the creator of a session based
messaging about the acceptance of the message for
distribution.
REQ-5: It must be possible to get the time-stamp at which the MSRP
switch dispatched a message.
REQ-6: The message sequence witnessed by different endpoints must be
identical across all the participants.
REQ-7: A conference participant must be able to determine the
identity of the creator of the message.
REQ-8: A conference participant must be able to determine the target
of the received message. For instance, the message might be
addressed to the whole conference, a sidebar conference or
just the recipient of the message (private message).
REQ-9: It must be possible to set up a sidebar session with one or
more participants of the conference.
REQ-10: It must be possible to send a message to one or more
participants of the conference (private instant message).
REQ-11: A conference participant may have a nickname or pseudonym
associated to him.
REQ-12: It must be possible for a participant to change his nickname
during the progress of the conference.
REQ-13: It must be possible that a participant only reveals his
nickname to the rest of the conference participants, but it
does not reveal his SIP URI.
REQ-14: On sending private messages, it might be possible that the
creator sends private messages to participants who have only
revealed their nickname, but not their routable SIP URI.
Niemi & Garcia-Martin Expires August 24, 2005 [Page 5]
Internet-Draft Multiparty MSRP February 2005
REQ-15: It must be possible that the MSRP switch is a contributor
that sends messages to the participants (e.g., message of the
day, welcome message, server is shutting down, etc.)
REQ-16: A session based instant messaging conference or sidebar
conference can be characterized with a topic whose purpose is
to identify the subject of conversation.
REQ-17: A user with the appropriate privileges must be able to set
and modify the topic of the conference or sidebar conference.
5. Overview of Operation
We define new conventions and extensions to MSRP that allows to
implement the requirements. Specifically, we define a new MSRP
method, DISTSEND that works similarly to the existing SEND method in
MSRP, but instead of distributing the message to the last MSRP
endpoint listed in the To-Path header field, the message is
ultimately distributed to one or more recipients listed in a new
Distribution header field. We mandate endpoints to send MSRP
messages wrapped as CPIM messages [RFC3862]. The From header of the
CPIM message indicates the creator, the To and Cc headers indicate
the visible receivers. In this way, we separate the presentation
purposes header (all of the Message/CPIM headers) from those used by
the MSRP switch to deliver the message (the new MSRP Distribution
header field)
6. Multiparty Session Based Instant Messaging Conferencing
6.1 Creating/deleting a chat room
Since we consider a chat room a particular type of conferences where
the media happens to be session based instant messaging (MSRP), the
methods defined by the SIP Conference Framework [I-D.ietf-sipping-
conferencing-framework]to create and delete conferences are
applicable to the chat room.
Once a session based message conference is created, the conference is
identified by a URI, like any other conference. Participants are
aware that the peer is a focus due to the presence of the "isfocus"
feature tag in the Contact header field of the 2xx-class response to
the INVITE request. Participants are also aware that the mixer is an
MSRP switch due to the presence of the 'message' media type and the
MSRP [I-D.ietf-simple-message-sessions] in the SDP [RFC2327].
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.
Niemi & Garcia-Martin Expires August 24, 2005 [Page 6]
Internet-Draft Multiparty MSRP February 2005
6.2 Detection of an MSRP switch
Using SIP signalling, a SIP UA can determine that the remote UA is a
focus due to the presence of the 'isfocus' media feature tag in the
Contact header field. There is not a similar indication at the MSRP
level, so it is not possible to determine, just using MSRP
signalling, that an MSRP endpoint is connected to an MSRP switch.
However, a since an MSRP switch is always controlled by a focus at
the SIP level, a conference participant whose SIP UA is able to
determine that the capacity of the remote UA is a focus, can safely
assume that the respective remote MSRP endpoint is an MSRP switch.
6.3 Procedures at the originating MSRP endpoint of a conference
participant
6.3.1 Sending MSRP messages to all the participants of the conference
MSRP provides for the existence of a SEND primitive that allows a
sender to transport an instant message to the receiver. The actual
data is enclosed in a body. MSRP mandates implementations to support
the Message/CPIM [RFC3862] format. A conference-aware participant
that sends an MSRP SEND request to an MSRP switch with the purpose of
being distributed to all the participants in the conference SHOULD
enclose the contents of the actual message in a Message/CPIM
[RFC3862] MIME-type format. The Message/CPIM MIME-type format allows
to wrap the actual instant message payload in other message formats
such as text/plain, text/html, etc.
NOTE: Wrapping the actual contents into a Message/CPIM wrapper
provides the MSRP switch with better CPIM compatibility.
Additionally, the MSRP switch may need to distribute copies of the
messages to the rest of the participants in a Message/CPIM format
too, thus, if the creator sends the message already in Message/
CPIM format the focus is relieved from the task of doing format
conversion.
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 where the user is
recognized in the conference. Identities that can be used are, among
others, a SIP URI [RFC3261] representing a permanent address of
record, a tel URI [RFC3966], an IM URI [RFC3860], an MSRP URL [I-
D.ietf-simple-message-sessions], and a nickname (Section 7). 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 distribution of messages, the creator SHOULD include an
anonymous identity, such as, for example, those "anonymous" SIP URIs
created as described in RFC 3261 [RFC3261] Section 8.1.1.3.
Niemi & Garcia-Martin Expires August 24, 2005 [Page 7]
Internet-Draft Multiparty MSRP February 2005
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 wrapper to the SIP URI [RFC3261] that represents the
focus of the conference or the MSRP URL [I-D.ietf-simple-message-
sessions] that represents conference session at the MSRP switch.
6.3.2 Sending MSRP messages to a reduced set of the participants of the
conference
Sending of MSRP messages to a reduced set of the participants of the
conference requires to define a new MSRP method 'DISTSEND', and a new
header field 'Distribution'. A new method is required because in
case the MSRP switch does not support this extension, the creator of
the message will expect an error response back rather than the
message to be distributed to the whole list of participants of the
conference. In fact, if the MSRP switch does not support the
DISTSEND method it will generate a 501 response and the message will
not be distributed to any participant.
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.
6.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 6.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 8.
Niemi & Garcia-Martin Expires August 24, 2005 [Page 8]
Internet-Draft Multiparty MSRP February 2005
6.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 8.
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,
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 6.3.1.
OPEN ISSUE: the paragraph above assumes that the participant
receives somehow the nicknames of each of the participants. Is
this assumption valid? Will the conference package have elements
to include nicknames? Or shall we define that extension?
6.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
Niemi & Garcia-Martin Expires August 24, 2005 [Page 9]
Internet-Draft Multiparty MSRP February 2005
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.
6.4 Procedures at the MSRP switch
An MSRP switch can receive messages sent from either conference-aware
participants or conference-unaware participants. The former will
follow the procedures indicated in this document, the MSRP switch
will receive a SEND or DISTSEND request that includes a Message/CPIM
wrapped message. It is not guaranteed that the latter will include a
Message/CPIM message.
It is assumed that the MSRP switch is able to map different
identities of the user. For instance, a user can be identified by
his SIP URI, MSRP URl, a nickname, a tel URI, an IM URI, etc.
6.4.1 receiving SEND requests
On receiving a complete SEND request or the last chunk of a SEND
request, the MSRP switch SHOULD create another SEND request to each
of the participants of the conference, and SHOULD NOT create a SEND
request to the creator of the message. This SEND request MUST
contain the body or bodies included in the received SEND request.
Then the MSRP switch MUST send the newly generated SEND request to
each of the recipients.
The MSRP switch MAY need to re-chunk the outgoing SEND requests, as
part of the general procedure for chunking SEND requests.
Other than that, 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].
6.4.2 receiving DISTSEND requests
On receiving a complete DISTSEND request or the last chunk of a
Niemi & Garcia-Martin Expires August 24, 2005 [Page 10]
Internet-Draft Multiparty MSRP February 2005
DISTSEND request, the MSRP switch MUST first inspect the Distribution
header field and determine the MSRP URL of each of the identities
listed there. Since this header field can contain URIs that are not
necessarily MSRP URLs, the MSRP switch has to resolve a given URI to
its corresponding existing MSRP URL (including the session
identifier). This can be done by either maintaining a local table
that maps various forms of identities to current MSRP session URLs,
or being able to determine those MSRP session URLs with the help of
an external source (for instance, the MSRP switch can do an ENUM
query to map to tel URIs to SIP URIs, which are eventually locally
mapped to an existing MSRP URL of the current session).
In case the MSRP switch is unable to resolve any of the URIs included
in the Distribution header of the DISTSEND request, the MSRP switch
MUST stop further processing of the request. Further more, depending
on the report requirements of the received DISTSEND request, the MSRP
switch B4might need to generate a REPORT request towards the MSRP
endpoint that sent the DISTEND request, to indicate the failure. If
this REPORT request is generated, the Status header field value
SHOULD contain a "000" namespace, a "481" short-status, and a "Unable
to resolve" 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.
Once all the URIs included in the Distribution header have been
resolved to an existing MSRP session URL, the MSRP switch generates a
SEND request per recipient. This SEND request MUST contain the body
or bodies included in the received DISTSEND request. Then the MSRP
switch MUST send the newly generated SEND request to each of the
recipients.
Generating a SEND request to the recipients instead of a DISTSEND
request guarantees compatibility for conference-unaware
participants.
OPEN ISSUE: It would be quite beneficial for the recipient to get
a DateTime header value of when the message was dispatched.
Message/CPIM offers a DateTime header that we could reuse, but
this would imply that the MSRP switch has to open the Message/CPIM
to re-write or add the value. We cannot use a DateTime header set
by the creator of the message because there is no guarantee that
the clock is synchronized to that of other participants. Perhaps
we should add a DateTime header at the MSRP level and make the
MSRP switch set this header.
The MSRP switch MAY need to re-chunk the outgoing SEND requests, as
part of the general procedure for chunking SEND requests.
Niemi & Garcia-Martin Expires August 24, 2005 [Page 11]
Internet-Draft Multiparty MSRP February 2005
6.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.
6.5 Procedures at the recipient MSRP endpoint of a conference
participant
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. In any case, the recipient is
able to determine whether the message was distributed to the whole
conference or a subset of it by inspecting the To header field of the
Message/CPIM.
If the recipient is subscribed to the conference event package at the
focus, he can map the nickname of the creator or intended recipients
with a SIP URI, providing that such participant didn't want to remain
anonymous.
7. Nicknames
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 string of characters that serves for the purpose of
identifying a participant to the rest of the participants of the
conference. A nickname can match the participant name, or identify
any characteristic, but it can be any other string that is not
associated with the participant at all. A nickname can be also a
collection of characters that do not make sense in any language, as a
mechanism to provide some anonymity of the nickname.
For the purpose of the chat room functionality, a nickname is also
composed of a URN [RFC2141]. The selection of a URN offers important
properties, such as:
Niemi & Garcia-Martin Expires August 24, 2005 [Page 12]
Internet-Draft Multiparty MSRP February 2005
A URN is non routable by definition. It just a name, and it does
not offer routability characteristics (unlike SIP URIs or MSRP
URLs).
A URN offers some hierarchy in the namespace. The hierarchy is
required to allow each MSRP switch to provide its own namespace of
nicknames.
Users are allowed to choose any nickname of their wish when they join
the conference. The only prerequisite is that the nickname is not
already in used by another participant. The nickname ought to be
unique within the set of conference managed by the focus. This
property allows a participant to join several conferences hosted by
the same focus and still keep the same nickname across all those
conferences. Note that we don't require a nickname to be globally
unique, but just locally unique within the focus.
Nicknames are non-routable identifiers. A participant of a
conference cannot derive the SIP or MSRP URI, or the IP address out
of the nickname chosen by another participant. Certainly the MSRP
switch binds nicknames with their respective MSRP URLs, however, this
binding exists only in the MSRP switch and is not necessarily visible
to the participants of the chat room. This property allows also a
participant to send a private instant message to a second participant
who is identified only by her nickname.
7.1 Representation of a nickname
A nickname is semantically defined as the combination of a display
name and URN. Nicknames are present in Message/CPIM From, To, and Cc
headers and in MSRP Distribution headers.
We define conventions that allow to a creator to include a nickname
in the From, To, or Cc headers of a Message/CPIM document or in an
MSRP Distribution header. The From, To , and Cc headers are already
defined in RFC 3862 [RFC3862] with the following syntax:
From-header = "From" ": " [ Formal-name ] "<" URI ">"
To-header = "To" ": " [ Formal-name ] "<" URI ">"
Cc-header = "cc" ": " [ Formal-name ] "<" URI ">"
For the purpose of this application, a "Formal-name" is effectively a
Display name, and the "URI" is effectively a URN as specified in RFC
2141 [RFC2141].
According to RFC 2141 [RFC2141] the syntax of a URN is:
<URN> ::= "urn:" <NID> ":" <NSS>
Niemi & Garcia-Martin Expires August 24, 2005 [Page 13]
Internet-Draft Multiparty MSRP February 2005
where <NID> is the Namespace Identifier, and <NSS> is the Namespace
Specific String.
For the purpose of this application we define an <NID> of "ietf:
params:msrp:nicknames". The selection of the <NID> is left up to the
MSRP switch, but in order to avoid clashes it is RECOMMENDED to
select a string that contains a reversal DNS domain name. For
instance, the following is the namespace of nicknames at
switch.example.com:
"urn:ietf:params:msrp:nicknames:com:example:switch"
The NSS of the URN actually completes the nickname. For example, the
URN part of the nickname "johnny" will be represented as:
"urn:ietf:params:msrp:nicknames:com:example:switch:johnny"
When the nickname is included in a CPIM header it can additionally
contain a Formal-name (Display Name). For instance:
From: "Prince of the snow" \
<urn:ietf:params:msrp:nicknames:com:example:switch:johnny>
7.2 Provision of nicknames
A participant of a conference controlled by a particular focus can
setup his nickname by any means outside the scope of this document.
For instance, the participant can log into a web page where he
authenticates and sets up his nickname.
OPEN ISSUE: Do we need to provide a mechanism with SIP to
negotiate nicknames?
8. 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].
8.1 The MSRP DISTSEND method
DISTSENDm = %x44.49.53.54.53.45.4E.44 ; DISTSEND in caps
Method = SENDm / REPORTm / AUTHm / DISTSENDm
/ ext-method
Niemi & Garcia-Martin Expires August 24, 2005 [Page 14]
Internet-Draft Multiparty MSRP February 2005
8.2 The MSRP Distribution header field
headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
header = Message-ID
/ Report-Success
/ Report-Failure
/ Byte-Range
/ Status
/ Distribution
/ ext-header
Distribution = "Distribution:" SP recipient-URI *( SP recipient-URI)
recipient-URI = addr-spec / MSRP-url / telephone-uri /
nickname-urn / absolute-URI
nickname-urn = URN
addr-spec is imported from RFC 3261 [RFC3261].
MSRP-url is imported from MSRP [I-D.ietf-simple-message-sessions].
telephone-uri is imported from RFC 3966 [RFC3966].
absolute-URI is imported from RFC 3986 [RFC3986].
URN is imported from RFC 2141 [RFC2141].
9. Examples
TBD.
10. IANA Considerations
This document does not include any IANA considerations.
11. 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.
12. References
Niemi & Garcia-Martin Expires August 24, 2005 [Page 15]
Internet-Draft Multiparty MSRP February 2005
12.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. 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.
[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-03 (work in
progress), October 2004.
[I-D.barnes-xcon-framework]
Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencingg", draft-barnes-xcon-framework-01
(work in progress), December 2004.
[I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-09 (work in progress),
Niemi & Garcia-Martin Expires August 24, 2005 [Page 16]
Internet-Draft Multiparty MSRP February 2005
October 2004.
12.2 Informative References
[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",
draft-ietf-sipping-conference-package-08 (work in
progress), December 2004.
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 August 24, 2005 [Page 17]
Internet-Draft Multiparty MSRP February 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 August 24, 2005 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 21:48:58 |