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:" ":" Niemi & Garcia-Martin Expires August 24, 2005 [Page 13] Internet-Draft Multiparty MSRP February 2005 where is the Namespace Identifier, and is the Namespace Specific String. For the purpose of this application we define an of "ietf: params:msrp:nicknames". The selection of the 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" \ 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]