ietf-nntp Section 7.1 - GREETING step.

[Brian Kantor]

My original intention with the 200 or 201 greeting herald was to indicate
to a reader process whether it had or had not permission to post.

We did the 201 solely so that a client attempting to post would not find
out the hard way (after time had been spent composing a message) that
posting was not permitted.  (Remember that at that time most of the
popular newsreaders did not invoke an editor to compose the message,
so recovery from a failed posting was annoyingly difficult.)  It had
no other meaning, especially NONE with regard to transport peers, and
none should be inferred.

Practice has shown this to be far too coarse a granularity, so were I
able to revisit that part of the spec, I would eliminate the 201 code
entirely, and use the 200 code only to indicate the connection readiness.
Some other mechanism would have to indicate privilege levels.

Recall also that at that time all determination of privilege was
done at connection acceptance time by looking up the address of the
connecting host (client or peer), so there was no way for the privilege
level to change during a connection.

Nowadays I would advise anyone designing a peer or client to treat both
200 and 201 the same and to determine transfer, reading, and posting
permissions in some other manner.

This is one of those areas in which RFC977 is not just deficient, but
actually WRONG.  I hope we will not perpetuate this error.
	- Brian