| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
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 April 8, 2010.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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 chat sessions, or chat rooms, using MSRP.
1.
Introduction
2.
Terminology
3.
Motivations and Requirements
4.
Overview of Operation
5.
Creating, Joining, and Deleting
a Chat Room
5.1.
Creating a Chat Room
5.2.
Joining a Chat Room
5.3.
Deleting a Chat Room
6.
Sending and Receiving Instant Messages
6.1.
Regular Messages
6.2.
Private Messages
6.3.
MSRP reports and responses
7.
Nicknames
7.1.
Using Nicknames within a Conference
7.2.
Modifying a Nickname
7.3.
Removing a Nickname
7.4.
Nicknames in the Conference Event Package
7.5.
Nicknames not supported nor allowed
8.
The SDP 'chatroom' attribute
9.
Examples
9.1.
Joining a chat room
9.2.
Setting up a nickname
9.3.
Sending a regular message to the chat room
9.4.
Sending a private message to a participant
9.5.
Chuncked private message
9.6.
Sending a private message using anonymous URI
9.7.
Nickname in a conference information document
10.
IANA Considerations
10.1.
New MSRP Method
10.2.
New MSRP Header
10.3.
New MSRP Status Codes
10.4.
New SDP Attribute
11.
Security Considerations
12.
Contributors
13.
Acknowledgments
14.
References
14.1.
Normative References
14.2.
Informative References
§
Authors' Addresses
| TOC |
The Message Session Relay Protocol (MSRP) (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [RFC4975] defines a mechanism for sending a series of instant messages within a session. The Session Initiation Protocol (SIP) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] in combination with the Session Description Protocol (SDP) (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [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 conversation called a conference that is hosted by a specialized user agent called a focus [RFC4353] (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.). Such a conference can naturally involve MSRP sessions. It is the responsibility of an entity handling the media to relay instant messages received from one participant to the rest of the participants in the conference.
Several such systems already exist in the Internet. Participants in a chat room can be identified with a pseudonym or nickname, and decide whether their real identity is disclosed to other participants. Participants can also use a rich set of features such as the ability to send private instant messages to other participants.
Similar conferences supporting chat rooms are already available today. For example, Internet Relay Chat (IRC) (Kalt, C., “Internet Relay Chat: Architecture,” April 2000.) [RFC2810], Extensible Messaging and Presence Protocol (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) [RFC3920] based chat rooms, and many other proprietary systems provide chat room functionality. Specifying equivalent functionality for MSRP-based systems provides competitive features and enables interworking between the systems.
This document defines requirements, conventions, and extensions for providing private messages and nickname management in centralized conferences with MSRP. Participants in a chat room can be identified by a pseudonym, and decide if their real identity is disclosed to other participants. This memo uses the SIP Conferencing Framework (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) [RFC4353] as a design basis. It also aims to be compatible with the A Framework for Centralized Conferencing (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” June 2008.) [RFC5239]. It is expected that future mechanisms will be developed for providing similar functionality in generic conferences, i.e., where the media is not only restricted to MSRP. The mechanisms described in this document provide a future compatible short-term solution for MSRP centralized conferences.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119], and indicate requirement levels for compliant implementations.
This memo deals with tightly coupled SIP conferences defined in SIP Conferencing Framework (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) [RFC4353] adopting the terminology. In addition to that terminology, we introduce some new terms:
- Nickname:
- a pseudonym or descriptive name associated to a participant. See Section 7 (Nicknames) for details
- Multi-party chat:
- an instance of a tightly coupled conference, in which the media exchanged between the participants consist of MSRP based instant messages. Also known as a chat room.
- Chat Room:
- a synonym for a multi-party chat
- Chat Room URI:
- a URI that identifies a particular chat room, and is a synonym of a Conference URI defined in [RFC4353] (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.)
- 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 is a MSRP endpoint. It is a special MSRP endpoint that receives MSRP messages, and delivers them to the other conference participants. The MSRP switch has a similar role to a conference mixer with the exception that the 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 intended for a single participant. A private IM is usually rendered distinctly from the rest of the IMs, indicating that the message was a private communication.
- Anonymous URI:
- a temporary Globally Routable User Agent URI (GRUU) (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.) [I‑D.ietf‑sip‑gruu] that can be registered with the conference focus to conceal a participant's SIP AOR from the other participants in the conference.
| TOC |
Although conference frameworks describing many types of conferencing applications already exist, such as the Framework for Centralized Conferencing (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” June 2008.) [RFC5239] and the SIP Conferencing Framework (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) [RFC4353], the exact details of session-based instant messaging conferences are not well-defined at the moment.
To allow interoperable chat implementations, for both conference-aware, and conference-unaware user agents, certain conventions for MSRP conferences need to be defined. It also seems beneficial to provide a set of features that enhance the baseline multi-party MSRP in order to be able to create systems that have functionality on par with existing chat systems, as well as enable building interworking gateways to these existing chat systems.
We define the following requirements:
- REQ-1:
- A basic requirement is the existence of a multi-party conference, where participants can join and leave the conference and get instant messages exchanged to the rest of the participants.
- 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 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 within the conference (i.e., a private instant message).
- REQ-5:
- A conference participant may have a nickname or pseudonym associated with their real identity.
- REQ-6:
- It must be possible for a participant to change their nickname during the progress of the conference.
- REQ-7:
- It must be possible that a participant is only known by an anonymous identity and not their real identity to the rest of the conference.
- REQ-8:
- It must be possible for the MSRP switch originate IMs to the conference by owner or administrator (e.g. message of the day, welcome messages, server is shutting down, etc.)
- REQ-9:
- It must be possible for the conference participants to learn the chat room capabilities described in this document.
| TOC |
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 Agent (UA) simply morphs from an ordinary UA into a special purpose one called a Focus UA. Another, commonly used setup is one where a dedicated node in the network functions as a Focus UA.
Each chat room has an identity of its own: a SIP URI that participants use to join the conference, e.g. by sending an INVITE request. The conference focus processes the invitations, and as such, maintains SIP dialogs with each participant. In an multi-party chat, or chat room, MSRP is one of the established media streams. Each conference participant establishes an MSRP session with the MSRP switch, which is a special purpose MSRP application. The MSRP sessions can be relayed by one or more MSRP relays found in [RFC4976] (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.). This is illustrated in Figure 1 (Multi-party chat overview shown with MSRP Relays and a conference Focus UA)
MSRP Sessions
+---------------------------+
| +-----------+ |
+---+--+ +---+--+ | |
| SIP | | SIP | | |
| MSRP | | MSRP | +--+---+----+
|Client| |Client| | MSRP |
+---+--+ ++-----+ | Relay |
| | +-----+-----+
SIP Dialogs | / |
| | | MSRP Sessions
+----+------+--+ |
| Conference | +-------+-----+
| Focus UA | | MSRP |
| |........| Switch |
| | | |
+---+--------+-+ +-------+-----+
| \ |
SIP Dialogs | | | MSRP Sessions
| \ |
+--+---+ +-+----+ +-----+------+
| SIP | | SIP | | MSRP |
| MSRP | | MSRP | | Relay |
|Client| |Client| +-+-------+--+
+---+--+ +--+---+ | |
| +-----------+ |
+------------------------------+
MSRP sessions
| Figure 1: Multi-party chat overview shown with MSRP Relays and a conference Focus UA |
The MSRP switch is similar to a conference mixer in that it handles media sessions with each of the participants and bridges these streams together. However, unlike a conference mixer, the MSRP switch merely forwards messages between participants but doesn't actually mix the streams in any way. The system is illustrated in Figure 2 (Multi-party chat in a Centralized Conference).
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
| Figure 2: Multi-party chat in a Centralized Conference |
Typically conference participants also subscribe to the conference event package (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) [RFC4575] to gather information about the conference roster in the form of conference state notifications. For example, participants can learn about other participants' identities.
All messages in the chat room use the 'Message/CPIM' wrapper content type (Klyne, G. and D. Atkins, “Common Presence and Instant Messaging (CPIM): Message Format,” August 2004.) [RFC3862], so that it is possible to distinguish between private and regular messages. When a participant wants to send an instant message to the conference, it constructs an MSRP SEND request and submits it to the MSRP switch including a regular payload (e.g. a Message/CPIM message that contains a text, html, an image, etc.). The Message/CPIM To header is set to the chat room URI. The switch then fans out the SEND request to all of the other participants using their existing MSRP sessions.
A participant can also send a private instant message addressed to a participants whose identity has been learned, e.g. via a notification from the conference event package (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) [RFC4575]. In this case the sender creates an MSRP SEND request with a Message/CPIM body whose To header contains not the chat room URI but the recipient's URI. The MSRP switch then forwards the SEND request to the recipient.
We extend the current MSRP negotiation that takes place in SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] to allow participants to learn whether the chat room supports and is willing to accept (e.g. due to local policy restrictions) certain MSRP functions defined in this memo, such as nicknames or private messaging.
Naturally, when a participant wishes to leave a chat room, it sends a SIP BYE request to the Focus UA and terminates the SIP dialog with the focus and MSRP sessions with the MSRP switch.
| TOC |
| TOC |
Since we consider a chat room a particular type of conference having MSRP media, the methods defined by the SIP Conference Framework (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) [RFC4353] for creating conferences are directly applicable to a chat room.
Once a chat room is created, it is identified by a SIP URI, like any other conference.
| TOC |
Participants usually join the conference by sending an INVITE request to the conference URI. As long as the conference policy allows, the INVITE request is accepted by the focus and the user is brought into the conference. Conference aware participants will detect that the peer is a focus due to the presence of the "isfocus" feature tag (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” August 2004.) [RFC3840] in the Contact header field of the 200-class response to the INVITE request. Conference unaware participants will not notice it is a foucs, and can not apply the additional mechanisms defined in this document. Participants are also aware that the mixer is an MSRP switch due to the presence of an 'message' media type and either TCP/MSRP or TCP/TLS/MSRP as the protocol field in the SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] media-line.
The conference focus of a chat room MUST include support for a Message/CPIM (Klyne, G. and D. Atkins, “Common Presence and Instant Messaging (CPIM): Message Format,” August 2004.) [RFC3862] top-level wrapper for the MSRP messages by setting the 'accept-types' MSRP media line attribute in the SDP offer or answer to include 'Message/CPIM'.
Note that the 'Message/CPIM' wrapper is used to carry the sender information that, otherwise, it will not be available to the recipient. Additionally, 'Message/CPIM' wrapper carries the recipient information (e.g. To and Cc: headers).
If a participant wants to remain anonymous to the rest of the participants in the conference, the participant's UA can register or acquire by other means a temporary GRUU with the conference focus. The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.) [I‑D.ietf‑sip‑gruu]. The temporary GRUU can be used in the From and To header in the 'Message/CPIM' wrapper concealing the participant's SIP AOR from the other participants in the conference.
The conference focus of a chat room MUST learn the chat room capabilities of each participant that joins the chat room, and MUST inform the MSRP switch of such support. This is to prevent that the MSRP switch distributes private messages to participants who do not support private messaging. The recipient could be able to render the private message, but not supporting private messages the participant can not respond.
| TOC |
As with creating a conference, the methods defined by the SIP Conference Framework (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) [RFC4353] for deleting a conference are directly applicable to a chat room. The MSRP switch will terminate the MSRP sessions with all the participants.
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.
| TOC |
| TOC |
This section describes the conventions used to send and receive instant messages that are addressed to all the participants in the chat room. These are sent over a regular MSRP SEND request that contains a Message/CPIM wrapper (Klyne, G. and D. Atkins, “Common Presence and Instant Messaging (CPIM): Message Format,” August 2004.) [RFC3862] that in turn contains the desired payload (e.g. text, image, video-clip, etc.).
When a chat room participant wishes to send an instant message to all the other participants in the chat room, he constructs an MSRP SEND request that MUST contain a top-level wrapper of type 'Message/CPIM' (Klyne, G. and D. Atkins, “Common Presence and Instant Messaging (CPIM): Message Format,” August 2004.) [RFC3862]. The actual instant message payload inside 'Message/CPIM' MAY be of any type negotiated in the SDP 'accepted-types' attribute according to the MSRP rules.
The sender SHOULD populate the From header of the Message/CPIM wrapper with a proper identity by which the user is recognized in the conference. Identities that can be used (among others) are:
The MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI.
Then the MSRP switch should inspect the To header field of the Message/CPIM wrapper. If the To header field of the Message/CPIM wrapper contains the chat room URI, the MSRP switch can generate a copy of the SEND request to each of the participants in the conference except the sender. The MSRP switch MUST NOT modify any of the bodies included in the received SEND request. Note that the MSRP switch does not need to wait for the reception of the complete MSRP chunk or MSRP message before it starts the distribution to the rest of the participants. Instead, once the MSRP switch has received the headers of the Message/CPIM body it SHOULD start the distribution process. Having the Message/CPIM header only in the first chunk, the MSRP switch MUST track the Message-Id until the last chunk of the message has been distributed.
An MSRP endpoint that receives a SEND request from the MSRP switch containing a Message/CPIM wrapper SHOULD first inspect the To header field of the Message/CPIM body. If the To header field is set to the chat room URI, it should render it is a regular message that has been distributed to all the participants in the conference. Then the MSRP endpoint SHOULD inspect the From header field of the Message/CPIM body to identify the sender. The From header field will include a URI that identifies the sender. The endpoint might have also received further identity information through a subscription to the SIP conference event package (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) [RFC4575].
| TOC |
This section describes the conventions used to send and receive private instant messages, i.e., instant messages that are addressed to one participant of the chat room rather to all of them. A chat room can signal support for private messages using the chatroom-attribute (see Section 8 (The SDP 'chatroom' attribute) for details).
When a chat room participant wishes to send a private instant message to a participant the chat room, it follows the same procedures for creating a SEND request as for regular messages (Regular Messages). The only difference is that the MSRP endpoint MUST populate the To header of the Message/CPIM with the identity of the intended recipient. The identity can be SIP, TEL, and IM URIs typically learned from the information received in notifications of the conference event package (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) [RFC4575].
As for regular messages, the MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI, and that the recipient is supporting private messages. See section Section 6.3 (MSRP reports and responses) for report and response handling. If successful, the MSRP switch should search it's mapping table to find the MSRP session established towards the recipient. If a match is found the MSRP switch MUST create a SEND request and MUST copy the contents of the sender's message to it.
An MSRP endpoint that receives a SEND request from the MSRP switch does the same validations as for regular messages (Regular Messages). If the To header field is different from the chat room URI, the MSRP endpoints know that it is a private message. It should render who it is from based on the From header of the Message/CPIM wrapper
It is possible that a participant, identified by a SIP Address of Record, joins a conference of instant messages from two or more different SIP UAs. It is RECOMMENDED that the the MSRP switch can map a participant or anonymous URI for two or more MSRP sessions. If the policy of the server allows for this, the MSRP switch MUST copy all messages intended for the recipient through each MSRP session.
| TOC |
The MSRP SHALL follow the success report and failure report handling described in section 7 of [RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.). For regular messages the MSRP switch MUST act as a MSRP endpoint receiver of the request according to section 5.3 of [RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.).
For regular messages the MSRP switch MAY use any report model in the copies of the regular SEND request intended for the recipients, but any received reports MUST NOT be forwarded to the originator of the original SEND request. This could lead to having the sender receiving multiple reports for a single MSRP request. The MSRP switch for regular messages SHALL construct responses according to section 7.2 of [RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.). If the URI included in the From header field of the Message/CPIM wrapper is not valid (e.g, because it does not "belong" to the user), the response code is 403. Otherwise the response code is 200.
Private messages (section Section 6.2 (Private Messages)) handle MSRP reports differently from regular chat room messages. The MSRP switch acts transparently having an end-to-end relationship between the sender and the recipient. The MSRP switch MUST for private messages keep any Sucess-Report and Failure-Report headers in the relayed request. Any reports or responses from the recipient MUST be forwarded to the sender.
For private messages the MSRP switch MUST follow section 7.2 of [RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) in the following error scenarios. The MSRP switch MUST inspect the To header field of the Message/CPIM wrapper. If the To header field of the Message/CPIM wrapper in the request does not contain the chat room URI, it must check if it contains a participants URI associated with a participant. If the URI in the To header can not be resolved (e.g. cased by a mistyped URI or that the recipient has abandoned he chat room), the response error code is 427. The new 427 status code indicates a failure to resolve the recipient URI in the To header field. If the recipient doesn't support private messages, the response code is 428. The new response 428 indicate that the recipient does not support private messages. A REPORT request MUST include a Message/CPIM wrapper, with the original From header field included in the SEND request, and the To header field of the original message. The message MUST NOT be forwarded to the recipient if above conditions applies.
| TOC |
A common characteristic of existing chat room services is that participants have the ability to present themselves with a nickname to the rest of the participants of the conference. It is used for easy reference of participants in the chat room, and can also provide anonymous participants with a meaningful descriptive name.
A nickname is a useful construct in many use cases, of which MSRP chat is but one example. It is associated with a URI of which the participant is known to the focus. It is a user selectable appearance of which the participant wants to be known to the other participants. It is not a 'display-name', but it is used somewhat like a display name. A main difference is that a nickname is unique inside a chat room to allow an unambiguous reference to a participant in the chat. Nicknames may be long lived, or may be temporary. Users also need to reserve a nickname prior to its utilization.
This memo specifies the nickname as a string. The nickname string MUST be unambiguous within the scope of the chat room (conference instance). This scope is similar to having a nickname unique inside a chat room from Extensible Messaging and Presence Protocol (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) [RFC3920]. The chat room may have policies associated with nicknames. It may not accept nickname strings at all, or a it may provide a wider unambiguous scope like a domain or server, similar to Internet Relay Chat (IRC) (Kalt, C., “Internet Relay Chat: Architecture,” April 2000.) [RFC2810].
| TOC |
This memo provides a mechanism to reserve a nickname for a participant for as long as the participant is logged into the chat room. The mechanism is based on a NICKNAME MSRP method (see below) and a new "Use-Nickname" header. Note that other mechanisms may exist (for example, a web page reservation system), although they are outside the scope of this document.
A conference participant who has established an MSRP session with the MSRP switch, where the MSRP switch has indicated the support and availability of nicknames with the 'nicknames' token in the 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP switch. The NICKNAME request MUST include a new Use‑Nickname header that contains the nickname string that the participant wants to reserve.
The MSRP switch that receives a NICKNAME request containing a nickname in the Use‑Nickname header field SHOULD first verify whether the policy of the chat room allows the nickname functionality. If is not allowed, the MSRP the response code is 501 section 7.2 of [RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) for constructing a response.
If the policy of the chat room allows the usage of nicknames, the MSRP switch SHOULD validate that the SIP AOR is entitled to reserve the nickname. The participant's authenticated identity can be derived after a successful HTTP Digest Authentication, included in a trusted SIP P-Asserted-Identity header field, included in a valid SIP Identity header field, or derived from any other present or future SIP authentication mechanism. Once the MSRP switch has validated that the participant is entitled to reserve the nickname, the response code is 200.
The reservation of a nickname can fail, e.g. if the NICKNAME request contains a malformed or non-existent Use‑Nickname header field, or if the same nickname has already been reserved by another participant in the conference. The validation can also fail where the SIP AOR is not entitled to reserve the nickname. In any of these cases the MSRP response code is 423.The semantics of the 423 response are: "Nickname usage failed; the nickname is not allocated to this user".
As indicated earlier, this specification defines a new MSRP header field: "Use-Nickname". The Use‑Nickname header field carries a nickname string, and SHOULD be included in the NICKNAME requests.
The syntax of the NICKNAME method and the "Use-Nickname" header field is built upon the MSRP formal syntax (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [RFC4975]
ext-method =/ NICKNAMEm
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header is specified in RFC 4975
Use-Nickname = "Use-Nickname" ":" nickname
nickname = quoted-string
| TOC |
Typically participants will reserve a nickname as soon as they join the chat room. But it is also possible for participants to modify their own nicknames and replace them it a new one at any time during the duration of the MSRP session. Modification of the nickname is not different from the initial reservation and usage of a nickname, thus the NICKNAME method is used as described in Section 7.1 (Using Nicknames within a Conference).
If a NICKNAME request that attempts to modify the current nickname of the user for some reason fails, the current nickname stays in effect. A new nickname comes into effect and the old one is released only after a NICKNAME request is accepted with a 200 response.
| TOC |
If the participant no longer wants to be known by a nickname in the conference, the participant can follow the method described in Section 7.2 (Modifying a Nickname). The nickname element of the Use‑Nickname header MUST be set to an empty quoted string.
| TOC |
Typically the conference focus acts as a notifier of the SIP conference event package (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) [RFC4575]. The conference focus MAY notify subscribers of the nickname reserved by a given participant. We define an extension to the conference event package to include nicknames. The extension adds a <nickname> child element to the <user> element containing the nickname string.
The following element is to be added to the sequence of the USER-TYPE in the XML schema in conference event package (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) [RFC4575]
<xs:element name="nickname" type="xs:string" minOccurs="0" \>
| TOC |
The participants of the conference are identified by the SIP, TEL and IM URI's typically learned from the information received in notifications of the conference event package (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) [RFC4575]. If nicknames are not supported nor allowed, the participant list of the conference will be less presentable.
| TOC |
There are a handful of use cases where a participant would like to learn the chat room capabilities supported by the MSRP switch and the chat room. For example, a participant would like to learn if the MSRP switch supports private messaging, otherwise, the participant may send what he believes is a private instant message addressed to a participant, but since the MSRP switch does not support the functions specified in this memo, the message gets eventually distributed to all the participants of the chat room.
The reverse case also exists. A participant, say Alice, whose user agent does not support the extensions defined by this document joins the chat room. The MSRP switch learns that Alice application does not support private messaging nor nicknames. If another participant, say Bob, sends a private message to Alice, the MSRP switch does not distribute it to Alice, because Alice is not able to differentiate it from a regular message sent to the whole roster. Further more, if Alice replied to this message, she would do it to the whole roster. Because of this, the MSRP switch keeps also track of users who do not support the extensions defined in this document.
In another scenario, the policy of a chat room may indicate that certain functions are not allowed. For example, the policy may indicate that nicknames or private messages are not allowed.
In order to provide the user with a good chat room experience, we define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a media-level attribute that MAY be included in conjunction with and MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the intersection of support and chat room local policy allowance for a number of functions specified in this document. Specifically, we provide the means for indicating support to use nicknames and private messaging.
The 'chatroom' SDP attribute has the following syntax:
chatroom = chatroom-label ":" chat-token *(SP chat-token)
chatroom-label = "chatroom"
chat-token = (nicknames-token | private-msg-token | token)
nicknames-token = "nicknames"
private-msg-token = "private-messages"
A conference focus that includes the 'nicknames' token in the session description is signaling that the MSRP switch supports and the chat room allows to use of the procedures specified in Section 7 (Nicknames). A conference focus that includes the 'private-messages' in the SDP description is signaling that the MSRP switch supports and the chat room allows to use of the procedures specified in Section 6.2 (Private Messages).
Example of the 'chatroom' attribute for an MSRP media stream that indicates the acceptance of nicknames and private messages:
a=chatroom:nickname private-messages
| TOC |
| TOC |
Figure 3 (Flow diagram of a user joining a chat room) presents a flow diagram where Alice joins a chat room by sending an INVITE request. This INVITE request contains a session description that includes the chatroom extensions defined in this document.
Alice Conference focus | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | |
| Figure 3: Flow diagram of a user joining a chat room |
F1: Alice constructs an SDP description that includes an MSRP media stream. She also indicates her support for the chatroom extensions defined in this document. She sends the INVITE request to the chat room server.
INVITE sip:chatroom22@chat.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Chatroom 22 <sip:chatroom22@chat.example.com> Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:alice@client.atlanta.example.com;transport=tcp> Content-Type: application/sdp Content-Length: [length] v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 atlanta.example.com m=message 7654 TCP/MSRP * a=accept-types:message/cpim text/plain text/html a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp a=chatroom:nickname private-messages
| Figure 4: INVITE request containing an SDP offer with
chat room extensions |
F2: The chat room server accepts the session establishment. It includes the 'isfocus' and other relevant feature tags in the Contact header field of the response. The chat room server also builds an SDP answer that also that forces the reception of messages wrapped in message/cpim envelops. It also includes the the chatroom attribute with the allowed extensions.
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: [length]
v=0
o=chat 2890844527 2890844527 IN IP4 chat.example.com
s=-
c=IN IP4 chat.example.com
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
a=chatroom:nickname private-messages
| Figure 5: 200 (OK) response including chat room
extensions |
F3: The session established is acknowledged (details not shown).
| TOC |
Figure 6 (Flow diagram of a user setting up her nickname) shows an example of Alice setting up a nickname using the conference as provider. Her first proposal is not accepted because the proposed nickname is already in use. Her second proposal is accepted.
Alice MSRP switch | | |(1) (MSRP) NICKNAME | |----------------------->| |(2) (MSRP) 423 | |<-----------------------| |(3) (MSRP) NICKNAME | |----------------------->| |(4) (MSRP) 200 | |<-----------------------| | |
| Figure 6: Flow diagram of a user setting up her nickname |
F1: Alice sends an MSRP NICKNAME request that contains her proposed nicknames in the Set-Nickname header field.
MSRP d93kswow NICKNAME To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Use-Nickname: "Alice the great" -------d93kswow$
| Figure 7: MSRP NICKNAME request with an initial nickname proposal |
F2: The MSRP switch analyzes the existing allocation of nicknames and detects that the nickname "Alice is great" is already provided to another participant by the conference. The MSRP switch answers with a 423 response.
MSRP d93kswow 423 Nickname usage failed To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp -------d93kswow$
| Figure 8: MSRP 423 response |
F3: Alice receives the response. She proposes a new nickname in a second NICKNAME request.
MSRP 09swk2d NICKNAME To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Use-Nickname: "Alice in wonderland" -------09swk2d$
| Figure 9: MSRP NICKNAME request with a second nickname proposal |
F4: The MSRP switch accepts the nickname proposal and answers with a 200 response.
MSRP 09swk2d 200 OK To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp -------09swk2d$
| Figure 10: MSRP NICKNAME request |
| TOC |
Figure 11 (Sending a regular message to the chat room) depicts a flow diagram where Alice is sending a regular message addressed to the chat room. The MSRP switch distributes the message to the rest of the participants.
Alice MSRP switch Bob Charlie | | | | | (1) (MSRP) SEND | | | |--------------------->| (3) (MSRP) SEND | | | (2) (MSRP) 200 |----------------------->| | |<---------------------| (4) (MSRP) SEND | | | |------------------------------->| | | (5) (MSRP) 200 OK | | | |<-----------------------| | | | (6) (MSRP) 200 OK | | | |<------------------------------ | | | | | | | | |
| Figure 11: Sending a regular message to the chat room |
F1: Alice builds a text message and wraps it in a CPIM message. She addresses the CPIM message to the chat room. She encloses the result in an MSRP SEND request and sends it to the MSRP switch via the existing TCP connection.
MSRP 3490visdm SEND To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Message-ID: 99s9s2 Byte-Range: 1-*/* Content-Type: message/cpim To: <sip:chatroom22@chat.example.com;transport=tcp> From: <sip:alice@atlanta.example.com> DateTime: 2009-03-02T15:02:31-03:00 Content-Type: text/plain Hello guys, how are you today? -------3490visdm$
| Figure 12: Instant message addressed to all participants
in the chat room |
F2: The MSRP switch acknowledges the reception of the SEND request with a 200 (OK) response.
MSRP 3490visdm 200 OK To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp Message-ID: 99s9s2 Byte-Range: 1-*/* -------3490visdm$
| Figure 13: 200 (OK) response |
F3: The MSRP switch creates a new MSRP SEND request that contains the received message/cpim body and sends it to Bob.
MSRP 490ej23 SEND To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp From-Path: msrp://chat.example.com:5678/jofofo3;tcp Message-ID: 304sse2 Byte-Range: 1-*/* Content-Type: message/cpim To: <sip:chatroom22@chat.example.com;transport=tcp> From: <sip:alice@atlanta.example.com> DateTime: 2009-03-02T15:02:31-03:00 Content-Type: text/plain Hello guys, how are you today? -------490ej23$
| Figure 14: Instant message sent to all participants |
The rest of the message flows are analogous to the previous. They are not shown here.
| TOC |
Figure 15 (Sending a private message to Bob) depicts a flow diagram where Alice is sending a private message addressed to Bob's SIP AOR. The MSRP switch distributes the message only to Bob.
Alice MSRP switch Bob | | | | (1) (MSRP) SEND | | |--------------------->| (3) (MSRP) SEND | | (2) (MSRP) 200 |----------------------->| |<---------------------| | | | | | | |
| Figure 15: Sending a private message to Bob |
F1: Alice builds a text message and wraps it in a CPIM message. She addresses the CPIM message to the Bob's nickname, which she learned from a notification in the conference event package. She encloses the result in an MSRP SEND request and sends it to the MSRP switch via the existing TCP connection.
MSRP 6959ssdf SEND To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Message-ID: okj3kw Byte-Range: 1-*/* Content-Type: message/cpim To: <sip:Bob%20the%20great@example.com> From: <sip:Alice%20in%20wonderland@example.com> DateTime: 2009-03-02T15:02:31-03:00 Content-Type: text/plain Hello Bob. -------6959ssdf$
| Figure 16: Private instant message addressed to one participant |
F2: The MSRP switch acknowledges the reception of the SEND request with a 200 (OK) response.
MSRP 6959ssdfm 200 OK To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp Message-ID: okj3kw Byte-Range: 1-*/* -------6959ssdfm$
| Figure 17: 200 (OK) response |
F3: The MSRP switch creates a new MSRP SEND request that contains the received message/cpim body and sends it only to Bob. Bob can distinguish the sender in the From header of the CPIM message. He also identifies this as a private message due to the To CPIM header.
MSRP 9v9s2 SEND To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp From-Path: msrp://chat.example.com:5678/jofofo3;tcp Message-ID: d9fghe982 Byte-Range: 1-*/* Content-Type: message/cpim To: <sip:Bob%20the%20great@example.com> From: <sip:alice@atlanta.example.com> DateTime: 2009-03-02T15:02:31-03:00 Content-Type: text/plain Hello Bob. -------9v9s2$
| Figure 18: Private instant message sent to Bob |
| TOC |
Figure 19 (Chuncked private message) depicts an example of the private message in Section 9.4 (Sending a private message to a participant) split in two chuncks. The MSRP switch must wait for the complete set of CPIM headers before distributing the messages.
MSRP 7443ruls SEND To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Message-ID: aft4to Byte-Range: 1-*/174 Content-Type: message/cpim To: <sip:Bob%20the%20great@example.com> From: <sip:sip:tgruu.7hatz6cn-098s-anonymous@chat.example.com;gr> -------7443ruls$ MSRP 7443ruls SEND To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Message-ID: aft4to Byte-Range: 68-174/174 Content-Type: message/cpim DateTime: 2009-03-02T15:02:31-03:00 Content-Type: text/plain Hello Bob -------7443ruls$
| Figure 19: Chuncked private message |
| TOC |
Figure 20 (Sending an anonymous private message to Bob) depicts a flow diagram where Alice is utilizing the temporary GRUU when sending a private message to Bob
Alice MSRP switch Bob | | | | (1) (MSRP) SEND | | |--------------------->| (3) (MSRP) SEND | | (2) (MSRP) 200 |----------------------->| |<---------------------| | | | | | | | | | |
| Figure 20: Sending an anonymous private message to Bob |
F1: Alice builds a text message adding her registered temp-gruu to the From header of the CPIM message
MSRP 7443ruls SEND To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Message-ID: aft4to Byte-Range: 1-*/* Content-Type: message/cpim To: <sip:Bob%20the%20great@example.com> From: <sip:sip:tgruu.7hatz6cn-098s-anonymous@chat.example.com;gr> DateTime: 2009-03-02T15:02:31-03:00 Content-Type: text/plain Hello Bob. -------7443ruls$
| Figure 21: Anonymous private instant message |
F2: The MSRP switch inspects the From header field and verifies that the temp-gruuu in registered to Alice. If the temporary gruu is valid, the MSRP acknowledges the reception of SEND request with a 200 (OK) response
MSRP 7443ruls 200 OK To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp Message-ID: aft4to Byte-Range: 1-*/* -------7443ruls$
| Figure 22: 200 (OK) response |
Flow F3 is not shown
| TOC |
Figure 23 (Nickname in a conference information document) depicts two user elements in a conference information document both having the nickname element with a nickname string.
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:chatroom22@chat.example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>MSRP nickname example</subject>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>2</user-count>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:Bob%20the%20great@example.com" state="full">
<nickname>Bobster</nickname>
</user>
<!--
USER
-->
<user entity="sip:alice@atlanta.example.com" state="full">
<nickname>Depressed Donkey</nickname>
</user>
</users>
</conference-info>
| Figure 23: Nickname in a conference information document |
| TOC |
| TOC |
This specification defines a new MSRP method to be added to the Methods sub-registry under the MSRP Parameter registry: NICKNAME. See section Section 7 (Nicknames) for details.
| TOC |
This specification defines a new MSRP header to be added to the header-field sub registry under the MSRP Parameter registry: Use‑Nickname. See section Section 7 (Nicknames) for details.
| TOC |
This specification defines three new MSRP status codes to be added to the Status-Code sub-registry under MSRP parameters.
The 427 status code indicates the failure to resolve the recipient URI in the To header field of the Message/CPIM wrapper in the SEND request. See section for details.
The 428 status code indicates that the recipient of a SEND request does not support private messages. See section for details.
The 423 response indicates that the requested nickname is not allocated to the user requesting it. See section Section 7 (Nicknames) for details.
| TOC |
This specification defines a new media level attribute in the Session Description Protocol (SDP) Parameters registry: chatroom. See section Section 8 (The SDP 'chatroom' attribute) for details.
| TOC |
This document proposes extensions to the Message Session Relay Protocol (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [RFC4975]. Therefore, the security considerations of such document apply to this document as well.
In general, messages sent to a multi-party session based messaging focus are not deem to expose any security threat. Nevertheless, if a participant wants to avoid eavesdropping from non authorized entities, it should send those messages a TLS (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] transport connection, as allowed by MSRP.
Nicknames will be used to show the appearances of the participants of the conference. A successful take over of a nickname from a participant might lead to private messages to be sent to the wrong destination. The recipient's URI will be different from the URI associated to the original owner of the nickname, but the sender might not notice this. To avoid take overs the MSRP switch MUST make sure that a nickname is unique inside a chat room. Also the security consideration for any authenticated identity mechanisms used to validate the SIP AOR will apply to this document as well. If a nickname can be reserved if it previously has been used by another participant in the chat room, is up to the policy of the chat room.
| TOC |
This work would have never been possible without the fruitful discussions in the SIMPLE WG mailing list, specially with Brian Rosen (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and improvements throughout the document.
| TOC |
The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, Matt Lepinski, Mary Barnes and Ben Campbell for providing comments.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [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 (TXT). |
| [RFC3840] | Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” RFC 3840, August 2004 (TXT). |
| [RFC3860] | Peterson, J., “Common Profile for Instant Messaging (CPIM),” RFC 3860, August 2004 (TXT). |
| [RFC3862] | Klyne, G. and D. Atkins, “Common Presence and Instant Messaging (CPIM): Message Format,” RFC 3862, August 2004 (TXT). |
| [RFC4566] | Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT). |
| [RFC4575] | Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” RFC 4575, August 2006 (TXT). |
| [RFC4975] | Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT). |
| [RFC4976] | Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” RFC 4976, September 2007 (TXT). |
| [RFC5239] | Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” RFC 5239, June 2008 (TXT). |
| [RFC5246] | Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT). |
| [I-D.ietf-sip-gruu] | Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” draft-ietf-sip-gruu-15 (work in progress), October 2007 (TXT). |
| TOC |
| [RFC2810] | Kalt, C., “Internet Relay Chat: Architecture,” RFC 2810, April 2000 (TXT). |
| [RFC3264] | Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” RFC 3264, June 2002 (TXT). |
| [RFC3920] | Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 3920, October 2004 (TXT, HTML, XML). |
| [RFC3966] | Schulzrinne, H., “The tel URI for Telephone Numbers,” RFC 3966, December 2004 (TXT). |
| [RFC4353] | Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” RFC 4353, February 2006 (TXT). |
| TOC |
| 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 | |
| Ericsson | |
| Calle Via de los Poblados 13 | |
| Madrid, ES 28033 | |
| Spain | |
| Email: | miguel.a.garcia@ericsson.com |
| Geir A. Sandbakken (editor) | |
| TANDBERG | |
| Philip Pedersens vei 20 | |
| N-1366 Lysaker | |
| Norway | |
| Phone: | +47 67 125 125 |
| Email: | geir.sandbakken@tandberg.com |
| URI: | http://www.tandberg.com |