-
Notifications
You must be signed in to change notification settings - Fork 0
/
rfc.txt
730 lines (480 loc) · 25.2 KB
/
rfc.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
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]