![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to reply CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / contrib / nntp / doc|
Return to reply CVS log | Up to [CSRG BSD Unix] / 43BSD / contrib / nntp / doc |
1.1 root 1: Brian,
2:
3: Here are the differences I see between your and my server.
4: I've included proposed changes, some to yours, some to mine. If
5: we could get agreed on a standard by this weekend, which may be
6: ambitious, it would be really good.
7:
8: BTW, is the stuff I'm ">" including the current version?
9:
10: Phil
11:
12:
13: > The whole idea is to keep the server as small and (computationally)
14: > inexpensive as possible. Reading news on our system is not a super
15: > popular pastime, but a central machine could still get rather heavily
16: > loaded if 5 people per system were to decide that it was time to catch
17: > up on the latest happenings.
18:
19: Agreed. This is, I feel, an implementation detail, although it
20: should be reflected in the protcol -- i.e., the protocol should
21: not be bulky or hard to implement. I don't think we suffer from
22: this problem.
23:
24: > No doubt I'll refine it further as I try to interface more client stuff
25: > to it. Right now it seems to have enough to start making a version of
26: > 'readnews' work with it.
27:
28: This is a matter of philosophy: I feel it's very important to make the
29: server as easy to interface with existing programs as possible, but
30: still be general enough to provide for future service.
31:
32: General differences: Let's try to make this as SMTP-like as
33: possible. One thing I noticed is that you put "."'s in front of
34: your reply codes. SMTP doesn't do this, and I can't think of
35: why you do it. Am I missing something?
36:
37: As far as variable length messages go, there are two possibilities:
38: The one I am using currently is the
39:
40: xxx-Start of text, look out /* assumed to be one line */
41: xxx-blah blah
42: xxx-blah blah
43: xxx-blah blah
44: xxx-blah blah
45: xxx end of text (no dash)
46:
47: I don't really like this, since it means we strip off four characters per
48: line, which slows things down that much.
49:
50: The second possibility is that we say
51:
52: xxx-Start of text, look out /* again, a one liner */
53: Text goes
54: here,
55: with a period on a
56: line by itself, just
57: like SMTP.
58: .
59: xxx End of text /* Maybe we don't need this message */
60:
61: As usual, any line in the message which starts with a period we
62: simply duplicate -- that it, we put an extra period in front,
63: and then the client strips it off. If there is only one period,
64: it must be EOF.
65:
66: How say you to this?
67:
68: > Commands consist of an UPPERCASE command word, some of
69: > which are followed by parameters. All input is in ASCII,
70: > terminated in CR-LF.
71:
72: Very much agreed, especially the CF-LF stuff. It's fairly
73: trivial to accept lower case, I think you already have hacked
74: your daemon to do this. But the std should probably call for
75: upper case.
76:
77: > BODY No parameters. Displays the body (text) of the
78: > current article.
79:
80: Same here, except we differ on arguments. All of my commands
81: like BODY, HEADER, etc. require an article number as an argument.
82: I think this is better because it's more what readnews/rn will
83: want: They have an "open article" function, with a numeric
84: argument. I don't think we need the "next" function, since it
85: hides the article numbers from the client, and the client, if
86: it is an existing program, will want to worry about article numbers.
87:
88: > GET nnn (nnn) is the numeric id of an article in the
89: > current newsgroup. It must be chosen from the
90: > range of articles provided when the newsgroup was
91: > selected.
92:
93: This is my "ARTICLE" command.
94:
95: > GROUP ggg (ggg) is the name of the newsgroup to be selected.
96:
97: Same here.
98:
99: > HEAD No parameters. Displays the header lines of the
100: > current article.
101:
102: Same here, but with parameters.
103:
104: > LAST No parameters. Backs up to the previous article
105: > in the current newsgroup. If already positioned
106: > at the beginning of the newsgroup, an error
107: > results.
108:
109: No equivalent here. Do we need this? Again, rn/readnews will
110: take care of this internally.
111:
112: > NEXT No parameters. Advances to the next article in
113: > the current newsgroup. If no more articles remain
114: > in the current group, an error results.
115:
116: Same comment as for LAST.
117:
118: > QUIT No parameters. The server process exits and
119: > closes the connection to the client.
120:
121: Great minds think alike.
122:
123: Some commands I didn't see in yours:
124:
125: ACTIVE - transmit the active file in normal format. By normal,
126: I mean normal, 4.2 UNIX active file format.
127:
128: POST - User sends an article, followed by a period on a line
129: by itself. This is passed to inews, which deals with
130: it. After inews has dealt with it, daemon returns
131: a reply code.
132:
133: NEWSINCE "date" List the new articles, since "date", where
134: date is a long integer containing the number of seconds
135: since Jan 1, 1970. Should this be GMT?
136:
137: BOUNDS - Show high and low message number in current newsgroup.
138: You provide this with your "GROUP" command, and I should
139: too.
140:
141: > Responses are of two kinds. Command/status responses
142: > are distinguished by having a single period (.) as the first
143: > character of the line. Text lines have no period, or if the
144: > text contained a period in the original, that period is dou-
145: > bled. The intention is that text messages will be displayed
146: > directly on the user's terminal (or processed through
147: > 'more'), whereas command/status responses will be inter-
148: > preted by the client program before any possible display is
149: > done.
150:
151: As I said above, I move we go to this sort of thing, but
152: have a single period, so as to be like SMTP. I love conformity.
153:
154: > Response codes are returned in a command/status return
155: > line (i.e., they are prefixed with a period). These are
156: > status reports or command responses from the daemon and
157: > indicate the response to the last command received from the
158: > client.
159:
160: You have your status messages much more thought out than I
161: do, since I sort of assigned them randomly/sequentially.
162: Also, has it been your experience that only 200/500 series gets used?
163:
164: > 1xx Informative messages - no significance except to
165: > humans. Probably these should be displayed to the
166: > user.
167: >
168: > 2xx Last command was ok and is being performed. Mostly
169: > just indicate that you asked the daemon to do something
170: > reasonable and it did it.
171: >
172: > 3xx Continue with the command. (used on commands that
173: > expect to receive more data) You should then send the
174: > rest of the data.
175: >
176: > 4xx Couldn't do your last command. Perhaps you simply
177: > specified a non-existing article or something.
178: >
179: > 5xx Couldn't do your last command. Serious error - the
180: > command was invalid, or was missing parameters, or the
181: > daemon program faulted. This means that something was
182: > wrong enough with your command that current status is
183: > in doubt. Perhaps one or more pointers has been
184: > changed. Don't proceed until you have re-established
185: > the environment (newgroup/article selection). (An
186: > exception is the "500 bad command" response - your
187: > entire command was flushed and ignored.)
188: >
189: > The next digit in the code indicates the function response
190: > category.
191: >
192: > x0x Client setup and miscellaneous messages
193: >
194: > x1x Newsgroup selection
195: >
196: > x2x Article selection
197: >
198: > x3x Article display
199: >
200: > x4x <reserved>
201: >
202: > x5x Posting
203: >
204: >
205: >
206: > The following response codes are to be expected.
207:
208: Following SMTP, it should be possible to write a "dumb" client which
209: doesn't look for a "211", but rather, a "2" in response to a
210: "GROUP" command, and it knows what order the arguments are in.
211:
212: > 200 news server ready
213: > 201 news server closing connection
214: > 211 %d %d %d %s
215: > (number of articles in group,
216: > first article number in the group,
217: > last article number in the group,
218: > name of the group.
219: > 215 active start
220: > 216 active end
221: > 221 %d %d %d %d %s article retrieved
222: > (article number,
223: > first article number in the group,
224: > last article number in the group,
225: > unique article id (usually the inode number)
226: > 230 head start
227: > 231 head end
228: > 235 body start
229: > 236 body end
230: > 250 article posted ok
231: > 354 send article to be posted. End with <CRLF>.<CRLF>
232: > 411 no such news group
233: > 412 empty newsgroup
234: > 413 more than MAXART articles; others suppressed
235: > 415 no active file
236: > 421 No next article in this group
237: > 422 No previous article in this group
238: > 422 no such article number in this group
239: > 431 no file
240: > 432 no file
241: > 500 bad command
242: > 521 article file missing
243: > 522 article file missing - unable to stat
244: > 550 can't start inews for posting
245: >
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.