Instant Messaging and Presence Protocol TAKEDA Hiroyuki Internet Draft ATASHI Networks Category: Informational January, 2011 Document: draft-nmmp-00.txt Document Expires: 11/16 Nishioka Miyuki Messaging 1.0 Protocol Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as 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 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. 1. Abstract ATASHI Networks will release a commercial Instant Messaging product called ATASHI Messenger Service. This document describes the protocol used by that product for core instant messaging and presence functionality. This protocol is provided 'as is' without warranty of any kind. And this protocol is based on MSN Messenger Service 1.0 Protocol due to harmony with existing Instant Messengers. 2. Conventions used in this document 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. 3. Introduction ATASHI Messenger Service enables a user to learn about the presence of other people on Local Area Network like HotSpot, and to communicate with them in realtime. This functionality is commonly referred to as "Instant Messaging" (IM). This document describes the syntax and semantics of the Nisioka Miyuki Messaging Protocol, the communication protocol running between ATASHI Messenger Service 1.0 clients and servers. Basically, ATASHI Messenger Service has not servers, and a client sends a message to a client directly as Peer to Peer. Additional background: 1. Some features extraneous to core instant messaging functionality contained within the ATASHI Messenger Service 1.0 protocol are beyond the scope of this document. Examples include client version management and directory functionality. 2. This document reflects the protocol used in the 1.0 release of ATASHI Messenger clients and servers, deployed on the Internet in October of 2002. However, the service is in production and rapidly growing, which almost certainly will necessitate changes to the protocol as ATASHI Networks gains operational experience with the service and expands its feature set. This Internet Draft may not be updated with such changes, and the changes may be made with little or no notice. 4. ATASHI Messenger Server Component Overview Basically, ATASHI Messenger Client sends message by Peer to Peer between client directly. But there is a kind of server due to security requirement called Redirect Server. 4.1 Redirect Server (RD) The Redirect Server is the gateway between the Internet and Local area Network(LAN). Basically, ATASHI Messenger Service is running on broadcast messaging on LAN. But it's should not receive broadcast message from the Internet due to security. A broadcast message from the Internet to LAN running ATASHI Local Area Messenger Service is receive by Redirect Server once and Redirect Server broadcasts message to LAN. 5. Protocol Conventions 5.1 Connection Type The ATASHI Messenger Protocol currently works over UDP/IP and TCP/IP. The ATASHI Messenger applications support connections over port numbers 3649, which is the registered port number assigned by the IANA (http://www.iana.org/assignments/port-numbers). 5.2 Command Syntax ATASHI Messenger Protocol command syntax is ASCII and single line-based. Commands begin with a case-sensitive, four-letter command type, followed by zero or more parameters, and terminated by CRLF. Parameters are separated by one or more whitespace characters and cannot contain whitespace characters. Parameters that contain spaces or extended (non 7-bit ASCII) characters should be encoded using URL-style encoding (e.g. "%20" for space). Some commands accept un-encoded binary data. In these cases, the length of the data is transmitted as part of the command, and the data is transmitted immediately following a CRLF of the command. 5.3 Asynchronous Requests Commands issued from the client to the another client that result in a reply are known as requests. Requests are entirely asynchronous. The client can submit several requests in sequence without waiting for the another client response after submitting each request. The client is required to deliver a response or an error for each request received, but it is not required to deliver the responses in the same order as the requests were received. The client can determine the request associated with a particular response by examining the Transaction ID parameter (described below). 5.4 User Handles ATASHI Messenger Service has NOT User Handles for identifying users and does NOT identify users. User is identified by IP address of the local machine. And the IP address's format is strings like '192.168.0.1'. The maximum acceptable length of the user handle is 15 bytes. 5.5 Nicknames A nickname (also known as "friendly name") is a user's representation of the "friendly" textual name associated with a user handle. (E.g. "TAKEDA Miyu" instead of 192.168.0.4). Nicknames are neither unique nor persistent, and can contain any valid Unicode characters. Custom user names are represented in UTF-8 as described in RFC-2044 and URL-encoded as described in RFC-1738 when transmitted between the client and server. The maximum acceptable length of the encoded custom user name is 387 in the current implementation. 5.6 Transaction Identifiers The Transaction Identifier (a.k.a. Transaction ID) is a numeric string representing a number between 0 and (2^32 - 1). It is a value that a client includes with any command that it issues to the client. In the current version of the protocol, the transaction identifier is used to associate message responses with client-issued commands. The client treats the transaction ID as an opaque number and does not assume any relationship between successive Transaction IDs or any particular starting Transaction ID. It is the client's responsibility to guarantee the uniqueness of the Transaction IDs for the purpose of disambiguating the commands and/or responses. (A future version of the protocol could enable the client to track the status or cancel a particular transaction using the transaction ID.) When the client sends the response to a command to the another client, it must include in the response the transaction ID that the client sent to the another client when the client originally issued the command. In cases where a server sends a command to a client that requires a transaction ID but is not in response to a specific client command, it will use 0 as the transaction ID. In cases where a client sends multiple responses to a single client request, the client will use the same transaction ID in each response. 6. Command Summary Table Command Description ================================================================== REQP Request user profile data. ------------------------------------------------------------------ ERRC ERRor Code. ------------------------------------------------------------------ LIST LIST. Request user list on network. ------------------------------------------------------------------ MESG MESsaGe. Chat message. ------------------------------------------------------------------ NTFY NoTiFY. General notify message. ------------------------------------------------------------------ PING PING. Check connection of user. ------------------------------------------------------------------ PONG PONG. Reply to PING. ------------------------------------------------------------------ REPP Reply of ASKP. ------------------------------------------------------------------ RSLT ReSuLT. Result for SRCH. ------------------------------------------------------------------ SRCH SeaRCH. Search online members by keyword. ------------------------------------------------------------------ STAT STATus. Notify own status. ------------------------------------------------------------------ VERN VERsioN. Negotiates common protocol Dispatch Client dialect between clients. ================================================================== 7. Presence and State Protocol Details This is a detailed list of protocol commands associated with presence functionality. They are defined in the order used by clients. Commands associated with instant messages are discussed in section 8 below. 7.1 Protocol Versioning After the client connects to a network by opening a TCP socket to port 3649, the client and server agree on a particular protocol version before they proceed. The protocol version handshake involves the following command exchange: VERN TrID dialect-name{ dialect-name...} The client can provide multiple dialect names in preferred order. The dialect-name parameter returned by another client is the version client is designating for this connection. The current protocol dialect-name supported by Messenger servers is "NMMP1". The dialect names are not case-sensitive. The string "0" is a reserved dialect name and is used to indicate a failure response. E.g.: VERN TrID 0{ dialect-name ... } Note: But now this command is not active. 7.2 Client States States are denoted by a string of three characters. The predefined states that the another client recognizes are: NLN - Make the client Online and send and receive notifications about buddies. FLN - Make the client Offline. If the client is already online, offline notifications will be sent to users. No message activity is allowed. HDN - Make the client Hidden/Invisible. If the client is already online, offline notifications will be sent to users. The client will appear as Offline to others but can receive online/offline notifications from other users. All other States are treated as sub-states of NLN (online). The other States currently supported are: BSY - Busy. IDL - Idle. BRB - Be Right Back. AWY - Away From Computer. PHN - On The Phone. LUN - Out To Lunch. 7.3 Error Information Error messages from the server are of the format: ERRC {TrID} {(error-info) {param...}} ERRC is a 3 digit decimal number indicating the error code. Error- info contains the description of the error in a text string. The optional parameters provide indication of the client command causing the error. TrID is the Transaction ID of the client command that caused this error. Any client generated errors will not have Transaction IDs. ERR_SYNTAX_ERROR 200 ERR_INVALID_PARAMETER 201 ERR_INVALID_USER 205 ERR_FQDN_MISSING 206 ERR_ALREADY_LOGIN 207 ERR_INVALID_USERNAME 208 ERR_INVALID_FRIENDLY_NAME 209 ERR_LIST_FULL 210 ERR_ALREADY_THERE 215 ERR_NOT_ON_LIST 216 ERR_ALREADY_IN_THE_MODE 218 ERR_ALREADY_IN_OPPOSITE_LIST 219 ERR_SWITCHBOARD_FAILED 280 ERR_NOTIFY_XFR_FAILED 281 ERR_REQUIRED_FIELDS_MISSING 300 ERR_NOT_LOGGED_IN 302 ERR_INTERNAL_SERVER 500 ERR_DB_SERVER 501 ERR_FILE_OPERATION 510 ERR_MEMORY_ALLOC 520 ERR_SERVER_BUSY 600 ERR_SERVER_UNAVAILABLE 601 ERR_PEER_NS_DOWN 602 ERR_DB_CONNECT 603 ERR_SERVER_GOING_DOWN 604 ERR_CREATE_CONNECTION 707 ERR_BLOCKING_WRITE 711 ERR_SESSION_OVERLOAD 712 ERR_USER_TOO_ACTIVE 713 ERR_TOO_MANY_SESSIONS 714 ERR_NOT_EXPECTED 715 ERR_BAD_FRIEND_FILE 717 ERR_AUTHENTICATION_FAILED 911 ERR_NOT_ALLOWED_WHEN_OFFLINE 913 ERR_NOT_ACCEPTING_NEW_USERS 920 8. Instant Messaging Protocol Details ATASHI Messenger Service utilizes a lightweight, sessionless messaging scheme. A client don't need to establish a common session to exchange instant messages. NMMP is P2P protocol exchanging without center server. Basically used UDP/IP and a instant messages is sent to broadcast address or IP address of client by UDP/IP. A client receives all instant message. And to filter message is client side business. 8.1 Instant Messages Sending an Instant Message The message is received in the following format: MESG TrID Source Destination NickName Length\r\nMessage Length is the length of Message in bytes. Length is the length of the Message parameter in bytes, whereas Message is the actual message as described below. 8.2 Receiving an Instant Message A client can receive an instant message from another client directly. The message is received in the following format: MESG TrID Source Destination Nickname length\r\nMessage The Nickname is that of the sending user. Length is the length of the message in bytes. Message is a MIME encoded stream, using a standard MIME header as defined by RFC-1521 and RFC-822. Message is constructed as: MIME-Header\r\nMIME-Header\r\n\r\nMessageData MIME-Header is constructed as: string": "string (E.g. "Content-Type: text/plain") The Content-Type MIME headers that the current client will use and recognize are: "text/plain;charset=UTF-8" "text/plain" If "charset=UTF-8" appears at the end of the Content-Type, the Message Data is UTF-8 encoded. UTF-8 encording is recommended but client can also use any encording like ASCII Shift_JIS ISO-2022-JP EUC-JP UTF-8 8.3 Getting Online Users A client can get member who is online. Request of online users is following format: LIST TrID Source Destination SubStatus1 SubStatus2 ...\r\n Generally, client get online (client status is NLN) user following format: LIST TrID Source Destination NLN\r\n 8.4 Replying for LIST command If a client status in Online (NLN), the client must reply answer following format: STAT TrID Source Destination Nickname NLN\r\n and this command is used sending own status to another client compulsorily. 8.5 Searching Member A client search users who has some keyword to send message following format: SRCH TrID Source Destination Query1{ Query2 ...}\r\n Query is keyword wanted to search. Generally the client will this message to broadcast address. 8.6 Replying for SRCH If a client status has keyword including SRCH message, the client must reply answer following format: RSLT TrID Source Destination Nickname\r\n 8.7 Requesting Profile A client request user profile following format: REQP TrID Source Destination\r\n This message must not be sent to broadcast address. 8.8 Replying for REQP A client replying for REQP message following format if the action is permitted by user. REPP TrID Source Destination Length\r\nMessage e.g. REPP 0 192.168.0.4 192.168.0.5 184 ALAM# 0 Nickname leiqunni Birthday 11/10/1973 Language Japanese English Chinese Country Japan State Tokyo Message Hi there) Hobby Programming :) Jobs Programmer Favorite Animation Thailand Evangelion Star%20Trek Japanese English Chinese 8.9 Notify This NTFY, notify command is used sending common notify. NTFY 0 Source Destination Length\r\nMessage The TrID will be unavailable, so TrID should be put '0'. 8.10 Ping PING command is checked to make sure existing client online. PING TrID Source Destination\r\n This message must not be sent to broadcast address. 8.11 PONG Replying for Ping. PONG TrID Source Destination\r\n This reply is not guarantee to answer PING. 9. Author's Addresses Author's Address TAKEDA Hiroyuki ATASHI Netoworks, Inc. Email to http://atashi.net/mail/