ietf-nntp Section 7.1 - GREETING step.

[Brian Kantor]

>> No, I think this is seriously flawed.  If a server returns a 200
>> but a subsequent POST fails, you've screwed the client.
>
>Why ? A POST can always fail.

Yes, but in nearly all other cases the problem that caused the failure
is temporary (eg, no space on disk) or is the fault of and correctable
by the person submitting the post (eg, misspelled newsgroup name).

A POST which failed because the client is not allowed to post is not
something that can be remedied by the poster, isn't going to get better
by itself, and I believe it violates the principle of least astonishment.

>> 201 indicates
>> ONLY the usability of the POST command.
>That's the question that we're trying to resolve.

Unless you redesign the protocol, 201 only indicates the usability of
the POST command.

NB: Using IHAVE from a read/post client to inject articles IS a
redesign of the protocol.  In RFC977, IHAVE is only for transport peers.
If it is currently being used by a read/post client, I believe it to be
within the current document's charter, and we should document it so.

However, from what I recall of the discussions here, it is NOT currently
being used this way, but some wish it to be, as a means of circumventing
the difficulty of arranging individual transfer permission from an ISP.

I have trouble with redesigning a protocol to make up for ISP management
difficulties.

I would instead say that the more correct thing to do is to enhance the
security model so that an ISP can give transfer permission to its clients
(eg, home linux systems) in some blanket way, thus eliminating the
problem of having to make individual site/customer negotiations, which
seems to be the root of the problem.  Such an enhanced security
implementation mechanism IS NOT A PROTOCOL ISSUE, and I do not believe
this WG should really be much concerned with it.
	- Brian