rfc.txt

Independent Submission                                               Cao
Internet-Draft                              George Washington University
Intended status: Standards Track                        October 16, 2018
Expires: April 19, 2019


                     Multi-chat Messaging Protocol

Abstract

   Multi-chat Messaging Protocol is an application layer protocol that
   works on top of TCP/IP.  The protocol is designed to work on client/
   server software architecture, but not on peer-to-peer network.  The
   protocol is a text-based, push protocol, aiming to set standards for
   the messaging communication among the parties involved in a multi-
   person chat room.  This document describes the operations of chat
   room parties and the format of message in detail.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 19, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Cao                      Expires April 19, 2019                 [Page 1]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.1.  Client  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.2.  Server  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.3.  Client Message  . . . . . . . . . . . . . . . . . . .   4
       1.3.4.  Server Message  . . . . . . . . . . . . . . . . . . .   4
       1.3.5.  Message Header  . . . . . . . . . . . . . . . . . . .   4
       1.3.6.  Message Body  . . . . . . . . . . . . . . . . . . . .   4
       1.3.7.  Server Status . . . . . . . . . . . . . . . . . . . .   5
   2.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Client Message  . . . . . . . . . . . . . . . . . . . . .   5
       2.1.1.  Message Header  . . . . . . . . . . . . . . . . . . .   5
         2.1.1.1.  Header Fields . . . . . . . . . . . . . . . . . .   5
         2.1.1.2.  Explanation . . . . . . . . . . . . . . . . . . .   6
       2.1.2.  Message Body  . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Server Message  . . . . . . . . . . . . . . . . . . . . .   6
       2.2.1.  Message Header  . . . . . . . . . . . . . . . . . . .   7
         2.2.1.1.  Relay Message . . . . . . . . . . . . . . . . . .   7
         2.2.1.2.  Response Message  . . . . . . . . . . . . . . . .   7
         2.2.1.3.  Explanation . . . . . . . . . . . . . . . . . . .   8
       2.2.2.  Message Body  . . . . . . . . . . . . . . . . . . . .   8
         2.2.2.1.  Relay Message . . . . . . . . . . . . . . . . . .   8
         2.2.2.2.  Response Message  . . . . . . . . . . . . . . . .   8
     2.3.  Operations  . . . . . . . . . . . . . . . . . . . . . . .   8
       2.3.1.  Start Session . . . . . . . . . . . . . . . . . . . .   8
         2.3.1.1.  Prerequisite  . . . . . . . . . . . . . . . . . .   8
         2.3.1.2.  Join Session  . . . . . . . . . . . . . . . . . .   8
         2.3.1.3.  Set Nickname  . . . . . . . . . . . . . . . . . .   9
       2.3.2.  Text Message Delivery . . . . . . . . . . . . . . . .   9
         2.3.2.1.  Private Message . . . . . . . . . . . . . . . . .   9
         2.3.2.2.  Public Message  . . . . . . . . . . . . . . . . .   9
       2.3.3.  File Sharing  . . . . . . . . . . . . . . . . . . . .   9
         2.3.3.1.  Share . . . . . . . . . . . . . . . . . . . . . .   9
         2.3.3.2.  Fetch . . . . . . . . . . . . . . . . . . . . . .  10
       2.3.4.  End Session . . . . . . . . . . . . . . . . . . . . .  10
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  chat  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.1.1.  Client Message  . . . . . . . . . . . . . . . . . . .  10
       3.1.2.  Relay Message . . . . . . . . . . . . . . . . . . . .  10
       3.1.3.  Response Message  . . . . . . . . . . . . . . . . . .  11
     3.2.  File Sharing  . . . . . . . . . . . . . . . . . . . . . .  11



Cao                      Expires April 19, 2019                 [Page 2]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


       3.2.1.  Chat Message  . . . . . . . . . . . . . . . . . . . .  11
       3.2.2.  Relay Message . . . . . . . . . . . . . . . . . . . .  11
       3.2.3.  Response Message to Chat  . . . . . . . . . . . . . .  11
       3.2.4.  Fetch Message . . . . . . . . . . . . . . . . . . . .  12
       3.2.5.  Response Message to Fetch . . . . . . . . . . . . . .  12
     3.3.  Set Nickname  . . . . . . . . . . . . . . . . . . . . . .  12
       3.3.1.  Nickname Message  . . . . . . . . . . . . . . . . . .  12
       3.3.2.  Response Message  . . . . . . . . . . . . . . . . . .  12
     3.4.  End Session . . . . . . . . . . . . . . . . . . . . . . .  13
       3.4.1.  Bye Message . . . . . . . . . . . . . . . . . . . . .  13
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

1.1.  Goals

   The Multi-chat Messaging Protocol is built on top of TCP, which
   ensures reliable transmission and also guarantees in-order message
   delivery.

   A multi-person chat room accommodates more than 2 participants to
   engage in one public conversation, meanwhile, private conversations
   that involves only 2 participants are also supported.  File sharing
   is also included as a part of this protocol.

1.2.  Requirements

   R1  The major purpose of using the multi-person chat room is to
       exchange brief text messages in close to real time.

   R2  Small-sized file sharing is also supported, in contrast to text
       message, file sharing does not happen in real time, as the shared
       files will be staged by server, and optionally fetched by clients
       themselves.

   R3  Large-sized file sharing is strongly not recommended, as file
       sharing uses the same network channel as text message, the
       potential network congestion will delay text message exchange,
       leading to failure in fulfilling R1.

   R4  Server should protect client privacy, information such as client
       IP address and port number should not be shared by server to
       another client.

   R5  Server should be capable to provide a list of unique identifiers
       of available clients, which can be used in private conversations.




Cao                      Expires April 19, 2019                 [Page 3]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


1.3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.3.1.  Client

   Clients are distributed message producers and consumers.  Clients
   only communicate with server, however, peer-to-peer communication
   among clients should not happen.

1.3.2.  Server

   Server is centralized message exchange mediator, which manages client
   connections, relays messages from client, and stages shared files for
   future downloads.

1.3.3.  Client Message

   Client message is message sent by client, it may also be perceived as
   a request for a certain service.  The payload of client message could
   be either ASCII texts or binary objects.

1.3.4.  Server Message

   Server message is message sent by server.  There are 2 types of
   server messages, one is the message relayed by server with payload
   content provided by client; the other is the message carrying server
   status in response to a client message.

1.3.5.  Message Header

   Message header is the first section of message.  A message header is
   composed in lines of ASCII texts, with a linefeed character marking
   the end of each line.

1.3.6.  Message Body

   Message body is the second section of message, also known as payload.
   A message body is composed of either ASCII texts or binary objects,
   both the type and length of message body are indicated in message
   header, and the message body itself is separated from message header.








Cao                      Expires April 19, 2019                 [Page 4]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


1.3.7.  Server Status

   In response to each client message, server status is included in the
   server message indicating the corresponding client message is
   successfully handled, or it cannot be handled for some reason.

2.  Protocol

2.1.  Client Message

   The format of client message usually includes 2 sections: a header
   and a body.  The 2 sections are separated by an additional linefeed
   character following the message header.  However, in some cases,
   message body is not necessary, it is applicable to build a message
   without body.

2.1.1.  Message Header

   Client message header is a text-based section containing several
   lines of ASCII text, with a linefeed character marking the end of
   each line.

   Each line of the message header shall be regarded as a field, whose
   name and value are separated by a whitespace character.

2.1.1.1.  Header Fields

   Below are all possible header fields, the mandatory fields are
   required in any type of message, whereas the optional fields are
   required in certain types of message.

        +----------------+----------------------------+-----------+
        |   Field Name   |    Field Value Options     |  Required |
        +----------------+----------------------------+-----------+
        |  Message-Type  |            chat            | mandatory |
        |                |           query            |           |
        |                |           fetch            |           |
        |                |          nickname          |           |
        |                |            bye             |           |
        |   Message-ID   | {auto incremental integer} | mandatory |
        |       To       |           {UID}            |  optional |
        |  Content-Type  |            text            |  optional |
        |                |    {filename extension}    |           |
        | Content-Length |     {number of bytes}      |  optional |
        +----------------+----------------------------+-----------+

                       Client Message Header Fields




Cao                      Expires April 19, 2019                 [Page 5]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


2.1.1.2.  Explanation

   "Message-Type" is a mandatory field that indicates the client message
   is a chat message, a query message, a fetch message, a nickname
   message or a bye message.  Chat messages will be relayed whereas the
   others will not.  Query message requests for the UID list of current
   active clients.  Fetch message requests for the transmission of file
   staged on server.  Nickname message requests for setting nickname for
   client.  Bye message notifies server that client is about to end the
   session and close the socket connection.

   "Message-ID" is also a mandatory field, whose value is represented by
   an auto incremental integer that is generated by client.  In another
   way, "Message-ID" is used by client as a serial number that
   identifies messages sent by its own.

   "To" is an optional field, which is only used when sending a private
   message to a specific client.

   "Content-Type" is an optional field that indicates the type of chat
   message body (payload), when sending text message, the field value
   should be "text", while when sending binary content, for example, a
   jpeg image, the field value should be "jpg".

   "Content-Length" is an optional field that indicates the byte length
   of message body, it is also a measure to mark the end of message
   body.

2.1.2.  Message Body

   The message body carries either message or file to server.  It is
   either composed of ASCII text or binary object, the type of message
   body should always match header field "Content-Type".  The end of
   message body is marked by header field "Content-Length".

2.2.  Server Message

   Server message uses the same structure as client message.  There are
   2 types of server message, namely Relay message and Response message.

   Relay message inherits some header fields from chat message sent by
   client, with an additional header field "From" indicating the
   sender's UID.  If the sender has provided a nickname, the nickname
   should be included in header field "Sender-Nickname".  The body of
   relay message inherits the text payload from chat message, but drops
   the binary payload.





Cao                      Expires April 19, 2019                 [Page 6]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


   Response message is the server feedback to all types of client
   messages.  The header includes 5 mandatory fields, namely "Status",
   "Message-Type", "Message-ID", "Content-Type" and "Content-Length".
   Response message always uses a message body, which may be composed of
   lines of ASCII texts or binary objects.

2.2.1.  Message Header

2.2.1.1.  Relay Message

   Below are all possible header fields of relay message,

   +-----------------+-------------------------+-----------+-----------+
   |    Field Name   |   Field Value Options   |  Required | Inherited |
   +-----------------+-------------------------+-----------+-----------+
   |   Message-Type  |           chat          | mandatory |    yes    |
   |        To       |          {UID}          |  optional |    yes    |
   |       From      |          {UID}          | mandatory |     no    |
   | Sender-Nickname |         {string}        |  optional |     no    |
   |     File-ID     |    {auto incremental    |  optional |     no    |
   |                 |         integer}        |           |           |
   |   Content-Type  |           text          | mandatory |    yes    |
   |                 |   {filename extension}  |           |           |
   |  Content-Length |    {number of bytes}    | mandatory |    yes    |
   +-----------------+-------------------------+-----------+-----------+

                        Relay Message Header Fields

2.2.1.2.  Response Message

   Below are all possible header fields of response message,

     +----------------+----------------------+-----------+-----------+
     |   Field Name   | Field Value Options  |  Required | Inherited |
     +----------------+----------------------+-----------+-----------+
     |     Status     |          Ok          | mandatory |     no    |
     |                |        Error         |           |           |
     |  Message-Type  |         chat         | mandatory |    yes    |
     |                |        query         |           |           |
     |                |        fetch         |           |           |
     |                |       nickname       |           |           |
     |   Message-ID   |      {integer}       | mandatory |    yes    |
     |  Content-Type  |         text         | mandatory |     no    |
     |                | {filename extension} |           |           |
     | Content-Length |  {number of bytes}   | mandatory |     no    |
     +----------------+----------------------+-----------+-----------+

                      Response Message Header Fields



Cao                      Expires April 19, 2019                 [Page 7]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


2.2.1.3.  Explanation

   "Status" is a mandatory field that indicates if server has fulfilled
   the request by client.

   For a chat message, "Status Ok" indicates the message has been
   successfully relayed, "Status Error" indicates the message cannot be
   relayed, and the reason of delivery failure should be included in
   message body as ASCII text.

   For a query, fetch or nickname message, "Status Ok" indicates that
   the request has been successfully fulfilled, the resource being
   requested should be found in message body.  "Status Error" should be
   perceived the same way as in chat message.

   Field "Message-ID" inherits its value from the client message, server
   writes this field back to allow the client track the status of
   messages it has sent.

2.2.2.  Message Body

2.2.2.1.  Relay Message

   The body of relay message is inherited from client message payload,
   which could be composed of ASCII text or binary objects.

2.2.2.2.  Response Message

   The body of response message is built in either ASCII text or binary
   object.  For chat and query message, the message body should be in
   ASCII text.  For fetch message, the response message body may be in
   ASCII text that indicates reason of failure, or may be in binary as a
   file payload.

2.3.  Operations

2.3.1.  Start Session

2.3.1.1.  Prerequisite

   Before session could start, a server instance must be started and
   listening on port 8080.

2.3.1.2.  Join Session

   Any client may join the session by establishing a TCP socket
   connection to server.  Once connected to server, client shall be




Cao                      Expires April 19, 2019                 [Page 8]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


   assigned a unique ID.  Then client starts the session by sending a
   "query" message to server for the UID list.

2.3.1.3.  Set Nickname

   By default, no nickname is set for client, however, client may update
   nickname anytime during the session by sending a "nickname" message.
   Nicknames are maintained by server, and duplicates are allowed.

2.3.2.  Text Message Delivery

2.3.2.1.  Private Message

   If "To" field is presented in client message header, the message
   should be processed by server as a private message thus exclusively
   relayed to the client designated by UID.  Before the message is
   relayed, a "From" field with sender UID shall be appended to the
   message header.

   If the target client is not available due to connection closed or
   reset, a response message carrying a "Status Error" with payload of
   failure reason shall be sent back to client.

   If the target client is available and message is delivered, a
   response message with "Status Ok" shall be sent back.

2.3.2.2.  Public Message

   If "To" field is not presented in client message header, the message
   should be processed by server as a public message and relayed to any
   other active clients.  Before the message is relayed, a "From" field
   with sender UID shall be appended to the message header.

   When done, a response message with "Status Ok" shall be sent back to
   the message sender.

   If there is no other active clients connected to chat room, the
   client message shall be discarded, and also a response message with
   "Status Ok" should be generated since no error has occurred.

2.3.3.  File Sharing

2.3.3.1.  Share

   Sharing a file is similar to sending a text message, however, server
   shall not relay the binary payload of client message, instead, server
   should stage the payload, assign a file ID to the payload, append the
   file ID to the header, and relay only the header like a text message.



Cao                      Expires April 19, 2019                 [Page 9]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


2.3.3.2.  Fetch

   To fetch a shared file, client must send a "fetch" message with
   payload of file ID that was previously acquired.  Then server sends a
   response message with the binary payload or an error.

2.3.4.  End Session

   To quit session, client must send a "bye" message before closing the
   socket, when server receives a "bye" message, it closes the
   corresponding socket thereafter without response.

   If client ends the session without issuing a "bye" message, server
   shall detect the closed connection when attempting to relay message.
   In this case, server shall close connection and include the cause of
   delivery failure in the response message sent back to the original
   message sender.

3.  Examples

3.1.  chat

3.1.1.  Client Message

   Take public chat message for example, the format goes as below,

   Message-Type chat \r\n
   Message-ID 22 \r\n
   Content-Type text \r\n
   Content-Length 12 \r\n
   \r\n
   How are you?

3.1.2.  Relay Message

   The server will relay the message above in a format as below,

   Message-Type chat \r\n
   From 9527 \r\n
   Sender-Nickname Tom \r\n
   Content-Type text \r\n
   Content-Length 12 \r\n
   \r\n
   How are you?







Cao                      Expires April 19, 2019                [Page 10]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


3.1.3.  Response Message

   After the server has successfully relayed the message, a response
   message with format as below will be sent back to the chat message
   sender "Tom",

   Status Ok \r\n
   Message-Type chat \r\n
   Message-ID 22 \r\n
   Content-Type text \r\n
   Content-Length 12 \r\n
   \r\n
   <no message body>

3.2.  File Sharing

3.2.1.  Chat Message

   Client should generate a message as below when sharing a file (e.g. a
   jpeg image),

   Message-Type chat \r\n
   Message-ID 25 \r\n
   Content-Type jpg \r\n
   Content-Length 3000 \r\n
   \r\n
   <binary content>

3.2.2.  Relay Message

   Server receives the message, stages the file, and generates a relay
   message as below,

   Message-Type chat \r\n
   From 9527 \r\n
   Sender-Nickname Tom \r\n
   File-ID 10 \r\n
   Content-Type jpg \r\n
   Content-Length 3000 \r\n
   \r\n
   <no message body>

3.2.3.  Response Message to Chat

   After the message has been relayed, server generates a response
   message to "Tom" in the same format as shown in the Chat section.





Cao                      Expires April 19, 2019                [Page 11]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


3.2.4.  Fetch Message

   Then other clients may optionally fetch the file staged on server by
   sending a "fetch" message as below,

   Message-Type fetch \r\n
   Message-ID 80 \r\n
   Content-Type text \r\n
   Content-Length 2 \r\n
   \r\n
   10

3.2.5.  Response Message to Fetch

   Server then generates a response with the file as payload,

   Status Ok \r\n
   Message-Type fetch \r\n
   Message-ID 80 \r\n
   Content-Type jpg \r\n
   Content-Length 3000 \r\n
   \r\n
   <binary content>

3.3.  Set Nickname

3.3.1.  Nickname Message

   Clients may set their nicknames by sending a "nickname" message,

   Message-Type nickname \r\n
   Message-ID 1 \r\n
   Content-Type text \r\n
   Content-Length 3 \r\n
   \r\n
   Tom

3.3.2.  Response Message

   Server then generates a response message as below,

   Status Ok \r\n
   Message-Type nickname \r\n
   Message-ID 1 \r\n
   Content-Type text \r\n
   Content-Length 3 \r\n
   \r\n
   Tom



Cao                      Expires April 19, 2019                [Page 12]

Internet-Draft        Multi-chat Messaging Protocol         October 2018


3.4.  End Session

3.4.1.  Bye Message

   To quit session, client must send a "bye" message to server, then
   close the socket connection.  There will not be any response from
   server for a "bye" message.

   Message-Type bye \r\n
   Message-ID 1000 \r\n
   \r\n
   <no message body>

4.  References

   [1]       Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [2]       Andre, P., "Extensible Messaging and Presence Protocol
              (XMPP): Core", 2011, RFC 6120,
              <https://www.rfc-editor.org/info/rfc6120>.

   [3]       Fielding, R., "Hypertext Transfer Protocol -- HTTP/1.1"
              , 1999, RFC 2616,
              <https://www.rfc-editor.org/info/rfc2616>.

Author's Address

   Warren (Wuchen) Cao
   George Washington University
   800 22nd Street, NW
   Washington, DC  20052
   United States

   Email: caowuchen@gwu.edu
















Cao                      Expires April 19, 2019                [Page 13]