Network Working Group A. Niemi Internet-Draft M. Garcia-Martin Expires: July 1, 2004 Nokia January 2004 Multi-party Message Sessions using the Message Session Relay Protocol (MSRP) draft-niemi-simple-chat-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a session, established using the Session Initiation Protocol (SIP). This document describes how MSRP can be used to create multi-party message sessions using the tightly coupled conferencing model. It defines conventions and extensions for enabling features similar to many existing services in the Internet, e.g., Internet Relay Chat (IRC) based chat rooms, such as setting up nicknames, sending private messages to a subset of the multy-party conferece, etc. Niemi & Garcia-Martin Expires July 1, 2004 [Page 1] Internet-Draft Multiparty MSRP January 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Document Conventions . . . . . . . . . . . . . . . . . . . . 3 1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Multiparty Message Sessions and Conferencing . . . . . . . . 4 4.1 Creating/deleting a chat room . . . . . . . . . . . . . . . 4 4.2 Sending and receiving messages within a chat room . . . . . 5 4.3 Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3.1 Representation of a nickname . . . . . . . . . . . . . . . . 6 4.3.2 Provision of nicknames to the focus . . . . . . . . . . . . 7 4.3.3 Procedures at the focus with respect nicknames . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 5.1 MIME Registration for application/nickname-info+xml . . . . 12 5.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:nickname-info . . . . . . . . . . . . 13 5.3 Schema Registration . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . 14 Informative References . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . 16 Niemi & Garcia-Martin Expires July 1, 2004 [Page 2] Internet-Draft Multiparty MSRP January 2004 1. Introduction The Message Session Relay Protocol (MSRP) [12] defines a mechanism for sending a series of Instant Messages within a session. The Session Initiation Protocol (SIP) [6] allows for two peers to set up such a session. In another application of SIP, a user agent can join in a multi-party session or a conference that is hosted by a specialized user agent called a conference focus [11]. Such a conference can naturally involve an MSRP session as media, where an Instant Message received from one participant is relayed to all the other participants. Such a multi-party Instant Messaging would typically be referred to as a chat room. Several of these types of chat rooms already exist in the Internet. Some of these chat rooms include a rich set of features, such as the ability of a participant to send private messages to one or more participants, or to establish sub-conferences within the existing conference. The aim of this document is to define conventions and extensions for enabling features similar to many of these existing applications in the Internet, e.g., Internet Relay Chat (IRC) based chat rooms. This memo uses the SIP Conferencing Framework [11] as a design base to define a set of extensions to SIP and SDP that enrich session based messaging conferences. 1.1 Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 1.2 Definitions This memo deals with a particular case of tightly coupled SIP conferences where the media exchanged consist of session based messaging. Unless otherwise noted, we use the terminology defined in the SIP Conferencing Framework [11] applied to the scope of this document. In addition to that terminology, we introduce some new terms: Nickname: a descriptive name associated to a participant. A nickname is non-routable pseudonym that the participant chooses for the purpose of additional identification towards the rest of the participants. Niemi & Garcia-Martin Expires July 1, 2004 [Page 3] Internet-Draft Multiparty MSRP January 2004 Session based message conference: a particular case of a tightly coupled SIP conference (as defined by the SIP Conferencing Framework [11]) where the media exchanged between the participants consist of session based instant messages transported with MSRP. Session based message mixer: a particular case of a mixer (as defined by the SIP Conferencing Framework [11]) where the media exchanged to or from the participants consist of session based instant messages transported with MSRP. Private instant message: an instant message whose intended list of destinations is a subset of the participants, rather than all the participants of the conference. 2. Motivation As SIP already provides a Conferencing Framework [11] that can be utilized in many types of conferencing applications, it seems beneficial to provide a set of features that when used specifically with MSRP, enhance the Instant Messaging conferences in order to compete in functionality with existing systems. 3. Requirements Requirements that enrich the session based messaging conferences have been already described in Requirements for Instant Messaging in 3GPP Wireless Systems [9] or the Advanced Instant Messaging Requirements for the Session Initiation Protocol [10]. 4. Multiparty Message Sessions and Conferencing 4.1 Creating/deleting a chat room Since we consider a chat room a particular type of conferences where the media happens to be session based messaging (MSRP), the methods defined by the SIP Conference Framework to create and delete conferences are applicable to the session based message conferences. Once a session based message conference is created, the conference is identified by a URI, like any other conference. Participants are aware that the peer is a focus due to the presence of the "isfocus" feature tag in the Contact header field of the 2xx-class response to the INVITE request. Participants are also aware that the mixer is a session based messaging mixer due to the presence of the message media type and the MSRP protocol in the SDP. In a one-to-one MSRP session, received Instant Messages are identified by the transport connection on which they arrive. In a chat room, where a single transport connection to the conference mixer is used for receiving Instant Messages from all of the other Niemi & Garcia-Martin Expires July 1, 2004 [Page 4] Internet-Draft Multiparty MSRP January 2004 conference participants, this is not sufficient. Each message needs to carry in it an identifier of the sender of the message. This is accomplished using the 'message/cpim' MIME type, as defined in [7]. The conference focus MUST insist on using the 'message/cpim' as the top-level wrapper type in the SDP, as defined in [12]. 4.2 Sending and receiving messages within a chat room MSRP provides for the existence of a SEND primitive that allows a sender to transport an instant message to the receiver. The actual is enclosed in a body. MSRP mandates implementations to support the message/cpim format. A participant that sends an MSRP SEND request to a session based message focus SHOULD enclose the contents of the actual message in a message/cpim MIME-type format. The message/cpim format allows to wrap other message formats such as text/plain, text/ html, etc. NOTE: Wrapping the actual contents into a message/cpim provides the session based messaging focus with better CPIM compatibility. Additionally, the focus may need to distribute copies of the messages to the rest of the participants in a message/cpim format, thus, if the sender sends the message already in message/cpim format the focus is relieved from the task of doing format conversion. A participant that sends an session based instant message to the conference mixer SHOULD include her nickname in the From header of the message/cpim wrapper (see the nicknames discussion in Section Section 4.3. A participant that sends an session based instant message addressed to the conference MUST set the To header of the message/cpim to the conference URI. A participant that sends a session based private instant message to one or more participants of the conference MUST include the nickname of the each of the intended receivers in either the To or Cc headers of the message/cpim. OPEN ISSUE: the paragraph above assumes that the participant receives somehow the nicknames of each of the participants. Is this assumption valid? Will the conference package have elements to include nicknames? Or shall we define that extension? 4.3 Nicknames A common characteristic of existing focuses is that participants have Niemi & Garcia-Martin Expires July 1, 2004 [Page 5] Internet-Draft Multiparty MSRP January 2004 the ability to identify themselves with a nickname to the rest of the participants in a conference. A nickname is a string of characters that serves for the purpose of identifying a participant to the rest of the participants of the conference. A nickname can match the participant name, or identify any characteristic, but it can be any other string that is not associated with the participant at all. A nickname can be also a collection of characters that do not make sense in any language, as a mechanism to provide some anonymity of the nickname. Users are allowed to choose any nickname of their wish when they join the conference. The only prerequisite is that the nickname is not already in used by another participant. The nickname ought to be unique within the set of conference instances managed by the focus. This property allows a participant to join several conferences in the same and still keep the same nickname across all those conferences. Note that we don't require a nickname to be globally unique, but just locally unique within the focus. Nicknames are non-routable identifiers. A participant of a conference cannot derive the SIP URI or IP address out of the nickname chosen by another participant. Certainly the focus binds nicknames with their respective SIP URIs, however, this binding exists only in the focus and is not visible to the participants of the conference. This property allows also a participant to send a private instant message to a second participant who is identified only by her nickname. 4.3.1 Representation of a nickname A nickname is syntactically defined as the combination of a display name and an IM URI. The IM URI [8] may be a non-routable URI, since the purpose of the URI is not to identify a SIP entity. This avoids routing based on the contents of a nickname. A non routable URI may be created by appending ".invalid" to an existing domain name. We define conventions that allow to a sender to include a nickname in the From, To or Cc headers of a message/cpim document. These headers are already defined in the CPIM message format [7] with the following syntax: From-header = "From" ": " [ Formal-name ] "<" URI ">" To-header = "To" ": " [ Formal-name ] "<" URI ">" Cc-header = "cc" ": " [ Formal-name ] "<" URI ">" A non-routable IM URI follows the format of a Network Access Identifier (NAI) (RFC 2486) [3]. Appending the domain ".invalid" to a NAI can make it non-routable. We chose an IM URI rather than a SIP URI since the purpose of the URI is not to identify a SIP entity. Niemi & Garcia-Martin Expires July 1, 2004 [Page 6] Internet-Draft Multiparty MSRP January 2004 Examples of nickname: "Prince of the snow" A nickname is scoped to be valid in the focus address space. The focus maintains a binding between nicknames and SIP URIs that allows to route private instant messages to the appropriate participant. However, this binding is not visible outside the focus, in particular, it is not visible to the participants of the conference. We represent nicknames in the From, To and Cc headers in the message/ cpim. If the message is a addressed to the whole conference, the To header of the CPIM message contains the conference URI. If the message is a private message address to a subset of the participants, To and Cc headers include the nickname of each of the intended recipients. The following examples shows a CPIM private message sent from a participant to a subset of the conference participants. Content-Type: message/cpim From: "Prince of the snow" To: "Blue Arrow" To: "Daisy" Cc: "Hook" DateTime: 2004-01-28T15:43:00-02:00 Content-Type: text/plain Content-ID: <092380923@foo.com> This is an example of a private instant message 4.3.2 Provision of nicknames to the focus A participant of a conference controlled by a particular focus can setup his nickname by any means outside the scope of this document. For instance, the participant can log into a web page where he authenticates and sets up his nickname. We also provide a mechanism that allows a participant to setup his nickname interactively with the focus. The mechanism is based on the exchange of XML "application/nickname-info+xml" documents. We define the "application/nickname-info+xml" in Section Section 4.3.2.1. The mechanism is inspired in the SDP offer/answer model, but instead, we define an XML "application/nickname-info+xml" offer/answer model. Any SIP request or responde can carry an "application/ nickname-info+xml" offer document, where the oferer express a request Niemi & Garcia-Martin Expires July 1, 2004 [Page 7] Internet-Draft Multiparty MSRP January 2004 to set her nickname. The focus response with an XML "application/ nickname-info+xml" answer where it authorizes or denies the request, or makes another suggestion. 4.3.2.1 The application/nickname-info+xml data format We define a nickname information XML document that is used to request, setup, and suggest other nicknames to a focus. Users of this specifications MUST support the "application/nickname-info+xml" data format and MAY support other data formats. As a consequence, the Accept header field in SIP messages MUST contain the "application/ nickname-info+xml" and MAY contain other types capable of representing a nickname. Nickname information is an XML document that MUST be well-formed and SHOULD be valid. Nickname information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying Nickname information documents. The namespace URI for elements defined by this specification is a URN [2], using the namespace identifier 'ietf' defined by RFC 2648 [4] and extended by [13]. This URN is: urn:ietf:params:xml:ns:nickname-info A Nickname information document begins with the root element tag "nickname-info" that contains a "version" attribute and an "entity" attribute The first time an offerer crates an offer, it initializes the "version" attribute to 0. Every time either the offerer or the answer crates a new offer or answer based on a previous document, it increments the version number by one. Versions are scoped by the pair of participant and focus. The "entity" attribute identifies the participant's URI whose nickname is being set. Most focuses will contain policy that disallows the own SIP URI to modify her own nickname, however policies are outside the scope of this memo. The "nickname-info" element contains a series of zero or more "nickname" child elements The "nickname" element contains information on a particular nickname. It has a two mandatory attributes, "id" and "state". The "id" attribute provides a single string that can be used as an identifier for this nickname. The "id" is created the first time the nickname is used. The "state" attribute carries the state of the nickname. Possible values are "suggested", indicating that the participant suggest a nickname for the entity; "confirmed", indicating that the Niemi & Garcia-Martin Expires July 1, 2004 [Page 8] Internet-Draft Multiparty MSRP January 2004 focus has confirmed that the nickname is unique and allocated to the entity; "denied" indicating that the focus does not authorize the usage of the nickname. In case the state is set to denied, an optional "reason" attribute can further indicate the reason of denial: "in-use" if the suggested nickname is already in use, or "policy" to indicate that the focus has some policy that denies the nickname (e.g., offensive word). The "nickname" element contains a "display-name" child element that contains the nickname display string that most application will render to the user. The "nickname" element can also contain a "uri"> child element. A participant MUST NOT set the "uri" element. The focus SHOULD set it to a non-routable IM URI that belongs to the address space of the focus. A participant SHOULD use his URI in the From header of a message/cpim message when it sends an instant message. 4.3.2.2 XML schema The following is the schema for the application/nickname-info+xml type: Niemi & Garcia-Martin Expires July 1, 2004 [Page 9] Internet-Draft Multiparty MSRP January 2004 4.3.2.3 Examples A participant has joined a session based messaging conference. She wants to setup a nickname, so she sends a SIP request that includes the following "application/nickname-info+xml" body. The document does not contain a URI, since URIs are set by the focus, it only contains the display name part of the nickname. The state is set to "suggested" since this is only a suggestion that needs to be confirmed by the focus. Niemi & Garcia-Martin Expires July 1, 2004 [Page 10] Internet-Draft Multiparty MSRP January 2004 Daisy Let's assume that the nickname is taken by another user. The focus sends a new XML body in a SIP message, where it steps up the version number in the document. The state of the nickname is set to "denied" and a "reason" is set to "in-use". The focus also suggest similar nicknames that are "available" for the participant to choose. The XML is: Daisy44 Daisy49 The participant decides not to take any of the suggestions, but instead suggests a new nickname. She also steps up the version number. Blue Arrow The focus of the conference verifies that the nickname is not in use by any other participant of any other conference. It internally binds the nickname with the SIP and MSRP URIs of the user. The focus steps up the version number, allocates an IM URI and returns the new Niemi & Garcia-Martin Expires July 1, 2004 [Page 11] Internet-Draft Multiparty MSRP January 2004 information in the XML body. Blue Arrow im:bluearrow@example.com.invalid 4.3.3 Procedures at the focus with respect nicknames Here we should describe that the focus verifies that the From header in the CPIM message is allocated to the user and keeps it in the CPIM message that sends to the rest of the participants. 5. IANA Considerations This document registers a new MIME type "application/ nickname-info+xml" and new XML namespace. 5.1 MIME Registration for application/nickname-info+xml MIME media type name: application MIME subtype name: nickname-info+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [5]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5]. Security considerations: See Section 10 of RFC 3023 [5] and Section 6 of this specification. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type has been used to support SIP applications in a multi-party session based Niemi & Garcia-Martin Expires July 1, 2004 [Page 12] Internet-Draft Multiparty MSRP January 2004 messaging environment. Additional Information: Magic Number: None File Extension: .nin or .xml Macintosh file type code: "TEXT" Personal and email address for further information: Miguel Garcia Intended usage: COMMON Author/Change controller: The IETF. 5.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:nickname-info This section registers a new XML namespace, as per the guidelines in [13]. URI: The URI for this namespace is urn:ietf:params:xml:ns:nickname-info. Registrant Contact: IETF, SIMPLE working group,, Miguel Garcia, . XML: BEGIN Nickname Information Namespace

Namespace for Nickname Information

application/nickname-info+xml

See RFCXXXX.

Niemi & Garcia-Martin Expires July 1, 2004 [Page 13] Internet-Draft Multiparty MSRP January 2004 END 5.3 Schema Registration This specification registers a schema, as per the guidelines in [13]. URI: please assign. Registrant Contact: IETF, SIMPLE working group,, Miguel Garcia, . XML: The XML can be found in Section 4.3.2.2. 6. Security Considerations In general, messages sent to a multy-party session based messaging focus are not deem to expose any security threat. Nevertheles, if a participant wants to avoid eavesdropping from non authorized entities, it should send those messages a TLS transport connection, as allowed by MSRP. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in progress), January 2003. [8] Peterson, J., "Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-im-04 (work in progress), October 2003. Niemi & Garcia-Martin Expires July 1, 2004 [Page 14] Internet-Draft Multiparty MSRP January 2004 Informative References [9] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless Systems", draft-niemi-simple-im-wireless-reqs-02 (work in progress), October 2003. [10] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", draft-rosenberg-simple-messaging-requirements-00 (work in progress), December 2002. [11] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-01 (work in progress), October 2003. [12] Campbell, B., "Instant Message Sessions in SIMPLE", draft-ietf-simple-message-sessions-02 (work in progress), October 2003. [13] Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003. Authors' Addresses Aki Niemi Nokia P.O. Box 321 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Miguel A. Garcia-Martin Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 480 4586 EMail: miguel.an.garcia@nokia.com Niemi & Garcia-Martin Expires July 1, 2004 [Page 15] Internet-Draft Multiparty MSRP January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Niemi & Garcia-Martin Expires July 1, 2004 [Page 16] Internet-Draft Multiparty MSRP January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Niemi & Garcia-Martin Expires July 1, 2004 [Page 17]