Internet-Draft K.J.Hay QUALCOMM, Incorporated Expires on 1 October 1997 26 March 1997 Multicast Chat (MCC) Protocol Status of this Memo This document is an Internet-Draft. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document is an rough draft for a proposed new Internet conferencing protocol called multicast chat (MCC) which uses IP multicast for the internet layer. IP Multicast IP multicast (also known as Internet multicast) is an Internet delivery mechanism such that a single host can broadcast to a group of hosts who are interested in listening. This differs from the standard point-to-point messaging (unicasting), that allows a connection between two hosts and from broadcasting, which to everyone, even those hosts who could care less. A multicast group is a group of hosts who are all listening to the same broadcast. Each multicast group has a class D IP address which is used when broadcasting to the group. To send to a group a host sends his message to the group's IP address. To listen to a group a host informs the network that it wishes to receive packets for the group's IP address. A host can join and leave any number of multicast groups at will. Multicast Chat Hay [Page 1] Internet Draft Multicast Chat (MCC) Protocol 26 March 1997 Multicast chat (MCC) is a proposed application protocol to allow real-time conferencing using IP multicast. Conceptual Actual |-------------| |--------------| | Application | | MCC | |-------------| |--------------| | Transport | | TBD | |-------------| |--------------| | Internet | | IP Multicast | |-------------| |--------------| An MCC client is any application that uses the MCC protocol to do real-time conferencing. A client can set up a chat room, which is then used to conference among a group of people. Each MCC room is assigned a multicast IP address. The MCC protocol has a reserved multicast address which it refers to as the CC. The CC, which stands for control channel, is used to pass room and client between clients. Once a room is created the client can inform other clients of its existence on the CC, allowing them to then join the room. The collection of all MCC clients is referred to as the MCC Network Connecting a Client to the Network All that a client needs to do to join the MCC network is to connect to the CC IP address and send a CLIENT JOIN message. The CLIENT message gives the other clients information about you along with informing them that you have connected to the MCC network. There is a corresponding CLIENT QUIT message to inform others that you have disconnected. Rooms and Folders When a room is created a multicast IP address is associated with it (How a available multicast IP address is acquired has not yet been figured out). The creator of the room also specifies the following information for the room: Room Path - This is the rooms name and folder path (see below). Topic - This is a optional string describing what the topic of the room is. One of the things specified in the creation of a room is the rooms path. MCC organizes rooms into a nested hierarchy of folders. The rooms path indicates what folder the channel can be found in. The folder path is considered part of the room path and appears as follows. Hay [Page 2] Internet Draft Multicast Chat (MCC) Protocol 26 March 1997 = /{/}/ The same name can be used for different channels if the folder paths are different. For example the room "Computers/Internet/C++" is considered a different room then "Computers/Software/C++". The top folder level is known as the lobby. The lobby contains only folders, no rooms, which is done to prevent the cluttering up of the lobby. This makes the room "/C++" an illegal room, since it can not be at the top level. Creating a Room To create a room, the user specifies a room name (including the folder path) and optionally a topic name for the room. If the channel in the specified folder already exists, then the create will fail. If the creation is successful then an IP address for the new channel is assigned (once again, how this is done needs to be determined) and the client notifies the other clients by sending a ROOM OPEN message on the CC. Joining a Room To join a room, a client must first get the room's IP address. One of the ways this can be done is by sending out a ROOMREQUEST command on the CC. If the room exist then the Room Keeper (see below) responds with a ROOM INFO command that includes the room's IP address. Once a client has the IP address it can connect to the address and listen into the room. Room Upkeep When a client sends a CHANNELREQUEST message a response should come from the room. The room itself is incapable of sending the response. That means someone in the room must send it for the room. That someone is known as the room keeper. The room keeper is the client who has been on the channel the longest. MCC Commands There are two types of commands in MCC. They are CC commands and room commands. CC commands are sent on the CC address while room commands are sent on the room address. The format for both are the same though. CR/LF The host is the machine that sent the command. Following the host is the command and its parameters. A CR/LF indicates the end of a Hay [Page 3] Internet Draft Multicast Chat (MCC) Protocol 26 March 1997 command line. Both CC and room commands are described in detail in the following sections. CC Command Reference CLIENT < action > { } The CLIENT command is used to send the user's client information to other clients. The parameter indicates the action being performed and can have the value JOIN, CHANGE, QUIT or INFO. JOIN informs the other clients that the user has just joined the MCC network. CHANGE informs of a change in the users client information. QUIT informs the other clients when quitting the MCC network. The QUIT action ignores all of the other parameters, and they therefore need not be sent. INFO is in response to a CLIENTREQUEST command asking for your client information. All actions, except QUIT, also supply a name the client will be known as while connected to the MCC network. A client also has the option of sending other information about itself. It does this by sending a tag describing what the data being sent is followed by the data itself. A client can send as much information about himself as he chooses. Data tage would be such things as real name, address, e- mail, home page, etc... CLIENTREQUEST < client name > The CLIENTREQUEST command is used to request client information about another client. The client being asked for information will respond, if it chooses to, with a CLIENT INFO command. CTC The CTC command stands for client-to-client, and allows client application to send specialized commands for their applications. If a client does not recognize a CTC command then it should ignore it completely. PING [ ] The PING command is used to tell other clients that you are still on the MCC network. A client should ping nor more then once a minute. If a room name is specified as a parameter then this means the ping is from a room, which the keeper is responsible for, and is used to tell others that the room still exists. ROOM < action > [ ] Hay [Page 4] Internet Draft Multicast Chat (MCC) Protocol 26 March 1997 The ROOM command is used to send the room information to other clients. The parameter indicates the action being performed and can have the value OPEN, CLOSE or INFO. OPEN informs the other clients that a client has created a new room. CLOSE informs the other clients when a room has closed down. The CLOSE action only supplies a and no ther parameters. INFO is in response to a ROOMREQUEST command asking for room information. ROOMREQUEST The ROOMREQUEST command is used to request room information. If is a complete room path, then only the keeper of that channel should respond with a ROOM INFO command. If if a folder path, then all channels in that folder, or any sub folder, should respond with a ROOM INFO command. Room Command Reference ACTION The ACTION command is used to describe an action being performed. If Bob sent an ACTION message with the message "is thinking about it", Then everyone else should see "Bob is thinking about it". AWAY [ ] The AWAY command is used to indicate when you are away from your computer, but stay connected to the room. If a message is specified (the message should tell why you are away) then the message is also sent to all other people in the room. If an AWAY message is sent without a message, then that person is no longer away. CTC This is similar to the CC version of the command except only people in the room receive the command. JOIN A person uses this command to announce their arrival into a room. LEAVE A person uses this command to announce when they are leaving a room. PING The PING command should be sent every so often by everyone in the Hay [Page 5] Internet Draft Multicast Chat (MCC) Protocol 26 March 1997 room to indicate they are still there. POST This is used to post your standard message to the room. TBDs This document gives an overview of the proposed MCC protocol. But there are still some things that need to be worked out. One of the things mentioned earlier was how exactly does a room obtain a multicast IP address and then notify the MBONE. (The MBONE is a term currently used to describe those networks that support multicast IP routing. In the next version of IP, multicast will be fully supported.) There is a program called SDR that keeps a sessions directory which may meet this need. Another question is what to use as a transport protocol. UDP seems obvious but it does not support guaranteed delivery. TCP guarantees delivery but does not seem implementable on a broadcast protocol like multicast IP. This entire subject needs to be worked out. Another problem is private rooms. The concept of private rooms has not been addressed in this document but it would probably be a desirable feature. The answer is probably to encrypt the session and not tell anyone about the channels. The concept of folders is very useful. It allows the breaking down of rooms into categories and allows people to find rooms they are interested in easier. The headache is how to implement folders. The protocol currently has a flaw in respect to folders. Given the following hierarchy (so its a little contrived): Technology ---+---Computers---+--- Software (room) | | | |--- Hardware (room) | |---VCRs---+---(60 different rooms) | | |---General (room) Say I want to know what is in the folder Technology. There are two folders and a room (Computers, VCRs and General). To get that information 63 rooms will respond (Software, Hardware, VCR's 60 rooms and General). Computers and VCRs can not respond because there is no one person in charge of the folder. This leads into the possible concept of having a folder keeper, similar to that of the room Hay [Page 6] Internet Draft Multicast Chat (MCC) Protocol 26 March 1997 keeper. Author's Address Kevin J. Hay QUALCOMM, Incorporated Eudora Division 6455 Lusk Blvd. San Diego, CA 92121-2779 Phone: (619) 658-2954 EMail: khay@qualcomm.com Draft expires on 1 October 1997 Hay [Page 7]