Network Working Group A. Niemi Internet-Draft Nokia Intended status: Standards Track M. Garcia-Martin Expires: July 31, 2008 Nokia Siemens Networks G. Sandbakken TANDBERG January 28, 2008 Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP) draft-ietf-simple-chat-01 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 July 31, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). 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 Niemi, et al. Expires July 31, 2008 [Page 1] Internet-Draft Multiparty MSRP January 2008 tools for establishing multi-party instant messaging (IM) sessions, or chat rooms, with MSRP. 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. Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 9 6. Sending and Receiving Instant Messages . . . . . . . . . . . . 9 6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 9 6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 11 7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Using Nicknames within a Conference . . . . . . . . . . . 14 7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 15 7.3. Nicknames in the Conference Event Package . . . . . . . . 16 8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 16 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 17 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 19 9.3. Sending a regular message to the chat room . . . . . . . . 21 9.4. Sending a private message to a participant . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Niemi, et al. Expires July 31, 2008 [Page 2] Internet-Draft Multiparty MSRP January 2008 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, 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, white boarding, 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, et al. Expires July 31, 2008 [Page 3] Internet-Draft Multiparty MSRP January 2008 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 Provider URI: a URI that provides scope in which the nickname is unambiguous and identifies it's provider. Se details in Section 7. 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 multiparty 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, et al. Expires July 31, 2008 [Page 4] Internet-Draft Multiparty MSRP January 2008 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. A private IM is usually rendered distinctly from the rest of the IMs, as to indicate that the message was a private communication. Replacement URI: an anonymous URI that is routable and unique inside the scope of the focus. It is used by the MSRP switch to send and receive anonymous messages. 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. Niemi, et al. Expires July 31, 2008 [Page 5] Internet-Draft Multiparty MSRP January 2008 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 or a single participant of the conference (i.e., a private message). REQ-5: It must be possible to send a message to a single participant within the conference (i.e., a private instant message). 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. 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: 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 Niemi, et al. Expires July 31, 2008 [Page 6] Internet-Draft Multiparty MSRP January 2008 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 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 a Niemi, et al. Expires July 31, 2008 [Page 7] Internet-Draft Multiparty MSRP January 2008 participants whose identity has been learned, 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 header contains not the chat room URI but the recipient's URI. The MSRP switch then forwards the SEND request to the recipient. 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. If the participant wants to remain anonymous to the rest of the participants, the participant can issue privacy by using the Privacy header [RFC3323] when sending the INVITE request to the conference URI. If a Privacy header is present and the focus allows anonymous participants, the focus MUST provide the participant with a replacement URI which can be used by the MSRP switch to route Niemi, et al. Expires July 31, 2008 [Page 8] Internet-Draft Multiparty MSRP January 2008 messages. The creation of the replacement URI SHOULD follow the recommendations of RFC 4574 section 5.6 [RFC4575] The MSRP switch MUST keep a mapping of the participant URI and replacement URI to route messages to and from anonymous participants. 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). The conference focus of a chat room MUST learn the chat room 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. 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. Sending and Receiving Instant Messages 6.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 Niemi, et al. Expires July 31, 2008 [Page 9] Internet-Draft Multiparty MSRP January 2008 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 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. If the participant has requested privacy when joining (Section 5.2) , the MSRP switch MUST replace the From header field of the Message/CPIM wrapper with the replacement URI associated to the sender 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 Niemi, et al. Expires July 31, 2008 [Page 10] Internet-Draft Multiparty MSRP January 2008 identity information through a subscription to the SIP conference event package [RFC4575]. 6.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 participant of the chat room rather to all of them. A chat room can signal support for private messages using the chatroom- attribute (see Section 8 for details). When a chat room participant wishes to send a private instant message to a participant 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 (e.g. text, image, video-clip etc.) 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 with the identity of intended recipient. The identity can be SIP, TEL, and IM URIs typically learned 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 chat room URI, it must check if it contains a participant or replacement URI. If the URI in the To header can not be resolved (e.g. cased by a mistyped URI or that the recipient has abandoned the chat room), 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 new 427 status code indicates a failure to resolve the recipient URI in the To header field. If the recipient is valid, but the recipient does not support private messages, and the Failure-Report header field of Niemi, et al. Expires July 31, 2008 [Page 11] Internet-Draft Multiparty MSRP January 2008 the SEND request was either not present in the original request, or had a value of "yes", the MSRP switch MUST send a REPORT request having the status code of 428. The new response 428 indicate that the recipient does not support private messages. In either case the REPORT request MUST include a Message/CPIM wrapper, with the original From header field included in the SEND request, and the To header field of the original message. The message MUST not be forwarded to the recipient if above conditions applies. The MSRP switch should search it's mapping table to find the MSRP session established towards the recipient. If a match is found the MSRP switch MUST create a SEND request and MUST copy the contents of the sender's message to it. If the sender has requested privacy when joining (Section 5.2) the conference, the MSRP switch MUST put the replacement URI in the From header. If no privacy is requested, the participant URI from the senders message will be used. If the To header of the sender's message contains a replacement URI, the MSRP switch MUST put the participant URI associated to the replacement URI in the To header field. If the To header in the senders message contains a participant URI, it will be used in To header field in the Message/CPIM wrapper. The new SEND request MUST be sent to the recipient. 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. 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]. It is possible that a participant, identified by a SIP Address of Record, joins a conference of instant messages from two or more different SIP UAs. It is RECOMMENDED that the an MSRP switch can map a participant or replacement URI for two or more MSRP sessions. If the policy of the server allows for this, the MSRP switch MUST copy all messages intended for the recipient through each MSRP session. 7. 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 Niemi, et al. Expires July 31, 2008 [Page 12] Internet-Draft Multiparty MSRP January 2008 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. A main difference being that the nickname is unique within a scope. The scope can be a chat room, a chat server or a domain. Nicknames may be long lived, or may be temporary. Users need to reserve a nickname prior to its utilization. This memo specifies the nickname as a string. The nickname string is unambiguous within the scope of the nickname provider URI. The nickname provider URI can be set to any URI which can issue nicknames. If the conference (chat room) itself can issue nicknames, the nickname provider URI would be the conference URI. This scope is similar to a nickname unique in a chat room from Extensible Messaging and Presence Protocol [RFC3920]. Similar to Internet Relay Chat (IRC) [RFC2810] having the nickname unambiguous within the scope of a server, the nickname provider URI can be set to the domain of the focus. The chat room 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 providers, or it may restrict the providers it accepts nicknames from. It may, for example only allow nicknames it issues itself. Nicknames are typically used for displaying purposes. The participant's user interface would typically display the nickname string. As the nickname string may not be unique within the chat room (conference) the user interface needs to take into account the scope of which it is provided. The nickname provider URI should be made available in the participant's user interface to avoid selecting a wrong participant intended as a recipient of a private messages. Also referring to nicknames of participants inside the chat itself may be ambiguous if a participant is referring to a nickname without any scope. 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 Niemi, et al. Expires July 31, 2008 [Page 13] Internet-Draft Multiparty MSRP January 2008 can be temporarily or permanent. o Validation of a nickname by the provider that reserved it and issued it. Validation is an official confirmation from the provider that issued the nickname, that the nickname is associated with the claimed SIP AoR. 7.1. Using Nicknames within a Conference This memo provides a mechanism to set a nickname for a participant for as long as the participants 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 string that the participant wants to reserve and the nickname provider URI to set the scope for the nickname. An MSRP switch that receives a NICKNAME request containing a nickname 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 chat room allows the usage of nicknames, the MSRP switch SHOULD validate that the participant URI is entitled to use the nickname inside the scope of the nickname provider URI. The participant's authenticated identity can be derived after a successful HTTP Digest Authentication, 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 and the nickname scope URI with the participant's own authenticated URI. 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 Niemi, et al. Expires July 31, 2008 [Page 14] Internet-Draft Multiparty MSRP January 2008 validation can also fail, e.g., if the Use-Nickname header contains a nickname provider URI for which the conference server has no authority and the conference server does not have the means to validate the nickname from the provider 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". As indicated earlier, this specification defines a new MSRP header field: "Use-Nickname". The Use-Nickname header field carries a nickname string and a nickname provider URI, and SHOULD be included in the NICKNAME requests. The nickname provider URI MUST be formatted according to the conventions for provider URIs. 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" ":" nickname ";" / nickname-provider-URI nickname = quoted-string nickname-provider-URI: name-addr 7.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 7.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 response. Niemi, et al. Expires July 31, 2008 [Page 15] Internet-Draft Multiparty MSRP January 2008 7.3. 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 adds a attribute to the containing the nickname. It also adds a attribute to the element containing the URI of the provider that issued the nickname. TO BE DONE: include a formal definition of the extension to the conference event package. 8. The SDP 'chatroom' attribute There are a handful of use cases where a participant would like to learn the chat room 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 chat room 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 chat room local policy allowance for a number of functions specified in this document. Specifically, we Niemi, et al. Expires July 31, 2008 [Page 16] Internet-Draft Multiparty MSRP January 2008 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" private-msg-token = "private-messages" A conference focus that includes the 'nicknames' token in the session description is signaling that the MSRP switch supports and the chat room allows to use the procedures specified in Section 7. A conference focus that includes the 'private-messages' in the SDP description is signaling that the MSRP switch supports and the chat room allows to use the procedures specified in Section 6.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 9. Examples 9.1. Joining a chat room Figure 5 presents a flow diagram where Alice joins a chat room by sending an INVITE request. This INVITE request contains a session description that includes the chatroom extensions defined in this document. Alice Conference focus | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | Figure 5: 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 chat Niemi, et al. Expires July 31, 2008 [Page 17] Internet-Draft Multiparty MSRP January 2008 room 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 ;tag=9fxced76sl To: Chatroom 22 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: 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 6: INVITE request containing an SDP offer with chat room extensions F2: The chat room server accepts the session establishment. It includes the 'isfocus' and other relevant feature tags in the Contact header field of the response. The chat room 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 with the allowed extensions. Niemi, et al. Expires July 31, 2008 [Page 18] Internet-Draft Multiparty MSRP January 2008 SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Chatroom 22 ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: \ ;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 7: 200 (OK) response including chat room extensions F3: The session established is acknowledged (details not shown). 9.2. Setting up a nickname Figure 8 shows an example of Alice setting up a nickname using the conference as provider. 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 8: Flow diagram of a user setting up her nickname Niemi, et al. Expires July 31, 2008 [Page 19] Internet-Draft Multiparty MSRP January 2008 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: "Alice the great" ; sip:chatroom22@chat.example.com -------d93kswow$ Figure 9: MSRP NICKNAME request with an initial nickname proposal F2: The MSRP mixer analyzes the existing allocation of nicknames and detects that the nickname "Alice is great" is already provided to another participant by the conference. 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 10: 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: "Alice in wonderland" ; sip:chatroom22@chat.example.com -------09swk2d$ Figure 11: MSRP NICKNAME request with a second nickname proposal F4: The MSRP 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 12: MSRP NICKNAME request Niemi, et al. Expires July 31, 2008 [Page 20] Internet-Draft Multiparty MSRP January 2008 9.3. Sending a regular message to the chat room Figure 13 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 13: 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: From: DateTime: 2007-03-02T15:02:31-03:00 Content-Type: text/plain Hello guys, how are you today? -------3490visdm$ Figure 14: 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, et al. Expires July 31, 2008 [Page 21] Internet-Draft Multiparty MSRP January 2008 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 15: 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: From: DateTime: 2007-03-02T15:02:31-03:00 Content-Type: text/plain Hello guys, how are you today? -------490ej23$ Figure 16: 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 17 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, et al. Expires July 31, 2008 [Page 22] Internet-Draft Multiparty MSRP January 2008 Figure 17: 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 learned 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: From: DateTime: 2007-03-02T15:02:31-03:00 Content-Type: text/plain Hello Bob. -------6959ssdf$ Figure 18: 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 19: 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, et al. Expires July 31, 2008 [Page 23] Internet-Draft Multiparty MSRP January 2008 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: From: DateTime: 2007-03-02T15:02:31-03:00 Content-Type: text/plain Hello Bob. -------9v9s2$ Figure 20: 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, et al. Expires July 31, 2008 [Page 24] Internet-Draft Multiparty MSRP January 2008 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. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 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. Niemi, et al. Expires July 31, 2008 [Page 25] Internet-Draft Multiparty MSRP January 2008 14.2. Informative References [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000. [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., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", draft-ietf-xcon-framework-10 (work in progress), November 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, et al. Expires July 31, 2008 [Page 26] Internet-Draft Multiparty MSRP January 2008 Geir A. Sandbakken TANDBERG N-1366 Lysaker Norway Phone: +47 67 125 125 Email: geir.sandbakken@tandberg.com URI: http://www.tandberg.com Niemi, et al. Expires July 31, 2008 [Page 27] Internet-Draft Multiparty MSRP January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, et al. Expires July 31, 2008 [Page 28]