summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc40.txt
blob: 2fd024ad80fce23f486ec397b24531a3af9538bd (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
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
Network Working Group                                         E. Harslem
Request for Comments: 40                                      J. Heafner
                                                                    RAND
                                                              March 1970

               More Comments on the Forthcoming Protocol

We have recently discussed NWG/RFC Nos. 36 and 39 with Steve Crocker,
UCLA.  Steve has asked that we elaborate on the errors, queries, and
HOST status that were mentioned in NWG/RFC #39.

Please voice your opinions soon in order to affect the forthcoming
protocol specifications.

ERROR MESSAGES

     <ERR> <Code> <Command length> <Command in error>

<Code> is an eight-bit field that specifies the error type.  The
assigned codes are shown below.  <Command length> is a 16-bit integer
that indicates the length of the <Command in error> in bits.  The
<Command in error> is the spurious command.

The ranges of <Code> are shown below in hexidecimal.

     00     Unspecified error types
     10-0F  Resource errors
     10-1F  Status errors
     20-2F  Content errors
     30-3F  Unused

Specific values of <Code> are shown below with their meaning.

     <Code> value   Semantics

         00         Unspecified errors.
         01         Request for an invalid resource.
         02         Request for an exhausted resource, try later.
        03-0F       Unused.
         10         Invalid <RSM>, i.e., link connected but unblocked.
         11         Invalid <SPD>.
         12         Invalid <ASG>, i.e., connected but no <RDY>
                      received.








                                                                [Page 1]
^L
     <Code> value   Semantics

         13         Message received on blocked link.
        14-1F       Unused.
         20         Unknown command code.
         21         Message received on unconnected link.
         22         Invalid <RFC>.
         23         Invalid <CLS>.
         24         Invalid <RSM>, i.e., link not connected.
         25         Invalid <FND>.
         26         Invalid <END>.
         27         Invalid <RDY>.
         28         Invalid <ASG>, i.e., not connected.
        29-2F       Unused.
        30-FF       Unused.

QUERIES

     <QRY> <My Socket>
or   <RPY> <Your Socket> <Text>

The <QRY> is the query indicated in NWG/RFC #39 and <RPY> is the reply.
The format of <Text> is shown below; also refer to NWG/RFC #36, p. 3.

<Text>::= <16 bit count of relevant connection table entries>
          <relevant connection table entries>

<relevant connection table entries>::=
                                     <relevant connection table entries>
                                     <a relevant connection table entry>
                                     <a relevant connection table entry>

<a relevant connection table entry>::= <local socket> <foreign socket>
                                       <link> <connection state>
                                       <flow state and buffer control>
                                       <reconnection control state>















                                                                [Page 2]
^L
HOST STATUS

     <NOP>

An NCP may be up, down, pending, etc.  When an NCP changes its
state to UP it should send a <NOP> to each remote NCP which
indicates the NCP is available.  The sending NCP can then
construct a vector of HOST status from the RFNMs it receives.  An
NCP receiving a <NOP> can update the availability of the sending
NCP in its HOST status vector.



       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Richard Ames 6/97 ]




































                                                                [Page 3]
^L