blob: 3f89f37e0934c244041a2e2051fd5dffdd2eece2 (
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
|
%%%
title = "Internet Delay Chat Protocol"
abbrev = "Internet Delay Chat Protocol"
area = "TBD"
workgroup = "TBD"
submissiontype = "independent"
ipr = "none"
keyword = ["chat", "protocol"]
#updates = [ <++> ]
#date = 2003-04-01T00:00:00Z
[seriesInfo]
name = "Internet-Draft"
value = "internet-delay-chat"
stream = "independent"
status = "informational"
[[author]]
initials = "A."
surname = "Yu"
fullname = "Andrew Yu"
#role = "author"
organization = "YK Pao School"
[author.address]
email = "andrew@andrewyu.org"
uri = "https://www.andrewyu.org/"
%%%
.# 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.
{mainmatter}
# Introduction
The IDC (Internet Delay Chat) protocol is a simple binary protocol that allows for federated teleconferencing.
(List concepts in subsections.)
# The IDC Protocol
## 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.
## 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.
# Conclusion
Bruh
# Security Considerations
Bruh
{backmatter}
{numbered="false"}
# Acknowledgements
Haxy hax
<!--
<reference anchor='<++>' target='<++>'>
<front>
<title><++></title>
<author initials='<++>' surname='<++>' fullname='<++>'>
<organization><++></organization>
<address>
<email><++>@<++></email>
<uri>https://<++></uri>
</address>
</author>
<date year='<++>' month="<++>" />
</front>
</reference>
-->
|
