Re: ietf-nntp Comments on the draft

"chris (c.) lewis" <clewis@nortel.ca> Thu, 03 October 1996 20:38 UTC

Received: from cnri by ietf.org id aa22104; 3 Oct 96 16:38 EDT
Received: from PHEASANT.ACADEM.COM by CNRI.Reston.VA.US id aa21943; 3 Oct 96 16:38 EDT
Received: (from majordom@localhost) by pheasant.ACADEM.COM (8.7.5/8.7.3) id PAA28531 for ietf-nntp-outgoing; Thu, 3 Oct 1996 15:36:54 -0500
X-Authentication-Warning: pheasant.ACADEM.COM: majordom set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by pheasant.ACADEM.COM (8.7.5/8.7.3) with ESMTP id PAA28526 for <ietf-nntp@PHEASANT.ACADEM.COM>; Thu, 3 Oct 1996 15:36:52 -0500
Received: from bnr.ca (x400gate.nortel.ca [192.58.194.73]) by academ.com (8.7.6/8.7.1) with SMTP id PAA20723 for <ietf-nntp@academ.com>; Thu, 3 Oct 1996 15:36:47 -0500 (CDT)
X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 3 Oct 1996 12:13:12 -0400
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 3 Oct 1996 12:12:42 -0400
X400-Received: by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed; Thu, 3 Oct 1996 12:12:41 -0400
Date: Thu, 3 Oct 1996 16:12:41 +0000
X400-Originator: /dd.id=psd52384/g=usenet/i=u/s=support/@bnr.ca
X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; <530olp$gek@bcarh8ab.bnr.ca>]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: ietf-nntp...
From: "chris (c.) lewis" <clewis@nortel.ca>
Message-ID: <530olp$gek@bcarh8ab.bnr.ca>
To: ietf-nntp@academ.com
References: <19961002215416.AAA16973@bpolk.mcom.com>
Subject: Re: ietf-nntp Comments on the draft
Path: not-for-mail
Newsgroups: nortel.list.ietf.nntp
Organization: Nortel
Lines: 47
Nntp-Posting-Host: bcarhbc0.bnr.ca
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

Re: AUTHINFO GENERIC

There is a conflict between the implementations and the specifications
for return codes.  After going through INN 1.4, I'm confused too... ;-)

The comments I'm making are on the implementations of GENERIC I've
seen (rather, implemented myself).  Specifically: INN1.4sec2,
INN1.4unoff2-4, NNTP 1.5.11tx, 1.5.12.

Things may be different in INN1.5 - I haven't looked yet.

Historically, servers have been responding with either 350 or 480
for authentication being required.  So, the phrases that refer to
"350" should probably say "350 or 480".  INN 1.4, in particular, returns
480 (for AUTHINFO USER/PASS too), and doesn't seem to know how to emit
a 350.  As I recall, I made 1.5.12 do the same thing.

The existing implementations respond with code 281 for authentication
accepted, and 502 for authentication rejected (only).

9.1.2.1 should list 503, not 502 for "authenticator not found or unspecified
server error".

This is what is currently implemented in all of the versions I've seen:

        500     If "authinfo" is an unknown command
        501     If only "authinfo user/pass" is supported.
        501     If a detectable error was found in the command
                (eg: ../ in authenticator, no parameters after
                "authinfo generic" etc.)
        502     authentication failed
        281     authentication succeeded
        503     If authenticator could not be invoked (missing,
                fork failed etc.  Try authentication again.)
	nnn	authenticator-specific protocol

In the draft, 350, 250 and 452 seem to have been taken from AUTHINFO SIMPLE,
whereas USER/PASS and GENERIC implementation in INN1.4unoff and NNTP 1.5.12
seems to use 480, 281 and 502 (if I recall correctly).

I don't have druthers other than the complications of fixing current
implementations.
-- 
"I can't stand this proliferation of paperwork.  It's useless to fight 
the forms.  You've got to kill the people producing them."
-- Vladimir Kabaidze, 64, General Director of Ivanovo Machine Building Works