ietf-nntp Section 7.1 - GREETING step.

David Riley David.Riley at software.com
Mon Jul 24 17:18:24 PDT 2000


On Mon, Jul 24, 2000 at 03:28:25PM -0700, Russ Allbery wrote:
> David Riley <David.Riley at software.com> writes:
> 
> > My point is that if the server will support IHAVE or POST, it should
> > respond with a 200.  Currently, it seems that a transit server which
> > does not support POST should respond with 201.
> 
> This isn't existing practice in INN; I'm not sure what other systems do
> here.  (Looking at some of the other feed-only systems like NNTPRelay or
> Cyclone may be enlightening; I don't have any handy to check at the
> moment.)

Cyclone, Diablo, NNTPRelay, INN -- in the past, and Earthquake all respond
with a 200, if IHAVE is available, even if POST is not available.  

> > I believe that such transit server should be able to respond with 200.
> 
> Bear in mind that when you split transit from reader, one of the points is
> that the transit side doesn't need to know about all the stuff the reader
> side has to figure out.  In particular, innd has no idea what access nnrpd
> will allow for a given connection, and has no ability to parse nnrpd's
> access files.

Also, it might not be known until the user authenticates whether or not
they will have access to do either.

I still believe that the server should respond with a 200 on connect if the
remote client is able to either IHAVE or POST.  I'd be willing to expand
that to if the remote client might be able to either IHAVE or POST.  (In
which case, further information will be made available with the MODE
READER.)

-- 
David Riley
David.Riley at software.com - Software.com, Inc. (Vancouver, B.C.)



More information about the ietf-nntp mailing list