blob: 1ae74619c212eafbe7a8414a2abad55e358fe469 (
plain) (
blame)
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
|
TBD A. Yu
YK Pao School
10 July 2022
Internet Delay Chat Protocol
internet-delay-chat
Abstract
The Internet Delay Chat protocol is a simple multiuser federated chat
protocol.
Status of This Memo
Internet Delay Chat is still a draft. It is subject to change
rapidly during development of the reference implementation.
Distribution of this memo is unlimited.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. The IDC Protocol . . . . . . . . . . . . . . . . . . . . . . 1
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Security Considerations . . . . . . . . . . . . . . . . . . . 2
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 2
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction
The IDC (Internet Delay Chat) protocol is a simple binary protocol
that allows for federated teleconferencing.
(List concepts in subsections.)
2. The IDC Protocol
2.1. Overview
The protocol as described herein is for use with both server to
server and client to server connections. There are, however,
restrictions on both types of connections that the other may not
have, as these connections have inherently different subjects.
Yu Informational [Page 1]
Internet Delay Chat Protocol July 2022
2.2. Messages
Servers and clients send each other messages which usually generate a
reply. If the message contains a valid command, as described in
later sections, the client SHOULD expect a reply as specified.
Each IDC message consists of two main parts: the command, and the
command parameters.
The protocol messages are extracted from a contiguous stream of
octets. When a command sequence is followed by the correct number of
arguments for the command, the message ends, and the very next byte
is treated as the next command.
<message> ::= <command> [ <params> ]
<command> ::= <octet> { <octet> }
<params> ::= <paramlenspec> <data> [ <params> ]
<data> ::= <Any sequence of octets>
<paramlenspec> ::= <A base-128 unsigned integer, where the first
bit of each octet indicates that the next octet
is still a legnth specifier (1) or is data (0),
and the last seven bits indicate one digit
in base-128.>
Note that the NUL (00) octet is not treated specially and is valid
data in IDC.
3. Conclusion
Bruh
4. Security Considerations
Bruh
Acknowledgements
Haxy hax
Author's Address
Andrew Yu
YK Pao School
Email: andrew@andrewyu.org
URI: https://www.andrewyu.org/
Yu Informational [Page 2]
|
