Network Working Group A. Niemi Internet-Draft M. Garcia-Martin Expires: January 19, 2006 Nokia July 18, 2005 Multi-party Instant Message (IM) Sessions using the Message Session Relay Protocol (MSRP) draft-niemi-simple-chat-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party instant message (IM) sessions, or chat rooms, using the centralized conferencing model. Niemi & Garcia-Martin Expires January 19, 2006 [Page 1] Internet-Draft Multiparty MSRP July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivations and Requirements . . . . . . . . . . . . . . . . . 4 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 5. Detailed Specification . . . . . . . . . . . . . . . . . . . . 7 5.1 Creating a Chat Room . . . . . . . . . . . . . . . . . . . 7 5.2 Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 8 5.3 Conference Participant Behavior . . . . . . . . . . . . . 8 5.3.1 Sending Instant Messages . . . . . . . . . . . . . . . 8 5.3.2 Sending Private Instant Messages . . . . . . . . . . . 9 5.3.3 Requesting Reports . . . . . . . . . . . . . . . . . . 10 5.3.4 Receiving Instant Messages . . . . . . . . . . . . . . 11 5.3.5 Receiving Private Instant Messages . . . . . . . . . . 11 5.4 MSRP Switch Behavior . . . . . . . . . . . . . . . . . . . 11 5.4.1 Relaying Instant Messages . . . . . . . . . . . . . . 12 5.4.2 Relaying Private Instant Messages . . . . . . . . . . 12 5.4.3 Generating reports . . . . . . . . . . . . . . . . . . 13 6. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Provisioning Nicknames . . . . . . . . . . . . . . . . . . 14 6.2 Modifying a Nickname . . . . . . . . . . . . . . . . . . . 14 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1 The MSRP DISTSEND method . . . . . . . . . . . . . . . . . 15 7.2 The MSRP Distribution Header Field . . . . . . . . . . . . 15 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1 Normative References . . . . . . . . . . . . . . . . . . . 15 11.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Niemi & Garcia-Martin Expires January 19, 2006 [Page 2] Internet-Draft Multiparty MSRP July 2005 1. Introduction The Message Session Relay Protocol (MSRP) [I-D.ietf-simple-message- sessions] defines a mechanism for sending a series of instant messages within a session. The Session Initiation Protocol (SIP) [RFC3261] in combination with the Session Description Protocol (SDP) [RFC3264] allows for two peers to establish and manage such sessions. In another application of SIP, a user agent can join in a multi-party session or conference that is hosted by a specialized user agent called a conference focus [I-D.ietf-sipping-conferencing-framework]. Such a conference can naturally involve an MSRP session as one of possibly many media components. It is the responsibility of an entity handling the media to relay instant messages received from one participant to the rest of the participants in the conference. Several such systems already exist in the Internet. Participants in a chat room can use a rich set of features, such as the ability to send private instant messages to one or more participants, and the ability to establish sub-conferences with one or more of the participants within the existing conference. They also allow combining instant messaging with other media components, such as voice, video, whiteboarding, screen sharing, and file transfer. The aim of this document is to define requirements, conventions and extensions for enabling features similar to many of these existing systems in the Internet, e.g., Internet Relay Chat (IRC) [RFC2810] and Extensible Messaging and Presence Protocol [RFC3920] based chat rooms. This memo uses the SIP Conferencing Framework [I-D.ietf-sipping- conferencing-framework] as a design base. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119], and indicate requirement levels for compliant implementations. This memo deals with a particular case of tightly coupled SIP conferences where the media exchanged consist of session-based instant messaging. Unless otherwise noted, we use the terminology defined in the SIP Conferencing Framework [I-D.ietf-sipping- conferencing-framework] applied to the scope of this document. In addition to that terminology, we introduce some new terms: Niemi & Garcia-Martin Expires January 19, 2006 [Page 3] Internet-Draft Multiparty MSRP July 2005 Session-based Instant Messaging Conference: an instance of a tightly coupled conference, in which the media exchanged between the participants consist of (among others) MSRP based instant messages. Also known as a chat room. Chat Room: a synonym for session-based instant messaging conference. Sender: the conference participant that originally created an instant message and sent it to the chat room for delivery. Recipient: the destination conference participant(s). This defaults to the full conference participant list, minus the IM Sender. MSRP switch: a media level entity that receives MSRP messages and delivers them to the other conference participants. An MSRP switch has a similar role to a conference mixer with the exception that an MSRP switch does not actually "mix" together different input media streams; it merely relays the messages between participants. Private Instant Message: an instant message sent in a chat room whose intended recipient is something other than the default. The recipient of a private IM can either be one specific conference participant, or a subset of the full participant list. A private IM is usually rendered distinctly from the rest of the IMs, as to indicate that the message was a private communication. 3. Motivations and Requirements Although conference frameworks describing many types of conferencing applications already exist, such as the Framework and Data Model for Centralized Conferencing [I-D.barnes-xcon-framework] and the SIP Conferencing Framework [I-D.ietf-sipping-conferencing-framework], the exact details of session-based instant messaging conferences are not well-defined at the moment. To allow interoperable chat implementations, for both conference- aware, and conference-unaware user agents, certain conventions for MSRP conferences need to be defined. It also seems beneficial to provide a set of features that enhance the baseline multiparty MSRP in order to be able to create systems that have functionality on par with existing chat systems. A number of requirements that enrich the session based messaging conferences have already been described in Requirements for Instant Messaging in 3GPP Wireless Systems [I-D.niemi-simple-im-wireless- reqs] or the Advanced Instant Messaging Requirements for the Session Niemi & Garcia-Martin Expires January 19, 2006 [Page 4] Internet-Draft Multiparty MSRP July 2005 Initiation Protocol [I-D.rosenberg-simple-messaging-requirements]. In addition, we define the following requirements: REQ-1: The conference must have the ability to host other media in addition to MSRP, as well as multiple streams of MSRP. REQ-2: A conference participant must be able to determine the identities of the sender and recipient of the received IMs. REQ-3: A conference participant must be able to determine the recipient of the received message. For instance, the recipient of the message might be the entire conference, a conference sidebar or a single participant of the conference (i.e., a private message). REQ-4: It must be possible to send a message to a single participant, or a subset of the conference participants (i.e., a private instant message). REQ-5: It must be possible to set up a sidebar session with one or more participants of the chat room. REQ-6: A conference participant may have a nickname or pseudonym associated with their real identity. REQ-7: It must be possible for a participant to change their nickname during the progress of the conference. OPEN ISSUE: This requirement (and the one above it) is not strictly an IM conference issue. In principle, participants of any conferences should be able to use a nickname, and change their nickname in the course of the conference. REQ-8: It must be possible that a participant is only known by their nickname and not their real identity to the rest of the conference. REQ-9: It must be possible for the MSRP switch itself to send IMs to the conference (e.g., message of the day, welcome messages, server is shutting down, etc.) REQ-10: A chat room, or a chat room sidebar must be able to be characterized with a topic whose purpose is to identify the subject of conversation. Niemi & Garcia-Martin Expires January 19, 2006 [Page 5] Internet-Draft Multiparty MSRP July 2005 REQ-11: A user with the appropriate privileges must be able to set and/or modify the topic of the chat room, or chat room sidebar. 4. Overview of Operation In order to set up a conference, one must first be created. Users wishing to host a conference themselves can of course do just that; their user agents simply morph from an ordinary user agent into a special purpose one called a conference focus. Another, commonly used setup is one where a dedicated node in the network functions as a conference focus. Each conference has an identity, a SIP URI that participants use to join the conference, e.g., by sending an INVITE. The conference focus processes the invitations, and as such maintains SIP dialogs with all of the participants. In an instant messaging conference, or chat room, one of the media streams offered is MSRP. Each conference participant establishes an MSRP session with an MSRP switch, which is a special purpose MSRP client. The MSRP switch is similar to a conference mixer, in that it is handles media sessions with each of the participants, and bridges these streams together. However, unlike a conference mixer, the MSRP switch merely relays messages between participants but doesn't actually mix the streams in any way. The system is illustrated in Figure 1. Niemi & Garcia-Martin Expires January 19, 2006 [Page 6] Internet-Draft Multiparty MSRP July 2005 +------+ | MSRP | |Client| +------+ +--.---+ +------+ | MSRP | | | MSRP | |Client| | _|Client| +------._ | ,' +------+ `._ | ,' `.. +----------+ ,' `| |' | MSRP | | Switch | ,| |_ _,-'' +----------+ ``-._ +------.-' | `--+------+ | MSRP | | | MSRP | |Client| | |Client| +------+ | +------+ +---'--+ | MSRP | |Client| +------+ Figure 1: Multiparty MSRP in a Centralized Conference When a participant wants to send an instant message to the conference, it constructs an MSRP SEND request and submits it to the MSRP switch. The switch then fans out the SEND to all of the other participants, using their MSRP sessions. A participant can also send a private communication by constructing an MSRP DISTSEND request with an appropriate recipient and submitting it to the MSRP switch. The switch will distribute the private message only to the indicated recipient rather than the full conference roster. If private communication is not supported (e.g., due to being disallowed by conference policy) the switch will not accept the DISTSEND method. All messages in the chat room use the 'message/cpim' wrapper content type [RFC3862], which enables identification of the message sender, intended recipient(s) and possible recipients of carbon-copies. Any MIME type can be included inside the wrapper type, e.g., 'text/ plain', 'text/html', 'image/jpeg' etc. When a participant wishes to leave a chat room, it sends a SIP BYE request to the conference focus and disconnects. More specific description of conference control functions are TBD. Niemi & Garcia-Martin Expires January 19, 2006 [Page 7] Internet-Draft Multiparty MSRP July 2005 5. Detailed Specification 5.1 Creating a Chat Room Since we consider a chat room a particular type of conference where one of the offered media happens to be MSRP, the methods defined by the SIP Conference Framework [I-D.ietf-sipping-conferencing- framework] for creating conferences are directly applicable to a chat room. Once a chat room is created, it is identified by a SIP URI, like any other conference. Participants are aware that the peer is a focus due to the presence of the "isfocus" feature tag in the Contact header field of the 2xx-class response to the INVITE request. Participants are also aware that the mixer is an MSRP switch due to the presence of the 'message' media type and either TCP/MSRP or TCP/ TLS/MSRP as the protocol field in the SDP [RFC2327] media-line. The conference focus of a chat room MUST insist on a Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by setting the 'accept-wrapped-types' attribute in the SDP offer or answer to include 'message/cpim'. It SHOULD also set the 'accept-types' attribute to '*', to indicate that any MIME type can be sent, unless the conference policy mandates certain types only. Note that 'message/cpim' is used to carry sender and recipient information for each instant message. The CPIM header will contain the sender, recipient(s) and any recipients of a carbon- copy. 5.2 Deleting a Chat Room As with creating a conference, the methods defined by the SIP Conference Framework [I-D.ietf-sipping-conferencing-framework] for deleting a conference are directly applicable to a chat room. Deleting a chat room is an action that heavily depends on the policy of the chat room. The policy can determine that the chat room is deleted when the creator leaves the conference, or with any out of band mechanism. 5.3 Conference Participant Behavior 5.3.1 Sending Instant Messages MSRP provides the SEND primitive that allows a sender to transport an instant message to the recipient. When a chat room participant Niemi & Garcia-Martin Expires January 19, 2006 [Page 8] Internet-Draft Multiparty MSRP July 2005 wishes to send an instant message to the chat room, it constructs a SEND request. The contents of the message MUST be encapsulated using the top-level wrapper of type 'message/cpim' [RFC3862]. The actual instant message payload inside 'message/cpim' MAY be of any type listed in the 'accept-types' attribute of the conference focus' SDP answe, e.g., text/plain, text/html, etc. A conference-aware participant that sends a session based instant message to an MSRP switch SHOULD populate the From header of the Message/CPIM wrapper with a proper identity by which the user is recognized in the conference. Identities that can be used (among others) are: o A SIP URI [RFC3261] representing the participant's address-of- record o A tel URI [RFC3966] representing the participan't telephone number o An IM URI [RFC3860] representing the participant's instant messaging address If the creator of the message wants to remain anonymous to the rest of the participants, and providing that the policy of the conference allows anonymous participation, the creator SHOULD include an anonymous identity, e.g., using the "anonymous" SIP URI as described in RFC 3261 [RFC3261] Section 8.1.1.3. A conference-aware participant that sends a session based instant message addressed to the chat room MUST set the To header of the Message/CPIM header to the SIP URI [RFC3261] of the conference focus, or to the URI of the participant(s) for which the instant message is targeted. Note that this URI can be any URI by which the recipient participant is known in the conference. It can also be the anonymous URI type, as discussed above. 5.3.2 Sending Private Instant Messages Sending of MSRP messages to a reduced set of the participants of the conference requires a new MSRP method 'DISTSEND', and a new header field 'Distribution'. SEND cannot be used because in case the MSRP switch does not support private instant messages, the sender of the message will expect an error response, and instead of the message being distributed to the default recipient, which is the entire Niemi & Garcia-Martin Expires January 19, 2006 [Page 9] Internet-Draft Multiparty MSRP July 2005 conference roster. The new header Distribution contains a list of participants that the creator wants the MSRP switch to distribute the message. This list of participants is a subset of the participants of the conference, whose identities have been learnt as part of the conference procedures, for instance, by inspecting the From header of Message/ CPIM bodies previously received by the endpoint, or by information acquired through a subscription to the conference event package [I-D.ietf-sipping-conference-package]. Additionally, the Distribution header can contain SIP URIs, such as the SIP URI of a sidebar conference or one participant. 5.3.2.1 The MSRP DISTSEND method We define a new MSRP 'DISTSEND' method. The semantics associated to this method is to distribute the payload to a reduced set of participants of the conference, rather than the whole set. The actual list of recipients is included in a Distribution (Section 5.3.2.2) header field. DISTSEND method is governed exactly by the same rules as the existing SEND method in MSRP, with the exception that the intended distribution of the message is expressed in the Distribution header field. DISTSEND requests MUST contain a Distribution header field, and MAY contain any other MSRP header field that is appropriate for the SEND method. The syntax of DISTSEND method is described in Section 7. 5.3.2.2 The MSRP Distribution header field We define a new MSRP Distribution header field, whose purpose is to convey a list of recipients of the MSRP message. The list can include any permanent or temporary identifier, including but not restricted to, SIP URIs, tel URIs, MSRP URLs, nicknames, etc. The syntax of the Distribution header field is described in Section 7. The mechanism described in this section is used to deliver a message to a subset of the participants of the conference. The subset can be indicated by the URI of a sidebar conference, or any other identifier of a participant, including temporary identifiers (such as MSRP URLs) and non routable identifiers (such as nicknames). A conference-aware participant that sends an MSRP message to a subset of the participants of the conference MUST create a DISTSEND request, Niemi & Garcia-Martin Expires January 19, 2006 [Page 10] Internet-Draft Multiparty MSRP July 2005 whose From-Path, To-Path and other possible header fields are created as a regular SEND request. The MSRP endpoint MUST include a Distribution header field that contains the list of recipients of the message. This list MUST be include only a subset of the participants of the conference or a URI that represents a sidebar conference. Then the MSRP endpoint SHOULD include a Message/CPIM wrapper. The To and Cc headers of it MUST include an identifier of the visible recipients, according to the semantics of To and Cc (note that invisible recipients are only listed in the MSRP Distribution header). The From header of the Message/CPIM SHOULD include the same information as described in Section 5.3.1. 5.3.3 Requesting Reports An MSRP endpoint might be interesting in receiving chronological information of the place in a sequence of MSRP messages where the endpoint-created message has been distributed to the recipients. For instance, and endpoint may require to insert sent messages in a sequence of received messages, so that the user has a time representation of the point in time at which a sent message has been distributed, and the relative order of that message in the sequence of other messages sent by other participants. A possible implementation of that requirement consist of the MSRP switch sending a copy of the message also to the creator of the message. However, we believe this might not be efficient, e.g., if the payload of the message is substantially large. Instead, an MSRP endpoint that requires to receive information of the sequence in which a message has been distributed MAY include a Report-Success header field with the values set to "yes" in either a SEND or DISTSEND request. An MSRP endpoint receiving a REPORT request for one of those messages can correlate the sequence of the sent message within the thread of conversation, and the endpoint may provide a visual representation of the sent message within the rest of the messages. 5.3.4 Receiving Instant Messages Both conference-aware and conference-unaware participants will receive MSRP SEND requests that contains a Message/CPIM message from an MSRP switch. The From header contains the identity of the creator of the message, in any available format. The To and Cc headers contain the intended recipient list, which can either be the SIP URI of the focus or the SIP URI of a sidebar conference, or any other URI of any participant in the conference. Niemi & Garcia-Martin Expires January 19, 2006 [Page 11] Internet-Draft Multiparty MSRP July 2005 5.3.5 Receiving Private Instant Messages Both conference-aware and conference-unaware participants will receive MSRP DISTSEND requests that contains a Message/CPIM message from an MSRP switch. The From header contains the identity of the creator of the message, in any available format. The To and Cc headers contain the intended recipient list, which can be any URI of any participant in the conference. Conference-unaware clients that do not understand the DISTSEND method SHOULD return an appropriate error response. Upon receiving such an error response, the MSRP switch will from then on suppress sending any private instant messages to that participant. We use this behavior in order to make sure private communications are duly marked as private in the participant's MSRP client implementations. It is notally unacceptable that a private instant message sent to a conference-unaware recipient becomes the topic of discussion of the full roster by mistake. 5.4 MSRP Switch Behavior An MSRP switch can receive messages sent from either conference-aware participants or conference-unaware participants. The switch receives either DISTSEND or SEND request that includes a Message/CPIM wrapped instant messages. It is assumed that the MSRP switch is able to map an identity that the participant is using to identify themselves in the conference and the corresponding MSRP session. In order to do that, the conference focus needs to maintain a mapping table between the conference participant identities and the MSRP session(s). A mapping is inserted into the table when a participant joins the conference, and the mappings are indexed using the identity that is visible to the conference roster, e.g.., the identity carried in the conference event package [I-D.ietf-sipping-conference-package]. 5.4.1 Relaying Instant Messages Upon receiving a complete SEND request or the last chunk of a SEND request, the MSRP switch performs the following steps: o Else, if the content type is not 'message/cpim' the MSRP switch aborts, and returns a 415 (Wrapper Type Unacceptable or Missing). o The MSRP switch MUST make sure that the identity carried in the 'From' heder field of Message/CPIM wrapper in the received SEND Niemi & Garcia-Martin Expires January 19, 2006 [Page 12] Internet-Draft Multiparty MSRP July 2005 request is one that the sender is authorized to use. By 'authorized' we mean that the participant has joined the conference using that same identity, and is also known by the other participants by that same identity. o If not, the switch MUST reject the SEND request. o The MSRP switch MUST create another SEND request for each of the other conference participants, containing the body or bodies included in the received SEND request. Then the MSRP switch sends the newly generated SEND request to each of the recipients. o The MSRP switch MAY need to re-chunk the outgoing SEND requests, as part of the general procedure for chunking SEND requests. Unless mentioned otherwise, outgoing MSRP SEND requests generated at the MSRP switch are governed by the general procedures for creating SEND requests specified in the MSRP specification [I-D.ietf-simple- message-sessions]. 5.4.2 Relaying Private Instant Messages Upon receiving a complete DISTSEND request or the last chunk of a DISTSEND request, the MSRP switch performs the following steps: o If the chat room disallows private instant messages, the MSRP switch MUST generate a 501 response and drop the message. A DISTSEND message MUST NOT be distributed to the full conference roster. Whether a chat room allows private messages is a policy decision and should be configurable by the conference creator. o Else, if the content type is not 'message/cpim' the MSRP switch aborts, and returns a 415 (Wrapper Type Unacceptable or Missing). o Else, the MSRP switch MUST make sure that the identity carried in the 'From' heder field of Message/CPIM wrapper in the received DISTSEND request is one that the sender is authorized to use. o If the switch is unable to resolve all of the URIs in the Distribution header field to actual conference participants, or the header field is missing, the switch MUST disregard the unresolved URIs. o The MSRP switch sends the received DISTSEND out to all of the conference participants whose URI is listed in Distribution header Niemi & Garcia-Martin Expires January 19, 2006 [Page 13] Internet-Draft Multiparty MSRP July 2005 field. It MUST NOT send the Distribution header field to the listed participants. OPEN ISSUE: Alternatively, we could use the Message/CPIM To and Cc header fields. The MSRP switch MAY need to re-chunk the outgoing DISTSEND requests, as part of the general procedure for chunking SEND requests. 5.4.3 Generating reports The MSRP procedures for generating reports apply for both received SEND and DISTSEND requests. On receiving a complete or the last chunk of a SEND or DISTSEND request with a Report-Success header field value set to "yes", the MSRP switch SHOULD inject a REPORT request back to the creator preserving the order the REPORT in the sequence of other distributed SEND or DISTSEND messages to that endpoint. To indicate failure to resolve one or more of the recipients in the 'Distribution' header field, the Status header field value SHOULD contain a "000" namespace, a "481" short-status, and a "Unable to Resolve Distribution" reason phrase. This REPORT request MUST also contain a Distribution header field that lists all the URIs that the MSRP switch was not able to resolve. 6. Nicknames [Editor's note: this chapter needs strengthening.] A common characteristic of existing chat room servers is that participants have the ability to identify themselves with a nickname to the rest of the participants in a conference. This provides a layer of anonymity, whereby the user is authenticated and identified by the chat room server, but not by participants of the chat room. A nickname is a URI that serves for the purposes of identifying a participant to the rest of the participants of the conference. It isn't necessarily a URI that resolves to the user outside of a specific conference, e.g., the "anonyous" SIP URI discssed earlier. One option to satisfy an aspect of nicknames is using the display name, with a real identity as the URI. A nickname in the display name offers a pseudonym that anyone can map to a real identity, thus not satisfying the anonymity requirements. Another option is to use a nicknaming service, that allows allocating nickname URIs to users. Using such a URI in a conference in effect Niemi & Garcia-Martin Expires January 19, 2006 [Page 14] Internet-Draft Multiparty MSRP July 2005 anonymizes the user, but still allows the user to be reached outside the chat room using the same identity. 6.1 Provisioning Nicknames OPEN ISSUE: Is this in scope for the work, or should the discussion of how nicknames are provisioned (including avoiding colliding display names) be included in this draft? 6.2 Modifying a Nickname OPEN ISSUE: This seems like a feature that is required in all conferneces, or even normal one-to-one calls. 7. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 [RFC2234] and extends the format syntax of MSRP [I-D.ietf-simple-message-sessions]. 7.1 The MSRP DISTSEND method DISTSENDm = %x44.49.53.54.53.45.4E.44 ; DISTSEND in caps Method =/ DISTSENDm 7.2 The MSRP Distribution Header Field headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) header =/ Distribution Distribution = "Distribution:" SP recipient-URI *( SP recipient-URI) recipient-URI = addr-spec / telephone-uri / absolute-URI addr-spec is imported from RFC 3261 [RFC3261]. telephone-uri is imported from RFC 3966 [RFC3966]. absolute-URI is imported from RFC 3986 [RFC3986]. Niemi & Garcia-Martin Expires January 19, 2006 [Page 15] Internet-Draft Multiparty MSRP July 2005 8. Examples TBD. 9. IANA Considerations This document does not include any IANA considerations. 10. Security Considerations In general, messages sent to a multi-party session based messaging focus are not deem to expose any security threat. Nevertheless, if a participant wants to avoid eavesdropping from non authorized entities, it should send those messages a TLS [RFC2246] transport connection, as allowed by MSRP. 11. References 11.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004. [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. Niemi & Garcia-Martin Expires January 19, 2006 [Page 16] Internet-Draft Multiparty MSRP July 2005 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [I-D.ietf-sipping-conferencing-framework] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-05 (work in progress), May 2005. [I-D.barnes-xcon-framework] Barnes, M. and C. Boulton, "A Framework and Data Model for Centralized Conferencing", draft-barnes-xcon-framework-02 (work in progress), February 2005. [I-D.ietf-simple-message-sessions] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-10 (work in progress), February 2005. 11.2 Informative References [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004. [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [I-D.niemi-simple-im-wireless-reqs] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless Systems", draft-niemi-simple-im-wireless-reqs-02 (work in progress), October 2003. [I-D.rosenberg-simple-messaging-requirements] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", draft-rosenberg-simple-messaging-requirements-01 (work in progress), February 2004. [I-D.ietf-sipping-conference-package] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", Niemi & Garcia-Martin Expires January 19, 2006 [Page 17] Internet-Draft Multiparty MSRP July 2005 draft-ietf-sipping-conference-package-12 (work in progress), July 2005. Authors' Addresses Aki Niemi Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 Email: aki.niemi@nokia.com Miguel A. Garcia-Martin Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 480 4586 Email: miguel.an.garcia@nokia.com Niemi & Garcia-Martin Expires January 19, 2006 [Page 18] Internet-Draft Multiparty MSRP July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Niemi & Garcia-Martin Expires January 19, 2006 [Page 19]